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