3-d Party SIP Опции

[Зараза]

Есть eMG80. Зарегистрированы 112 - софт-фон на компьютере, 111 - SIP-DECT Panasonic KX-TGP500, 129 - Phontage Deluxe, 110 - аналоговый телефон. Все в локалке.

Проблема: не могу дозвониться на 111 с аналоговых телефонов eMG80.

Выход в город: 110, 111, 112, 129 - работает.
110 -> 112, 129 - все OK
129, 112 -> 111 - все OK
110 -> 111 - соединение не происходит, получаю отлуп.

вот в таком виде:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.1.174:5060;branch=z9hG4bK-f79-3c745d-1a80a3c8-40efb320;rport=5060
To: <sip:111@192.168.1.171>
From: <sip:110@192.168.1.174>;tag=40f3e2c0-ae01a8c0-13c4-65014-f79-4c39fedb-f79
Call-ID: 40f75070-ae01a8c0-13c4-65014-f79-6603d065-f79
CSeq: 1 INVITE
Content-Length: 0

SIP/2.0 488 Not Acceptable Here
Via: SIP/2.0/UDP 192.168.1.174:5060;branch=z9hG4bK-f79-3c745d-1a80a3c8-40efb320;rport=5060
To: <sip:111@192.168.1.171>;tag=1395545948
From: <sip:110@192.168.1.174>;tag=40f3e2c0-ae01a8c0-13c4-65014-f79-4c39fedb-f79
Call-ID: 40f75070-ae01a8c0-13c4-65014-f79-6603d065-f79
CSeq: 1 INVITE
Allow: INVITE,ACK,CANCEL,BYE,OPTIONS,NOTIFY,REFER,UPDATE
Content-Length: 0

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

[Зараза]

Техподдержка Panasonic порекомендовала попробовать выключить G.722. Собственно не могу понять, есть ли возможность его выключить на стороне станции.
PGM132 Device Codec Type сделал G.711, рестарт нужен?

[harris]

Техподдержка Panasonic порекомендовала попробовать выключить G.722. Собственно не могу понять, есть ли возможность его выключить на стороне станции.
PGM132 Device Codec Type сделал G.711, рестарт нужен?

Нельзя выключить то, чего нет. Станция eMG в принципе не поддерживает G.722.

[mikle]

Осмелюсь предположить, что это потому, что IP-DECT не от Ericsson-LG Enterprise...
Ну а на самом деле, как видно, Panasonic не поддерживает обработку INVITE с приостановленным вызовом.
В SDP с=0.0.0.0 и/или номер порта=65535 реально означает (читайте рекомендации), что система будет ждать ответа вызываемого для того, что бы назначить системный RTP кодек. И имеет место быть это при вызове от TDM устройств станции, а в случае вызова от Phontage или SIP софтовых клиентов RTP точки используются терминальные, посему
система их легко и использует в сигнализации.

Вы спросите - а для чего приостановленный вызов? За разработчиков отвечу - в целях экономии, т.е. непродуктивного использования системных кодеков, ведь вызываемый может вообще не ответить, или у вызываемого автохолд, или, не поддерживаемый системой кодек, так зачем задействовать свой кодек, если ещё пока непонятно нужен ли он будет вообще.
Замечено, что Panasonic грешит этим всюду, например новый KX-HDV100 имеет точно такой-же баг (в добавок к ряду других багов).

[Зараза]

Вы спросите - а для чего приостановленный вызов? За разработчиков отвечу - в целях экономии, т.е. непродуктивного использования системных кодеков, ведь вызываемый может вообще не ответить, или у вызываемого автохолд, или, не поддерживаемый системой кодек, так зачем задействовать свой кодек, если ещё пока непонятно нужен ли он будет вообще.
Замечено, что Panasonic грешит этим всюду, например новый KX-HDV100 имеет точно такой-же баг (в добавок к ряду других багов).

Спасибо за конструктивный комментарий. Собственно про это harris в одном из постов выше писал. И печально, что на стороне LG это нельзя выключить.

[harris]

Спасибо за конструктивный комментарий. Собственно про это harris в одном из постов выше писал. И печально, что на стороне LG это нельзя выключить.

А почему вас печалит LG, а не Панас?? Станция же действует в рамках протокола. Почему Панас не поддерживает стандартную процедуру?? Уже неоднократно случалось, что баги Панаса (H.323) приходилось обходить на стороне LG. Может, пора и на строне Панаса немного подкрутить...

[Зараза]

Может, пора и на строне Панаса немного подкрутить...

Я получил внятный ответ в канале поддержки Panasonic'а.

RFC 2327 (SDP)
The second sub-field is the transport port to which the media stream will be sent. The meaning of the transport port depends on the network being used as specified in the relevant "c" field and on the transport protocol defined in the third sub-field. Other
ports used by the media application (such as the RTCP port, see [2]) should be derived algorithmically from the base media port. Note: 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.

SHOULD и EVEN я выделил.
Вот это в INVITE: m=audio 65535 RTP/AVP 0 8, не соответствует указанному RFC, так как номер порта нечетный.

[Dron]

Я получил внятный ответ в канале поддержки Panasonic'а.
RFC 2327 (SDP)
The second sub-field is the transport port to which the media stream will be sent. The meaning of the transport port depends on the network being used as specified in the relevant "c" field and on the transport protocol defined in the third sub-field. Other
ports used by the media application (such as the RTCP port, see [2]) should be derived algorithmically from the base media port. Note: 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.

SHOULD и EVEN я выделил.
Вот это в INVITE: m=audio 65535 RTP/AVP 0 8, не соответствует указанному RFC, так как номер порта нечетный.

А как тогда понимать "по 65535 включительно"? 65 535 - нечетное число. Не шибко в английском силен...

[Зараза]

А как тогда понимать "по 65535 включительно"? 65 535 - нечетное число. Не шибко в английском силен...

Написано по 65535 включительно, но для RTP номер порта должен быть четный.
Пример звонок с Phontage на TGP500, все OK, в INVITE - m=audio 8006 RTP/AVP 0 8 111 (8006 - четный).

[mikle]

Написано по 65535 включительно, но для RTP номер порта должен быть четный.
Пример звонок с Phontage на TGP500, все OK, в INVITE - m=audio 8006 RTP/AVP 0 8 111 (8006 - четный).

Панас поддерживает и четные и нечётные - ему по барабану, проверял я на некоторых телефонах. Лукавят спецы Панаса.
Вопрос всем - каким четным или нечётным должен быть номер порта, если RTCP не используется в Панасе?
Ответ напрашивается однозначный - любым. Посему и 65535 должен поддерживаться.
Вопрос в другом - включен ли RTCP на Панасе? Вот если выключен, то это баг Панаса.

[Зараза]

Панас поддерживает и четные и нечётные - ему по барабану, проверял я на некоторых телефонах. Лукавят спецы Панаса.
Вопрос всем - каким четным или нечётным должен быть номер порта, если RTCP не используется в Панасе?
Ответ напрашивается однозначный - любым. Посему и 65535 должен поддерживаться.
Вопрос в другом - включен ли RTCP на Панасе? Вот если выключен, то это баг Панаса.

Мне в общении с техподдержкой сложно аргументировать общими фразами. Мне в техподдержке Panasonic дают и просят конкретные ссылки на RFC.

В вашем ответе я не могу логику проследить. Пытаюсь построить цепочку и получается что-то странное: если RTCP не используется, то 65535 должен работать, но 65535 не работает, значит как следствие RTCP используется, значит бага нет.

[mikle]

Мне в общении с техподдержкой сложно аргументировать общими фразами. Мне в техподдержке Panasonic дают и просят конкретные ссылки на RFC.

В вашем ответе я не могу логику проследить. Пытаюсь построить цепочку и получается что-то странное: если RTCP не используется, то 65535 должен работать, но 65535 не работает, значит как следствие RTCP используется, значит бага нет.

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

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

[Серый]

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

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

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

[harris]

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

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

[Серый]

См. описание протокола 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. Посмотрите еще раз результаты теста, которые Михаил выложил выше.

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

[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

 

[Зараза]

Второй с 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.