3-d Party SIP Опции

[mikle]

Сейчас в настройках стоит Транспортный протокол для SIP = UDP. Я не совсем понимаю каким боком в контексте обсуждения RTCP. Ведь о четности портов идет в RFC для RTP (- RTP/AVP - the IETF's Realtime Transport Protocol using the Audio/Video profile carried over UDP.)

В контексте обсуждения Вас просят посмотреть настройки RTCP. У меня нет вашей модели - я не могу это сделать, но в другой Панасониковской модели она есть. Вот её я бы и выключил и попробовал.

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

 Panas.GIF ( 55,31 килобайт ) Кол-во скачиваний: 22

 

[mikle]

Боюсь, что этот вопрос проигнорируют, так как это гипотетическая ситуация не имеющая отношения к конкретной проблеме.

Так давайте сделаем реальный Вызов. Сможете Свой Панас Выставить в открытый доступ? Я бы сделал тестовый вызов с a=rtcp:65534
а Вы бы протрассировали... Вот тогда и будут аргументы для панаса.

[Зараза]

В контексте обсуждения Вас просят посмотреть настройки RTCP. У меня нет вашей модели - я не могу это сделать, но в другой Панасониковской модели она есть. Вот её я бы и выключил и попробовал.

Такая морда как в HDV100 и такие же настройки есть в TGP600. В TGP500 таких настроек нет. Есть нечто "RTCP интервал" - указание промежутка времени между пакетами RTCP, в дефолте 0 выключено.
Полный мануал на TGP500 есть здесь: http://csj.psn-web.net/sipphone_net/downlo..._Russian_VA.pdf

[Зараза]

Так давайте сделаем реальный Вызов. Сможете Свой Панас Выставить в открытый доступ? Я бы сделал тестовый вызов с a=rtcp:65534
а Вы бы протрассировали... Вот тогда и будут аргументы для панаса.

TGP500 выставить не могу. Но, есть TGP600, у которого аналогичная проблема, то есть с eMG80 он не работает абсолютно аналогичным образом. Могу выставить его.

[Зараза]

Да, немного в тему. Сегодня пробовал еще два SIP-DECT'а в связке с eMG80. Panasonic KX-TGP600 - проблема аналогичная, Siemens C610 - все работает. Привязывал все три аппарата TGP500/TGP600/C610 на один и тот же extension.

[Dron]

Сейчас сможете?
На всякий случай с регистрацией - любой аккаунт.

И чем все закончилось? Жутко интересно!

[mikle]

И чем все закончилось? Жутко интересно!

Смотрите трассировки в приложенном файле:
----------------------
Panasonic не обрабатывает нормально (отбивает)
m=audio 65535 RTP/AVP 8
a=rtcp:65534
----------------------
Panasonic обрабатывает нормально
m=audio 65534 RTP/AVP 8
a=rtcp:65533
----------------------
Panasonic обрабатывает нормально
m=audio 65533 RTP/AVP 8
a=rtcp:65532
----------------------
Panasonic обрабатывает нормально
m=audio 65533 RTP/AVP 8
----------------------
Выводы:
1)Панас спокойно обрабатывает и четные и нечётные порты.
2) Понимает прямое назначение a=rtcp RTCP портов
3) Просто не обрабатывает 65535. Это Баг!
------------------------------------------------
Доп рассуждения о четном и нечетном портах...
Для себя определяю требование чет-нечет как требование для инициатора (передатчика), но это не означает что
получатель (приёмник) SDP не должен обрабатывать SDP c другим порядком...
NAPT может легко поменять номер порта, ему вообщем-то пофиг чет-нечет, а stun это определит, да и ALG тоже
может внести свою лепту.
----------------------

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

 Panasonic_KX_TG600_RTCP_enable.rar ( 2,05 килобайт ) Кол-во скачиваний: 3

 

[mikle]

Здесь правовая база!

Есть RFC 3605 - Real Time Control Protocol (RTCP) attribute inSession Description Protocol (SDP)
И RFC 3605 поддерживается Панасоником.
В этом RFC говорится, что RFC1889 - старая версия и что есть необходимость указывать rtcp порт
непосредственно.

1. Introduction.
.........................................
RTCP port numbers were necessarily derived from the base
media port in older versions of RTP (such as [RFC1889]), but now that
this restriction has been lifted, there is a need to specify RTCP ports explicitly in SDP.

Там же в RFC 3605 говориться, что при прохождении через NAT порты
RTP/RTCP могут измениться и STUN может вычислить это изменение.
Изменяться они могут по как угодно, посему
m=audio 65535 RTP/AVP 8
a=rtcp:65534
может иметь место быть и, естественно, должно быть обработано правильно!

3.1. How do we Discover Port Numbers?

The proposed solution is only useful if the host can discover the
"translated port numbers", i.e., the value of the ports as they
appear on the "external side" of the NAT. One possibility is to ask
the cooperation of a well connected third party that will act as a
server according to STUN [RFC3489]. We thus obtain a four step
process:

1 - The host allocates two UDP ports numbers for an RTP/RTCP pair,

2 - The host sends a UDP message from each port to the STUN server,

3 - The STUN server reads the source address and port of the packet,
and copies them in the text of a reply,

4 - The host parses the reply according to the STUN protocol and
learns the external address and port corresponding to each of the
two UDP ports.

[Серый]

Хорошо, подойдём с другой стороны к Панасонику. В SDP в атрибутах можно "в лоб" указать номер порта RTCP (RFC3261).
Вопрос к Панасонику - обработает ли он такой вызов?

m=audio 65535 RTP/AVP 8
a=rtcp:65534

В RFC3261 я не нашел упоминания про RTCP, уточните, пожалуйста, всё-таки что Вы имели ввиду? Спасибо.

[harris]

В RFC3261 я не нашел упоминания про RTCP, уточните, пожалуйста, всё-таки что Вы имели ввиду? Спасибо.

См. описание протокола SDP - RFC4566.
SIP (RFC3261) описывает способ установления и завершения пользовательского интернет-сеанса, включающего обмен мультимедийным содержимым.
А SDP служит для описания уже самой сессии передачи потоковых данных, т.е. атрибутов обмена медиа данными.

[mikle]

В RFC3261 я не нашел упоминания про RTCP, уточните, пожалуйста, всё-таки что Вы имели ввиду? Спасибо.

См RFC 3605

[Серый]

См. описание протокола SDP - RFC4566.
SIP (RFC3261) описывает способ установления и завершения пользовательского интернет-сеанса, включающего обмен мультимедийным содержимым.
А SDP служит для описания уже самой сессии передачи потоковых данных, т.е. атрибутов обмена медиа данными.

Игорь, я Вас понял, но, ИМХО, для аппарата, продающегося в РФ с 2009 года с поддержкой "RFC3261 and companion RFCs", и SDP2327 (а не RFC4566) и без возможности RTCP
что можно требовать для взаимодействия с новейшей eMG80?

[harris]

Игорь, я Вас понял, но, ИМХО, для аппарата, продающегося в РФ с 2009 года с поддержкой "RFC3261 and companion RFCs", и SDP2327 (а не RFC4566) и без возможности RTCP
что можно требовать для взаимодействия с новейшей eMG80?

Сергей! Насколько следует из тестов, которые провел уваж. Mikle, проблема не в отсутствии поддержки RTCP у данного телефона, а только в том, что в телефоне есть один маленький баг:
- телефон не обрабатывает RTP порт 65535. В рекомендациях сказано, что диапазон портов может быть от 1024 по 65535 ВКЛЮЧИТЕЛЬНО. Но телефон обрабатывает от 1024 ДО 65535. Т.е. 65535 просто выпал из диапазона, и все. ИМХО, выглядит это, как стандартная ошибка программиста.
- я предполагаю, что корейцы не будут вносить изменения в софт ради одной модели телефона, или одного производителя. Все остальные телефоны других производителей спокойно отрабатывают порт 655353. Впрочем, за официальным ответом разработчиков нужно обращаться к Михаилу.

[Серый]

Сергей! Насколько следует из тестов, которые провел уваж. Mikle, проблема не в отсутствии поддержки RTCP у данного телефона, а только в том, что в телефоне есть один маленький баг:
- телефон не обрабатывает RTP порт 65535. В рекомендациях сказано, что диапазон портов может быть от 1024 по 65535 ВКЛЮЧИТЕЛЬНО. Но телефон обрабатывает от 1024 ДО 65535. Т.е. 65535 просто выпал из диапазона, и все. ИМХО, выглядит это, как стандартная ошибка программиста.
- я предполагаю, что корейцы не будут вносить изменения в софт ради одной модели телефона, или одного производителя. Все остальные телефоны других производителей спокойно отрабатывают порт 655353. Впрочем, за официальным ответом разработчиков нужно обращаться к Михаилу.

Игорь, вносить изменения для устаревшей модели, согласен, не нужно.
For transports based on UDP, the value should be in the range
1024 to 65535 inclusive. For RTP compliance it should be an even
number.
Допустим, при парном назначении портов какой порт будет следующим после 65535?

[harris]

Игорь, вносить изменения для устаревшей модели, согласен, не нужно.
For transports based on UDP, the value should be in the range
1024 to 65535 inclusive. For RTP compliance it should be an even
number.
Допустим, при парном назначении портов какой порт будет следующим после 65535?

Сергей! Это касается вызывающей стороны. А вызываемая сторона должна обрабатывать любой порт, принятый в полученном Invite, неважно четный или нечетный, что и нормально выполняет Панас, но только за исключением порта 65535. Посмотрите еще раз результаты теста, которые Михаил выложил выше.

[Серый]

Сергей! Это касается вызывающей стороны. А вызываемая сторона должна обрабатывать любой порт, принятый в полученном Invite, неважно четный или нечетный, что и нормально выполняет Панас, но только за исключением порта 65535. Посмотрите еще раз результаты теста, которые Михаил выложил выше.

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

[harris]

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

Что считать "правильными" данными?? Панас нормально отрабатывает rtp на порт 65533. Порт нечетный!!
Порты могут быть замены при прохождении через NAPT и ALG. Порты могут дойти до вызываемого вовсе не как два последовательных порта. Собственно поэтому и добавили в рекомендации дескриптор a=rtcp: xxxx.
В случае с rtp port =65533, Панас "вычисляет" rtcp порт как 65534?? Допустим. А при попытке вычисления rtcp порта при rtp=65535 Панас выходит за допустимый диапазон портов?? Но Панас не поддерживает RTCP, зачем тогда вычислять порт rtcp??

И обратите внимание, что все телефоны других производителей, нормально отрабатывают порт 65535.

Далее пояснения от Михаила:
1) Если нельзя вычислить rtcp порт, это не повод для отклонения сессии.
2) Панас отбивает вызов с портом 65535, даже если у Панаса rtcp отключен!!! Кстати rtcp отключен по умолчанию у Панаса.

[harris]

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

[Зараза]

Игорь, я Вас понял, но, ИМХО, для аппарата, продающегося в РФ с 2009 года с поддержкой "RFC3261 and companion RFCs", и SDP2327 (а не RFC4566) и без возможности RTCP
что можно требовать для взаимодействия с новейшей eMG80?

Указанные тесты проводились Mikle не с TGP500, а с TGP600, то есть прямо самой свежей текущей моделью SIP DECT от Panasonic. Кроме того, по информации от Mikle, абсолютно аналогичная проблема есть и в самом свежем SIP телефоне KX-HDV100.

[Серый]

Указанные тесты проводились Mikle не с TGP500, а с TGP600, то есть прямо самой свежей текущей моделью SIP DECT от Panasonic. Кроме того, по информации от Mikle, абсолютно аналогичная проблема есть и в самом свежем SIP телефоне KX-HDV100.

Эти новые продукты лично я не тестировал, пока только в планах.