Версия для печати темы

Автор: Зараза 17.9.2015, 8:58

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

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

Автор: Зараза 17.9.2015, 9:35

Звонок с 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

Автор: Зараза 17.9.2015, 9:37

Звонок с аналогового на 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

Автор: Зараза 17.9.2015, 9:38

Invite'ы абсолютно одинаковые, но в первом случае Ringing, во втором случае Not Acceptable.

Автор: Dron 17.9.2015, 9:55

А что у вас с VoIP каналами? CO VoIP Mode?

Автор: Зараза 17.9.2015, 10:10

VOIU channel 1 copy
Available VOIU 3 channels

CO VoIP Mode: Common

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

Автор: Dron 17.9.2015, 10:29

Порты в сети не режутся. Вот, к примеру, в ваших трейсах при вызове с Phontage в invite порт RTP 8006, а при вызове с аналогового абонента - 65535.

Автор: Зараза 17.9.2015, 10:40

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

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

Автор: Зараза 17.9.2015, 10:48

Кстати, да, а почему такой странный номер порта? В iPECS_PortUsage_eMG80.pdf вообще такого диапазона нет.

Автор: Dron 17.9.2015, 10:58

Попробуйте не COMMON, а что то другое с RTP.

Автор: Dron 17.9.2015, 11:01

И в чем разница между вызовами на SIP-DECT 111 и на SIP-софтфон 112? Если зарегить SIP-софтфон под 111?

Автор: Зараза 17.9.2015, 11:19

См. ниже. Пост 15 - резюме.

Автор: Зараза 17.9.2015, 11:20

Звонок с 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

Автор: Зараза 17.9.2015, 11:22

Звонок с 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

Автор: Зараза 17.9.2015, 11:25

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

INVITE'ы одинаковые вплоть до m=audio 65535.

Автор: Зараза 17.9.2015, 11:38

Все OK, на софтфон 111 я могу дозвониться с 110.

Автор: Зараза 17.9.2015, 11:39

Этот ведь параметр вроде влияет на CO Транки. Нет?

Автор: Зараза 17.9.2015, 11:40

В общем проблема очень странная с моей точки зрения. Сначала когда я обнаружил, что не могу прозвониться на SIP-DECT, но могу на софт-фон - грешил на настройку SIP-DECT. Потом когда я обнаружил, что я могу на SIP-DECT прозвониться с софт-фона и Phontage - я озадачился.

Автор: Зараза 18.9.2015, 9:51

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

Автор: harris 18.9.2015, 10:21

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

Автор: Dron 18.9.2015, 10:25

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

Автор: harris 18.9.2015, 10:28

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

Автор: harris 18.9.2015, 10:31

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

Автор: Зараза 18.9.2015, 13:01

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

Автор: ALLeX 19.9.2015, 23:31

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

Автор: harris 20.9.2015, 11:14

Имхо, дело не в кодеке 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 с реальным портом дело не доходит... Имхо, как-то так и причину, мне кажется, нужно искать в Панасе.

Автор: Зараза 21.9.2015, 7:16

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


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

Автор: harris 21.9.2015, 11:15

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

Автор: Зараза 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-сети.

Автор: Зараза 21.9.2015, 17:48

Нахожусь не возле станции, поэтому поднял 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:53

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

Автор: Зараза 21.9.2015, 18:04

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

Автор: Зараза 21.9.2015, 18:06

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

Автор: Dron 21.9.2015, 18:09

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

Автор: Dron 21.9.2015, 18:21

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

Автор: harris 21.9.2015, 18:47

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

Автор: harris 21.9.2015, 23:31

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

Автор: Зараза 22.9.2015, 3:44

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

Автор: Зараза 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?

Автор: Dron 22.9.2015, 13:05

107 - это что?

Автор: Зараза 22.9.2015, 13:16

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

Автор: Dron 22.9.2015, 13:38

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

Автор: mikle 22.9.2015, 13:53

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

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

Автор: vldmr 22.9.2015, 15:46

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

Автор: vldmr 22.9.2015, 15:58

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

Автор: Зараза 22.9.2015, 16:58

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

Автор: Зараза 22.9.2015, 16:59

Да, 192.168.1.10 - 192.168.1.254.

Автор: Зараза 22.9.2015, 17:00

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

Автор: Зараза 22.9.2015, 17:08

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

Автор: harris 22.9.2015, 17:44

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

Автор: Зараза 22.9.2015, 17:45

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

Автор: Зараза 24.9.2015, 15:37

Я получил внятный ответ в канале поддержки 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 24.9.2015, 15:43

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

Автор: Зараза 24.9.2015, 15:55

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

Автор: mikle 24.9.2015, 17:47

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

Автор: Зараза 24.9.2015, 17:59

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

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

Автор: mikle 24.9.2015, 18:00

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

Автор: mikle 24.9.2015, 18:11

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

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

Автор: Зараза 24.9.2015, 18:12

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

Автор: Зараза 24.9.2015, 18:15

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

Автор: mikle 24.9.2015, 18:23

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

Автор: mikle 24.9.2015, 18:26

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

Автор: Зараза 24.9.2015, 18:35

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

Автор: Зараза 24.9.2015, 18:36

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

Автор: Зараза 24.9.2015, 18:42

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

Автор: Dron 25.9.2015, 9:51

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

Автор: mikle 25.9.2015, 10:05

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

Автор: mikle 25.9.2015, 13:14

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

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

Автор: Серый 26.9.2015, 13:44

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

Автор: harris 26.9.2015, 15:01

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

Автор: mikle 27.9.2015, 10:44

См RFC 3605

Автор: Серый 27.9.2015, 23:43

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

Автор: harris 28.9.2015, 7:52

Сергей! Насколько следует из тестов, которые провел уваж. Mikle, проблема не в отсутствии поддержки RTCP у данного телефона, а только в том, что в телефоне есть один маленький баг:
- телефон не обрабатывает RTP порт 65535. В рекомендациях сказано, что диапазон портов может быть от 1024 по 65535 ВКЛЮЧИТЕЛЬНО. Но телефон обрабатывает от 1024 ДО 65535. Т.е. 65535 просто выпал из диапазона, и все. ИМХО, выглядит это, как стандартная ошибка программиста.
- я предполагаю, что корейцы не будут вносить изменения в софт ради одной модели телефона, или одного производителя. Все остальные телефоны других производителей спокойно отрабатывают порт 655353. Впрочем, за официальным ответом разработчиков нужно обращаться к Михаилу.

Автор: Серый 28.9.2015, 9:53

Игорь, вносить изменения для устаревшей модели, согласен, не нужно.
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 28.9.2015, 10:21

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

Автор: Серый 28.9.2015, 11:38

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

Автор: harris 28.9.2015, 16:28

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

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

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

Автор: harris 28.9.2015, 16:39

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

Автор: Зараза 28.9.2015, 20:42

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

Автор: Серый 29.9.2015, 9:09

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

Автор: mikle 29.9.2015, 9:16

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

Автор: mikle 30.9.2015, 11:29

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

Автор: Зараза 30.9.2015, 12:43

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

Автор: mikle 30.9.2015, 12:55

Другой коварный вопрос - Будет ли Панас так работать?
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 Панас шлёт на один и тот-же порт на одном и том-же адресе!
И ничего его не смущает...

Автор: Зараза 30.9.2015, 13:51

На подобные вопросы поддержка Panasonic не хочет отвечать. Они просто говорят, дайте RFC в соответствии с которым, с вашей точки зрения, мы что-то делаем неправильно. Я дал ссылку на 3605, но есть предположения, что получу в ответ что-то вроде: "Читая 3605, находим - The RTCP attribute MAY be used as a media level attribute. MAY это не значит MUST или SHOULD и значит это вовсе не требование и мы можем игнорировать это поле и считать RTCP как +1 от RTP, а +1 к 65535 не легален".

Автор: Зараза 30.9.2015, 13:52

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

Можно дамп?

Автор: mikle 30.9.2015, 14:21

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

Автор: Зараза 30.9.2015, 17:40

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

Автор: mikle 30.9.2015, 19:12

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

Автор: Зараза 30.9.2015, 20:11

Из pdf в виде текста не копируется, вставлять картинку не хочу.
Посмотрите в http://cs.psn-web.net/support/sipphone_net/download/HDV1/manual/hdv100/ag/HDV100_AG(ru)_ZA.pdf
раздел 5.3.23

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

Автор: mikle 1.10.2015, 10:48

1) Судя из названия этот параметр отвечает за проверку приходящих RTP пакетов на предмет последующего преобразования в аудио. Проигрывать или отбрасывать. По умолчанию проигрывает со всех источников - с адресов и портов не соответствующих SDP, хотя должно быть все наоборот.
2) Проверил ваше предположение. Выставил RTP_TARGET_CHECK=3 в ConfigKX-HDV100.cfg, загрузил ConfigKX-HDV100.cfg.
Ничего не изменилось. Как 65535 не понимает, так и не понимает.

Вывод - RTP_TARGET_CHECK в данной модели вообще не поддерживается. Японцы закладывают всё что только можно на будущее...

Автор: Зараза 3.10.2015, 5:02

Запрос о проблеме отклонения INVITE с портом 65535 отправлен на завод Panasonic. Жду результата.

Автор: Зараза 10.11.2015, 20:00

В общем получен был ответ на уровне: да, есть ограничение в RTP порт 65535, да, в документации ничего нет, но в документацию будет внесено. Все остальные доводы про зачем вычислять RTCP как RTP+1, если RTCP порт в явном виде указывается в SDP - ушли мимо. Можно закрыть вопрос совместимости DECT Panasonic с АТС LG. Несовместимо.

Автор: harris 10.11.2015, 22:09

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

Автор: mikle 11.11.2015, 9:33

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

Автор: mikle 17.11.2015, 9:50

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

Автор: Зараза 17.11.2015, 15:28

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

Автор: mikle 17.11.2015, 16:30

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

Автор: Зараза 18.11.2015, 5:13

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

Автор: mikle 10.12.2015, 18:29

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

Автор: Alex71 11.3.2016, 15:43

Проблема полностью совпала с вашей темой.
Установил на 80-ку фазу 2. Вот что получил:
1. Поменялись порты на VOIP с 70** на 71**(очень актуально, если АТС за натом и подключена транком)
2. Появилась возможность звонить с аналоговых телефонов на SIP-DECT Panasonic KX-TGP500 после некой процедуры. На каждый аналоговый или цифровой порт нужно сделать звонок с KX-TGP500(если Panasonic-ов несколько, звонок достаточно сделать с любого одного), причем на аналоговых (цифровых) телефонах должно установиться соединение. После этого все работает до следующей перезагрузки станции. После рестарта процедуру нужно повторить.

Автор: Alex71 11.3.2016, 15:45

Проблема полностью совпала с вашей темой.
Установил на 80-ку фазу 2. Вот что получил:
1. Поменялись порты на VOIP с 70** на 71**(очень актуально, если АТС за натом и подключена транком)
2. Появилась возможность звонить с аналоговых телефонов на SIP-DECT Panasonic KX-TGP500 после некой процедуры. На каждый аналоговый или цифровой порт нужно сделать звонок с KX-TGP500(если Panasonic-ов несколько, звонок достаточно сделать с любого одного), причем на аналоговых (цифровых) телефонах должно установиться соединение. После этого все работает до следующей перезагрузки станции. После рестарта процедуру нужно повторить.

Автор: mikle 11.3.2016, 16:11

Мдя... Подтверждаю - Нужно хотябы раз ответить на входящий вызов, тогда всё наладится...
Ща пинать буду мальцов....

Автор: toha1525 10.6.2016, 12:23

Подскажите проблему решили?
Фазу2 залили, но проблема с телефонами HDV100 не ушла

Автор: mikle 10.6.2016, 12:32

Решили окончательно и бесповоротно на самых последних версиях:
2.0.18
2.1.6

Автор: toha1525 10.6.2016, 12:54

на этой версии я правильно понял, проблема решена?

Автор: mikle 10.6.2016, 12:55

Нет конечно - это версии фазы 1, тем более 2015 года. (Старьё)

Автор: toha1525 10.6.2016, 13:13

прошу прощения, прикрепил совсем не то, правильная
 IMG_20160610_130202.bmp ( 535,84 килобайт ) : 8

Автор: mikle 10.6.2016, 13:21

Что-то картинка не загружается.

Автор: AXEL 10.6.2016, 13:43

Ссылку на версию2,1,6 отправил на почту

Автор: toha1525 10.6.2016, 16:31

спасибо, вылечилось