MMTel feature tag (ICSI) missing in Contact header of SIP INVITE for audio calls

[GoogleCodeExporter]

What steps will reproduce the problem?
1.Initiate an audion call
2.Look at wireshark capture
3.

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

The contact header should include the MMTel ICSI.
3GPP TS 24.229, section 5.1.2A.1.1
If this is a request for a new dialog, the Contact header field is populated as 
follows:
1)  a contact header value which is one of:
-   if a public GRUU value ("pub-gruu" header field parameter) has been saved 
associated with the public user identity to be used for this request, and the 
UE does not indicate privacy of the P-Asserted-Identity, then the UE should 
insert the public GRUU ("pub-gruu" header field parameter) value as specified 
in draft-ietf-sip-gruu [93]; or
-   if a temporary GRUU value ("temp-gruu" header field parameter) has been saved 
associated with the public user identity to be used for this request, and the 
UE does indicate privacy of the P-Asserted-Identity, then the UE should insert 
the temporary GRUU ("temp-gruu" header field parameter) value as specified in 
draft-ietf-sip-gruu [93]; or
-   otherwise, a SIP URI containing the contact address of the UE;
NOTE 7: The above items are mutually exclusive.
2)  include an "ob" SIP URI parameter, if the UE supports multiple 
registrations, and the UE wants all subsequent requests in the dialog to arrive 
over the same flow identified by the flow token as described in the 
draft-ietf-sip-outbound [92];
3)  if the request is related to an IMS communication service that requires the 
use of an ICSI then the UE shall include in a g.3gpp.icsi-ref media feature 
tag, as defined in subclause 7.9.2 and RFC 3841 [56B], the ICSI value (coded as 
specified in subclause 7.2A.8.2) for the IMS communication service. The UE may 
also include other ICSI values that the UE is prepared to use for all dialogs 
with the terminating UE(s); and
4)  if the request is related to an IMS application that is supported by the UE, 
then the UE may include in a g.3gpp.iari-ref media feature tag, as defined in 
subclause 7.9.3 and RFC 3841 [56B], the IARI value (coded as specified in 
subclause 7.2A.9.2) that is related to the IMS application and that applies for 
the dialog.

Imsdroid only includes oma im tag (which is probably not applicable for this 
case):
Contact: 
<sip:user_1@192.168.178.22:52476;transport=udp>;+g.oma.sip-im;language="en,fr"

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

Please provide any additional information below.

Original issue reported on code.google.com by mandrajg@gmail.com on 3 Nov 2010 at 2:14

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

This is not a mandatory standard procedure to signal support for the IMS 
Multimedia Telephony Communication Service framework (3GPP TS 24.173). You can 
also use "P-Preferred-Service" header. IMSDroid uses this header. It's also 
possible to use "Accept-Contact" header.
Example:
{{{
Contact: 
<sip:impu@doubango.org;gr=urn:uuid:xxx;comp=sigcomp>;+g.3gpp.icsi-ref="urn%3Aurn
-7%3gpp-service.ims.icsi.mmtel"
Accept-Contact: *;+g.3gpp.icsi-ref="urn%3Aurn-7%3gpp-service.ims.icsi.mmtel"
P-Preferred-Service: urn:urn-7:3gpp-service.ims.icsi.mmtel
}}}

I will add it for the next release.

Original comment by boss...@yahoo.fr on 3 Nov 2010 at 10:59

[GoogleCodeExporter]

Fixed in version 1.0.320.

Original comment by boss...@yahoo.fr on 4 Nov 2010 at 6:54

• Changed state: Fixed

[GoogleCodeExporter]

Hi,

in the new version IMSDroid 2.0.395 is added new string:

Accept-Contact: *;+g.3gpp.icsi-ref="urn%3Aurn-7%3Agpp-service.ims.icsi.mmtel"

This is wrong. String have to be without "%3A".In this case string "%3A" 
replace ":".

Correct string:

Accept-Contact: *;+g.3gpp.icsi-ref="urn:urn-7:3gpp-service.ims.icsi.mmtel"

Please look the next page:

http://www.3gpp.org/Uniform-Resource-Name-URN-list

BR

Original comment by dino.nev...@gmail.com on 27 Apr 2011 at 1:31