[SR-Users] multihomed Kamailio and enable_double_rr

Steve Davies steve-lists-srusers at connection-telecom.com
Tue Aug 20 18:00:40 CEST 2013


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 -> 172.16.230.128:5060
INVITE sip:7171001 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>.
From: "vc2 2686959"<sip:2686959 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 -> 41.221.230.60:5060
INVITE sip:7171001 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>.
From: "vc2 2686959"<sip:2686959 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 -> 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>;tag=as70703d1c.
To: "vc2 2686959"<sip:2686959 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.
.


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 -> 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>;tag=as70703d1c.
To: "vc2 2686959"<sip:2686959 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.
.


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 -> 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>;tag=as70703d1c.
To: "vc2 2686959"<sip:2686959 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 -> 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>;tag=as70703d1c.
To: "vc2 2686959"<sip:2686959 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20130820/6465903b/attachment-0001.html>


More information about the sr-users mailing list