On 20 Aug 2013 18:49, "Daniel-Constantin Mierla" miconda@gmail.com wrote:

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.

Hi,

Thanks for the reply.

I am in control of the upstream proxy, which is opensips 1.6. But I did not write the config file.

There isn't any NAT between the two proxies.

But I don't quite understand your suggestion that the proxy on 41.221.230.60 should route the INVITE per the Record-Route. The record-route only says what path reply packets should take?

In the opensips.cfg on that box in the route block the first thing of consequence it does is:

# Handle NAT

#xlog("L_NOTICE","!! route (handle nat)");

if ( has_body( "application/sdp" ) ) {

if ( nat_uac_test( "31" ) ) {

setbflag( 1 );

fix_nated_contact();

force_rport();

fix_nated_sdp( "3" );

}

}

Here's what that proxy sends to the endpoint (an Asterisk server) (in this case I did the test from a different source address - 10.64.16.114 instead of 10.64.5.16):

U 41.221.230.60:5060 -> 41.221.230.60:5070

INVITE sip:7171001@41.221.230.60:5070;transport=udp SIP/2.0.

Record-Route: sip:41.221.230.60;lr=on;ftag=4e98ab39.

Record-Route: sip:10.64.16.114;r2=on;lr=on;ftag=4e98ab39;nat=yes.

Record-Route: sip:172.16.230.128;r2=on;lr=on;ftag=4e98ab39;nat=yes.

Via: SIP/2.0/UDP 41.221.230.60;branch=z9hG4bK0d3e.ad00dc64.0.

Via: SIP/2.0/UDP 10.64.16.114;rport=5060;received=10.64.16.114;branch=z9hG4bK0d3e.2656ccb.0.

Via: SIP/2.0/UDP 172.16.230.1:7770 ;branch=z9hG4bK-d8754z-a9e5930255ad0731-1---d8754z-;rport=7770.

Max-Forwards: 15.

Contact: sip:2686959@10.64.16.114:5060;transport=udp.

To: sip:7171001@vc2.connection-telecom.com.

From: "vc2 2686959"sip:2686959@vc2.connection-telecom.com;tag=4e98ab39.

Call-ID: MDRiN2U5ZGRlMmE5YjMzYjkxOGNkMjk1MTYxOWU1MDQ.

CSeq: 2 INVITE.

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO.

Content-Type: application/sdp.

Proxy-Authorization: ...stuff...

Supported: replaces.

User-Agent: Bria 3 release 3.5.3 stamp 70600.

Content-Length: 294.

P-hint: outbound.

X-Enswitch-RURI: sip:7171001@vc2.connection-telecom.com;transport=udp.

X-Enswitch-Source: 10.64.16.114:5060.

.

v=0.

o=- 1377021191518335 1 IN IP4 10.64.16.114.

s=Bria 3 release 3.5.3 stamp 70600.

c=IN IP4 10.64.16.114.

t=0 0.

m=audio 42646 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.

a=direction:active.

You say that the BYE arrives at Kamailio with the R-URI with the IP or Kamailio. Wasn't that substitution done originally by Kamailio itself in the NAT support?

Thanks, Steve