Hello,
Please refer to sip trace: http://pastebin.org/86010.
On LINE 294, PSTN sends the Re-INVITE
On LINE 378, REGISTRAR sends 200 OK to SIP SBC (with RFC 1918 Address, that is being relayed from the UAC that also sends this same address upon 200 OK of the Re-Invite).
Let me know if this makes sense, this trace was taken on the SBC.
El Miércoles, 3 de Febrero de 2010, Brandon Armstead escribió:
Hello,
Please refer to sip trace: http://pastebin.org/86010.
On LINE 294, PSTN sends the Re-INVITE
And there is the error (in PSTN_PROXY server):
U +0.000104 MY_SBC_PROXY:5060 -> PSTN_PROXY_IP:5060 SIP/2.0 200 OK. To: "" sip:7143642300@sip-dev01.myproxy.com;tag=437a03f314fce56fo0. From: sip:8778242288@sip- dev01.myproxy.com;tag=a9d5ed0-13c4-4b69c983-4c452b6f-2d9ebe5b. Call-ID: 4cf8f943-c7a1f05f@10.160.100.32. CSeq: 1 INVITE. Via: SIP/2.0/UDP PSTN_PROXY_IP:5060;rport=5060;received=208.94.157.10;branch=z9hG4bK-48f8c-4b69cd08-4c52ec66-35ca5cf4. Record-Route: sip:MY_REGISTRAR_PROXY;lr=on;ftag=a9d5ed0-13c4-4b69c983-4c452b6f-2d9ebe5b. Record-Route: sip:MY_SBC_PROXY;lr=on;ftag=a9d5ed0-13c4-4b69c983-4c452b6f-2d9ebe5b. Contact: "" sip:7143642300@10.160.100.32:5060. Server: Linksys/PAP2T-5.1.6(LS). Content-Length: 255. Content-Type: application/sdp.
v=0. o=- 130969 130969 IN IP4 10.160.100.32. s=-. c=IN IP4 10.160.100.32. t=0 0. m=audio 16476 RTP/AVP 0 100 101. a=rtpmap:0 PCMU/8000. a=rtpmap:100 NSE/8000. a=fmtp:100 192-193. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:20. a=sendrecv.
U +0.031146 PSTN_PROXY_IP:5060 -> MY_SBC_PROXY:5060 ACK sip:7143642300@10.160.100.32:5060 SIP/2.0. From: sip:8778242288@sip- dev01.myproxy.com;tag=a9d5ed0-13c4-4b69c983-4c452b6f-2d9ebe5b. To: "" sip:7143642300@sip-dev01.myproxy.com;tag=437a03f314fce56fo0. Call-ID: 4cf8f943-c7a1f05f@10.160.100.32. CSeq: 1 ACK. Via: SIP/2.0/UDP PSTN_PROXY_IP:5060;branch=z9hG4bK-48f97-4b69cd08-4c52ed08-32120aec. Max-Forwards: 69. Contact: sip:18778242288@PSTN_PROXY_IP:5060;transport=udp. Route: sip:MY_SBC_PROXY;lr;ftag=437a03f314fce56fo0. Route: sip:MY_REGISTRAR_PROXY;lr;ftag=437a03f314fce56fo0. Content-Length: 0.
This is a re-INVITE and the UA (MY_SBC_PROXY) replies a 200 with the natted Contact (as usual). Then the PSTN_PROXY server creates the ACK by setting such private SIP URI as RURI. This is incorrect, this RURI *MUST* be the remote target set in the initial INVITE/200 (the Contact the UA received when the dialog was established). This remote target cannot change within a dialog (as Alex and me have explained in this thread).
PSTN_PROXY is buggy.
On 02/03/2010 04:44 PM, Iñaki Baz Castillo wrote:
This is a re-INVITE and the UA (MY_SBC_PROXY) replies a 200 with the natted Contact (as usual). Then the PSTN_PROXY server creates the ACK by setting such private SIP URI as RURI. This is incorrect, this RURI *MUST* be the remote target set in the initial INVITE/200 (the Contact the UA received when the dialog was established). This remote target cannot change within a dialog (as Alex and me have explained in this thread).
I do not have statistics, but anecdotally speaking, I have encountered this problem so often and had to work around it by re-fixing the Contact in the sequential INVITE or reply to it that I did not even know it was an incorrect behaviour! I suspect it is rather common.
El Miércoles, 3 de Febrero de 2010, Alex Balashov escribió:
On 02/03/2010 04:44 PM, Iñaki Baz Castillo wrote:
This is a re-INVITE and the UA (MY_SBC_PROXY) replies a 200 with the natted Contact (as usual). Then the PSTN_PROXY server creates the ACK by setting such private SIP URI as RURI. This is incorrect, this RURI *MUST* be the remote target set in the initial INVITE/200 (the Contact the UA received when the dialog was established). This remote target cannot change within a dialog (as Alex and me have explained in this thread).
I do not have statistics, but anecdotally speaking, I have encountered this problem so often and had to work around it by re-fixing the Contact in the sequential INVITE or reply to it that I did not even know it was an incorrect behaviour! I suspect it is rather common.
I always fix Contact also for re-INVITE so I don't know about statistics :)
Iñaki Baz Castillo wrote:
El Miércoles, 3 de Febrero de 2010, Brandon Armstead escribió:
Hello,
Please refer to sip trace: http://pastebin.org/86010.
On LINE 294, PSTN sends the Re-INVITE
And there is the error (in PSTN_PROXY server):
U +0.000104 MY_SBC_PROXY:5060 -> PSTN_PROXY_IP:5060 SIP/2.0 200 OK. To: "" sip:7143642300@sip-dev01.myproxy.com;tag=437a03f314fce56fo0. From: sip:8778242288@sip- dev01.myproxy.com;tag=a9d5ed0-13c4-4b69c983-4c452b6f-2d9ebe5b. Call-ID: 4cf8f943-c7a1f05f@10.160.100.32. CSeq: 1 INVITE. Via: SIP/2.0/UDP PSTN_PROXY_IP:5060;rport=5060;received=208.94.157.10;branch=z9hG4bK-48f8c-4b69cd08-4c52ec66-35ca5cf4. Record-Route: sip:MY_REGISTRAR_PROXY;lr=on;ftag=a9d5ed0-13c4-4b69c983-4c452b6f-2d9ebe5b. Record-Route: sip:MY_SBC_PROXY;lr=on;ftag=a9d5ed0-13c4-4b69c983-4c452b6f-2d9ebe5b. Contact: "" sip:7143642300@10.160.100.32:5060. Server: Linksys/PAP2T-5.1.6(LS). Content-Length: 255. Content-Type: application/sdp.
v=0. o=- 130969 130969 IN IP4 10.160.100.32. s=-. c=IN IP4 10.160.100.32. t=0 0. m=audio 16476 RTP/AVP 0 100 101. a=rtpmap:0 PCMU/8000. a=rtpmap:100 NSE/8000. a=fmtp:100 192-193. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:20. a=sendrecv.
U +0.031146 PSTN_PROXY_IP:5060 -> MY_SBC_PROXY:5060 ACK sip:7143642300@10.160.100.32:5060 SIP/2.0. From: sip:8778242288@sip- dev01.myproxy.com;tag=a9d5ed0-13c4-4b69c983-4c452b6f-2d9ebe5b. To: "" sip:7143642300@sip-dev01.myproxy.com;tag=437a03f314fce56fo0. Call-ID: 4cf8f943-c7a1f05f@10.160.100.32. CSeq: 1 ACK. Via: SIP/2.0/UDP PSTN_PROXY_IP:5060;branch=z9hG4bK-48f97-4b69cd08-4c52ed08-32120aec. Max-Forwards: 69. Contact: sip:18778242288@PSTN_PROXY_IP:5060;transport=udp. Route: sip:MY_SBC_PROXY;lr;ftag=437a03f314fce56fo0. Route: sip:MY_REGISTRAR_PROXY;lr;ftag=437a03f314fce56fo0. Content-Length: 0.
This is a re-INVITE and the UA (MY_SBC_PROXY) replies a 200 with the natted Contact (as usual). Then the PSTN_PROXY server creates the ACK by setting such private SIP URI as RURI. This is incorrect, this RURI *MUST* be the remote target set in the initial INVITE/200 (the Contact the UA received when the dialog was established). This remote target cannot change within a dialog (as Alex and me have explained in this thread).
rfc3261 section 12.2. says that target refreshing is allowed.
PSTN_PROXY is buggy.
maybe RFC 3261 is buggy :-)
El Miércoles, 3 de Febrero de 2010, Klaus Darilion escribió:
This is a re-INVITE and the UA (MY_SBC_PROXY) replies a 200 with the natted Contact (as usual). Then the PSTN_PROXY server creates the ACK by setting such private SIP URI as RURI. This is incorrect, this RURI *MUST* be the remote target set in the initial INVITE/200 (the Contact the UA received when the dialog was established). This remote target cannot change within a dialog (as Alex and me have explained in this thread).
rfc3261 section 12.2. says that target refreshing is allowed.
PSTN_PROXY is buggy.
maybe RFC 3261 is buggy :-)
My brain is buggy today XD
Yes, it seems that RFC 3261 allows remote target being changed within a dialog. It could be useful for mobility (I imagine a WiFi SIP phone which changes its IP in middle of a call so it must send a re-INVITE to indicate the remote endpoint about its new signalling and media address). So cool...
-
Alex Balashov -
Brandon Armstead -
Iñaki Baz Castillo -
Klaus Darilion