107 как и 110 аналоговый порт. Плотно общаюсь с поддержкой Арткома сейчас, они собрали стенд. И аналогичная ситуация - системник 100 на SIP-абонентов отдает в connection нормальный адрес, все порты аналоговые в базовом блоке отдают при звонке на SIP-абонентов 0.0.0.0. Размышляют над этим.

У вас System IP Range в 102 программе из той же подсети, что и адрес процессора?

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

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

A TCP подключение панас умеет? Попробуйте.

Я так понимаю что если имеем 8 IP каналов то и кодеков должно быть свободных 8 для этих каналов и зачем их экономить?
Получается что может не хватить кодеков и система блокируема?

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

Да, 192.168.1.10 - 192.168.1.254.

Умеет, пробовал, результат аналогичен.

Вы имеете в виду 5.4, RFC 6337?

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

Меня печалит, если честно, все. 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.)

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