Comments 24
Было бы круто собрать это в виде самодостаточной библиотеки и выложить куда-нибудь на Github.
Для «собрать библиотеку» надо слишком много кода и дебага.
SIP сложен и многогранен, RTP тоже в подарок пошлёт пару ведер.
Судя по тексту, автору досталась еще не самая плохая ситуация :)
Было бы INBOUND DTMF + экзотический кодек…
А автор молодец! Вполне корректно решенная (в данных ограничениях) задача.
SIP сложен и многогранен, RTP тоже в подарок пошлёт пару ведер.
Судя по тексту, автору досталась еще не самая плохая ситуация :)
Было бы INBOUND DTMF + экзотический кодек…
А автор молодец! Вполне корректно решенная (в данных ограничениях) задача.
да, я согласна с предыдущим оратором. целью поста было предоставить какую-то общую информацию о том, как парсировать ответ сервера, чем можно пренебречь при составлении пакетов и что важно, как раз минуя описание частностей.
Один из частных случаев их применения — (около)медицинское учреждение, расположенное в железо-бетонном здании, глушащем WiFi и сигнал мобильного телефона.
В сериале «Доктор Хаус» врачи тоже сообщения на пейджер получали, интересно, не там ли была подсмотрена идея :)
Как напечатать сообщение для голубиной почты азбукой Морзе с помощью Arduino. (А вообще решение хорошее.)
Я конечно извиняюсь что вмешиваюсь, но вроде бы как давным давно подобные проблемы решают применением FemtoCell — даже в РФ их ставит как минимум МТС и Мегафон. Для работы требуется только наличие интернета, с провайдером поднимается туннель (обычно IPSEC) и в помещениях появляется связь на обычных сотовых.
en.wikipedia.org/wiki/Femtocell
en.wikipedia.org/wiki/Femtocell
Большинство пейджинговых компаний предоставляют Email гейтвеи для своих клиентов. Просто шлёте емейл на номер@компания.ру и всех делов…
Интересно долго еще ананиз#ом будут заниматься с Java в задачах где очевидным решением является использование C/C++?
Вы уж простите, а что если у Вас случиться GC Collect в момент отправки RTP? А если RE-INVITE? А сколько кодеков Вы уже поддерживаете?
ИМХО на Хабре можно найти огромное количество решений на коленке. Если нужно обращайтесь прикомпилю к вашей Java какой-то BareSIP или типо того, а то тошно смотреть на это извращение…
Вы уж простите, а что если у Вас случиться GC Collect в момент отправки RTP? А если RE-INVITE? А сколько кодеков Вы уже поддерживаете?
ИМХО на Хабре можно найти огромное количество решений на коленке. Если нужно обращайтесь прикомпилю к вашей Java какой-то BareSIP или типо того, а то тошно смотреть на это извращение…
Действительно, сколько надо кодеков, чтобы отправить короткую тоновую последовательность?
И что делать, если вдруг случилась сборка мусора — не может же получатель принять ее всего лишь за обычный сетевой лаг?
И что делать, если вдруг случилась сборка мусора — не может же получатель принять ее всего лишь за обычный сетевой лаг?
А с кодеками дело обстоит несколько сложно, так как некоторые провайдеры сегодня используют только G.729,
но на имплементацию которого на Java я бы с удовольствием взглянул. И Вас могут(!) просто не соединить с
указанным PBX сервером вообще. То есть решение частное и ненадежное! Понятное дело, что статья не о реальной
имплементации телефонии, а о какой-то игре с пейджером, но тут дело в подходе.
Я, к сожалению, не знаю сколько может продолжаться лаг, но если например он займет больше чем 200 мс., то
слушать такой лаг уже будет плохо, а сервер PBX и совсем может DTMF разбить на два.
Вообщем на мой взгляд применение в этом случае здесь Java неоправдано.
P.S. Я хотел бы выслушать мнения всех минусующих здесь иначе буду считать и требовать отказаться от вашего мнения и вернуть карму на место! Я за обоснованный спор…
но на имплементацию которого на Java я бы с удовольствием взглянул. И Вас могут(!) просто не соединить с
указанным PBX сервером вообще. То есть решение частное и ненадежное! Понятное дело, что статья не о реальной
имплементации телефонии, а о какой-то игре с пейджером, но тут дело в подходе.
Я, к сожалению, не знаю сколько может продолжаться лаг, но если например он займет больше чем 200 мс., то
слушать такой лаг уже будет плохо, а сервер PBX и совсем может DTMF разбить на два.
Вообщем на мой взгляд применение в этом случае здесь Java неоправдано.
P.S. Я хотел бы выслушать мнения всех минусующих здесь иначе буду считать и требовать отказаться от вашего мнения и вернуть карму на место! Я за обоснованный спор…
У автора была конкретная задача — и она решена. При чем тут абстрактный «подход»?
Если получившаяся программа — десктопная утилита, то память у нее просто не успеет закончиться, и все проблемы неактуальны. А если это — веб-приложение, то можно сборку мусора запустить перед отправкой сообщения. Да и я точно так же могу возмутиться самим подходом к реализации HTTP-сервера на плюсах: всем же очевидно, что плюсы — не для веба, как бы не пытались казаться универсальным языком.
PS всех считать и требовать будете в другом месте. Поставил минус в карму только из-за этого требования.
Если получившаяся программа — десктопная утилита, то память у нее просто не успеет закончиться, и все проблемы неактуальны. А если это — веб-приложение, то можно сборку мусора запустить перед отправкой сообщения. Да и я точно так же могу возмутиться самим подходом к реализации HTTP-сервера на плюсах: всем же очевидно, что плюсы — не для веба, как бы не пытались казаться универсальным языком.
PS всех считать и требовать будете в другом месте. Поставил минус в карму только из-за этого требования.
> У автора была конкретная задача — и она решена. При чем тут абстрактный «подход»?
Не реализован полностью протокол SIP, который используется в этом решении. А значит и решение при различных условиях
может оказаться не надежным. Речь идет о надежности подхода и использовании целевого инструмента.
Считаю, что решения вроде такого можно выкидывать на помойку еще до публикации на habrahabr.
> Да и я точно так же могу возмутиться самим подходом к реализации HTTP-сервера на плюсах: всем же очевидно, что плюсы — не для веба, как бы не пытались казаться универсальным языком.
Обоснуйте свое мнение. Первое речь идет о SIP протоколе телефонии Вы уверены, что прочитали тему внимательно? Второе о универсальности C/C++ я не говорил, а говорил о более подходящем решении на более подходящем языке для конкретной задачи. Вы дважды ошиблись и принесли мне незаслуженный минус. revoke please or defend your position…
> всех считать и требовать будете в другом месте. Поставил минус в карму только из-за этого требования.
Таким образом Вы признаете, что ваш минус основан на предвзятом отношении и никаким образом не относиться к техническому вопросу обсуждаемому тут. Таким образом можно сделать несколько выводов:
1. Вы заложник своих чувств (обычно заложники чувст девушки и женьщины);
2. От Вас комментарий не по теме (аннулируйте пожалуйста и отвечайте по делу);
Не смотря на ваше предвзятое отношение и полное непонимание предмета разговора мне нравиться ваша позиция относительно защиты вашего мнения. Хотя на мой взгляд Вы не смогли доказать, так как ошиблись и спутали протоколы HTTP и SIP.
Так Вы за подход тяп-ляп и в продакшен я так понял.
Не реализован полностью протокол SIP, который используется в этом решении. А значит и решение при различных условиях
может оказаться не надежным. Речь идет о надежности подхода и использовании целевого инструмента.
Считаю, что решения вроде такого можно выкидывать на помойку еще до публикации на habrahabr.
> Да и я точно так же могу возмутиться самим подходом к реализации HTTP-сервера на плюсах: всем же очевидно, что плюсы — не для веба, как бы не пытались казаться универсальным языком.
Обоснуйте свое мнение. Первое речь идет о SIP протоколе телефонии Вы уверены, что прочитали тему внимательно? Второе о универсальности C/C++ я не говорил, а говорил о более подходящем решении на более подходящем языке для конкретной задачи. Вы дважды ошиблись и принесли мне незаслуженный минус. revoke please or defend your position…
> всех считать и требовать будете в другом месте. Поставил минус в карму только из-за этого требования.
Таким образом Вы признаете, что ваш минус основан на предвзятом отношении и никаким образом не относиться к техническому вопросу обсуждаемому тут. Таким образом можно сделать несколько выводов:
1. Вы заложник своих чувств (обычно заложники чувст девушки и женьщины);
2. От Вас комментарий не по теме (аннулируйте пожалуйста и отвечайте по делу);
Не смотря на ваше предвзятое отношение и полное непонимание предмета разговора мне нравиться ваша позиция относительно защиты вашего мнения. Хотя на мой взгляд Вы не смогли доказать, так как ошиблись и спутали протоколы HTTP и SIP.
Так Вы за подход тяп-ляп и в продакшен я так понял.
Не реализован полностью протокол SIP, который используется в этом решении. А значит и решение при различных условиях может оказаться не надежным.
О каких «других условиях» идет речь? Да, тут не обрабатывается, например, входящий звонок. Но его попросту невозможно обработать в рамках программы, отправляющей текстовое сообщение.
> Да и я точно так же могу возмутиться самим подходом к реализации HTTP-сервера на плюсах: всем же очевидно, что плюсы — не для веба, как бы не пытались казаться универсальным языком.А вы прочитали мое сообщение? Наверное, нет — тогда бы вы не спрашивали, откуда взялось HTTP.
Обоснуйте свое мнение. Первое речь идет о SIP протоколе телефонии Вы уверены, что прочитали тему внимательно?
> О каких «других условиях» идет речь?
1. Не произведено согласование кодеков. В конечном итоге должен быть выбран только один(!) кодек в формируемом RTP их изначально три. Возможно магия произойдет внутри какой-то фабрики, но… Кто в дальнейшем будет формировать данные?
2. Не идет отправки данных в RTP в указанном кодеке. Тут верно мысль у автора пошла, слать хотя бы нули, так как RTCP действительно разрывает соединение после того как решает, что удаленная сторона сидит за NAT.
Для Вас конечно это не важно, так как сервер постарается(!) максимально исправлять ошибки таких вот горе разработчиков.
> А вы прочитали мое сообщение? Наверное, нет — тогда бы вы не спрашивали, откуда взялось HTTP.
Да. Вы сменили предмет спора с SIP протокола на спор о HTTP подтвердив его аргументом «всем же очевидно».
Пожалуйста не меняйте тему на HTTP речь сейчас о том, что «изобретение трехколесного велосипеда на Java не оправдано, так как есть решение универсальное и протестированное выполненное на Си и имеющее достоинства перед показанной в статье имплементацией».
1. Не произведено согласование кодеков. В конечном итоге должен быть выбран только один(!) кодек в формируемом RTP их изначально три. Возможно магия произойдет внутри какой-то фабрики, но… Кто в дальнейшем будет формировать данные?
2. Не идет отправки данных в RTP в указанном кодеке. Тут верно мысль у автора пошла, слать хотя бы нули, так как RTCP действительно разрывает соединение после того как решает, что удаленная сторона сидит за NAT.
Для Вас конечно это не важно, так как сервер постарается(!) максимально исправлять ошибки таких вот горе разработчиков.
> А вы прочитали мое сообщение? Наверное, нет — тогда бы вы не спрашивали, откуда взялось HTTP.
Да. Вы сменили предмет спора с SIP протокола на спор о HTTP подтвердив его аргументом «всем же очевидно».
Пожалуйста не меняйте тему на HTTP речь сейчас о том, что «изобретение трехколесного велосипеда на Java не оправдано, так как есть решение универсальное и протестированное выполненное на Си и имеющее достоинства перед показанной в статье имплементацией».
Если получившаяся программа — десктопная утилита, то память у нее просто не успеет закончиться, и все проблемы неактуальны. А если это — веб-приложение, то можно сборку мусора запустить перед отправкой сообщения. Да и я точно так же могу возмутиться самим подходом к реализации HTTP-сервера на плюсах: всем же очевидно, что плюсы — не для веба, как бы не пытались казаться универсальным языком.Скажите, по какому протоколу работают веб-приложения?
И где вы тут нашли аргумент «всем же очевидно»?
На этом я спор заканчиваю, потому что теперь всем точно все очевидно.
а что если у Вас случиться GC Collect в момент отправки RTPНу и что же будет по-вашему?
Вы сталкивались когда-нибудь с «stop-the-world» при выполнении вашего приложения на Java из-за GC Collect?
Что-то я себе с трудом представляю как надо наговнокодить в такой задаче чтобы получить «stop-the-world» GC на 200мс.
Вы сталкивались когда-нибудь с «stop-the-world» при выполнении вашего приложения на Java из-за GC Collect?Ну, бывало всякое (не в таких примитивных приложениях, конечно), но вы на вопрос-то ответьте)
Потому как из ваших слов пока следует, что на java вообще ничего не нужно писать, особенно то, что использует сокеты и тому подобное.
Sign up to leave a comment.
Назад в 90-е или как отправить сообщение на пейджер через Java