artem
18.12.2012
8698

Некорректный SDP в Re-Invite

Подключая одного оператора к IP-АТС Asterisk довелось столкнуться со странной проблемой. При исходящем звонке устанавливалось нормальное голосовое соединение и начинался разговор. По прошествии ровно 5 минут 18 секунд происходило странное: возникала односторонняя слышимость, т.е. один голосовой канал отваливался. При этом проблема воспроизводилась из раза в раз и решить её никак не получалось.

Оба сервера (станция Asterisk и провайдер) находятся на внешних реальных IP-адресах. В логах Asterisk не сообщалось ничего криминального.

Полный tcpdump предоставил следующую информацию:

После установки голосового соединения трафик нормальным образом идет между станциями. На 5-й минуте трафик расщепляется и начинает отправлятсья Asterisk-ом на один IP, а приниматься с другого. Причиной этому являлся Re-Invite пакет, который предлагал перейти на новый медиа-сервер.

Телефонное ядро провайдера построено на ферме SIP-серверов, с сервеом регистрации и медиа-серверами. Сервер регистрации управляя сессией может переключать звонки на менее загруженные сервера, и все это в рамках установленного голосового соединения.

Из дампа стало понятно, что на 5-й минуте сервер регистрации присылает SDP-заголовок с указанием нового медиа-сервера, на что сервер Asterisk отвечает пакетом 200 — OK. Но если провайдер переходит на новый IP и начинает слать с него RTP-трафик, то Asterisk продолжает слать RTP-трафик на прежний сервер, как будто бы и не было никакого SDP-заголовка.

Возникло предположение, что Asterisk некорректно обрабаытвает SDP, либо не умеет переключать медиа-сессию для установленного разговора. Для ответа на этот вопрос вместо Asterisk был установлен PAP2T адаптер, который мы подключили к серверу оператора. Тест, аналогичный прежним, а именно звонок длительностью более 5-ти минут, прошел успешно: голос не оборвался, а переключение на новый медиа-сервер произошло успешно.

Такая информация дала понять, что Asterisk некорректно обрабатывает определенные SDP-заголовки. Но долгие поиски решения натолкнули на мысль, что могут быть виноваты обе стороны: оператор присылает не совсем точный SDP-заголовок, а Asterisk, понимая эту некорректность, отвечает статусом 200 — OK, как будто бы запрос правильный.

Решением проблемы оказалась установка параметра ignoresdpversion=yes, который позволяет менее педантично подходить к анализу SDP-заголовка. После установки этого параметра проблема устранилась. Переключение на новый медиа-сервер Asterisk теперь производит корректно.

Проблема воспроизводилась на версиях Asterisk 1.8.5.0, Asterisk 1.6.0.28

 
avatar
  Подписаться  
Уведомление о

Остались вопросы?

Я - Кондрашин Игорь, менеджер компании Voxlink. Хотите уточнить детали или готовы оставить заявку? Укажите номер телефона, я перезвоню в течение 3-х секунд.

VoIP оборудование

ближайшие курсы

ближайшие Вебинары

ONLINE

Why Choose HUGE?

Unlimited pre-designed elements

Each and every design element is designed for retina ready display on all kind of devices

User friendly interface and design

Each and every design element is designed for retina ready display on all kind of devices

100% editable layered PSD files

Each and every design element is designed for retina ready display on all kind of devices

Created using shape layers

Each and every design element is designed for retina ready display on all kind of devices