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 -> 172.16.230.128:5060
INVITE sip:7171001@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@172.16.230.1:3694;transport=udp>.
To: <sip:7171001@vc2.connection-telecom.com>.
From: "vc2 2686959"<sip:2686959@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@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@172.16.230.1:3694;transport=udp>.
To: <sip:7171001@vc2.connection-telecom.com>.
From: "vc2 2686959"<sip:2686959@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@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@vc2.connection-telecom.com>;tag=as70703d1c.
To: "vc2 2686959"<sip:2686959@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@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".


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.
To: "vc2 2686959"<sip:2686959@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-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.
To: "vc2 2686959"<sip:2686959@vc2.connection-telecom.com>;tag=014e3010.
Call-ID: ZDQ4YThjNzEzOTBhOTE5NGViNTFhM2Q5MTY2ZmY1ZDc.
CSeq: 102 BYE.
Server: kamailio (4.0.3 (i386/linux)).
Content-Length: 0.
.


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.
To: "vc2 2686959"<sip:2686959@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@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