Hello,
The configuration is:
Jitsi #1 registered with sip2sip.info Jitsi #2 registered with my server(s) (Kamailio edge proxy and Kamailio registrar) on Amazon AWS running Kamailio from git master
I make a call from Jitsi #1 to Jitsi #2 (there are SRV records for my domain in Amazon Route 53 so that sip2sip.info can find my servers). The flow of the call is:
Jitsi #1 -> sip2sip.info -> Kamailio edge proxy -> Kamailio registrar -> Kamailio edge proxy -> Jitsi #2
The calls do not get established properly because the ACK is not correctly routed. Calls between two Jitsi instances registered on my servers works. Calls from Jitsi #2 to Jitsi #1 (my servers to sip2sip.info) also work. This problem occurs whatever the value of the "enable_double_rr" modparam.
The 200 OK (INVITE) sent from my servers back to sip2sip.info looks OK and has a valid looking route-set:
SIP/2.0 200 OK To: <sip:...callee...@...callee domain...>;tag=e5116094 Via: SIP/2.0/UDP 81.23.228.129:5060;rport=5060;branch=z9hG4bKdb93.87290485.0;i=0efbc,SIP/2.0/TLS 192.168.0.135:52379;rport=52379;received=a.b.c.d;branch=z9hG4bK-363631-23ca624fe9c119f229080992ed4fc143 Record-Route: sip:Rlwj4KMCy9UUUAMK9JufE8VamABismk=@e.f.g.h:5061;transport=tls;r2=on;lr=on,sip:Rlwj4KMCy9UUUAMK9JufE8VamABismk=@10.244.155.159:5080;transport=tcp;r2=on;lr=on,sip:10.101.62.154;transport=tcp;lr=on,sip:10.244.155.159:5080;transport=tcp;r2=on;lr=on,sip:e.f.g.h;r2=on;lr=on,sip:81.23.228.129;r2=on;lr;ftag=2d246de3;did=989.4a20eb73,sip:81.23.228.129:5061;transport=tls;r2=on;lr;ftag=2d246de3;did=989.4a20eb73 CSeq: 2 INVITE Call-ID: 38135c0b82a8a7d571352350d207b943@0:0:0:0:0:0:0:0 From: "Caller" sip:...caller...@sip2sip.info;tag=2d246de3 Contact: "callee" <sip:...callee...@10.6.201.224:60847;transport=tls;registering_acc=...callee domain...> User-Agent: Jitsi2.3.4622.9647Linux Content-Type: application/sdp Content-Length: 838
...lots of SDP...
The ACK from sip2sip.info to my servers looks OK too:
ACK sip:...callee...@174.129.184.181:5060;transport=tls;registering_acc=...callee domain... SIP/2.0 Call-ID: 38135c0b82a8a7d571352350d207b943@0:0:0:0:0:0:0:0 CSeq: 2 ACK Via: SIP/2.0/UDP 81.23.228.129:5060;branch=z9hG4bKdb93.87290485.2;i=0efbc Via: SIP/2.0/TLS 192.168.0.135:52379;rport=52379;received=a.b.c.d;branch=z9hG4bK-363631-212696616e66a14286e3165485387895 From: "Caller" sip:...caller...@sip2sip.info;tag=2d246de3 To: "callee" <sip:...callee...@...callee domain...>;tag=e5116094 Max-Forwards: 69 Route: sip:e.f.g.h;r2=on;lr=on,sip:10.244.155.159:5080;transport=tcp;r2=on;lr=on,sip:10.101.62.154;transport=tcp;lr=on,sip:Rlwj4KMCy9UUUAMK9JufE8VamABismk=@10.244.155.159:5080;transport=tcp;r2=on;lr=on,sip:Rlwj4KMCy9UUUAMK9JufE8VamABismk=@e.f.g.h:5061;transport=tls;r2=on;lr=on Contact: "Caller" sip:...caller...@90.152.0.102:52379;transport=tls;registering_acc=sip2sip_info User-Agent: Jitsi2.2.4603.9615Windows 7 Content-Length: 0
But the ACK from from my edge proxy to my registrar looks very broken:
ACK sip:Rlwj4KMCy9UUUAMK9JufE8VamABismk=@e.f.g.h:5061;transport=tls;r2=on;lr=on SIP/2.0 Call-ID: 38135c0b82a8a7d571352350d207b943@0:0:0:0:0:0:0:0 CSeq: 2 ACK Via: SIP/2.0/TCP e.f.g.h:5060;branch=z9hG4bKdb93.444f42f24139f6dc512d70f61ca64be4.0 Via: SIP/2.0/UDP 81.23.228.129:5060;rport=5060;branch=z9hG4bKdb93.87290485.2;i=0efbc Via: SIP/2.0/TLS 192.168.0.135:52379;rport=52379;received=a.b.c.d;branch=z9hG4bK-363631-212696616e66a14286e3165485387895 From: "Caller" sip:...caller...@sip2sip.info;tag=2d246de3 To: "callee" <sip:...callee...@...callee domain...>;tag=e5116094 Max-Forwards: 16 Route: sip:10.244.155.159:5080;transport=tcp;r2=on;lr=on,sip:10.101.62.154;transport=tcp;lr=on,sip:Rlwj4KMCy9UUUAMK9JufE8VamABismk=@10.244.155.159:5080;transport=tcp;r2=on;lr=on Contact: "Caller" sip:...caller...@a.b.c.d:52379;transport=tls;registering_acc=sip2sip_info User-Agent: Jitsi2.2.4603.9615Windows 7 Content-Length: 0
With debug turned up on the edge proxy I see the output from lines 673 and 723 indicating that the loose.c:after_strict() is run.
My edge proxy configuration is:
request_route { route(REQINIT);
route(OPTIONS);
sip_trace(); setflag(F_SIPTRACE);
if (is_method("CANCEL")) { if (t_check_trans()) { route(RELAY); } exit; }
route(WITHINDLG); ...
route[WITHINDLG] { if (has_totag()) { if (!loose_route()) { switch($rc) { case -2: send_reply("403", "Forbidden"); exit; default: if (is_method("ACK")) { if ( t_check_trans() ) { route(RELAY); exit; } else { exit; } } send_reply("404","Not Found"); } } else { if ($rc == 2) { setflag(F_OB_DRIVEN); }
if (is_method("NOTIFY")) { record_route(); } route(RELAY); } exit; } }
Have I done something fundamentally stupid here, or is there some obscure bug in the loose/strict routing code?
Regards,
Peter
Hello,
looks like a broken routing logic somewhere. What addresses are assigned to your server? There are some exposed or masked in the trace you send, which of those are?
Cheers, Daniel
On 5/20/13 9:03 PM, Peter Dunkley wrote:
Hello,
The configuration is:
Jitsi #1 registered with sip2sip.info Jitsi #2 registered with my server(s) (Kamailio edge proxy and Kamailio registrar) on Amazon AWS running Kamailio from git master
I make a call from Jitsi #1 to Jitsi #2 (there are SRV records for my domain in Amazon Route 53 so that sip2sip.info can find my servers). The flow of the call is:
Jitsi #1 -> sip2sip.info -> Kamailio edge proxy -> Kamailio registrar -> Kamailio edge proxy -> Jitsi #2
The calls do not get established properly because the ACK is not correctly routed. Calls between two Jitsi instances registered on my servers works. Calls from Jitsi #2 to Jitsi #1 (my servers to sip2sip.info) also work. This problem occurs whatever the value of the "enable_double_rr" modparam.
The 200 OK (INVITE) sent from my servers back to sip2sip.info looks OK and has a valid looking route-set:
SIP/2.0 200 OK To:<sip:...callee...@...callee domain...>;tag=e5116094 Via: SIP/2.0/UDP 81.23.228.129:5060;rport=5060;branch=z9hG4bKdb93.87290485.0;i=0efbc,SIP/2.0/TLS 192.168.0.135:52379;rport=52379;received=a.b.c.d;branch=z9hG4bK-363631-23ca624fe9c119f229080992ed4fc143 Record-Route:<sip:Rlwj4KMCy9UUUAMK9JufE8VamABismk=@e.f.g.h:5061;transport=tls;r2=on;lr=on>,<sip:Rlwj4KMCy9UUUAMK9JufE8VamABismk=@10.244.155.159:5080;transport=tcp;r2=on;lr=on>,<sip:10.101.62.154;transport=tcp;lr=on>,<sip:10.244.155.159:5080;transport=tcp;r2=on;lr=on>,<sip:e.f.g.h;r2=on;lr=on>,<sip:81.23.228.129;r2=on;lr;ftag=2d246de3;did=989.4a20eb73>,<sip:81.23.228.129:5061;transport=tls;r2=on;lr;ftag=2d246de3;did=989.4a20eb73> CSeq: 2 INVITE Call-ID: 38135c0b82a8a7d571352350d207b943@0:0:0:0:0:0:0:0 From: "Caller"<sip:...caller...@sip2sip.info>;tag=2d246de3 Contact: "callee"<sip:...callee...@10.6.201.224:60847;transport=tls;registering_acc=...callee domain...> User-Agent: Jitsi2.3.4622.9647Linux Content-Type: application/sdp Content-Length: 838 ...lots of SDP...
The ACK from sip2sip.info to my servers looks OK too:
ACKsip:...callee...@174.129.184.181:5060;transport=tls;registering_acc=...callee domain... SIP/2.0 Call-ID: 38135c0b82a8a7d571352350d207b943@0:0:0:0:0:0:0:0 CSeq: 2 ACK Via: SIP/2.0/UDP 81.23.228.129:5060;branch=z9hG4bKdb93.87290485.2;i=0efbc Via: SIP/2.0/TLS 192.168.0.135:52379;rport=52379;received=a.b.c.d;branch=z9hG4bK-363631-212696616e66a14286e3165485387895 From: "Caller"<sip:...caller...@sip2sip.info>;tag=2d246de3 To: "callee"<sip:...callee...@...callee domain...>;tag=e5116094 Max-Forwards: 69 Route: <sip:e.f.g.h;r2=on;lr=on>,<sip:10.244.155.159:5080;transport=tcp;r2=on;lr=on>,<sip:10.101.62.154;transport=tcp;lr=on>,<sip:Rlwj4KMCy9UUUAMK9JufE8VamABismk=@10.244.155.159:5080;transport=tcp;r2=on;lr=on>,<sip:Rlwj4KMCy9UUUAMK9JufE8VamABismk=@e.f.g.h:5061;transport=tls;r2=on;lr=on> Contact: "Caller"<sip:...caller...@90.152.0.102:52379;transport=tls;registering_acc=sip2sip_info> User-Agent: Jitsi2.2.4603.9615Windows 7 Content-Length: 0
But the ACK from from my edge proxy to my registrar looks very broken:
ACKsip:Rlwj4KMCy9UUUAMK9JufE8VamABismk=@e.f.g.h:5061;transport=tls;r2=on;lr=on SIP/2.0 Call-ID: 38135c0b82a8a7d571352350d207b943@0:0:0:0:0:0:0:0 CSeq: 2 ACK Via: SIP/2.0/TCP e.f.g.h:5060;branch=z9hG4bKdb93.444f42f24139f6dc512d70f61ca64be4.0 Via: SIP/2.0/UDP 81.23.228.129:5060;rport=5060;branch=z9hG4bKdb93.87290485.2;i=0efbc Via: SIP/2.0/TLS 192.168.0.135:52379;rport=52379;received=a.b.c.d;branch=z9hG4bK-363631-212696616e66a14286e3165485387895 From: "Caller"<sip:...caller...@sip2sip.info>;tag=2d246de3 To: "callee"<sip:...callee...@...callee domain...>;tag=e5116094 Max-Forwards: 16 Route: <sip:10.244.155.159:5080;transport=tcp;r2=on;lr=on>,<sip:10.101.62.154;transport=tcp;lr=on>,<sip:Rlwj4KMCy9UUUAMK9JufE8VamABismk=@10.244.155.159:5080;transport=tcp;r2=on;lr=on> Contact: "Caller"<sip:...caller...@a.b.c.d:52379;transport=tls;registering_acc=sip2sip_info> User-Agent: Jitsi2.2.4603.9615Windows 7 Content-Length: 0
With debug turned up on the edge proxy I see the output from lines 673 and 723 indicating that the loose.c:after_strict() is run.
My edge proxy configuration is:
request_route { route(REQINIT); route(OPTIONS); sip_trace(); setflag(F_SIPTRACE); if (is_method("CANCEL")) { if (t_check_trans()) { route(RELAY); } exit; } route(WITHINDLG); ... route[WITHINDLG] { if (has_totag()) { if (!loose_route()) { switch($rc) { case -2: send_reply("403", "Forbidden"); exit; default: if (is_method("ACK")) { if ( t_check_trans() ) { route(RELAY); exit; } else { exit; } } send_reply("404","Not Found"); } } else { if ($rc == 2) { setflag(F_OB_DRIVEN); } if (is_method("NOTIFY")) { record_route(); } route(RELAY); } exit; } }
Have I done something fundamentally stupid here, or is there some obscure bug in the loose/strict routing code?
Regards,
Peter
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev