[May 14 14:16:15] WARNING[31798]: chan_sip.c:8749 process_sdp_c: Unable to lookup
RTP Audio host in c= line, 'IN IP4 8000'
[May 14 14:16:15] WARNING[31798]: chan_sip.c:8397 process_sdp: Insufficient information
in SDP (c=)...

Дело в том, что Zoiper нарушает RFC4566 – SDP: Session Description Protocol. Согласно этому документу, параметр SDP ‘c=’ должен быть использован для указания адреса соединения:

5.7.  Connection Data ("c=")

      c=<nettype> <addrtype> <connection-address>

   The "c=" field contains connection data.

   A session description MUST contain either at least one "c=" field in
   each media description or a single "c=" field at the session level.
   It MAY contain a single session-level "c=" field and additional "c="
   field(s) per media description, in which case the per-media values
   override the session-level settings for the respective media.

   The first sub-field ("<nettype>") is the network type, which is a
   text string giving the type of network.  Initially, "IN" is defined
   to have the meaning "Internet", but other values MAY be registered in
   the future (see Section 8).

   The second sub-field ("<addrtype>") is the address type.  This allows
   SDP to be used for sessions that are not IP based.  This memo only
   defines IP4 and IP6, but other values MAY be registered in the future
   (see Section 8).

   The third sub-field ("<connection-address>") is the connection
   address.  OPTIONAL sub-fields MAY be added after the connection
   address depending on the value of the <addrtype> field.

   ...

В действительности же Zoiper пытается в поле ‘c=’ указать порт, не смотря на то, что он уже указан в поле ‘m=’:

s=Zoiper_session
c=IN IP4 8000
t=0 0
m=image 8000 udptl t38

а вот Linksys SPA2102 (прошивка 5.1.12) заполняет все поля корректно:

s=-
c=IN IP4 10.10.10.201
t=0 0
m=image 16474 udptl t38

Zoiper заполняет неверно поле ‘c=’ только для сообщения re-INVITE, которое должно запустить t38 сессию. Сообщение INVITE, инициирующее голосовое соединение, составляется корректно:

s=Zoiper_session
c=IN IP4 10.10.10.202
t=0 0
m=audio 8000 RTP/AVP 8 3 101

Самое интересное заключается в том, что Asterisk 1.6.0 отлично передавал факсы отправленные с помощью Zoiper, не смотря на нарушение RFC. Вероятно Asterisk стал чувствительным к ошибке, после внедрения нового алгоритма обработки SDP Asterisk 1.6.2 revision 227760.

Лично для меня, сегодня существует 3 ключевые проблемы в ветке 1.6.0 (срез за декабрь 2009 – февраль 2010), не позволяющие использовать её промышленно.

• Issue #16608 – Под большой нагрузкой (~150) звонков, Asterisk лочится. Подобное поведение, на мой взгляд, худшая из возможных проблем. Вылавливать подобные ошибки гораздо сложнее сегфолтов, кроме того, их невозможно моментально обнаружить, по этому клиенты испытывают перерывы связи до пары минут.
• Несовместимость T.38 с Mera. Во второй половине 2009 года, над стеком T.38 в Asterisk была проделана большая работа, направленная на повышение совместимости, однако результат, на мой взгляд, оказался противоположным. Возможно, виновата сама Mera, т.к. она не шлёт заголовок T38MaxBitRate, тем не менее эта же Mera (Mera DAMOS 1.3.2.20 – 1.3.2.40) Корректно работает со срезом Asterisk 1.6.0 за февраль – апрель 2009 года.
• Сегфолты на некоторых факсах. Происходят не часто – пару раз в неделю при большой нагрузке. Вероятней всего сегфолты, это ещё одно следствие перетрубаций со стеком T.38.

Таким образом, текущий срез ветки 1.6.0 серьёзно уступает транку времён Asterisk 1.4, тогда можно было смело брать trunk для production. Сейчас надо очень тщательно выбирать даже из версий ветки 1.6.0, что уж говорить про 1.6.1 и 1.6.2. Судя по всему, понимают сложившуюся ситуацию и в Digium, недавно было объявлено, об очередном изменении политики релизов. Но об этом в следующей заметке :)

SIP/2.0 420 Bad Extension
Via: SIP/2.0/UDP 10.10.10.207:5060;branch=z9hG4bK514b3ee2;rport
From: <SIP:1000@10.10.10.207>;tag=as6951d52f
To: <SIP:1010@10.10.10.220>;tag=67D56388-98E
Call-ID: B51F13DD-FDDA11DE-8C59D5E5-5043F4E7@10.10.10.220
CSeq: 102 INVITE
Unsupported: timer
Content-Length: 0

Cisco ругается, на присутствие в ReINVITE заголовка «Require: timer». Лечится это, добавлением параметра:

session-timers=refuse

в файл SIP.conf. Эта директива отключает поддержку таймеров SIP- сессий (RFC 4028).

Дело в том, что в режиме session-timers=accept (по умолчанию), Asterisk работает с таймерми в том случае, если клиент поддерживает их. Asterisk считает, что клиент поддерживает таймеры, если в сообщении INVITE от клиента имеется заголовок Session-Expires или если если клиент ответил 200 OK на INVITE пришедший от Asterisk, который содержал заголовок Session-Expires. Cisco (AS5350 IOS 12.3(3b)) не поддерживает таймеры, но и не отклоняет первоначальный INVITE от Asterisk – отсюда между устройствами возникает недопонимание.

Подробно описывается развитие, от первой реализации T.38 passthrough только для SIP каналов, до текущей, полноценной поддержки факсов: теперь Asterisk может не только передавать факсы между абонентами, но и самостоятельно принимать и отправлять их с помощью T.38. Во время работы над этим функционалом, возникло большое количество проблем в совместимости различных реализаций T.38. Вот что пишет на этот счёт Кевин:

In addition, the T.38 negotiation process was redesigned to allow Asterisk applications to actually be T.38 endpoints; this resulted in the ability to send and receive FAX over audio *and* T.38 links.

Once this got into the community’s hands, we started seeing large numbers of bug reports because users could not successfully FAX over T.38 with various ATAs and service providers. I won’t go into the gory details of why this was the case, except to repeat a recent quote from Steve himself on IRC: “The T.38 spec was written after a night of heavy drinking as a joke.”. While that’s not technically true, it is true that compliance with the T.38 recommendation, primarily in the SIP/SDP negotiations area, is very poor across the industry. Producing a T.38 endpoint that interoperates widely is a complex and difficult process, that can only be achieved through hours and hours (and hours) of testing.

Теперь о планах на будущее. Следующий релиз Asterisk будет носить номер 1.8. К моменту выхода 1.8 app_fax будет разделен на 2 части: res_fax и res_fax_spandsp. Модуль res_fax будет содержать приложения для диалплана и функции для согласования параметров T.38 сессии. Второй модуль – res_fax_spandsp обеспечивает непосредственно работу с факсом (T.30). В данном случае это обертка для библиотеки spandsp. Такое решение обусловлено тем, что Digium с одной стороны стремится оставить открытой максимальную часть кода, а с другой стороны предоставляет коммерческое решение для факсов. Т.е. весь проприетарный код вынесен в отдельный субмодуль – res_fax_digium. Этот модуль и есть коммерческое Fax for Asterisk.

С выходом версии 1.8 начнётся работа над FAX relay – механизмом способным преобразовывать T.38 в G711 и обратно. Предположительно, FAX relay будет реализован с помощью нового API в res_fax.

• State of FAX (primarily T.38) in Asterisk trunk (planning for 1.8 release)