Route set changed - Transport parameter added

[GoogleCodeExporter]

In some scenarios, the route set is modified adding a transport parameter.
This is contravening RFC3261, item 4 of Section 16.6:

      The URI placed in the Record-Route header field value MUST be a
      SIP or SIPS URI. [...]  The URI SHOULD NOT contain the transport
      parameter unless the proxy has knowledge (such as in a private
      network) that the next downstream element that will be in the path
      of subsequent requests supports that transport.

This creates problems with very strict proxies (some IMS environments).
See below for an example and next entry for a proposed patch.

Example (see the first Route header in ACK is NOT the same as Record-Route in 
200, a transport parameter is added):

-->
INVITE sip:user1@test SIP/2.0
Call-ID: 508c238826f34cc442773452a447c3cf@1.1.1.1
CSeq: 1 INVITE
From: 
<sip:user2@test>;tag=90236820_0415af62_0832a211-8956-49aa-b678-9d1c1181f265
To: <sip:user1@test>
Max-Forwards: 70
Contact: <sip:user2@1.1.1.1:5080;transport=tcp>
Route: <sip:2.2.2.2:4060;transport=tcp;lr>
Route: <sip:orig@scscf.test:6060;lr>
Via: SIP/2.0/TCP 
1.1.1.1:5080;branch=z9hG4bK0832a211-8956-49aa-b678-9d1c1181f265_0415af62_2641136
0901572123

<--
SIP/2.0 200 OK
Via: SIP/2.0/TCP 
1.1.1.1:5080;branch=z9hG4bK0832a211-8956-49aa-b678-9d1c1181f265_0415af62_2641136
0901572123;rport=59046
From: 
<sip:user2@test>;tag=90236820_0415af62_0832a211-8956-49aa-b678-9d1c1181f265
To: <sip:user1@test>;tag=1b77e8bd-09c4-4505-9f69-ec391c2c2fda
Call-ID: 508c238826f34cc442773452a447c3cf@1.1.1.1
CSeq: 1 INVITE
Record-Route: <sip:mo@scscf.test:6060;lr>
Record-Route: <sip:mo@pcscf.test:4060;lr>
Contact: <sip:user3@3.3.3.3:8060>

-->
ACK sip:user3@3.3.3.3:8060 SIP/2.0
Call-ID: 508c238826f34cc442773452a447c3cf@1.1.1.1
CSeq: 1 ACK
From: 
<sip:user2@test>;tag=90236820_0415af62_0832a211-8956-49aa-b678-9d1c1181f265
To: <sip:user1@test>;tag=1b77e8bd-09c4-4505-9f69-ec391c2c2fda
Max-Forwards: 70
Route: <sip:mo@pcscf.test:4060;lr;transport=tcp>
Route: <sip:mo@scscf.test:6060;lr>
Via: SIP/2.0/TCP 
1.1.1.1:5080;branch=z9hG4bK0832a211-8956-49aa-b678-9d1c1181f265_0415af62_2641136
1507407868
Content-Length: 0

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

Please use labels and text to provide additional information.

Original issue reported on code.google.com by josemre...@gmail.com on 17 Dec 2012 at 10:33

[GoogleCodeExporter]

I think issue is caused by a bug in SipServletRequestImpl.java

Proposed patch attached.

Original comment by josemre...@gmail.com on 17 Dec 2012 at 10:39

Attachments:

• patch.issue.186.txt

[GoogleCodeExporter]

This issue was updated by revision 6a67aedfb0fb.

Fix committed. Avoiding the cloning for performance reasons and rather 
resetting the transport back to what it was before any changes could be made by 
the resolving

Original comment by jean.deruelle on 21 Dec 2012 at 11:26

[GoogleCodeExporter]

Let me know if the new Fix works for you.

Original comment by jean.deruelle on 21 Dec 2012 at 11:27

• Changed state: Started

[GoogleCodeExporter]

Thanks, Jean, we will test and report back
JM

Original comment by josemre...@gmail.com on 27 Dec 2012 at 1:33

[GoogleCodeExporter]

Thanks, Jean, tested and working fine so far.

Original comment by josemre...@gmail.com on 17 Jan 2013 at 12:21

[GoogleCodeExporter]

Original comment by jean.deruelle on 5 Jul 2013 at 7:44

• Added labels: MSS-3.0.0.FINAL
• Removed labels: MSS-2.1.0.FINAL

[GoogleCodeExporter]

Original comment by jean.deruelle on 29 Apr 2014 at 5:25

• Changed state: Backported
• Added labels: TelScale-7.0.1.GA

[GoogleCodeExporter]

Original comment by jean.der...@telestax.com on 25 Aug 2014 at 10:53

• Added labels: MSS-2.1.0.FINAL
• Removed labels: MSS-3.0.0.FINAL