Remote Call Control in Office Communications Server R2 uses UPDATE method to maintain persistent sessions between Communicator 2007 R2 and CSTA Gateway


For most of the administrators who have ran into issues with RCC my colleagues blog has been a great help. With the evolution of OCS and the SIP standard, there have been two changes in the behavior since the time Rajesh put that blog out. Hopefully this blog with help you look out for issues arising due to those changes.


As noted in Rajesh's blog entry, the Microsoft Communicator 2007 R2 (MOC) establishes a persistent connection between itself and the CSTA gateway. This connection is used to send notification\events\commands bi-directionally. MOC is responsible to keep this connection alive. The earlier blog states - "To ensure that the SIP/CSTA Gateway is running and the signaling link is available, Office Communicator refreshes the INVITE dialog every 10 minutes by sending a Re-INVITE with the RequestSystemStatus command." However, MOC now uses an updated mechanism to keep up this connection.


The changes are -

  1. Instead of using re-INVITE  to keep the connection alive, MOC now uses the UPDATE method by default.
  2. Instead of refreshing the session every 10 minutes, MOC now refreshes it every 25 minutes.


After 25 minutes MOC tries to refresh the session. In case the CSTA gateway is not aware of UPDATE method, it may just ignore this request and the session is torn down as the session timer is elapsed. If you enable logging on the MOC and look at the log file in Snooper, you will see that after 25 minutes of inactivity MOC will send a refresh using UDPATE method. However, never get a response from the CSTA gateway.


This will lead to RCC failures where the client is no longer receiving a toast for incoming calls or can no longer originate calls from the desk phone using the MOC, say after 25 minutes of inactivity.


After code level investigation here is the current logical algorithm the MOC uses to decide whether to use UPDATE or reINVITE to refresh the session -



So if the CSTA gateway vendor does not support UPDATE method-

  1. Include an Allow header in the 200OK response to the INVITE,
  1. Do not include UPDATE as supported methods.


Comments (6)
  1. Jigar Dani says:

    Yes, Dr. Rez. I will do the needful asap.

    Thanks for visiting my post.

  2. Jigar Dani says:


    Thanks for visiting my post.

    The changes are to be made on the CSTA Gateway side. They should add an Allow header with no UPDATE method listed.

    Hope this helps.



  3. Jigar Dani says:

    Hi Miguel,

    Thanks for visiting my blog.

    Not that I am aware of. What kind of heard beat is this? Remember this is just to keep the SIP session alive.

    If you want to pursue this further, you can open a case with Microsoft Support and someone will be able to help you find a solution for your complicated deployment. As a final resort, you may also file a Design Change Request, if there is not a work around.

    Hope this helps.



  4. Hi Jigar!

    Nice post.  I would like to add your blog to NextHop UC Blog World at…/ee410018.aspx. But first you would need to add to your blog an About This Blog section and some background intormation on yourself. These are good practices regardless. Are you interested?

    Best… DrRez  ( or

  5. John says:

    We're experiencing the problem where our CSTA gateway is rejecting UPDATE commands. Could you clarify how the fixes you outline at the end of your article get applied? Are you suggesting the CSTA vendor should make those changes, or can they be made somewhere in the OCS/Communicator environment?


  6. miguel says:


    I'd like to know if it's possible to reduce this 25 minutes refreshing time in any way (by configuration…) I'm working with a "complicated" RCC environment and I'm searching for a kind of "heartbeat" method… but I think 25 minutes is a too long interval…



Comments are closed.

Skip to main content