3-d Party SIP Опции

[Зараза]

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

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

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

[Зараза]

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

VOIU channel 1 copy
Available VOIU 3 channels

CO VoIP Mode: Common

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

[Dron]

VOIU channel 1 copy
Available VOIU 3 channels

CO VoIP Mode: Common

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

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

[Зараза]

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

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

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

[Зараза]

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

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

[Dron]

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

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

[Dron]

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

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

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

[Зараза]

И в чем разница между вызовами на 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.

[Зараза]

Если зарегить SIP-софтфон под 111?

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

[Зараза]

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

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

[Зараза]

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

[Зараза]

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

[harris]

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

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

[Dron]

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

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

[harris]

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

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

[harris]

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

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

[Зараза]

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

[ALLeX]

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

[harris]

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

[Зараза]

Имхо, дело не в кодеке G.722. Вроде в трассировках он нигде и не встречается, и станция его не предлагает.

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

Если вы обратили внимание, то при вызове SIP абонента от TDM устройства станция всегда работает с применением Re-Invite.

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

[harris]

А вот это "всегда" выключить нельзя?

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

[Зараза]

И еще хорошо бы снять снифер 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-сети.

Прикрепленные файлы

 107_113.zip ( 997 байт ) Кол-во скачиваний: 2

 

[Зараза]

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

Используя 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 для голосовой связи - ХЗ. Мне повторить это не удалось. "
И таблетки не было.

[Зараза]

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

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

[Dron]

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

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

[Dron]

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

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

[harris]

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

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

[harris]

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

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

[Зараза]

Вернемся к вопросу, который вам выше задавал уваж. 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?

Прикрепленные файлы

 trace.zip ( 68,48 килобайт ) Кол-во скачиваний: 1

 

[Dron]

Приехал на объект, решил сделать еще раз трассировку. С номера 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 - это что?

[Зараза]

107 - это что?

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

[Dron]

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 для этих каналов и зачем их экономить?
Получается что может не хватить кодеков и система блокируема?

[Зараза]

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

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

[Зараза]

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

Да, 192.168.1.10 - 192.168.1.254.

[Зараза]

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

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

[Зараза]

В SDP с=0.0.0.0 и/или номер порта=65535 реально означает (читайте рекомендации), что система будет ждать ответа вызываемого для того, что бы назначить системный RTP кодек.

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

[harris]

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

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

[Зараза]

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

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

[Зараза]

Может, пора и на строне Панаса немного подкрутить...

Я получил внятный ответ в канале поддержки Panasonic'а.

RFC 2327 (SDP)
The second sub-field is the transport port to which the media stream will be sent. The meaning of the transport port depends on the network being used as specified in the relevant "c" field and on the transport protocol defined in the third sub-field. Other
ports used by the media application (such as the RTCP port, see [2]) should be derived algorithmically from the base media port. Note: For transports based on UDP, the value should be in the range 1024 to 65535 inclusive. For RTP compliance it SHOULD be an EVEN number.

SHOULD и EVEN я выделил.
Вот это в INVITE: m=audio 65535 RTP/AVP 0 8, не соответствует указанному RFC, так как номер порта нечетный.

[Dron]

Я получил внятный ответ в канале поддержки Panasonic'а.
RFC 2327 (SDP)
The second sub-field is the transport port to which the media stream will be sent. The meaning of the transport port depends on the network being used as specified in the relevant "c" field and on the transport protocol defined in the third sub-field. Other
ports used by the media application (such as the RTCP port, see [2]) should be derived algorithmically from the base media port. Note: For transports based on UDP, the value should be in the range 1024 to 65535 inclusive. For RTP compliance it SHOULD be an EVEN number.

SHOULD и EVEN я выделил.
Вот это в INVITE: m=audio 65535 RTP/AVP 0 8, не соответствует указанному RFC, так как номер порта нечетный.

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

[Зараза]

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

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

[mikle]

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

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

[Зараза]

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

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

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

[mikle]

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

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

[mikle]

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

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

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

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

[Зараза]

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

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

[Зараза]

Хорошо, подойдём с другой стороны к Панасонику. В SDP в атрибутах можно "в лоб" указать номер порта RTCP (RFC3261).
Вопрос к Панасонику - обработает ли он такой вызов?
m=audio 65535 RTP/AVP 8
a=rtcp:65534

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

[mikle]

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

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

Прикрепленные файлы

 Panas.GIF ( 55,31 килобайт ) Кол-во скачиваний: 22

 

[mikle]

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

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

[Зараза]

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

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

[Зараза]

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

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

[Зараза]

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

[Dron]

Сейчас сможете?
На всякий случай с регистрацией - любой аккаунт.

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

[mikle]

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

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

Прикрепленные файлы

 Panasonic_KX_TG600_RTCP_enable.rar ( 2,05 килобайт ) Кол-во скачиваний: 3

 

[mikle]

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

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

[Серый]

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

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

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

[harris]

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

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

[mikle]

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

См RFC 3605

[Серый]

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

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

[harris]

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

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

[Серый]

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

Игорь, вносить изменения для устаревшей модели, согласен, не нужно.
For transports based on UDP, the value should be in the range
1024 to 65535 inclusive. For RTP compliance it should be an even
number.
Допустим, при парном назначении портов какой порт будет следующим после 65535?

[harris]

Игорь, вносить изменения для устаревшей модели, согласен, не нужно.
For transports based on UDP, the value should be in the range
1024 to 65535 inclusive. For RTP compliance it should be an even
number.
Допустим, при парном назначении портов какой порт будет следующим после 65535?

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

[Серый]

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

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

[harris]

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

Что считать "правильными" данными?? Панас нормально отрабатывает 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]

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

[Зараза]

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

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

[Серый]

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

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

[mikle]

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

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

[mikle]

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

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

Прикрепленные файлы

 rtp_rtcp65533_rtp_rtcp65535.rar ( 135,98 килобайт ) Кол-во скачиваний: 0

 

[Зараза]

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

[mikle]

Другой коварный вопрос - Будет ли Панас так работать?
v=0
o=MZHSIP 1000 1032 IN IP4 61.41.111.69
s=MZHSIP
c=IN IP4 61.41.111.69
t=0 0
m=audio 5060 RTP/AVP 8
a=rtcp:5060 IN IP4 61.41.111.69
a=rtpmap:8 PCMA/8000
a=ptime:20
a=sendrecv

Ответ - работает! SIP cигнализацию, rtp, rtcp Панас шлёт на один и тот-же порт на одном и том-же адресе!
И ничего его не смущает...

[Зараза]

Как Вы объясните, то что во втором случае вызов не обслужен, если он обслужен в первом?

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

[Зараза]

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

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

Можно дамп?

[mikle]

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

Можно дамп?

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

Прикрепленные файлы

 sip_rtp_rtcp_5060.rar ( 171,48 килобайт ) Кол-во скачиваний: 2

 

[Зараза]

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

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

[mikle]

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

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

[Зараза]

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

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

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

[mikle]

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

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

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

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

[Зараза]

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

[Зараза]

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

[harris]

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

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

[mikle]

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

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

[mikle]

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

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

[Зараза]

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

[mikle]

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

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

[Зараза]

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

[mikle]

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

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