[SR-Users] Fwd: multihomed Kamailio and enable_double_rr

[Steve Davies]

On 20 Aug 2013 18:49, "Daniel-Constantin Mierla" <miconda at 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 at 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 at 10.64.16.114:5060;transport=udp>.

To: <sip:7171001 at vc2.connection-telecom.com>.

From: "vc2 2686959"<sip:2686959 at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20130820/5084aaf8/attachment.html>