Меня печалит, если честно, все. Panasonic настоятельно просит ссылку на описание "стандартной процедуры", которую он не поддерживает.

Я получил внятный ответ в канале поддержки 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 включительно, но для RTP номер порта должен быть четный.
Пример звонок с Phontage на TGP500, все OK, в INVITE - m=audio 8006 RTP/AVP 0 8 111 (8006 - четный).

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

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

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

Включен ли RTCP на Панасе? Посмотрите.

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

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

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

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

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

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

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

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

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

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

Смотрите трассировки в приложенном файле:
----------------------
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 тоже
может внести свою лепту.
----------------------

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

Есть 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.

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

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

См RFC 3605

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

Сергей! Насколько следует из тестов, которые провел уваж. 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?

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

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

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

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

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

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

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

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

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

Мне тоже хочется понять логику вызываемой стороны. В приложенном файле трассировка пакетов 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, вызов не обслуживается.
Как Вы объясните, то что во втором случае вызов не обслужен, если он обслужен в первом?

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

Другой коварный вопрос - Будет ли Панас так работать?
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 не легален".

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

Можно дамп?

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

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

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

Из 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. Несовместимо.

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

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

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

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

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

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

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