четверг, 17 июля 2008 г.

Разработчик, возлюби RFC

Когда вам попадается в руки инструмент, который очень любит стандарты, вы имеете множество шансов найти глюки в разных программах, авторы которых не так свято чтят разнообразные RFC. С другой стороны если не чтить RFC, то как вообще можно гарантировать работу чего либо от разных производителей?

Глюки обнаружились при переходе на FreeSWITCH.
1. Телефоны Linksys SPA901 и SPA921 неправильно называют кодек g729 в SDP (Session Description Protocol). Для того чтобы поправить это, вам нужно зайти на web интерфейс телефона, переключить в режим Admin+Advanced. Далее на вкладке "SIP" в разделе "SDP Payload Types" ищем пункт "G729a Codec Name:" и приводим к виду "g729", то есть убираем "a" на конце.

2. Вообще в интернете не встречал упоминания, но шлюзы Addpac AP1005 (4xFXO) также страдают забавным глюком - они отдают странный SDP при связи друг с другом: a=rtpmap:18 G729/8000/3

Так как FreeSWITCH свято чтит RFC и документ, который будет указан ниже (а быть может эта любовь от SIP стека Sofia, производства компании Nokia), то он прекрасно знает, что rtpmap с номером 18 может означать только G729/8000/1 Никаких "a" или трех звуковых каналов, что вообще забавно смотрится - 3 канала на моно голос это явный перебор.

Излечить шлюзы удалось только путем двухнедельного общения с техподдержкой Addpac - дали все таки какой то вариант прошивки, по словам инженера просто убрали вообще всякие упоминания числа каналов. И правильно - не можете правильно указывать, лучше вообще не указывать, что вполне соответствует RFC.

В остальном телефоны и шлюзы впечатление оставляют самое приятное - телефоны работают как от них ожидается, шлюзы Addpac чудесно гибкие в настройке. Но все же - чем им так не угодили RFC?

Как я подозреваю, большинство реализаций смотрит только на номер rtpmap, и ничуть не заботится разбором последующих конструкций. А вот это зря - например кодеки g726-xx статического номера не имеют, а шлюзы Addpac для g726-16 другой номер, кроме как 116, не воспринимают. Это противоречит RFC и этому документу.

Вот думаю, мучать техподдержку дальше или плюнуть - все таки когда знаешь подводные камни, то знаешь и как их обходить.

На этом внеочередное заседание любителей RFC объявляю закрытым.

4 комментария:

Анонимный комментирует...

На самом деле главное правило VoIP разработчика (а может и вообще любого разработчика) - на входе постарайся понимать любой диалект, на выходе говори по стандарту. Результат в таком случае получается наилучший. Патрушев Антон. Разработчик Naumen Phone.

Deepwalker комментирует...

На правах рекламы : )

Попробую выяснить у разработчиков FS их точку зрения, быть может эта мысль им тоже покажется здравой.
Мне кажется, что смотреть на все после номера payload не имеет особого смысла, если номер меньше 97, но видимо таким образом они пытаются защитится от ошибок неверного определения.

Анонимный комментирует...

Можно сказать и так (я про рекламу). Хотя общий смысл бы в том чтобы объяснить свою позицию и показать что она где-то используется/работает. ;)

Если же по существу говорить, то мы используем подобные "финты" стороннего оборудования в том числе для того, чтобы определить кто стоит на другой стороне. Иногда помогает добиваться совместимости в совсем уж клинических случаях.

Deepwalker комментирует...

Кстати Pingtel'овский SipX тоже вполне почти все глюки скрывал (только вот CSeq на AP100 терялся, пришлось в коде его проверку оторвать).

И вы и они делаете коммерческие продукты, отсюда и возня с ошибками вендоров железячных VoIP решений.

Но ситуация, как мне кажется, с корректной поддержкой стандартов вендорами все таки улучшается со временем.

Надеюсь как нибудь познакомиться с вашим продуктом, реклама подействовала : )