locked
RCC with MOC 2.0 RRS feed

  • Question

  • Hi,
    I have a Office Communications Server 2007 backend and clients are a mix of MOC 1.0 and MOC 2.0 (2.0.6362).  The problem I have is that remote control seems to work on the first client but not the second.
    The user settings are as follows:
    msRTCSIP-Line: tel:+1XXXXXXX2374
    msRTCSIP-LineServer: sip:csta@csta.foo.com

    csta.foo.com points to a CSTA gateway via a static route on the server.  As I mentioned, there are no problems with MOC 1 clients.  MOC 2 clients, however, do not complete the initial negaotiation with the CSTA gateway.  The INVITE to the gateway goes through.  The gateway replies with a 200 OK.  MOC 2 then immediately closes the session with a BYE request.  I looked through the client trace logs:

    10/30/2007|17:43:53.746 1140:188 TRACE :: call.SetState[01741538]  SIP_CALL_STATE_ALERTING-->SIP_CALL_STATE_CONNECTED for sip:csta@csta.foo.com, stack=02138860

    10/30/2007|17:43:53.746 1140:188 ERROR :: OUTGOING_INVITE_TRANSACTION:: ProcessFinalResponse SetRemoteContact failed failed (0x80ee0005)


    After that, it sends the BYE and closes the session.  Does anyone know what difference between MOC 1 and MOC 2 could be causing this behavior?

    Thanks!
    Tuesday, October 30, 2007 10:03 PM

All replies

  • Hi

     

    Maybe you can try with RCC Server URI like sip:+1XXXXXXX2374@csta.foo.com.

    I think it is documented in RTM doc.

     

    Thursday, November 1, 2007 9:19 AM
  • Just tried that.  Didn't work unfortunately.  I still get the same error in the trace logs.

     

    Thursday, November 1, 2007 1:56 PM
  •  

    What is your RCC gateway ?
    Thursday, November 1, 2007 10:56 PM
  • the gateway is something we've developed internally based on TR87 / ECMA323 standard. 

    MOC2 sends this in the initial INVITE:

    <?xml version="1.0"?>^M
    <RequestSystemStatus xmlns="http://www.ecma-international.org/standards/ecma-323/csta/ed3"><extensions><privateData><private><lcs:
    line xmlns:lcs="http://schemas.microsoft.com/Lcs/2005/04/RCCExtension">tel:+1XXXXX7181;phone-context=dialstring</lcs:line></priva
    te></privateData></extensions></RequestSystemStatus>^M

    The gateway replies with this blob in a 200 OK:

    <?xml version="1.0"?>
    <RequestSystemStatusResponse xmlns="http://www.ecma-international.org/standards/ecma-323/csta/ed3"><systemStatus>normal</systemSta
    tus><extensions><privateData><private><lcs:line xmlns:lcs="http://schemas.microsoft.com/Lcs/2005/04/RCCExtension">tel:+1XXXXXXX7181
    ;phone-context=dialstring</lcs:line></private></privateData></extensions></RequestSystemStatusResponse>


    At this point, MOC2 will ACK, then terminate the session with the lines I pasted in previous post in the trace log.

    The gateway works properly with MOC1; instead of terminating the session, MOC1 follows up with a <GetCSTAFeatures>, and continues the session properly.  I'm not really sure what it is that changed in the MOC2 client that causes the session to stop.  It's probably something in the first repsonse from the gateway that MOC2 doesn't like, and that's exactly what I'm trying to figure out.
    Thanks!


    Thursday, November 1, 2007 11:35 PM
  • Hi,

     

    I have seen a similar problem in our LCS lab setup. The MOC2005 client could not setup the phone integration, and when looking in the RCC gateway logs I saw the SIP INVITE and the SIP 200 OK. But there was no ACK from the client, instead just a BYE from the LCS server. It turned out this was caused by the client not able to resolve the DNS name for the LCS pool (enterprise edition). So I would recommend you to check out the DNS from the client running the MOC2.

     

    Good luck!

     

    Thursday, November 8, 2007 1:31 PM
  • Hi,

     

    Did you solve your pb ?

     

    As I have worked a bit more on RCC, I saw that if your RCC gateway works on SIP and not on TLS, you need to had enable SIP on the front end, as by default only TLS is enabled. If you don't, you have a unconsistent behaviour for RCC calls (sometime calls get through sometime not, with 481 call leg does not exist SIP error)

    Wednesday, December 12, 2007 8:30 AM