On 20 Aug 2013 18:49, "Daniel-Constantin Mierla" <mico...@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:7171...@vc2.connection-telecom.com>.
From: "vc2 2686959"<sip:2686...@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:7171...@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
_______________________________________________
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
