RE: Issue with RI 1.2 and Microsoft Live Communication Server (LCS)

Ranga,

Thanks!!!  I will grab the latest code and test, but this sounds like it
will do the trick.  

Best regards,

Mike

  

-----Original Message-----
From: M. Ranganathan [mailto:[email protected]] 
Sent: Thursday, June 29, 2006 3:12 AM
To: Vivino, Michael F (Michael)
Cc: [email protected]
Subject: Re: [nist-sip] Issue with RI 1.2 and Microsoft Live
Communication Server (LCS)

Hi Michael,

I  have changed the code in SIPDialog to clone the last response From
and To headers in generating the new From and To headers so that header
parameters are preserved. Please give it a try and let me know if it
fixes the problem. I am keen on interoperating with as many well known
stacks as possible so yes I am interested in solving such
interoperabiltiy issues provided they are within the norms of the RFC.

>As I said, we already have a workaround in our application code for
now.
>And we could always just tell Microsoft that they really should depend 
>on the tag value(s) alone and map those to their "epid" in their 
>implementation ;)
>  
>
Of course. The issue of course would be whom in Microsoft can you tell? 
There seems to be a few problems in their usage of notify and Message
somewhere. To this end Jeroen added an isBuggyClient method somewhere. 
One shudders to think that maybe they will fix the problem and not
change the User-Agent header version :-)

The latest changes are committed to the cvs repository on
is2.antd.nist.gov. Please see http://jain-sip.dev.java.net  for
instructions on how to get it from there.

Regards

Ranga

Vivino, Michael F (Michael) wrote:

>We recently (early June) upgraded from the 1.1 RI to the latest 1.2 RI,

>which among other things, fixed a bunch of concurrency problems (THANK 
>YOU, by the way!!!).  However, we then encountered a mysterious problem

>with Microsoft Office Communicator (MOC) and their Live Communication 
>Server (LCS), which I have just resolved.  The issue is this:
>
>For the 1.1 RI, the SipDialog.createRequest() method resulted in 
>cloning of the original-request To/From headers.  For the latest 1.2 
>RI, it appears that new headers are created, using the cached local and

>remote address and tag values, so any other parameters present in the 
>origingal To/From headers are dropped.
>
>The problem with this is that MOC/LCS adds a (Microsoft-proprietary?) 
>parameter "epid" (endpoint id) to the From header in their requests.
>LCS apparently depends on this parameter value to make the association 
>with the original UAC (the MOC endpoint). When a UAS wants to send a 
>request on the dialog back to the MOC client through LCS, if the "epid"
>parameter is missing from the To header, LCS drops the request.  Thus 
>the 1.1 RI worked, and the latest 1.2 RI fails.
>
>Once we found the cause, we were able to work around this in code by 
>getting the "epid" parameter from the original request's From header 
>and setting it explicitly on subsequent requests.
>
>It appears either implementation (1.1 or 1.2) could be considered 
>conforming to rfc3261, section 12.2.1.1, in particular:
>
>   The URI in the To field of the request MUST be set to the remote URI
>   from the dialog state.  The tag in the To header field of the
request
>   MUST be set to the remote tag of the dialog ID.  The From URI of the
>   request MUST be set to the local URI from the dialog state.  The tag
>   in the From header field of the request MUST be set to the local tag
>   of the dialog ID.  If the value of the remote or local tags is null,
>   the tag parameter MUST be omitted from the To or From header fields,
>   respectively.
>
>
>This section is mute on what to do about any extension parameters, so 
>they could theoretically be copied or not. And I didn't find much else 
>in the way of guidance on this in the standards.  The question is, 
>would it be a problem to add back in the To/From header cloning 
>behavior?  For now, that's the only way the nist 1.2 implementation 
>will work "out-of-the-box" with MS MOC/LCS -- or any other vendor 
>product that might try something similar with extension parameters 
>here.  Did you have an explicit reason for dropping that behavior from 
>1.2?  What do you think?
>
>As I said, we already have a workaround in our application code for
now.
>And we could always just tell Microsoft that they really should depend 
>on the tag value(s) alone and map those to their "epid" in their 
>implementation ;)
>
>Regards,
>
>Mike Vivino
>
>
>_______________________________________________
>nist-sip mailing list
>[email protected]
>http://www-x.antd.nist.gov/mailman/listinfo/nist-sip
>
>  
>


--
M. Ranganathan 

Advanced Networking Technologies Division, National Institute of
Standards and Technology (NIST), 100 Bureau Drive, Stop 8920,
Gaithersburg, MD 20899. 
tel:301 975 3664 , fax:301 590 0932 http://w3.antd.nist.gov/ Advanced
Networking Technologies For the People!