Originating one to one chat session fails

[GoogleCodeExporter]

What steps will reproduce the problem?
I have two Android emulators running on same machine and i am trying to 
establish chat session.
Start a new one 2 one chat and send a message to the terminating user
The message is delivered to terminating user but as soon as the terminating 
user accepts the invitation, the originating user gets error saying the chat 
session failed.

What is the expected output? What do you see instead?
As soon as terminating user accepts the invitation, the chat session should be 
established and originating user should be able to send further messages.

What version of the product are you using? On what operating system?
2.3.6 . OS - Windows 7

Please provide any additional information below.
Failure occurs at a point when the originatingone2onechat code tries to create 
MSRP client at 10.0.2.15:9.
The socket fails with connection refused error.

Original issue reported on code.google.com by gawri.vi...@gmail.com on 6 Feb 2012 at 10:35

Attachments:

• one2onechatissue.txt

[GoogleCodeExporter]

Your problem is because you are on the same machine so same address IP+port. We 
support RFC4145, in this case the local MSRP port is 9 by defaukt in active 
mode. And in your particular case both instance will use (@IP+port 9).

Original comment by jmauffret@gmail.com on 23 Feb 2012 at 8:43

• Changed state: WontFix

[GoogleCodeExporter]

Or you need an application server between UE instances

Original comment by jmauffret@gmail.com on 24 Feb 2012 at 8:36

[GoogleCodeExporter]

The analysis above is not correct IMHO, and the implementation actually using 
port 9 also seems to me to be incorrect.

Note that the governing RFC for MSRP, 4975, says in section 6.2 that the the 
port to be used must be determined as follows:
"An MSRP host device is identified by the authority component of an
   MSRP URI.

   If the authority component contains a numeric IP address and port,
   they MUST be used as listed."

These are ports 20001 and 20000 in the MSRP uris in the offer and answer 
respectively:
a=path:msrp://10.0.2.15:20001/1328521603204;tcp
a=path:msrp://10.0.2.15:20000/1328521604742;tcp

Section 8.1 of the MSRP RFC says the port in the SDP should (for the most part) 
agree with the port in the path.  

I'd also note that port 9 is a trash port, not to be used, and is presumably a 
dummy value in this case.

Given that the same (unreachable, private) IP address is given for both MSRP 
instances, it is not at all clear to me how the two emulators could ever talk 
to each other from different machines.  The SIP messages have other headers to 
do routing, but the MSRP here, without relays, needs to do a direct TCP 
connection.  I see here on the same machine things can work: 
http://developer.android.com/tools/devices/emulator.html#connecting.  But it 
isn't obvious to me that it would work on different devices... 

I'm gathering the port 9 comes from things like:
http://tools.ietf.org/html/draft-ietf-simple-msrp-acm-05
Which says:
"
   If the a=setup attribute value is "active", the port number value
   MUST either be the actual port number that the MSRP UA will use for
   the TCP endpoint, or the port value 9.
"

Original comment by lndresn...@gmail.com on 16 Jul 2012 at 12:49

[GoogleCodeExporter]

I had two clients running on different machines. Still I am facing the same 
issue ( connection refused ).

Original comment by tupak...@gmail.com on 30 Oct 2012 at 9:41

[GoogleCodeExporter]

I am using 2.4.8 on 2.3.6/2.3.4 android 

Original comment by tupak...@gmail.com on 30 Oct 2012 at 11:33

[GoogleCodeExporter]

I believe the issue is related to the sender of the originator of the invite 
being set as actpass and the terminator of the chat session is then set to 
active BUT both offer port 9 and both the originator and termintor try to 
connect at the same time with both failing. 

I'm not suggesting this as fix I just wanted to post to help others, continue 
discussion, this enabled me to get the Chat Invite working and a MSRP session 
connected. 

I just changed the createSetupAnswer(String offer) in ImsServiceSession as 
follows:

        if (offer.equals("actpass")) {
            // Passive mode by default if there is a NAT or AS IM
            // actpass
                // CHANGED BY ME, from active to passive
            return "passive";
        } else

Now the originator offers actpass and port 9, the terminator responds to the 
offer with passive and port 20000, the originator then connects successfully to 
port 20000 on the terminating device.  
MSRP setup and works (as far as I can see).

Original comment by android....@mob.openmindnetworks.com on 1 Nov 2012 at 2:18

[GoogleCodeExporter]

Yes if you don t have an AS, this is the right solution. Then in the current 
implementation we should follow the comedia rfc.

Original comment by jmauffret@gmail.com on 1 Nov 2012 at 7:21

[GoogleCodeExporter]

I installed the OpenIMS for cscf servers. These servers and clients are working 
behind NAT. While registration and options methods work fine the publish and 
Invite ( for chat) are failing. On further debugging I saw the ACK message is 
delivered from (Chat) Initiator to Termination after receiving the 200 OK. and 
is reaching the server and server ignores it. I just want to confirm is ACK is 
mandatory for 200 OK to establish the  session?

Original comment by tupak...@gmail.com on 3 Dec 2012 at 2:56

[GoogleCodeExporter]

Yes this is mandatory for session based on INVITE

Original comment by jmauffret@gmail.com on 3 Dec 2012 at 6:28

• Changed state: Done