This article explains how the
new Communications Server default SIP session renegotiation (using the UPDATE method) behavior may break remote
call control sessions between Microsoft Office Communicator and some gateways. In
my experience as a senior support engineer, I have seen this issue with NEC
OW5000 and it could happen with other gateways.
Author: Jigar Dani
Publication date: January 2011
Product version: Microsoft
Office Communications Server 2007 R2
the interoperation between Microsoft Office Communicator and your remote call
control gateway is failing every 25 minutes from the time Communicator starts,
users will not able to do the following:
calls from their desk phone using Communicator
the desktop alert on Communicator for incoming calls to their desk phone
most administrators who have had issues with remote call control, my colleague,
Ramanathan, has written a blog post
that has been a great help. With the evolution of Microsoft Office Communications
Server and the SIP standard, there have been two changes in the behavior of
remote call control since the time Rajesh wrote his post. Hopefully this article
will help you look out for issues that might arise due to those changes.
Remote Call Control
noted in Rajesh’s blog post, Communicator 2007 R2 establishes a persistent connection
between itself and the CSTA gateway. This connection is used to send
notifications, events, and commands bi-directionally. Communicator is
responsible for keeping this connection alive. Rajesh’s blog post states the
“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.”
what has changed is that Communicator now uses an updated mechanism to keep up
changes that mechanism has created are the following:
of using re-INVITE to keep the
connection alive, Communicator now uses the UPDATE method by default.
of refreshing the session every 10 minutes, Communicator now refreshes it every
25 minutes, Communicator tries to refresh the session. If the CSTA gateway is
not aware of the UPDATE method, it might
ignore this request, and the session will break as the session time is elapsed.
If you enable logging on Communicator and look at the UCCP log file in Snooper,
you will see that after 25 minutes of inactivity, Communicator sends a refresh
using the UDPATE method. However, Communicator
never gets a response from the CSTA gateway.
leads to remote call control failures where the user does not receive a desktop
alert for incoming calls or can no longer make calls from the desk phone by using
Communicator after 25 minutes of inactivity.
1 illustrates the current logical algorithm Communicator uses to decide whether
to use UPDATE or re-INVITE to refresh the session.-
1. Communicator algorithm
My investigations found that the CSTA gateway I was dealing
with did not support the UPDATE method. Therefore, it was ignoring the request
from Communicator to update the session. If Communicator does not receive a
response to an UPDATE request, this will most likely be the case.
the CSTA gateway vendor does not support the UPDATE method, do the following:
- Include an Allow header in the 200OK response to
- Do not include UPDATE as a supported method in the Allow header.
This change in how the default SIP session negotiates remote
call control sessions need not leave your Communicator users in a bind. It may
be that the default mechanism to keep a remote call control session alive uses
the UPDATE method instead of a re-INVITE.
Lync Server Resources
- Lync Server 2010 documentation in the TechNet Library
- DrRez blog
- Lync Server and Communications Server resources
We Want to Hear from You
Keywords: Office Communications Server 2007 R2, RCC, remote, call,
control, rcc, R2, gateway, NEC, ow5000, reinvite, invite, refresh, session,
timer, 25, minutes, 10, gw, update, upgrade, moc, communicator, csta