3 Feb
2010
3 Feb
'10
10:35 p.m.
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.
3 Feb
3 Feb
10:44 p.m.
New subject: [Kamailio-Users] Loose Route / Re-Invite (brandon@cryy.com)
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(a)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(a)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.
--
Iñaki Baz Castillo <ibc(a)aliax.net>
10:49 p.m.
New subject: [Kamailio-Users] Loose Route / Re-Invite (brandon@cryy.com)
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.
--
Alex Balashov - Principal
Evariste Systems LLC
Tel : +1 678-954-0670
Direct : +1 678-954-0671
Web : http://www.evaristesys.com/
10:56 p.m.
New subject: [Kamailio-Users] Loose Route / Re-Invite (brandon@cryy.com)
El Miércoles, 3 de Febrero de 2010, Alex Balashov escribió:
On 02/03/2010 04:44 PM, Iñaki Baz Castillo wrote:
I always fix Contact also for re-INVITE so I don't know about statistics :)
--
Iñaki Baz Castillo <ibc(a)aliax.net>
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. 
11:47 p.m.
New subject: [Kamailio-Users] Loose Route / Re-Invite (brandon@cryy.com)
Iñaki Baz Castillo wrote:
El Miércoles, 3 de Febrero de 2010, Brandon Armstead
escribió:
rfc3261 section 12.2. says that target refreshing is allowed.
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(a)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(a)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.
maybe RFC 3261 is buggy :-)
4 Feb
4 Feb
12:04 a.m.
New subject: [Kamailio-Users] Loose Route / Re-Invite (brandon@cryy.com)
El Miércoles, 3 de Febrero de 2010, Klaus Darilion escribió:
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...
--
Iñaki Baz Castillo <ibc(a)aliax.net>
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 :-)
5371
days inactive
5371
days old
5 comments
4 participants
participants (4)
-
Alex Balashov -
Brandon Armstead -
Iñaki Baz Castillo -
Klaus Darilion