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)