REFER has two Contact headers with RFC3261-equivalent URIs

What steps will reproduce the problem?
1.  Set up OpenIMSCore
2.  Start collecting TCP SIP traffic using tcpdump
3.  Create a group chat
4.  Attempt to add a new user to the group chat

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

I'm expecting to see the outgoing REFER request from OrangeLabs RI client to 
have a Contact: header in this format:

Contact: 
<sip:10.0.2.15:5060;transport=tcp>;+g.oma.sip-im;+sip.instance="<urn:gsma:imei:0
00000000000000>"

Instead, I see this:

Contact: 
<sip:10.0.2.15:5060;transport=tcp>;+g.oma.sip-im,<sip:10.0.2.15:5060;transport=T
CP>;+sip.instance="<urn:gsma:imei:000000000000000>"

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

OrangeLabs v2.5.3, on Android 4.0.3

Please provide any additional information below.

It turns out that OpenIMSCore gets upset with the two Contact header URIs that 
(as I read RFC3261) are equivalent two each other.  Specifically, I'm 
interpreting the 2nd and 7th bullets on Section 19.1.4 "URI Comparison" of 
RFC3261 (top of p154, bottom of p154), and this first example on Page 155:

   The URIs within each of the following sets are equivalent:

   sip:%61lice@atlanta.com;transport=TCP
   sip:alice@AtLanTa.CoM;Transport=tcp

I suppose this is perhaps not technically an android-rcs-ims-stack bug, and 
maybe an OpenIMSCore one. Nevertheless, I'm not sure why the RCS stack is 
including two equivalent URIs; perhaps they could be made to be consistent?

Either way, OpenIMSCore behaves badly and responds with a "400 Multiple Contact 
Headers".  Whether it is complaining about simply having two Contact headers or 
two equivalent contact headers: that I do not know.

Since this seems to work with other systems just fine, this is a low priority.

Thanks!

Armen

Original issue reported on code.google.com by armen.ba...@gmail.com on 16 May 2013 at 10:07

capt-jk / android-rcs-ims-stack

REFER has two Contact headers with RFC3261-equivalent URIs #110