[SR-Users] multihomed Kamailio and enable_double_rr
Daniel-Constantin Mierla
miconda at gmail.com
Tue Aug 20 18:49:10 CEST 2013
Hello,
the problem with the BYE is that the R-URI is the ip address of
kamailio, resulting in match for strict routing rather than loose
routing (both cases are handled by loose_route() function).
My guess of what happens is that 41.221.230.60 detects the invite as
coming from behind nat and does something like fix_nated_contact(). Not
being the first proxy in the path of the caller, should not do any
contact mangling, but rely only on Recor-Route headers for routing.
If you cannot control 41.221.230.60 or ask for a change there, the
solution is to use htable in your config to store the contact uri from
invite and replace it in bye before loose_route().
I wanted to add such logic in default config for kamailio as well (not
mangle contact if not first proxy), but forgot about it, I'll do it
soon. There is a new function is_first_hop() in devel version, for older
version the solution is to store the number of record-route headers for
request and compare with the number of them in response.
Cheers,
Daniel
On 8/20/13 6:00 PM, Steve Davies wrote:
> Hi,
>
> I'm having a problem with routing of BYEs in my multi homed Kamailio.
>
> My setup is a phone on 172.16.230.1, talking to Kamailio on
> 172.16.230.128.
> On the "outside" Kamailio uses 10.64.5.16 and its talking to 41.221.230.60
>
> I'm using the stock Kamailio 4.0.3 kamailio.cfg, with:
> WITH_NAT defined
> mhomed=1
> Little change in NATMANAGE to do the rtpproxy_manage with ie or ei
> as appropriate, coming from my previous post and the response from Alex.
>
> Here's the invite from the phone:
>
> U 172.16.230.1:3694 <http://172.16.230.1:3694> ->
> 172.16.230.128:5060 <http://172.16.230.128:5060>
> INVITE sip:7171001 at vc2.connection-telecom.com
> <mailto:sip%3A7171001 at vc2.connection-telecom.com>;transport=udp
> SIP/2.0.
> Via: SIP/2.0/UDP
> 172.16.230.1:3694;branch=z9hG4bK-d8754z-6a91626ae4c3f625-1---d8754z-;rport.
> Max-Forwards: 70.
> Contact: <sip:2686959 at 172.16.230.1:3694;transport=udp>.
> To: <sip:7171001 at vc2.connection-telecom.com
> <mailto:sip%3A7171001 at vc2.connection-telecom.com>>.
> From: "vc2 2686959"<sip:2686959 at vc2.connection-telecom.com
> <mailto:sip%3A2686959 at vc2.connection-telecom.com>>;tag=014e3010.
> Call-ID: ZDQ4YThjNzEzOTBhOTE5NGViNTFhM2Q5MTY2ZmY1ZDc.
> CSeq: 2 INVITE.
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE,
> SUBSCRIBE, INFO.
> Content-Type: application/sdp.
> Proxy-Authorization: ...some stuff...
> Supported: replaces.
> User-Agent: Bria 3 release 3.5.3 stamp 70600.
> Content-Length: 256.
> .
> v=0.
> o=- 1377005946728952 1 IN IP4 172.16.230.1.
> s=Bria 3 release 3.5.3 stamp 70600.
> c=IN IP4 172.16.230.1.
> t=0 0.
> m=audio 52448 RTP/AVP 8 18 101.
> a=rtpmap:18 G729/8000.
> a=fmtp:18 annexb=yes.
> a=rtpmap:101 telephone-event/8000.
> a=fmtp:101 0-15.
> a=sendrecv.
>
>
> Kamailio forwards with double-Record-Route with both of its addresses.
> I believe this is per SIP OUTBOUND RFC:
>
> U 10.64.5.16:5060 <http://10.64.5.16:5060> -> 41.221.230.60:5060
> <http://41.221.230.60:5060>
> INVITE sip:7171001 at vc2.connection-telecom.com
> <mailto:sip%3A7171001 at vc2.connection-telecom.com>;transport=udp
> SIP/2.0.
> Record-Route: <sip:10.64.5.16;r2=on;lr=on;ftag=014e3010;nat=yes>.
> Record-Route: <sip:172.16.230.128;r2=on;lr=on;ftag=014e3010;nat=yes>.
> Via: SIP/2.0/UDP 10.64.5.16;branch=z9hG4bKe355.e526ca52.0.
> Via: SIP/2.0/UDP
> 172.16.230.1:3694;branch=z9hG4bK-d8754z-6a91626ae4c3f625-1---d8754z-;rport=3694.
> Max-Forwards: 16.
> Contact: <sip:2686959 at 172.16.230.1:3694;transport=udp>.
> To: <sip:7171001 at vc2.connection-telecom.com
> <mailto:sip%3A7171001 at vc2.connection-telecom.com>>.
> From: "vc2 2686959"<sip:2686959 at vc2.connection-telecom.com
> <mailto:sip%3A2686959 at vc2.connection-telecom.com>>;tag=014e3010.
> Call-ID: ZDQ4YThjNzEzOTBhOTE5NGViNTFhM2Q5MTY2ZmY1ZDc.
> CSeq: 2 INVITE.
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE,
> SUBSCRIBE, INFO.
> Content-Type: application/sdp.
> Proxy-Authorization: ...some stuff...
> Supported: replaces.
> User-Agent: Bria 3 release 3.5.3 stamp 70600.
> Content-Length: 270.
> P-hint: outbound.
> .
> v=0.
> o=- 1377005946728952 1 IN IP4 10.64.5.16.
> s=Bria 3 release 3.5.3 stamp 70600.
> c=IN IP4 10.64.5.16.
> t=0 0.
> m=audio 59194 RTP/AVP 8 18 101.
> a=rtpmap:18 G729/8000.
> a=fmtp:18 annexb=yes.
> a=rtpmap:101 telephone-event/8000.
> a=fmtp:101 0-15.
> a=sendrecv.
> a=nortpproxy:yes.
>
>
> So that behaviour seems OK. The call does get correctly established
> and rtpproxy is correctly setup and audio passes in both directions.
>
>
> But when the BYE is sent (from the outside), though, things go wrong:
>
> Here's what arrives from upstream. Route: has the two entries per the
> RR that was sent.
>
> U 41.221.230.60:5060 <http://41.221.230.60:5060> ->
> 10.64.5.16:5060 <http://10.64.5.16:5060>
> BYE sip:2686959 at 10.64.5.16:5060;transport=udp SIP/2.0.
> Record-Route: <sip:41.221.230.60;lr=on;ftag=as70703d1c>.
> Via: SIP/2.0/UDP 41.221.230.60;branch=z9hG4bKbd37.4108b6b2.0.
> Via: SIP/2.0/UDP
> 41.221.230.60:5070;received=41.221.230.60;branch=z9hG4bK4e6b38bf;rport=5070.
> Route:
> <sip:10.64.5.16;r2=on;lr=on;ftag=014e3010;nat=yes>,<sip:172.16.230.128;r2=on;lr=on;ftag=014e3010;nat=yes>.
> Max-Forwards: 69.
> From: <sip:7171001 at vc2.connection-telecom.com
> <mailto:sip%3A7171001 at vc2.connection-telecom.com>>;tag=as70703d1c.
> To: "vc2 2686959"<sip:2686959 at vc2.connection-telecom.com
> <mailto:sip%3A2686959 at vc2.connection-telecom.com>>;tag=014e3010.
> Call-ID: ZDQ4YThjNzEzOTBhOTE5NGViNTFhM2Q5MTY2ZmY1ZDc.
> CSeq: 102 BYE.
> User-Agent: Enswitch.
> X-Asterisk-HangupCause: Normal Clearing.
> X-Asterisk-HangupCauseCode: 16.
> Content-Length: 0.
> X-Enswitch-RURI: sip:2686959 at 10.64.5.16:5060;transport=udp.
> X-Enswitch-Source: 41.221.230.60:5070 <http://41.221.230.60:5070>.
> .
>
>
> So Kamailio peels off the first route and then sends the BYE actually
> to itself. With an oddly formed blank Route: header.
>
> Tracing through the kamailio.cfg the BYE is processed in WITHINDLG -
> loose_route() succeeds
>
> It logs that 172.16.230.128 "is loose router".
>
>
> U 10.64.5.16:5060 <http://10.64.5.16:5060> -> 172.16.230.128:5060
> <http://172.16.230.128:5060>
> BYE sip:172.16.230.128;r2=on;lr=on;ftag=014e3010;nat=yes SIP/2.0.
> Record-Route: <sip:41.221.230.60;lr=on;ftag=as70703d1c>.
> Via: SIP/2.0/UDP 10.64.5.16;branch=z9hG4bKbd37.25d16bf3.0.
> Via: SIP/2.0/UDP
> 41.221.230.60;rport=5060;branch=z9hG4bKbd37.4108b6b2.0.
> Via: SIP/2.0/UDP
> 41.221.230.60:5070;received=41.221.230.60;branch=z9hG4bK4e6b38bf;rport=5070.
> Route: .
> Max-Forwards: 16.
> From: <sip:7171001 at vc2.connection-telecom.com
> <mailto:sip%3A7171001 at vc2.connection-telecom.com>>;tag=as70703d1c.
> To: "vc2 2686959"<sip:2686959 at vc2.connection-telecom.com
> <mailto:sip%3A2686959 at vc2.connection-telecom.com>>;tag=014e3010.
> Call-ID: ZDQ4YThjNzEzOTBhOTE5NGViNTFhM2Q5MTY2ZmY1ZDc.
> CSeq: 102 BYE.
> User-Agent: Enswitch.
> X-Asterisk-HangupCause: Normal Clearing.
> X-Asterisk-HangupCauseCode: 16.
> Content-Length: 0.
> X-Enswitch-RURI: sip:2686959 at 10.64.5.16:5060;transport=udp.
> X-Enswitch-Source: 41.221.230.60:5070 <http://41.221.230.60:5070>.
> .
>
>
> When Kamailio receives the BYE from itself it sends a 404 Not here.
> Which is forwarded back upstream. This 404 Not here is generated in
> WITHINDLG too; looks like loose_route() fails (which makes sense since
> there is nothing in the Route header), and in that case WINTHINDLG
> only has code for dealing with SUBSCRIBE and ACK.
>
> U 172.16.230.128:5060 <http://172.16.230.128:5060> ->
> 10.64.5.16:5060 <http://10.64.5.16:5060>
> SIP/2.0 404 Not here.
> Via: SIP/2.0/UDP 10.64.5.16;branch=z9hG4bKbd37.25d16bf3.0;rport=5060.
> Via: SIP/2.0/UDP
> 41.221.230.60;rport=5060;branch=z9hG4bKbd37.4108b6b2.0.
> Via: SIP/2.0/UDP
> 41.221.230.60:5070;received=41.221.230.60;branch=z9hG4bK4e6b38bf;rport=5070.
> From: <sip:7171001 at vc2.connection-telecom.com
> <mailto:sip%3A7171001 at vc2.connection-telecom.com>>;tag=as70703d1c.
> To: "vc2 2686959"<sip:2686959 at vc2.connection-telecom.com
> <mailto:sip%3A2686959 at vc2.connection-telecom.com>>;tag=014e3010.
> Call-ID: ZDQ4YThjNzEzOTBhOTE5NGViNTFhM2Q5MTY2ZmY1ZDc.
> CSeq: 102 BYE.
> Server: kamailio (4.0.3 (i386/linux)).
> Content-Length: 0.
> .
>
>
> U 10.64.5.16:5060 <http://10.64.5.16:5060> -> 41.221.230.60:5060
> <http://41.221.230.60:5060>
> SIP/2.0 404 Not here.
> Via: SIP/2.0/UDP
> 41.221.230.60;rport=5060;branch=z9hG4bKbd37.4108b6b2.0.
> Via: SIP/2.0/UDP
> 41.221.230.60:5070;received=41.221.230.60;branch=z9hG4bK4e6b38bf;rport=5070.
> From: <sip:7171001 at vc2.connection-telecom.com
> <mailto:sip%3A7171001 at vc2.connection-telecom.com>>;tag=as70703d1c.
> To: "vc2 2686959"<sip:2686959 at vc2.connection-telecom.com
> <mailto:sip%3A2686959 at vc2.connection-telecom.com>>;tag=014e3010.
> Call-ID: ZDQ4YThjNzEzOTBhOTE5NGViNTFhM2Q5MTY2ZmY1ZDc.
> CSeq: 102 BYE.
> Server: kamailio (4.0.3 (i386/linux)).
> Content-Length: 0.
> .
>
>
>
> I tried with enable_double_rr as 0 and that did send only one
> Record-Route with the relayed INVITE, but the record route uses the
> inside address of the proxy and so we never even receive the BYE from
> the upstream system in that case.
>
> I'm kinda lost about where this is going wrong - so pointers would be
> welcome!
>
> Thanks,
> Steve
>
>
>
>
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20130820/936be193/attachment-0001.html>
More information about the sr-users
mailing list