3-d Party SIP Опции

[mikle]

Но в целом, на мой взгляд, было бы лучше, если бы в станции корейцы использовали более прозрачную процедуру для "задержанного вызова", которая описана в рекомендациях как Media Delayed Offer. В этом случае первое сообщение Invite вообще не содержит никакого SDP.

Вопрос - а все ли терминалы поддерживают Media Delayed Offer? Думаю не все... И может их число даже больше, чем тех, которые не отрабатывают нормально 65535 для RTP. Так что "хрен редьки не слаще"...

[mikle]

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

Мне тоже хочется понять логику вызываемой стороны. В приложенном файле трассировка пакетов 2-х вызовов
на KX-HDV100.
Первый с SDP вызывающей стороны
v=0
o=MZHSIP 1000 1032 IN IP4 61.41.111.69
s=MZHSIP
c=IN IP4 61.41.111.69
t=0 0
m=audio 65533 RTP/AVP 8
a=rtcp:65533 IN IP4 61.41.111.70
a=rtpmap:8 PCMA/8000
a=ptime:20
a=sendrecv
Второй с SDP вызывающей стороны
v=0
o=MZHSIP 1000 1033 IN IP4 61.41.111.69
s=MZHSIP
c=IN IP4 61.41.111.69
t=0 0
m=audio 65535 RTP/AVP 8
a=rtcp:65535 IN IP4 61.41.111.70
a=rtpmap:8 PCMA/8000
a=ptime:20
a=sendrecv
В первом случае вызов проходит и есть реально rtp и rtcp на разные IP - RTP на 61.41.111.69, RTCP на 61.41.111.70 порт и там и там 65533. (Кто в графике вдруг не увидит RTCP тот может поставить фильтр ip.addr == 61.41.111.70)
А вот во втором случае, когда адреса те-же, а порт 65535, вызов не обслуживается.
Как Вы объясните, то что во втором случае вызов не обслужен, если он обслужен в первом?

Прикрепленные файлы

 rtp_rtcp65533_rtp_rtcp65535.rar ( 135,98 килобайт ) Кол-во скачиваний: 0

 

[Зараза]

По прошлой ситуации с TGP500 и eMG80 у меня дело с поддержкой Panasonic зашло в тупик. Я этот вопрос для себя закрыл. Сейчас открыл новый вопрос в тему "TGP600 и 65535 с явным указанием RTCP". Посмотрим, что из этого выйдет.

[mikle]

Другой коварный вопрос - Будет ли Панас так работать?
v=0
o=MZHSIP 1000 1032 IN IP4 61.41.111.69
s=MZHSIP
c=IN IP4 61.41.111.69
t=0 0
m=audio 5060 RTP/AVP 8
a=rtcp:5060 IN IP4 61.41.111.69
a=rtpmap:8 PCMA/8000
a=ptime:20
a=sendrecv

Ответ - работает! SIP cигнализацию, rtp, rtcp Панас шлёт на один и тот-же порт на одном и том-же адресе!
И ничего его не смущает...

[Зараза]

Как Вы объясните, то что во втором случае вызов не обслужен, если он обслужен в первом?

На подобные вопросы поддержка Panasonic не хочет отвечать. Они просто говорят, дайте RFC в соответствии с которым, с вашей точки зрения, мы что-то делаем неправильно. Я дал ссылку на 3605, но есть предположения, что получу в ответ что-то вроде: "Читая 3605, находим - The RTCP attribute MAY be used as a media level attribute. MAY это не значит MUST или SHOULD и значит это вовсе не требование и мы можем игнорировать это поле и считать RTCP как +1 от RTP, а +1 к 65535 не легален".

[Зараза]

Другой коварный вопрос - Будет ли Панас так работать?
v=0
o=MZHSIP 1000 1032 IN IP4 61.41.111.69
s=MZHSIP
c=IN IP4 61.41.111.69
t=0 0
m=audio 5060 RTP/AVP 8
a=rtcp:5060 IN IP4 61.41.111.69
a=rtpmap:8 PCMA/8000
a=ptime:20
a=sendrecv

Ответ - работает! SIP cигнализацию, rtp, rtcp Панас шлёт на один и тот-же порт на одном и том-же адресе!
И ничего его не смущает...

О! Это другое дело, значит они однозначно используют RTCP порт указанный в SDP, а не считают его как +1.

Можно дамп?

[mikle]

О! Это другое дело, значит они однозначно используют RTCP порт указанный в SDP, а не считают его как +1.

Можно дамп?

Пожалуйста дамп.
Только учтите, что WireShark очень прямолинейно себя ведёт, полагая
что по одному порту могут приниматься данные только одного протокола.
Так что Вам придется поотфильтровывать многое и несколько раз, чтобы увидеть картину.

Прикрепленные файлы

 sip_rtp_rtcp_5060.rar ( 171,48 килобайт ) Кол-во скачиваний: 2

 

[Зараза]

Второй с SDP вызывающей стороны
v=0
o=MZHSIP 1000 1033 IN IP4 61.41.111.69
s=MZHSIP
c=IN IP4 61.41.111.69
t=0 0
m=audio 65535 RTP/AVP 8
a=rtcp:65535 IN IP4 61.41.111.70
a=rtpmap:8 PCMA/8000
a=ptime:20
a=sendrecv
А вот во втором случае, когда адреса те-же, а порт 65535, вызов не обслуживается.
Как Вы объясните, то что во втором случае вызов не обслужен, если он обслужен в первом?

Скажите, а Вы не пробовали то же самое в HDV100 при RTP_TARGET_CHECK = 3?

[mikle]

Скажите, а Вы не пробовали то же самое в HDV100 при RTP_TARGET_CHECK = 3?

Нет. А что это за значение опции?

[Зараза]

Нет. А что это за значение опции?

Из pdf в виде текста не копируется, вставлять картинку не хочу.
Посмотрите в http://cs.psn-web.net/support/sipphone_net...0_AG(ru)_ZA.pdf
раздел 5.3.23

Насколько я вижу в веб-морде этого параметра нет, но он может быть установлен в файле конфигурации заливаемом по tftp.

[mikle]

Из pdf в виде текста не копируется, вставлять картинку не хочу.
Посмотрите в http://cs.psn-web.net/support/sipphone_net...0_AG(ru)_ZA.pdf
раздел 5.3.23

Насколько я вижу в веб-морде этого параметра нет, но он может быть установлен в файле конфигурации заливаемом по tftp.

1) Судя из названия этот параметр отвечает за проверку приходящих RTP пакетов на предмет последующего преобразования в аудио. Проигрывать или отбрасывать. По умолчанию проигрывает со всех источников - с адресов и портов не соответствующих SDP, хотя должно быть все наоборот.
2) Проверил ваше предположение. Выставил RTP_TARGET_CHECK=3 в ConfigKX-HDV100.cfg, загрузил ConfigKX-HDV100.cfg.
Ничего не изменилось. Как 65535 не понимает, так и не понимает.

Вывод - RTP_TARGET_CHECK в данной модели вообще не поддерживается. Японцы закладывают всё что только можно на будущее...

[Зараза]

Запрос о проблеме отклонения INVITE с портом 65535 отправлен на завод Panasonic. Жду результата.

[Зараза]

В общем получен был ответ на уровне: да, есть ограничение в RTP порт 65535, да, в документации ничего нет, но в документацию будет внесено. Все остальные доводы про зачем вычислять RTCP как RTP+1, если RTCP порт в явном виде указывается в SDP - ушли мимо. Можно закрыть вопрос совместимости DECT Panasonic с АТС LG. Несовместимо.

[harris]

В общем получен был ответ на уровне: да, есть ограничение в RTP порт 65535, да, в документации ничего нет, но в документацию будет внесено. Все остальные доводы про зачем вычислять RTCP как RTP+1, если RTCP порт в явном виде указывается в SDP - ушли мимо. Можно закрыть вопрос совместимости DECT Panasonic с АТС LG. Несовместимо.

Понятно. Жаль, что так.

[mikle]

В общем получен был ответ на уровне: да, есть ограничение в RTP порт 65535, да, в документации ничего нет, но в документацию будет внесено. Все остальные доводы про зачем вычислять RTCP как RTP+1, если RTCP порт в явном виде указывается в SDP - ушли мимо. Можно закрыть вопрос совместимости DECT Panasonic с АТС LG. Несовместимо.

Не совсем так - у Вас конкретный ответ от Панасоника - отказать! А вот Корейцы ответили - подумаем, может сделаем (вместо 65535 - указывать 65534 или программируемый номер порта).

[mikle]

Не совсем так - у Вас конкретный ответ от Панасоника - отказать! А вот Корейцы ответили - подумаем, может сделаем (вместо 65535 - указывать 65534 или программируемый номер порта).

Начиная с фазы 2 версии R1.3.14 eMG80/800/UCP (уже доступна для партнёров производителя) посылается номер порта 65534 и все панасониковские телефоны и IP-DECT работают.
Рассматривается вопрос о внесении таких-же изменений в eMG80 фазы 1.

[Зараза]

Для меня так отличная новость. Надеюсь в фазе 1 все же сделают это.

[mikle]

Для меня так отличная новость. Надеюсь в фазе 1 все же сделают это.

А почему-бы Вам не установить фазу 2 сейчас? Если Вам не нужны никакие новые лицензии, после установки фазы 2 Вы получаете функционал фазы 2 с лицензиями фазы 1. Переход на лицензии фазы 2 осуществляется при загрузке файла лицензий фазы 2. Т.е. при необходимости в какой-то новой лицензии...

[Зараза]

Может стоит создать отдельный топик по ликбезу относительно особенностей прошивок фаз 1/2? А то ходит много слухов.

[mikle]

Может стоит создать отдельный топик по ликбезу относительно особенностей прошивок фаз 1/2? А то ходит много слухов.

Послал Вам на почту данные об исправлении фазы 1. Ждем результат.