А в Zone Attribute(439) Codec Type он есть.

Добавили??? Значит я это упустил, не заметил...

Да, виноват, добавили...

Так как все же выключить G.722, чтобы станция вообще забыла о нем?

А что в логах eMG <-> SIP-DECT ?
По идее АТС при "Trying" должна ломится на 111 с INVATE (которого в логах не видно почему то).
А вообще проблема с "Not Acceptable Here" чаще всего вызвана кодеками... Попробуйте оставить только 1 кодек на вызывающей стороне.

Имхо, дело не в кодеке G.722. Вроде в трассировках он нигде и не встречается, и станция его не предлагает.
Если вы обратили внимание, то при вызове SIP абонента от TDM устройства станция всегда работает с применением Re-Invite.
В первом сообщении Invite станция указывает RTP порт 65535, т.е. "пустой" порт, т.к. она еще не назначила порт для обслуживания этого вызова. Ведь вызываемый абонент, может быть, и не ответит вовсе..., зачем зря занимать VOIP канал.
А после ответе вызываемого SIP абонента (200 OK, ACK) станция уже повторно посылает Invite (т.е. это Re-Invite), но уже указывает реальный RTP порт (7000) для связи.
Так вот SIP Softphone нормально воспринимает эту процедуру, а панасовский SIP-DECT, похоже, отрицательно реагирует на порт 65535 (FF'h) и отбивает вход. вызов. До Re-Invite с реальным портом дело не доходит... Имхо, как-то так и причину, мне кажется, нужно искать в Панасе.

Я на этот факт уже ранее обратил внимание, но чем черт не шутит.


А вот это "всегда" выключить нельзя?
Прочел в ELG_iPECS_eMG80_A&P_st_IS1_1.pdf все, что нашлось по Invite, ничего толком не вижу.

Насколько мне известно - нет, нельзя. Это зашито в алгоритме работы станции.
Попробуйте выяснить в тех. поддержке Панаса, может ли это быть его реакция на порт 65535, с чем это связано, и как это преодолеть.
И еще хорошо бы снять снифер Wireshark'ом, чтобы посмотреть и сигнализацию и RTP трафик.

Используя ipdump снял дамп для wireshark'а и обнаружил, что станция при звонке 107 - 113 шлет в Connection Information IN IP 0.0.0.0. У меня просто глаза на лоб вылезли. Потому что выше в дампа звонка с 110 - 111 приведенном в сообщении 3 четко видно c=IN IP4 192.168.1.174. И 111 и 113 два SIP-DECT'а, а 107 и 110 два аналоговых телефона. Ситуация становится все более странной.

Дамп в приложении.

Да, напомню, станция и телефоны в одной IP-сети.

Нахожусь не возле станции, поэтому поднял DISA и через DISA делаю звонок на номер 113. И, таки да, опять c=IN IP4 0.0.0.0 в логах, чего я не видел ранее. Как это победить?

INVITE sip:113@192.168.1.170:5060 SIP/2.0
From: <sip:anonymous@192.168.1.174>;tag=40f329e0-ae01a8c0-13c4-65014-d7f-2896a0f6-d7f
To: <sip:113@192.168.1.170:5060>
Call-ID: 40f6b550-ae01a8c0-13c4-65014-d7f-243cf6d0-d7f
CSeq: 1 INVITE
Via: SIP/2.0/UDP 192.168.1.174:5060;rport;branch=z9hG4bK-d7f-34b826-6337e347-40eef9a0
Max-Forwards: 70
Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,REFER,SUBSCRIBER,NOTIFY,MESSAGE,INFO,PRAC
K,UPDATE
Supported: replaces,UPDATE,INFO
User-Agent: Ericsson-LG Enterprise iPECS-eMG eMG80 A.0Kg
Contact: <sip:anonymous@192.168.1.174:5060;transport=UDP>
Content-Type: application/sdp
Content-Length: 171

v=0
o=iPECS-eMG 34648 34648 IN IP4 0.0.0.0
s=iPECS-eMG Call
c=IN IP4 0.0.0.0
t=0 0
m=audio 65535 RTP/AVP 0 8
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=sendrecv

Так опять на SIP-DECT, а что при вызове софтфона? В Re-Invite, видимо, наряду с правильным портом и правильный адрес.

http://www.artcom.ru/forum/index.php?showt...ost&p=90471
Пост 23. "Почему станция выдает адрес 0.0.0.0 для голосовой связи - ХЗ. Мне повторить это не удалось. "
И таблетки не было.

С софт-фоном не могу ответить сейчас, не представляется возможным проверить. До Re-Invite не доходит, посмотрите дамп, там всего три строки.

Вам Игорь, вроде разъяснил, в чем может быть проблема. Похоже, панасоник ваш, действительно, на всем этом "спотыкается"...

Снимите сниф вызова софтфона, когда нет отлупа. Давайте посмотрим, что в этом случае.

Выше была трассировка (не сниф) вызова на софтфон 112. Там все нормально, и есть Re-Invite с реальными адресом и портом.

Вернемся к вопросу, который вам выше задавал уваж. Dron: какой режим у вас указан для VOIP каналов??
Если стоит по умолчанию режим Common, то нужно изменить его. Уже неоднократно упоминали, что нежелательно оставлять режим Common. Нужно в вашем случаем существующие VOIP каналы поставить в режим SIP&RTP_RELAY.
Сейчас посмотрел старую переписку - была подобная проблема с каналами и адресом 0.0.0.0, если режим назначен в виде Common.

Стоит SIP&RTP-Packet-Relay. Я склоняюсь к мысли инициализировать станцию и запрограммировать с нуля. Меня смущает то, что в одних дампах при звонках на SIP-DECT в Connection Info я видел нормальные адреса, в других 0.0.0.0 и между двумя дампами изменений в настройках не проводилось. Сегодня сделаю и сниму еще раз дампы.

Приехал на объект, решил сделать еще раз трассировку. С номера 110 звоню на 113, в одном случае это SIP-DECT, во втором случае это Eyebeam. В первом случае звонок не проходит, во втором случае проходит. Но в обоих дампах connection information IN IP4 192.168.1.174, то есть правильно все. Но вчерашний дамп, который я выкладывал был сделан для звонка 107 - 113 и в нем connection information IN IP4 0.0.0.0. Сейчас повторил - аналогично. Все дампы выложил. Ест идеи почему станция при звонке с 107 отдает RTP адрес 0.0.0.0, а при звонке с 110 отдает адрес 192.168.1.174?

107 - это что?