Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: 3-d Party SIP
АРТКОМ Форум > Форумы для специалистов > Техническая поддержка iPECS-eMG80 & iPECS-eMG100
Страницы: 1, 2, 3
Зараза
Есть 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

Не могу понять как проблема может быть увязана с тем, что инициатор проблемного звонка - аналоговый абонент.
Зараза
Звонок с Phontage на 111, OK
738249-
[[[[[[[[[[@@@@@ [SIPM] Creation Call ID => 84 (a)@@@@@]]]]]]]]]]
738249-
[[[[[[[[[[@@@@@ [SIPM] Creation Call SS ID => 85 @@@@@]]]]]]]]]]
738249-[CallIdx:84(All:100)][Sipm_SipCallCreate](max:2 OUT:1,IN:0)
738249-CalSip_MakeSdp: dtmf:2, adm:4
738249-CalSip_AddVoiceDTMFSDPWithSRTP: srtp:0, offer:0, dtmf:2
738249-Crypto num: 0
738253-[CallIdx:84][Sipm_CallMsgHandler] CALL ---> SIPM (INVITE)
738253-[CallIdx:84][Sipm_CallMsgHandler] received callInfo->contactIp(192.168.1.174),port(5060)
738253-[CallIdx:84][Sipm_CallMsgHandler] revised callInfo->contactIp(192.168.1.174),port(5060)
738253-[CallIdx:84][Sipm_CallMsgHandler] final callInfo->contactIp(192.168.1.174),port(5060), trans(UDP), EXT
738253---------------------------- From CALL To SIPM INVITE ---------------------------
738253- port_no(13), port_type(STN), is_trunk(0), route_no(65535), displayName()
738253- srcNum(129), srcIp(192.168.1.174), srcPort(5060)
738253- destNum(111), destIp(192.168.1.171), destPort(5060)
738253- signalIp(192.168.1.171), signalPort(5060), replace_id((nil))
738253- contactUser(129), contactIp(192.168.1.174), contactPort(5060), request_uri()
738253- auth_userid(), CallLeg(0x40f774f0), Uid(0)
738253- pai_id(), privacy(), rpi_id(), pref_id() in TRUNK
738253- p_asserted_id(129)in EXT
738253- diversion(), id(0), is_static(0)
738253---------------------------------------------------------------------------------
738253-[Sipm_SipConnProcInviteReq] (84) RvSipCallLegSetTranscTimers set
738253-[Sipm_SipConnProcInviteReq] (84) Trans_mode(0, 13)
738253-[Sipm_SipConnectCall] param : [2]
738253-[Sipm_SipConnectCall] contact:129@192.168.1.174:5060;transport=UDP
738253-[CallIdx:84][Sipm_SipEvCallMsgSend] SIPM ---> INVITE
738253-[Sipm_SipUtilSetOtherHeaderInMsg] Allow => INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,REFER,SUBSCRIBER,NOTIFY,MESSAGE,INFO,PRAC
K,UPDATE
738253-[Sipm_SipUtilSetOtherHeaderInMsg] P-Asserted-Identity => <sip:129@192.168.1.174>
738253-[Sipm_SipUtilSetOtherHeaderInMsg] Supported => replaces,UPDATE,INFO
738253-=============================================
738253-Send SDP MSG[84] => v=0
o=iPECS-eMG 73825 73825 IN IP4 192.168.1.175
s=iPECS-eMG Call
c=IN IP4 192.168.1.175
t=0 0
m=audio 8006 RTP/AVP 0 8 111
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:111 X-nt-inforeq/8000
a=sendrecv
738253-=============================================
738253-[Sipm_SipUtilSetOtherHeaderInMsg] User-Agent => Ericsson-LG Enterprise iPECS-eMG eMG80 A.0Kg

[ 28/11/14 21:33:25 ]+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Sent 898 Bytes to 192.168.1.171:5060 by UDP (SendEv)
--------------------------------------------------------------------------------
INVITE sip:111@192.168.1.171:5060 SIP/2.0
From: <sip:129@192.168.1.174>;tag=40f41920-ae01a8c0-13c4-65014-1ccd-e027ab0-1ccd
To: <sip:111@192.168.1.171:5060>
Call-ID: 40f774f0-ae01a8c0-13c4-65014-1ccd-1eed9ff2-1ccd
CSeq: 1 INVITE
Via: SIP/2.0/UDP 192.168.1.174:5060;rport;branch=z9hG4bK-1ccd-70840c-6d731c42-40eff220
Max-Forwards: 70
Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,REFER,SUBSCRIBER,NOTIFY,MESSAGE,INFO,PRAC
K,UPDATE
P-Asserted-Identity: <sip:129@192.168.1.174>
Supported: replaces,UPDATE,INFO
User-Agent: Ericsson-LG Enterprise iPECS-eMG eMG80 A.0Kg
Contact: <sip:129@192.168.1.174:5060;transport=UDP>
Content-Type: application/sdp
Content-Length: 218

v=0
o=iPECS-eMG 73825 73825 IN IP4 192.168.1.175
s=iPECS-eMG Call
c=IN IP4 192.168.1.175
t=0 0
m=audio 8006 RTP/AVP 0 8 111
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:111 X-nt-inforeq/8000
a=sendrecv

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

738253-[CallIdx:84][Sipm_SipEvCallState(s:01)] OUTGOING - Inviting(reason:LOCAL_INVITING)
738253-[CallIdx:84][PORT NUMBER : 0x000d, Type:STN] CALL <--- SIPM (100 Trying)

[ 28/11/14 21:33:25 ]===========================================================
Received 319 Bytes from 192.168.1.171:5060 by UDP (ReceiveEv)
--------------------------------------------------------------------------------
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.1.174:5060;branch=z9hG4bK-1ccd-70840c-6d731c42-40eff220;rport=5060
To: <sip:111@192.168.1.171>
From: <sip:129@192.168.1.174>;tag=40f41920-ae01a8c0-13c4-65014-1ccd-e027ab0-1ccd
Call-ID: 40f774f0-ae01a8c0-13c4-65014-1ccd-1eed9ff2-1ccd
CSeq: 1 INVITE
Content-Length: 0


================================================================================

738261-[Sipm_SipTransportMsgReceivedExt]..Response...
738261-[CallIdx:84][Sipm_SipEvCallMsgReceive] SIPM <--- 100(Method:INVITE(0), reason:Trying)
738261-[CallIdx:84][Sipm_SipEvCallState(s:13)] OUTGOING - Proceeding(reason:NOTHING_ALL)

[ 28/11/14 21:33:25 ]===========================================================
Received 431 Bytes from 192.168.1.171:5060 by UDP (ReceiveEv)
--------------------------------------------------------------------------------
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 192.168.1.174:5060;branch=z9hG4bK-1ccd-70840c-6d731c42-40eff220;rport=5060
To: <sip:111@192.168.1.171>;tag=525471431
From: <sip:129@192.168.1.174>;tag=40f41920-ae01a8c0-13c4-65014-1ccd-e027ab0-1ccd
Call-ID: 40f774f0-ae01a8c0-13c4-65014-1ccd-1eed9ff2-1ccd
CSeq: 1 INVITE
Contact: <sip:111@192.168.1.171:5060>
Allow: INVITE,ACK,CANCEL,BYE,OPTIONS,NOTIFY,REFER,UPDATE
Content-Length: 0
Зараза
Звонок с аналогового на 111, отлуп
397064-
[[[[[[[[[[@@@@@ [SIPM] Creation Call ID => 68 (a)@@@@@]]]]]]]]]]
397064-
[[[[[[[[[[@@@@@ [SIPM] Creation Call SS ID => 69 @@@@@]]]]]]]]]]
397064-[CallIdx:68(All:100)][Sipm_SipCallCreate](max:2 OUT:1,IN:0)
397064-CalSip_MakeSdp: dtmf:2, adm:4
397064-CalSip_AddVoiceDTMFSDPWithSRTP: srtp:0, offer:0, dtmf:2
397064-Crypto num: 0
397065-[CallIdx:68][Sipm_CallMsgHandler] CALL ---> SIPM (INVITE)
397065-[CallIdx:68][Sipm_CallMsgHandler] received callInfo->contactIp(192.168.1.174),port(5060)
397065-[CallIdx:68][Sipm_CallMsgHandler] revised callInfo->contactIp(192.168.1.174),port(5060)
397065-[CallIdx:68][Sipm_CallMsgHandler] final callInfo->contactIp(192.168.1.174),port(5060), trans(UDP), EXT
397065---------------------------- From CALL To SIPM INVITE ---------------------------
397065- port_no(13), port_type(STN), is_trunk(0), route_no(65535), displayName()
397065- srcNum(110), srcIp(192.168.1.174), srcPort(5060)
397065- destNum(111), destIp(192.168.1.171), destPort(5060)
397065- signalIp(192.168.1.171), signalPort(5060), replace_id((nil))
397065- contactUser(110), contactIp(192.168.1.174), contactPort(5060), request_uri()
397065- auth_userid(), CallLeg(0x40f75070), Uid(0)
397065- pai_id(), privacy(), rpi_id(), pref_id() in TRUNK
397065- p_asserted_id(110)in EXT
397065- diversion(), id(0), is_static(0)
397065---------------------------------------------------------------------------------
397065-[Sipm_SipConnProcInviteReq] (68) RvSipCallLegSetTranscTimers set
397065-[Sipm_SipConnProcInviteReq] (68) Trans_mode(0, 13)
397065-[Sipm_SipConnectCall] param : [2]
397065-[Sipm_SipConnectCall] contact:110@192.168.1.174:5060;transport=UDP
397065-[CallIdx:68][Sipm_SipEvCallMsgSend] SIPM ---> INVITE
397065-[Sipm_SipUtilSetOtherHeaderInMsg] Allow => INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,REFER,SUBSCRIBER,NOTIFY,MESSAGE,INFO,PRAC
K,UPDATE
397065-[Sipm_SipUtilSetOtherHeaderInMsg] P-Asserted-Identity => <sip:110@192.168.1.174>
397065-[Sipm_SipUtilSetOtherHeaderInMsg] Supported => replaces,UPDATE,INFO
397065-=============================================
397065-Send SDP MSG[68] => v=0
o=iPECS-eMG 39707 39707 IN IP4 192.168.1.174
s=iPECS-eMG Call
c=IN IP4 192.168.1.174
t=0 0
m=audio 65535 RTP/AVP 0 8 111
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:111 X-nt-inforeq/8000
a=sendrecv
397065-=============================================
397065-[Sipm_SipUtilSetOtherHeaderInMsg] User-Agent => Ericsson-LG Enterprise iPECS-eMG eMG80 A.0Kg

[ 28/11/14 20:36:32 ]+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Sent 895 Bytes to 192.168.1.171:5060 by UDP (SendEv)
--------------------------------------------------------------------------------
INVITE sip:111@192.168.1.171:5060 SIP/2.0
From: <sip:110@192.168.1.174>;tag=40f3e2c0-ae01a8c0-13c4-65014-f79-4c39fedb-f79
To: <sip:111@192.168.1.171:5060>
Call-ID: 40f75070-ae01a8c0-13c4-65014-f79-6603d065-f79
CSeq: 1 INVITE
Via: SIP/2.0/UDP 192.168.1.174:5060;rport;branch=z9hG4bK-f79-3c745d-1a80a3c8-40efb320
Max-Forwards: 70
Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,REFER,SUBSCRIBER,NOTIFY,MESSAGE,INFO,PRAC
K,UPDATE
P-Asserted-Identity: <sip:110@192.168.1.174>
Supported: replaces,UPDATE,INFO
User-Agent: Ericsson-LG Enterprise iPECS-eMG eMG80 A.0Kg
Contact: <sip:110@192.168.1.174:5060;transport=UDP>
Content-Type: application/sdp
Content-Length: 219

v=0
o=iPECS-eMG 39707 39707 IN IP4 192.168.1.174
s=iPECS-eMG Call
c=IN IP4 192.168.1.174
t=0 0
m=audio 65535 RTP/AVP 0 8 111
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:111 X-nt-inforeq/8000
a=sendrecv

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

397065-[CallIdx:68][Sipm_SipEvCallState(s:01)] OUTGOING - Inviting(reason:LOCAL_INVITING)
397065-[CallIdx:68][PORT NUMBER : 0x000d, Type:STN] CALL <--- SIPM (100 Trying)

[ 28/11/14 20:36:32 ]===========================================================
Received 315 Bytes from 192.168.1.171:5060 by UDP (ReceiveEv)
--------------------------------------------------------------------------------
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


================================================================================

397074-[Sipm_SipTransportMsgReceivedExt]..Response...
397074-[CallIdx:68][Sipm_SipEvCallMsgReceive] SIPM <--- 100(Method:INVITE(0), reason:Trying)
397074-[CallIdx:68][Sipm_SipEvCallState(s:13)] OUTGOING - Proceeding(reason:NOTHING_ALL)

[ 28/11/14 20:36:32 ]===========================================================
Received 401 Bytes from 192.168.1.171:5060 by UDP (ReceiveEv)
--------------------------------------------------------------------------------
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
Зараза
Invite'ы абсолютно одинаковые, но в первом случае Ringing, во втором случае Not Acceptable.
Dron
Цитата(Зараза @ 17.9.2015, 9:38) *
Invite'ы абсолютно одинаковые, но в первом случае Ringing, во втором случае Not Acceptable.

А что у вас с VoIP каналами? CO VoIP Mode?
Зараза
Цитата(Dron @ 17.9.2015, 12:55) *
А что у вас с VoIP каналами? CO VoIP Mode?


VOIU channel 1 copy
Available VOIU 3 channels

CO VoIP Mode: Common

Ни одного VoIP транка нет, станция пустая, то есть на сейчас в принипе кроме меня и этих моих звонков VoIP ничем не утилизируется.
Dron
Цитата(Зараза @ 17.9.2015, 10:10) *
VOIU channel 1 copy
Available VOIU 3 channels

CO VoIP Mode: Common

Ни одного VoIP транка нет, станция пустая, то есть на сейчас в принипе кроме меня и этих моих звонков VoIP ничем не утилизируется.

Порты в сети не режутся. Вот, к примеру, в ваших трейсах при вызове с Phontage в invite порт RTP 8006, а при вызове с аналогового абонента - 65535.
Зараза
Цитата(Dron @ 17.9.2015, 13:29) *
Порты в сети не режутся. Вот, к примеру, в ваших трейсах при вызове с Phontage в invite порт RTP 8006, а при вызове с аналогового абонента - 65535.

Плоская сеть в пределах одного коммутатора. Нечем там резать.

Не могу систему толком поймать. Казалось бы проблема - вызовы с аналоговых на SIP не работают. Но при этом вызов с аналогового на 111 SIP-DECT KX-TGP500 не работает, но на SIP-софтфон 112 с аналогового все OK. Тут же с 129 Phontage и на 112 и на 111 без проблем звонки ходят. То есть проблема выглядит как бы с аналогового на SIP-DECT 111 - не работает.
Зараза
Цитата(Dron @ 17.9.2015, 13:29) *
Порты в сети не режутся. Вот, к примеру, в ваших трейсах при вызове с Phontage в invite порт RTP 8006, а при вызове с аналогового абонента - 65535.

Кстати, да, а почему такой странный номер порта? В iPECS_PortUsage_eMG80.pdf вообще такого диапазона нет.
Dron
Цитата(Зараза @ 17.9.2015, 10:48) *
Кстати, да, а почему такой странный номер порта? В iPECS_PortUsage_eMG80.pdf вообще такого диапазона нет.

Попробуйте не COMMON, а что то другое с RTP.
Dron
Цитата(Зараза @ 17.9.2015, 10:40) *
Плоская сеть в пределах одного коммутатора. Нечем там резать.

Не могу систему толком поймать. Казалось бы проблема - вызовы с аналоговых на SIP не работают. Но при этом вызов с аналогового на 111 SIP-DECT KX-TGP500 не работает, но на SIP-софтфон 112 с аналогового все OK. Тут же с 129 Phontage и на 112 и на 111 без проблем звонки ходят. То есть проблема выглядит как бы с аналогового на SIP-DECT 111 - не работает.

И в чем разница между вызовами на SIP-DECT 111 и на SIP-софтфон 112? Если зарегить SIP-софтфон под 111?
Зараза
Цитата(Dron @ 17.9.2015, 14:01) *
И в чем разница между вызовами на SIP-DECT 111 и на SIP-софтфон 112?

См. ниже. Пост 15 - резюме.
Зараза
Звонок с 110 на 112, OK.

Sent 896 Bytes to 192.168.1.175:11726 by UDP (SendEv)
--------------------------------------------------------------------------------
INVITE sip:112@192.168.1.175:11726 SIP/2.0
From: <sip:110@192.168.1.174>;tag=40f3dd50-ae01a8c0-13c4-65014-eff-6332807-eff
To: <sip:112@192.168.1.175:11726>
Call-ID: 40f74e28-ae01a8c0-13c4-65014-eff-399b55d9-eff
CSeq: 1 INVITE
Via: SIP/2.0/UDP 192.168.1.174:5060;rport;branch=z9hG4bK-eff-3a9799-17476c4d-40efaa60
Max-Forwards: 70
Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,REFER,SUBSCRIBER,NOTIFY,MESSAGE,INFO,PRAC
K,UPDATE
P-Asserted-Identity: <sip:110@192.168.1.174>
Supported: replaces,UPDATE,INFO
User-Agent: Ericsson-LG Enterprise iPECS-eMG eMG80 A.0Kg
Contact: <sip:110@192.168.1.174:5060;transport=UDP>
Content-Type: application/sdp
Content-Length: 219

v=0
o=iPECS-eMG 38486 38486 IN IP4 192.168.1.174
s=iPECS-eMG Call
c=IN IP4 192.168.1.174
t=0 0
m=audio 65535 RTP/AVP 0 8 111
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:111 X-nt-inforeq/8000
a=sendrecv

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

384860-[CallIdx:67][Sipm_SipEvCallState(s:01)] OUTGOING - Inviting(reason:LOCAL_INVITING)
384860-[CallIdx:67][PORT NUMBER : 0x000e, Type:STN] CALL <--- SIPM (100 Trying)

[ 28/11/14 20:34:30 ]===========================================================
Received 421 Bytes from 192.168.1.175:11726 by UDP (ReceiveEv)
--------------------------------------------------------------------------------
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 192.168.1.174:5060;rport=5060;branch=z9hG4bK-eff-3a9799-17476c4d-40efaa60
Contact: <sip:112@192.168.1.175:11726>
To: <sip:112@192.168.1.175:11726>;tag=5f19916c
From: <sip:110@192.168.1.174>;tag=40f3dd50-ae01a8c0-13c4-65014-eff-6332807-eff
Call-ID: 40f74e28-ae01a8c0-13c4-65014-eff-399b55d9-eff
CSeq: 1 INVITE
User-Agent: eyeBeam release 1102u stamp 52345
Content-Length: 0


================================================================================

384871-[Sipm_SipTransportMsgReceivedExt]..Response...
384871-[CallIdx:67][Sipm_SipEvCallMsgReceive] SIPM <--- 180(Method:INVITE(0), reason:Ringing)
384871-[CallIdx:67][PORT NUMBER : 0x000e, Type:STN] CALL <--- SIPM (180 Ringing)
384871-[CallIdx:67][Sipm_SipEvCallState(s:13)] OUTGOING - Proceeding(reason:NOTHING_ALL)

[ 28/11/14 20:34:34 ]===========================================================
Received 664 Bytes from 192.168.1.175:11726 by UDP (ReceiveEv)
--------------------------------------------------------------------------------
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.174:5060;rport=5060;branch=z9hG4bK-eff-3a9799-17476c4d-40efaa60
Contact: <sip:112@192.168.1.175:11726>
To: <sip:112@192.168.1.175:11726>;tag=5f19916c
From: <sip:110@192.168.1.174>;tag=40f3dd50-ae01a8c0-13c4-65014-eff-6332807-eff
Call-ID: 40f74e28-ae01a8c0-13c4-65014-eff-399b55d9-eff
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
Content-Type: application/sdp
User-Agent: eyeBeam release 1102u stamp 52345
Content-Length: 132

v=0
o=- 3 2 IN IP4 192.168.1.175
s=CounterPath eyeBeam 1.5
c=IN IP4 192.168.1.175
t=0 0
m=audio 45116 RTP/AVP 0 8
a=sendrecv

================================================================================

385233-[Sipm_SipTransportMsgReceivedExt]..Response...
385233-[CallIdx:67][Sipm_SipEvCallMsgReceive] SIPM <--- 200(Method:INVITE(0), reason:OK)
385233-SDP Msg Construct Parse - SinglePart
385233-=============================================
385233-Receive SDP MSG[67] =>
v=0
o=- 3 2 IN IP4 192.168.1.175
s=CounterPath eyeBeam 1.5
c=IN IP4 192.168.1.175
t=0 0
m=audio 45116 RTP/AVP 0 8
a=sendrecv
385233-=============================================
385233-[CallIdx:67][Sipm_SipEvCallState(s:10)] OUTGOING - RemoteAccepted(reason:REMOTE_ACCEPTED)
385233-[CallIdx:67][PORT NUMBER : 0x000e, Type:STN] CALL <--- SIPM (200 OK)
385233-[CallIdx:67][Sipm_SipEvCallMsgSend] SIPM ---> ACK
385233-[Sipm_SipCheckContactAddr] user:, system_ip:192.168.1.174:5060, trans_mode:UDP, URI
385233-[Sipm_SipUtilSetOtherHeaderInMsg] User-Agent => Ericsson-LG Enterprise iPECS-eMG eMG80 A.0Kg

[ 28/11/14 20:34:34 ]+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Sent 475 Bytes to 192.168.1.175:11726 by UDP (SendEv)
--------------------------------------------------------------------------------
ACK sip:112@192.168.1.175:11726 SIP/2.0
From: <sip:110@192.168.1.174>;tag=40f3dd50-ae01a8c0-13c4-65014-eff-6332807-eff
To: <sip:112@192.168.1.175:11726>;tag=5f19916c
Call-ID: 40f74e28-ae01a8c0-13c4-65014-eff-399b55d9-eff
CSeq: 1 ACK
Via: SIP/2.0/UDP 192.168.1.174:5060;rport;branch=z9hG4bK-f03-3aa62f-1ea0ef15-40efac20
Max-Forwards: 70
User-Agent: Ericsson-LG Enterprise iPECS-eMG eMG80 A.0Kg
Contact: <sip:110@192.168.1.174:5060;transport=UDP>
Content-Length: 0


++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

385233-[CallIdx:67][Sipm_SipEvCallState(s:06)] OUTGOING - Connected(reason:ACK_SENT)
385233-- CalSip_Parse_SDP: [SIP:14]
385233-Crypto num: 0
385233-- CalSip_UpdateCryptoInfo: 0
385234-CalSip_MakeSdp: dtmf:2, adm:4
385234-CalSip_AddVoiceDTMFSDPWithSRTP: srtp:0, offer:1, dtmf:2
385234-Crypto num: 0
385234-CalSip_MakeSdp: dtmf:2, adm:4
385234-CalSip_AddVoiceDTMFSDPWithSRTP: srtp:0, offer:0, dtmf:2
385234-Crypto num: 0
385234-CalSip_MakeSdp: dtmf:2, adm:4
385234-CalSip_AddVoiceDTMFSDPWithSRTP: srtp:0, offer:1, dtmf:2
385235-Crypto num: 0
385243-[CallIdx:67][Sipm_CallMsgHandler] CALL ---> SIPM (Re-INVITE)
385243---------------------------- From CALL To SIPM INVITE ---------------------------
385243- port_no(14), port_type(STN), is_trunk(0), route_no(65535), displayName()
385243- srcNum(110), srcIp(192.168.1.174), srcPort(5060)
385243- destNum(112), destIp(192.168.1.175), destPort(11726)
385243- signalIp(192.168.1.175), signalPort(11726), replace_id((nil))
385243- contactUser(110), contactIp(192.168.1.174), contactPort(5060), request_uri()
385243- auth_userid(), CallLeg(0x40f74e28), Uid(0)
385243- pai_id(), privacy(), rpi_id(), pref_id() in TRUNK
385243- p_asserted_id(110)in EXT
385243- diversion(), id(0), is_static(0)
385243---------------------------------------------------------------------------------
385243-[CallIdx:67][Sipm_CallMsgHandler] p_asserted_id(110) in EXT reINVITE
385243-[CallIdx:67][Sipm_SipEvCallMsgSend] SIPM ---> INVITE
385243-[CallIdx:67][Sipm_SipEvCallMsgSend] request uri(192.168.1.175), nat_used(0)
385243-[Sipm_SipUtilSetOtherHeaderInMsg] Allow => INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,REFER,SUBSCRIBER,NOTIFY,MESSAGE,INFO,PRAC
K,UPDATE
385243-[Sipm_SipUtilSetOtherHeaderInMsg] Supported => replaces,UPDATE,INFO
385243-[Sipm_SipUtilSetOtherHeaderInMsg] P-Asserted-Identity => <sip:110@192.168.1.174>
385243-[Sipm_SipCheckContactAddr] user:110, system_ip:192.168.1.174:5060, trans_mode:UDP, URI
385243-=============================================
385243-Send SDP MSG[67] => v=0
o=iPECS-eMG 38524 38524 IN IP4 192.168.1.174
s=iPECS-eMG Call
c=IN IP4 192.168.1.174
t=0 0
m=audio 7000 RTP/AVP 0 111
a=rtpmap:0 PCMU/8000
a=rtpmap:111 X-nt-inforeq/8000
a=sendrecv
385243-=============================================
385243-[Sipm_SipUtilSetOtherHeaderInMsg] User-Agent => Ericsson-LG Enterprise iPECS-eMG eMG80 A.0Kg

[ 28/11/14 20:34:34 ]+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Sent 921 Bytes to 192.168.1.175:11726 by UDP (SendEv)
--------------------------------------------------------------------------------
INVITE sip:112@192.168.1.175:11726 SIP/2.0
From: <sip:110@192.168.1.174>;tag=40f3dd50-ae01a8c0-13c4-65014-eff-6332807-eff
To: <sip:112@192.168.1.175:11726>;tag=5f19916c
Call-ID: 40f74e28-ae01a8c0-13c4-65014-eff-399b55d9-eff
CSeq: 2 INVITE
Via: SIP/2.0/UDP 192.168.1.174:5060;rport;branch=z9hG4bK-f03-3aa694-61ff1903-40efade0
Max-Forwards: 70
Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,REFER,SUBSCRIBER,NOTIFY,MESSAGE,INFO,PRAC
K,UPDATE
Supported: replaces,UPDATE,INFO
P-Asserted-Identity: <sip:110@192.168.1.174>
User-Agent: Ericsson-LG Enterprise iPECS-eMG eMG80 A.0Kg
Contact: <sip:110@192.168.1.174:5060;transport=UDP>
Session-Expires: 1800;refresher=uac
Content-Type: application/sdp
Content-Length: 194

v=0
o=iPECS-eMG 38524 38524 IN IP4 192.168.1.174
s=iPECS-eMG Call
c=IN IP4 192.168.1.174
t=0 0
m=audio 7000 RTP/AVP 0 111
a=rtpmap:0 PCMU/8000
a=rtpmap:111 X-nt-inforeq/8000
a=sendrecv

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

385243-[CallIdx:67][Sipm_SipEvCallReInviteState(s:3)] State Name - Re-Invite Sent

[ 28/11/14 20:34:34 ]===========================================================
Received 333 Bytes from 192.168.1.175:11726 by UDP (ReceiveEv)
--------------------------------------------------------------------------------
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.1.174:5060;rport=5060;branch=z9hG4bK-f03-3aa694-61ff1903-40efade0
To: <sip:112@192.168.1.175:11726>;tag=5f19916c
From: <sip:110@192.168.1.174>;tag=40f3dd50-ae01a8c0-13c4-65014-eff-6332807-eff
Call-ID: 40f74e28-ae01a8c0-13c4-65014-eff-399b55d9-eff
CSeq: 2 INVITE
Content-Length: 0


================================================================================

385255-[Sipm_SipTransportMsgReceivedExt]..Response...
385255-[CallIdx:67][Sipm_SipEvCallMsgReceive] SIPM <--- 100(Method:INVITE(0), reason:Trying)
385255-[CallIdx:67][Sipm_SipEvCallReInviteState(s:7)] State Name - Re-Invite Proceeding

[ 28/11/14 20:34:34 ]===========================================================
Received 662 Bytes from 192.168.1.175:11726 by UDP (ReceiveEv)
--------------------------------------------------------------------------------
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.174:5060;rport=5060;branch=z9hG4bK-f03-3aa694-61ff1903-40efade0
Contact: <sip:112@192.168.1.175:11726>
To: <sip:112@192.168.1.175:11726>;tag=5f19916c
From: <sip:110@192.168.1.174>;tag=40f3dd50-ae01a8c0-13c4-65014-eff-6332807-eff
Call-ID: 40f74e28-ae01a8c0-13c4-65014-eff-399b55d9-eff
CSeq: 2 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
Content-Type: application/sdp
User-Agent: eyeBeam release 1102u stamp 52345
Content-Length: 130

v=0
o=- 3 3 IN IP4 192.168.1.175
s=CounterPath eyeBeam 1.5
c=IN IP4 192.168.1.175
t=0 0
m=audio 45116 RTP/AVP 0
a=sendrecv

================================================================================

385265-[Sipm_SipTransportMsgReceivedExt]..Response...
385265-[CallIdx:67][Sipm_SipEvCallMsgReceive] SIPM <--- 200(Method:INVITE(0), reason:OK)
385265-SDP Msg Construct Parse - SinglePart
385265-=============================================
385265-Receive SDP MSG[67] =>
v=0
o=- 3 3 IN IP4 192.168.1.175
s=CounterPath eyeBeam 1.5
c=IN IP4 192.168.1.175
t=0 0
m=audio 45116 RTP/AVP 0
a=sendrecv
385265-=============================================
385265-[CallIdx:67][Sipm_SipEvCallReInviteState(s:5)] State Name - Re-Invite Remote Accepted
385265-[CallIdx:67][PORT NUMBER : 0x000e, Type:STN] CALL <--- SIPM (200 OK Reinvite)
385265-[CallIdx:67][Sipm_SipEvCallMsgSend] SIPM ---> ACK
385265-[Sipm_SipCheckContactAddr] user:110, system_ip:192.168.1.174:5060, trans_mode:UDP, URI
385265-[Sipm_SipUtilSetOtherHeaderInMsg] User-Agent => Ericsson-LG Enterprise iPECS-eMG eMG80 A.0Kg

[ 28/11/14 20:34:34 ]+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Sent 475 Bytes to 192.168.1.175:11726 by UDP (SendEv)
--------------------------------------------------------------------------------
ACK sip:112@192.168.1.175:11726 SIP/2.0
From: <sip:110@192.168.1.174>;tag=40f3dd50-ae01a8c0-13c4-65014-eff-6332807-eff
To: <sip:112@192.168.1.175:11726>;tag=5f19916c
Call-ID: 40f74e28-ae01a8c0-13c4-65014-eff-399b55d9-eff
CSeq: 2 ACK
Via: SIP/2.0/UDP 192.168.1.174:5060;rport;branch=z9hG4bK-f03-3aa772-69f2d568-40efafa0
Max-Forwards: 70
User-Agent: Ericsson-LG Enterprise iPECS-eMG eMG80 A.0Kg
Contact: <sip:110@192.168.1.174:5060;transport=UDP>
Content-Length: 0


Зараза
Звонок с 110 на 111, отлуп.

Sent 895 Bytes to 192.168.1.171:5060 by UDP (SendEv)
--------------------------------------------------------------------------------
INVITE sip:111@192.168.1.171:5060 SIP/2.0
From: <sip:110@192.168.1.174>;tag=40f3e2c0-ae01a8c0-13c4-65014-f79-4c39fedb-f79
To: <sip:111@192.168.1.171:5060>
Call-ID: 40f75070-ae01a8c0-13c4-65014-f79-6603d065-f79
CSeq: 1 INVITE
Via: SIP/2.0/UDP 192.168.1.174:5060;rport;branch=z9hG4bK-f79-3c745d-1a80a3c8-40efb320
Max-Forwards: 70
Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,REFER,SUBSCRIBER,NOTIFY,MESSAGE,INFO,PRAC
K,UPDATE
P-Asserted-Identity: <sip:110@192.168.1.174>
Supported: replaces,UPDATE,INFO
User-Agent: Ericsson-LG Enterprise iPECS-eMG eMG80 A.0Kg
Contact: <sip:110@192.168.1.174:5060;transport=UDP>
Content-Type: application/sdp
Content-Length: 219

v=0
o=iPECS-eMG 39707 39707 IN IP4 192.168.1.174
s=iPECS-eMG Call
c=IN IP4 192.168.1.174
t=0 0
m=audio 65535 RTP/AVP 0 8 111
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:111 X-nt-inforeq/8000
a=sendrecv

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

397065-[CallIdx:68][Sipm_SipEvCallState(s:01)] OUTGOING - Inviting(reason:LOCAL_INVITING)
397065-[CallIdx:68][PORT NUMBER : 0x000d, Type:STN] CALL <--- SIPM (100 Trying)

[ 28/11/14 20:36:32 ]===========================================================
Received 315 Bytes from 192.168.1.171:5060 by UDP (ReceiveEv)
--------------------------------------------------------------------------------
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


================================================================================

397074-[Sipm_SipTransportMsgReceivedExt]..Response...
397074-[CallIdx:68][Sipm_SipEvCallMsgReceive] SIPM <--- 100(Method:INVITE(0), reason:Trying)
397074-[CallIdx:68][Sipm_SipEvCallState(s:13)] OUTGOING - Proceeding(reason:NOTHING_ALL)

[ 28/11/14 20:36:32 ]===========================================================
Received 401 Bytes from 192.168.1.171:5060 by UDP (ReceiveEv)
--------------------------------------------------------------------------------
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


================================================================================

397079-[Sipm_SipTransportMsgReceivedExt]..Response...
397079-[CallIdx:68][Sipm_SipEvCallMsgReceive] SIPM <--- 488(Method:INVITE(0), reason:Not Acceptable Here)
397079-[CallIdx:68][PORT NUMBER : 0x000d, Type:STN] CALL <--- SIPM (Response 488)
397079-[CallIdx:68][Sipm_SipEvCallMsgSend] SIPM ---> ACK
397079-[Sipm_SipCheckContactAddr] user:, system_ip:192.168.1.174:5060, trans_mode:UDP, URI
397079-[Sipm_SipUtilSetOtherHeaderInMsg] User-Agent => Ericsson-LG Enterprise iPECS-eMG eMG80 A.0Kg

[ 28/11/14 20:36:32 ]+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Sent 471 Bytes to 192.168.1.171:5060 by UDP (SendEv)
--------------------------------------------------------------------------------
ACK sip:111@192.168.1.171:5060 SIP/2.0
From: <sip:110@192.168.1.174>;tag=40f3e2c0-ae01a8c0-13c4-65014-f79-4c39fedb-f79
To: <sip:111@192.168.1.171>;tag=1395545948
Call-ID: 40f75070-ae01a8c0-13c4-65014-f79-6603d065-f79
CSeq: 1 ACK
Via: SIP/2.0/UDP 192.168.1.174:5060;rport;branch=z9hG4bK-f79-3c745d-1a80a3c8-40efb320
Max-Forwards: 70
User-Agent: Ericsson-LG Enterprise iPECS-eMG eMG80 A.0Kg
Contact: <sip:110@192.168.1.174:5060;transport=UDP>
Content-Length: 0


Зараза
Отличия:
110 -> 112: INVITE, RINGING, OK, ACK, INVITE, Trying, ACK
110 -> 111: INVITE, Trying, Not Acceptable Here

INVITE'ы одинаковые вплоть до m=audio 65535.
Зараза
Цитата(Dron @ 17.9.2015, 14:01) *
Если зарегить SIP-софтфон под 111?

Все OK, на софтфон 111 я могу дозвониться с 110.
Зараза
Цитата(Dron @ 17.9.2015, 13:58) *
Попробуйте не COMMON, а что то другое с RTP.

Этот ведь параметр вроде влияет на CO Транки. Нет?
Зараза
В общем проблема очень странная с моей точки зрения. Сначала когда я обнаружил, что не могу прозвониться на SIP-DECT, но могу на софт-фон - грешил на настройку SIP-DECT. Потом когда я обнаружил, что я могу на SIP-DECT прозвониться с софт-фона и Phontage - я озадачился.
Зараза
Техподдержка Panasonic порекомендовала попробовать выключить G.722. Собственно не могу понять, есть ли возможность его выключить на стороне станции.
PGM132 Device Codec Type сделал G.711, рестарт нужен?
harris
Цитата(Зараза @ 18.9.2015, 9:51) *
Техподдержка Panasonic порекомендовала попробовать выключить G.722. Собственно не могу понять, есть ли возможность его выключить на стороне станции.
PGM132 Device Codec Type сделал G.711, рестарт нужен?

Нельзя выключить то, чего нет. Станция eMG в принципе не поддерживает G.722.
Dron
Цитата(harris @ 18.9.2015, 10:21) *
Нельзя выключить то, чего нет. Станция eMG в принципе не поддерживает G.722.

А в Zone Attribute(439) Codec Type он есть.
harris
Цитата(Dron @ 18.9.2015, 10:25) *
А в Zone Attribute(439) Codec Type он есть.

Добавили??? Значит я это упустил, не заметил... sad.gif
harris
Цитата(harris @ 18.9.2015, 10:28) *
Добавили??? Значит я это упустил, не заметил... sad.gif

Да, виноват, добавили...
Зараза
Так как все же выключить G.722, чтобы станция вообще забыла о нем?
ALLeX
А что в логах eMG <-> SIP-DECT ?
По идее АТС при "Trying" должна ломится на 111 с INVATE (которого в логах не видно почему то).
А вообще проблема с "Not Acceptable Here" чаще всего вызвана кодеками... Попробуйте оставить только 1 кодек на вызывающей стороне.
harris
Цитата(Зараза @ 18.9.2015, 13:01) *
Так как все же выключить G.722, чтобы станция вообще забыла о нем?

Имхо, дело не в кодеке 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 с реальным портом дело не доходит... Имхо, как-то так и причину, мне кажется, нужно искать в Панасе.
Зараза
Цитата(harris @ 20.9.2015, 14:14) *
Имхо, дело не в кодеке G.722. Вроде в трассировках он нигде и не встречается, и станция его не предлагает.

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

Цитата(harris @ 20.9.2015, 14:14) *
Если вы обратили внимание, то при вызове SIP абонента от TDM устройства станция всегда работает с применением Re-Invite.

А вот это "всегда" выключить нельзя?
Прочел в ELG_iPECS_eMG80_A&P_st_IS1_1.pdf все, что нашлось по Invite, ничего толком не вижу.
harris
Цитата(Зараза @ 21.9.2015, 7:16) *
А вот это "всегда" выключить нельзя?

Насколько мне известно - нет, нельзя. Это зашито в алгоритме работы станции.
Попробуйте выяснить в тех. поддержке Панаса, может ли это быть его реакция на порт 65535, с чем это связано, и как это преодолеть.
И еще хорошо бы снять снифер Wireshark'ом, чтобы посмотреть и сигнализацию и RTP трафик.
Зараза
Цитата(harris @ 21.9.2015, 14:15) *
И еще хорошо бы снять снифер 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
Dron
Цитата(Зараза @ 21.9.2015, 17:28) *
Используя 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-сети.

Так опять на SIP-DECT, а что при вызове софтфона? В Re-Invite, видимо, наряду с правильным портом и правильный адрес.
Зараза
http://www.artcom.ru/forum/index.php?showt...ost&p=90471
Пост 23. "Почему станция выдает адрес 0.0.0.0 для голосовой связи - ХЗ. Мне повторить это не удалось. "
И таблетки не было.
Зараза
Цитата(Dron @ 21.9.2015, 20:53) *
Так опять на SIP-DECT, а что при вызове софтфона? В Re-Invite, видимо, наряду с правильным портом и правильный адрес.

С софт-фоном не могу ответить сейчас, не представляется возможным проверить. До Re-Invite не доходит, посмотрите дамп, там всего три строки.
Dron
Цитата(Зараза @ 21.9.2015, 18:06) *
С софт-фоном не могу ответить сейчас, не представляется возможным проверить. До Re-Invite не доходит, посмотрите дамп, там всего три строки.

Вам Игорь, вроде разъяснил, в чем может быть проблема. Похоже, панасоник ваш, действительно, на всем этом "спотыкается"...
Dron
Цитата(Зараза @ 21.9.2015, 18:04) *
http://www.artcom.ru/forum/index.php?showt...ost&p=90471
Пост 23. "Почему станция выдает адрес 0.0.0.0 для голосовой связи - ХЗ. Мне повторить это не удалось. "
И таблетки не было.

Снимите сниф вызова софтфона, когда нет отлупа. Давайте посмотрим, что в этом случае.
harris
Цитата(Dron @ 21.9.2015, 18:21) *
Снимите сниф вызова софтфона, когда нет отлупа. Давайте посмотрим, что в этом случае.

Выше была трассировка (не сниф) вызова на софтфон 112. Там все нормально, и есть Re-Invite с реальными адресом и портом.
harris
Цитата(Зараза @ 21.9.2015, 18:06) *
С софт-фоном не могу ответить сейчас, не представляется возможным проверить. До Re-Invite не доходит, посмотрите дамп, там всего три строки.

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

Стоит 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?
Dron
Цитата(Зараза @ 22.9.2015, 12:32) *
Приехал на объект, решил сделать еще раз трассировку. С номера 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 - это что?
Зараза
Цитата(Dron @ 22.9.2015, 16:05) *
107 - это что?

107 как и 110 аналоговый порт. Плотно общаюсь с поддержкой Арткома сейчас, они собрали стенд. И аналогичная ситуация - системник 100 на SIP-абонентов отдает в connection нормальный адрес, все порты аналоговые в базовом блоке отдают при звонке на SIP-абонентов 0.0.0.0. Размышляют над этим.
Dron
Цитата(Зараза @ 22.9.2015, 13:16) *
107 как и 110 аналоговый порт. Плотно общаюсь с поддержкой Арткома сейчас, они собрали стенд. И аналогичная ситуация - системник 100 на SIP-абонентов отдает в connection нормальный адрес, все порты аналоговые в базовом блоке отдают при звонке на SIP-абонентов 0.0.0.0. Размышляют над этим.

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

Вы спросите - а для чего приостановленный вызов? За разработчиков отвечу - в целях экономии, т.е. непродуктивного использования системных кодеков, ведь вызываемый может вообще не ответить, или у вызываемого автохолд, или, не поддерживаемый системой кодек, так зачем задействовать свой кодек, если ещё пока непонятно нужен ли он будет вообще.
Замечено, что Panasonic грешит этим всюду, например новый KX-HDV100 имеет точно такой-же баг (в добавок к ряду других багов).
vldmr
A TCP подключение панас умеет? Попробуйте.
vldmr
Я так понимаю что если имеем 8 IP каналов то и кодеков должно быть свободных 8 для этих каналов и зачем их экономить?
Получается что может не хватить кодеков и система блокируема?
Зараза
Цитата(mikle @ 22.9.2015, 16:53) *
Вы спросите - а для чего приостановленный вызов? За разработчиков отвечу - в целях экономии, т.е. непродуктивного использования системных кодеков, ведь вызываемый может вообще не ответить, или у вызываемого автохолд, или, не поддерживаемый системой кодек, так зачем задействовать свой кодек, если ещё пока непонятно нужен ли он будет вообще.
Замечено, что Panasonic грешит этим всюду, например новый KX-HDV100 имеет точно такой-же баг (в добавок к ряду других багов).

Спасибо за конструктивный комментарий. Собственно про это harris в одном из постов выше писал. И печально, что на стороне LG это нельзя выключить.
Зараза
Цитата(Dron @ 22.9.2015, 16:38) *
У вас System IP Range в 102 программе из той же подсети, что и адрес процессора?

Да, 192.168.1.10 - 192.168.1.254.
Зараза
Цитата(vldmr @ 22.9.2015, 18:46) *
A TCP подключение панас умеет? Попробуйте.

Умеет, пробовал, результат аналогичен.
Зараза
Цитата(mikle @ 22.9.2015, 16:53) *
В SDP с=0.0.0.0 и/или номер порта=65535 реально означает (читайте рекомендации), что система будет ждать ответа вызываемого для того, что бы назначить системный RTP кодек.

Вы имеете в виду 5.4, RFC 6337?
harris
Цитата(Зараза @ 22.9.2015, 16:58) *
Спасибо за конструктивный комментарий. Собственно про это harris в одном из постов выше писал. И печально, что на стороне LG это нельзя выключить.

А почему вас печалит LG, а не Панас?? blink.gif smile.gif Станция же действует в рамках протокола. Почему Панас не поддерживает стандартную процедуру?? Уже неоднократно случалось, что баги Панаса (H.323) приходилось обходить на стороне LG. Может, пора и на строне Панаса немного подкрутить... smile.gif
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Форум IP.Board © 2001-2024 IPS, Inc.