Closed GoogleCodeExporter closed 9 years ago
The problem comes from IMSDroid which should not send the correct feature tags
for image sharing (see GSMA IR 79). Yoy should have the feature tag
+g.3gpp.app_ref=\"urn%3Aurn-xxx%3A3gpp-application.ims.iari.gsma-is\" in the
INVITE. If it's not the case the RCS stack rejects it with a 606 Not ACceptable.
Original comment by jmauffret@gmail.com
on 23 Mar 2011 at 7:31
Why is the issue from IMSDroid? the sender is the RCS RI client. I thought it
is the RCS RI client at the destination that is rejecting the request.
Here are my tests
RCS RI client (sender) ---------> IMSDroid (works)
RCS RI client (sender) ---------> RCS RI Client (fails)
If it helps, I am using the Ericsson IMS as the back end.
Let me see if I can get the trace at both ends.
Original comment by Sydney.C...@gmail.com
on 23 Mar 2011 at 9:58
Here is my adb trace for the Invite. The invite does contain the g.3gpp.app_ref
tag.
V/[RCS][SipUdpManager]( 1694): Contact:
<sip:146.11.99.169:5060>;+g.3gpp.cs-voice;+g.3gpp.app_ref="urn%3Aurn-xxx%3A3gpp-
application.ims.iari.gsma-is"
Details:
V/[RCS][SipUdpManager]( 1694): >>>>>>>>>> SIP message sent (1123 bytes):
V/[RCS][SipUdpManager]( 1694): INVITE tel:+61xxxxxxxx SIP/2.0
V/[RCS][SipUdpManager]( 1694): Call-Id: rRa_f7S+AA@146.11.99.169
V/[RCS][SipUdpManager]( 1694): CSeq: 1 INVITE
V/[RCS][SipUdpManager]( 1694): From: "test1"
<sip:+61xxxxxxxx@ericsson.com>;tag=rRa_f7S_AA
V/[RCS][SipUdpManager]( 1694): To: <tel:+61xxxxxxxxx>
V/[RCS][SipUdpManager]( 1694): Via: SIP/2.0/UDP
146.11.99.169:5060;branch=z9hG4bK1300838065267
V/[RCS][SipUdpManager]( 1694): Max-Forwards: 70
V/[RCS][SipUdpManager]( 1694): Contact:
<sip:146.11.99.169:5060>;+g.3gpp.cs-voice;+g.3gpp.app_ref="urn%3Aurn-xxx%3A3gpp-
application.ims.iari.gsma-is"
V/[RCS][SipUdpManager]( 1694): Route:
<sip:xxx.xxx.xxx.xxx:5081;lr;transport=udp>
V/[RCS][SipUdpManager]( 1694): User-Agent: IM-client/OMA1.0
Orange-RCS-client/V2.0
V/[RCS][SipUdpManager]( 1694): Allow: INVITE, ACK, BYE, CANCEL, NOTIFY,
OPTIONS, MESSAGE
V/[RCS][SipUdpManager]( 1694): Supported: timer
V/[RCS][SipUdpManager]( 1694): Content-Type: application/sdp
V/[RCS][SipUdpManager]( 1694): Accept-Contact:
*;+g.3gpp.cs-voice;+g.3gpp.app_ref="urn%3Aurn-xxx%3A3gpp-application.ims.iari.gs
ma-is";explicit
V/[RCS][SipUdpManager]( 1694): Content-Length: 400
V/[RCS][SipUdpManager]( 1694):
V/[RCS][SipUdpManager]( 1694): v=0
V/[RCS][SipUdpManager]( 1694): o=+61433977873 3509826865 3509826865 IN IP4
146.11.99.169
V/[RCS][SipUdpManager]( 1694): s=-
V/[RCS][SipUdpManager]( 1694): c=IN IP4 146.11.99.169
V/[RCS][SipUdpManager]( 1694): t=0 0
V/[RCS][SipUdpManager]( 1694): m=message 20000 TCP/MSRP *
V/[RCS][SipUdpManager]( 1694):
a=path:msrp://146.11.99.169:20000/1300838065265;tcp
V/[RCS][SipUdpManager]( 1694): a=connection:new
V/[RCS][SipUdpManager]( 1694): a=setup:active
V/[RCS][SipUdpManager]( 1694): a=accept-types:image/jpeg
V/[RCS][SipUdpManager]( 1694): a=max-size:524288
V/[RCS][SipUdpManager]( 1694): a=file-transfer-id:1300838065265
V/[RCS][SipUdpManager]( 1694): a=file-disposition:render
V/[RCS][SipUdpManager]( 1694): a=sendonly
V/[RCS][SipUdpManager]( 1694): a=file-selector:name:"DSC_0002.jpg"
type:image/jpeg size:2705481
Will try to capture the receiving trace today.
Original comment by Sydney.C...@gmail.com
on 23 Mar 2011 at 10:05
Sorry I haven't understood your first decription.
I have checked the code and we send a 606 if there is no GSM call initiated
before the INVITE (RCS rich call feature) or if the INVITE does not match the
internal triggering rules (for image sharing it's: presence of tag "MSRP" and
presence of tag "+g.3gpp.app_ref...").
In your case it seems you don't initiate a GSM call.
Original comment by jmauffret@gmail.com
on 24 Mar 2011 at 7:40
Sorry for the belated reply. I was sick.
Back to your answer, I am happy with the diagnostic. That is exactly what has
happened. I did not initiate a GSM call hence the error 606.
Can we modify the behaviour that it ignores checking for GSM prerequisite? This
is for our POC project (Proof of Concept).
Original comment by Sydney.C...@gmail.com
on 29 Mar 2011 at 5:37
To disable GSM call correlation, you can use the "Provisioning" application to
uncheck the local parameter "Rich call mode" in the second panel (don't forget
to save the config via the menu and to restart the RCS service). Or set the
database parameter RcsSettingsData.RICHCALL_MODE to false by default in the
code).
Original comment by jmauffret@gmail.com
on 29 Mar 2011 at 8:32
Thanks. I will try the code mode.
Oh FYI, the provisioning application crashed on running on a Nexus S (Android
2.3). Is this a bug? Do you want me to log this issue separately?
Original comment by Sydney.C...@gmail.com
on 29 Mar 2011 at 9:59
Please, send us the traces concerning this bug.
Original comment by jmauffret@gmail.com
on 30 Mar 2011 at 6:44
Please close issue. All is working now. Mistake on my part. I was installing
software in incorrect order. I should have install the RCS_core_2.2.0.apk
before RCS_provisioning_2.2.0.apk
Many thanks again :)
Original comment by Sydney.C...@gmail.com
on 1 Apr 2011 at 4:55
Original comment by jmauffret@gmail.com
on 1 Apr 2011 at 6:04
Original issue reported on code.google.com by
Sydney.C...@gmail.com
on 23 Mar 2011 at 1:03