183 Session Progress & 180 Ringing (PROGRESS & ALERTING)

[tma]

Господа,
Подкиньте ссылку, где говориться о правильной последовательности отправки 183 и 180 в SIP и PROGRESS и ALERTING в H323.
Пока обнаружилось, что в H323 недопустим порядок посылки PROGRESS после ALERTING'а.
Судя по: Q931 - Sending PROGRESS after sending ALERTING is a protocol error.

Терминаторы присылают либо только PROGRESS (IE8), либо PROGRESS, а затем ALERTING.

В SIP все с точностью наоборот, что меня очень удивляет -- нельзя (или нет смысла) посылать 180 после 183:
сслыка

When "RING" event is requested, always send 180 Ringing (if it hasn't been sent yet) followed by 183 Session Progress and in-band audio

и далее:

Once '183 Session Progress' is sent, it is not useful to send '180 Ringing' any longer... the 183 message informs the endpoint that future progress indications for this session will be provided inband via the audio stream. Most (if not all) SIP endpoints would ignore any 180 received after a 183 anyway.

Столкнулся с тем, что 180 после 183 нормально переваривает часть адаптеров и телефонов (Linksys и др.), но к примеру Fritz!Box тут же затыкается.
Т.е. как только получает 180, КПВ тут же прекращается. Иногда же КПВ вообще не успевает пройти, т.к. полная тишина (RTP бегает)... Т.е. не на всех устройвах это проявляется.

Нужны ссылки на RFC и прочую тех. документацию.
Заранее благодарю!

[tma]

а насчет SIP
http://www.packetizer.com/ipmc/sip/sip_call_flows.html

По этой ссылке они умудрились перепутать 183 Session Progress и 180 Ringing.

разве наоборот? помоему все прямо
...
тоесть ALERTING 180, PROGRESS 183

Да речь не об этом.
В ISDN (Q931) ну и в H323 запрещается посылать PROGRESS после ALERTING. Наоборот можно, что я и получаю частенько.
В случае с SIP нельзя посылать 180 Ringing после 183 Session Progress. А наоборот -- вполне себе нормально.
Т.е. последовательность разная у H323 и SIP, хотя авторы SIP особо ничего нового не изобретали и многое просто слизали из H323
сильно упростив (я имею ввиду логику).

[tma]

в SIP нет разницы какой первый 183 или 180, транзакция серверная и клиентская его должна обработать по любому
и обе они будут находится в состоянии Proceeding пока приходят 1xx ответы или генерируются 1xx ответы ядром SIP сервера или клиента

Разницы нет, но вот только КПВ пропадает, т.к. SDP игнорируется.

но даже если после 183 прийдет 180
транзакция его все равно будет обрабатывать и не завершится пока не прийдет 200 OK

Часть устройств при этом затыкаются и КПВ пропадает.
Так что разница есть и существенная. То, что допустимо с точки зрения протокола, недопустимо с точки зрения пользователя.
Вопрос в том, можно ли получив 183 игнорировать следующий далее 180 или нет.

[tma]

возможная причина разрыва не правильно реализовано ядро SIP

Разрыва нет. Все с этим Ok. Но нет КПВ. А сидеть и думать почему тишина -- это недопустимо.

что значит игнорировать?

Речь о конвертации из H323 в SIP.
Если тупо конвертировать PROGRESS в 183, а ALERTING в 180, то пропадает КПВ (при такой последовательности).
Я предлагаю игнорировать ALERTING после получения PROGRESS при конвертации протокола,
т.е. оставлять только 183.

Поэтому вопрос в том, допустимо ли наличие одного лишь 183 с SDP или же генерация фейкового 180, т.е.
смена порядка поступления ALERTING и PROGRESS при конвертации.

[tma]

у тебя же я так понимаю наоборот
183 с SDP
а потом идут 180 180 180

Да.

покажи кратко коллфлов на пальцах и что там с наличием SDP

Чуть позже выложу.

[tma]

Что за шрифт в квотинге? Нифига не видно. ;(

а как у тебя когда они шиворот на выворот идут,
я еще не нашел
но проскакивала информация что если сервер генерит такой порядок (183 180 180) то у него не правильно реализовано ядро

Там нет чередующихся 183 и 180.
Вначале идет PROGRESS, преобразуется в 183 Session Progress.
Затем идет ALERTING, преобразуется в 180 Ringing.
Затем ответ - идет OK.
Что шиворот навыворот я не понял.
180 и 183 идут с SDP.

Если приходит только 180 с SDP, то КПВ нет.
Softswitch не умеет генерировать КПВ сам -- он транзитный, далее OpenSER (Kamailio) стоит.

Если же от терминатора идет только PROGRESS, преобразуется в 183 Session Progress с SDP, то КПВ есть.

но финальный должен быть уже 200 OK
а предудущий в 200 OK должен быть 183 содержащий SDP

С OK все в порядке.

клиенту же получения 180 после 183 не должно никак влиять
он уже свой SDP RTP должен был получить

Влияет только тем, что пропадает КПВ. Со всем остальным все хорошо.
Причем иногда КПВ "проскакивает", видимо если ALERTING/Ringing задерживается.

не должен он отметать
он должен у себя переключать КПВ, тоесть при получения 180 переключатся на КПВ встроеный или на КПВ который в 180 SDP от оператора

Сам он тоже КПВ не генерирует и в SDP не берет. Может как раз этот SDP и мешает?..
Но RTP идет. Вполне вероятно что клиент кривой, хотя странно. Проблема обнаружена пока только с Fritz!Box.
Но данный девайс очень распространен в Германии. Было бы странно, если бы там была ошибка...
Вот и вожусь, блин...

Сценарий очень прост:
нет КПВ:
183 Session Progress
180 Ringing
OK

есть КПВ:
183 Session Progress
OK

P.S. Кстати некоторые устройства требуют именно "183 Session Progress". Если придет "183 Progress", то не будет КПВ.

[tma]

Есть еще вариант:

Есть КПВ:
180 Ringing
183 Session Progress
OK

[tma]

вообщем вывод такой
у тебя кривой клиент

Странно то, что этот клиент (Fritz!Box) используется половиной Германии и выпускается там.
Почему у них ни у кого не возникает такой проблемы?

В цепочке используется еще RTPProxy для проксирования RTP, но ни с одним клиентом больше нет проблем.
Исключить для теста не могу -- NAT.

[tma]

ps при этом ты не указал
все эти варианты ответов идут с одного ядра(совтсвича) или разные(может камильфо или еще какой шлюз)?

Тестировалось на 2х схемах:
I) Fritz!Box -SIP-> Kamailio with RTPProxy -SIP-> Softswitch -H323-> any terminator
В данном случае зависит от терминатора.
1. дает только Progress
2. дает
a) PROGRESS/Progress
b) ALERTING/Ringing + SDP
3. дает только Ringing + SDP

В случае 1 КПВ есть, в случае 2 и 3 КПВ нет.

II) Fritz!Box -SIP-> asterisk -SIP-> Kamailio -SIP-> Quintum Call Relay -H323-> Quintum CMS -ISDN-> PSTN
В данном случае идет:
180 Ringing
183 Session Progress

[tma]

видимо те запросы которые обрабатывает Fritz!Box однородны
а ты в него пытаешься 4 вида запросов отправить
в итоге не все правильно понимаются

Запросы посылает терминатор.
Я всего-навсего пытаюсь понять:
а) Какие он обрабатывает.
б) Почему он не понимает 180 after 183.

В случае "б" вопрос: так должно быть или нет? Linksys, ZyXEL, еще 1 адаптер, eyeBeam - с КПВ все Ok.

Также интересует: можно ли убрать 180 вообще если уже был 183 с SDP. Будет ли это нарушением и вызовет ли проблемы.