Incorrect routing by webrtc2sip when two Route headers are present

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Creating an initial INVITE from webrtc/SIPml5 with webrtc2sip gateway 
(connecting to OpenIMSCore)
2. The initial INVITE has the proxy server Route header and the IMS service 
Route header

A sample INVITE (from Chrome on MacOSX) is pasted below (note the two Route 
headers - one to deliver to the proxy and the other for the IMS network).

--- BEGIN ---
SEND: INVITE sip:7326990001@zone-a.ims.ar SIP/2.0
Via: SIP/2.0/WS 
df7jal23ls0d.invalid;branch=z9hG4bKedTSIdy721Ja7qafu3h54UcbF7vrPrNd;rport
From: <sip:7326990002@zone-a.ims.ar>;tag=Ml1Ns1PTMtb2ac3hQk00
To: <sip:7326990001@zone-a.ims.ar>
Contact: 
<sip:7326990002@df7jal23ls0d.invalid;rtcweb-breaker=yes;click2call=no;transport=
ws>;impi=7326990002%40zone-a.ims.ar;ha1=3b59fc32cceaa3d9147adb9c4b722082;+g.oma.
sip-im;+sip.ice;language="en,fr"
Call-ID: 6c2cc7d2-a243-d60e-8421-24dcea1834b2
CSeq: 9020 INVITE
Content-Type: application/sdp
Content-Length: 1733
Route: <sip:pcscf.zone-a.ims.ar:4060;lr;sipml5-outbound;transport=udp>
Max-Forwards: 70
Route: <sip:orig@scscf.zone-a.ims.ar:6060;lr>
User-Agent: IM-client/OMA1.0 sipML5-v1.2013.08.10B
Organization: Doubango Telecom

v=0
o=- 4491581003526103600 2 IN IP4 127.0.0.1
s=Doubango Telecom - chrome
t=0 0
a=group:BUNDLE audio
a=msid-semantic: WMS IMUCVohK0O3qllSlzXR556IpQdoJVRnkN6zo
m=audio 59668 RTP/SAVPF 111 103 104 0 8 107 106 105 13 126
c=IN IP4 98.109.4.179
a=rtcp:59668 IN IP4 98.109.4.179
a=candidate:3596738868 1 udp 2113937151 192.168.1.16 59668 typ host generation 0
a=candidate:3596738868 2 udp 2113937151 192.168.1.16 59668 typ host generation 0
a=candidate:544315616 1 udp 1845501695 98.109.4.179 59668 typ srflx raddr 
192.168.1.16 rport 59668 generation 0
a=candidate:544315616 2 udp 1845501695 98.109.4.179 59668 typ srflx raddr 
192.168.1.16 rport 59668 generation 0
a=candidate:2564955588 1 tcp 1509957375 192.168.1.16 0 typ host generation 0
a=candidate:2564955588 2 tcp 1509957375 192.168.1.16 0 typ host generation 0
a=ice-ufrag:9ZcfiAXs70R/Z93W
a=ice-pwd:gHhl9JwYFxEQPyWphvAhDoDr
a=ice-options:google-ice
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=sendrecv
a=mid:audio
a=rtcp-mux
a=crypto:0 AES_CM_128_HMAC_SHA1_32 
inline:wgfOzuyMZwo+Cs/EHMcLB8pFD615r573aUsjRbSr
a=crypto:1 AES_CM_128_HMAC_SHA1_80 
inline:IWl9M+DtmYHSpdSOfmVfnAIYag3PDDGDC95MFAG9
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:107 CN/48000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:126 telephone-event/8000
a=maxptime:60
a=ssrc:513449468 cname:+EapbUPrWeosnJdY
a=ssrc:513449468 msid:IMUCVohK0O3qllSlzXR556IpQdoJVRnkN6zo 
IMUCVohK0O3qllSlzXR556IpQdoJVRnkN6zoa0
a=ssrc:513449468 mslabel:IMUCVohK0O3qllSlzXR556IpQdoJVRnkN6zo
a=ssrc:513449468 label:IMUCVohK0O3qllSlzXR556IpQdoJVRnkN6zoa0
--- END ---

What is the expected output? What do you see instead?

The expectation is that the first route will be consumed (only the second Route 
header will remain) and the INVITE will be directed to the P-CSCF (as per the 
first Route header).

Using Wireshark, I see the modified INVITE from webrtc2sip heading towards the 
S-CSCF instead of the P-CSCF! The IMS service Route header is present with the 
P-CSCF route header taken out (as it should be). The UDP information and 
related SIP message snippet (without SDP) from Wireshark is pasted below.

Note: Both P-CSCF and S-CSCF have IP address 192.4.20.116. The P- is on port 
4060 and the S- is on port 6060.

--- BEGIN ---
Internet Protocol Version 4, Src: 192.4.20.115 (192.4.20.115), Dst: 
192.4.20.116 (192.4.20.116)
User Datagram Protocol, Src Port: 10060 (10060), Dst Port: 6060 (6060)

INVITE sip:7326990001@zone-a.ims.ar SIP/2.0
Via: SIP/2.0/UDP 192.4.20.115:10060;branch=z9hG4bK-1215408676;rport
From: <sip:7326990002@zone-a.ims.ar>;tag=1020375863
To: <sip:7326990001@zone-a.ims.ar>
Contact: 
<sip:7326990002@192.4.20.115:10060;ws-src-ip=10.109.16.124;ws-src-port=57532;ws-
src-proto=ws;transport=udp>
Call-ID: cbee7d06-1505-bca9-2776-0064f0bc0877
CSeq: 1133804803 INVITE
Content-Type: application/sdp
Content-Length: 1079
Max-Forwards: 70
Route: <sip:orig@scscf.zone-a.ims.ar:6060;lr>
User-Agent: webrtc2sip Media Server 2.5.1
Supported: 100rel
--- END ---

What version of the product are you using? On what operating system?

Clients:
- webrtc/SIPml5 on Chrome on MacOSX
Servers:
- webrtc2sip v2.5.1 is compiled (Revision 114) on Ubuntu 13.04
- OpenIMSCore on Ubuntu 13.04

Note: The webrtc2sip configuration is the default except for an additional dns 
server entry pointing to the DNS server for the IMS network.

Please provide server logs with DEBUG level equal to INFO

Attached a trace of the webrtc2sip log.

Please provide browser logs

See pasted relevant SIP message at beginning of this report (can produce entire 
log if required).

Thanks,
Devasis

Original issue reported on code.google.com by Devasis....@gmail.com on 1 Oct 2013 at 3:18

Attachments:

• webrtc2sip.log

[GoogleCodeExporter]

Hello Devasis, 

may I ask you how do you setup your sipml5 client or which webrtc client do you 
use?
I used sipml5 client(http://sipml5.org/call.htm) and it successfully registered 
to my open ims core, but when I want to send INVITE to open ims core, it used 
Service-Route header to carry scscf information instead Route header.
It bothered me a lot.. dont know where the problem is..

Original comment by hank52...@gmail.com on 15 Nov 2013 at 3:14

[GoogleCodeExporter]

So I did manage to eventually get everything working with a full IMS network 
including a media server, application server, etc. It however did require me to 
go in and change/uncomment lines of code in various places and recompile.

Am hoping to get some time to document all the changes and post the document 
online. Looks like the codebase does actually handle all the cases required for 
IMS networks - however, much of the functionality has been commented out in 
various places (unfortunately, without any meaningful comments).

Original comment by Devasis....@gmail.com on 15 Nov 2013 at 6:59

[GoogleCodeExporter]

So you mean you modified/uncommented both sipml5 client and webrtc2sip gateway 
source code to get everything working with IMS network? Or you only changed and 
recompiled the webrtc2sip gw source code?

It will be great that you post the document. Hope that I can see the document 
soon.
Btw, thanks for answering me.

Original comment by hank52...@gmail.com on 18 Nov 2013 at 3:37