Multiple Routes: - Issue 2346

[Hugh Waite]

Hello,
We have just moved from MSS 1.5.0.FINAL to 1.6.0 and have come across an issue which is identical to issue 2346 http://code.google.com/p/mobicents/issues/detail?id=2346 which was marked fixed-verified in March.

We downloaded the 1.6.0 snapshot on May 5 and built using maven. However we are still getting the double Route: header described in the issue tracker.

INVITE sip:8765...@192.168.0.53:8002 SIP/2.0
Record-Route: <sip:192.168.0.24:5080;transport=tcp;appname=dee59962;proxy=true;app_id=fea5efbc-1f37-4b7d-a2c8-9b66dd616fbb;lr>
Record-Route: <sip:192.168.0.50:5065;transport=tcp;lr>
Record-Route: <sip:192.168.0.50:5060;transport=tcp;lr>
Record-Route: <sip:192.168.0.21;lr=on>
Via: SIP/2.0/UDP 192.168.0.24:5080;branch=z9hG4bKfea5efbc-1f37-4b7d-a2c8-9b66dd616fbb_dee59962_49384929
Via: SIP/2.0/TCP 192.168.0.50:5065;branch=z9hG4bK542c.9e69fadb9d25723681fa918daabb3f46.01-164zsd;received=192.168.0.24;rport=38304
Via: SIP/2.0/TCP 192.168.0.50:5060;branch=z9hG4bK542c.9e69fadb9d25723681fa918daabb3f46.01-164
Via: SIP/2.0/TCP 192.168.0.21;branch=z9hG4bK542c.9e69fadb9d25723681fa918daabb3f46.0;i=2603;rport=48939
Via: SIP/2.0/TCP 192.168.0.54:5060;received=192.168.0.134;branch=z9hG4bK-16466-1-4
Via: SIP/2.0/TCP 192.168.0.81:5060;branch=z9hG4bK-sbc-16466-1-1
From: "123" <sip:1234...@crocodile-rcs.com>;tag=16466SIPpTag001
Call-ID: 1-1...@192.168.0.54
CSeq: 2 INVITE
User-Agent: SIPp/3.2
Proxy-Authorization: Digest username="12345678",realm="BREDBAND",cnonce="6b8b4567",nc=00000001,qop=auth,uri="sip:crocodile-rcs.com",nonce="MTMwNTExNzg0OToYx2kPP8ZzWyTxYCnRGRcP",response="7839195ddbd6387e1d638302b8acf8e8",algorithm=md5,opaque="MTMwNTExNzg0OToYx2kPP8ZzWyTxYCnRGRcP"
Contact: <sip:192.168.0.54:5060;transport=TCP>
Max-Forwards: 67
Subject: 05-SBC-test1
Content-Type: application/sdp
Route: <sip:192.168.0.50:5065;lr;transport=udp;node_host=192.168.0.24;node_port=5080>
Route: <sip:192.168.0.21:5060;lr;transport=udp;dns_route=true>
Route: <sip:192.168.0.21;lr>
To: "bob" <tel:87654321>
Content-Length: 135

The tracker said to make sure jain-sip-ext was updated. Is this something that we don't have in a snapshot downloaded last week?

Any pointers?

Thanks,
Hugh

-- 
--
Hugh Waite
Senior Design Engineer
Crocodile RCS Ltd.

[Jean Deruelle]

Weird,

Can you attach your logs in DEBUG mode, and the call flow to the issue, I will reopen it to investigate. Also please specify the type of application (B2BUA, proxy, UAS, UAC) and if you're pushing Route headers.

Thanks

Jean

[Hugh Waite]

Logs attached, plus a diagram of the expected call flow.

The application is a proxy under control from an external system. After authentication, the INVITE is proxied to the destination (192.168.0.53). We push a Route: <sip:192.168.0.21;lr> for the next hop.

In the log file, we start the outbound INVITE at about line 1251 and the extra Route header gets added at line 1423. We also have an outboundProxy configured for the load balancers, so this gets another Route: header as well.

After that it may get confusing, because the proxy tries to route the request back to the MSS (default destination) due to the incorrect Routes, eventually causing a 404.

I did a little experiment and removed the 'balancers' and 'outboundProxy' lines from server.xml. When the INVITE was forwarded, it only had a single Route: header. Is this issue possibly due to using an outboundProxy and/or balancers? I'll try and get a trace of that as well...

Hugh

[Andrew Miller]

As a experiment we built 1.6 Snapshot with the
"request.addFirst(nextHopRouteHeader);" in send(Hop hop) commented
out. This prevents the insertion of the Route: header with DNS
parameter
(Route: <sip:192.168.0.21:5060;lr;transport=udp;dns_route=true>).

We are using fixed IP addresses, so we don't need to use DNS. This
patches the problem. However, it's not a solution, as other people are
going to need DNS.

So, it seems there is a problem with 1.6 in the presence of load
balancers. My guess is that the Route: header for the balancer is
pushed on top of the DNS Route: header, so the DNS code is failing to
spot and remove it.

[Jean Deruelle]

Your guess is correct, I reopened the case, I just committed a fix to avoid that the DNS Route is added when MSS is fronted by the Load Balancer, can you update and retry ?

Thanks

Jean

[Andrew Miller]

Ported that fix into our slightly modified 1.6 Snapshot and retested. That is now working for us.

I've made a similar comment on the issue tracker

Many thanks

Andy (and Hugh)