none
Call drop after 30 seconds of perfect silence (No RTP stream) is this by design? Can it be changed

    Question

  • Setup _ we have OCS R1. Mediation server is connected to Call Manager via a Cisco Cube.
    The system is working very well except for one "quirk".

    If an OCS user leaves a message on Cisco unity, after exactly 30 seconds from starting to leave a message the call is dropped even if you are midway through talking.
    Looking at the network trace _ looking at SIP on 5060 from the mediation server.
    There is no SIP traffic for 30 seconds; call setup is all normal etc, until suddenly the mediation server sends a SIP BYE.
    Looking at the RTP stream all the traffic is one way. From OCS to unity. I.e. there is effectively perfect silence the other way and no RTP stream coming back.

    I suspect that OCS detect the lack of RTP traffic coming back and closes the call.
    Is my suspicion correct and is there anyway to alter the behaviour of OCS to not close the call for say 6o seconds or longer?

    Thanks for any help


    Alistair
    • Moved by Matt Sousa - MSFT Thursday, December 17, 2009 10:54 PM forum migration (From:Telephony)
    Tuesday, March 31, 2009 1:41 PM

All replies

  • Hi Alistair,

    Glad you brought this up as I have the exact same problem. I think it could be related to the update message that the IP-IP GW sends to the medaition server. I get a interal server error which doesnt really say to much other than there is an issue. Then not long after that the call ends.

    Ceratinly seems to be an OCS issue and I am not sure whether R2 will fix the issue. I am going to keep looking into this and see what I can come up with.


    Cheers
    Chris
    http://voipnorm.blogspot.com/
    Tuesday, March 31, 2009 7:25 PM
  • Hi Alistair,

    I did a bit of research into this and so far no luck. I have the latest updates applied to the R1 mediation server and other than the generic internal server error generated by the mediation server there is really no clue as to what else is going on. I am in the process of getting an R2 medaition configured in the lab so hopefully in the next few days I will have the answer as to whether this solves the issue. I have also sent some MSFT folks the log details to see if this is a known problem. If it isnt I will raise a PS case to get us some help solve it. I am surprised this issue hasnt been raised before.

    Cheers
    Chris
    http://voipnorm.blogspot.com/
    Wednesday, April 01, 2009 6:27 PM
  • In my experience the "30 seconds timeout" on Mediation Server is mostly a problem with missing (or not the expected kind of) RTCP events. Maybe you can investigate that in your environment.
    Johann Deutinger | MCTS Exchange 2007 / OCS 2007 (+088-924)
    Wednesday, April 01, 2009 9:35 PM
  • Thanks for the tip. I will check it out.
    http://voipnorm.blogspot.com/
    Wednesday, April 01, 2009 9:39 PM
  • Thanks both. I will dig into the RTCP too.
    I have also dropped a line to Francois to see if he can find out anything.

    Regards
    Alistair



    Alistair
    Thursday, April 02, 2009 4:17 PM
  • I did the same thing. Finding out whether there is a RTCP timer WMI setting would be good then it can probably be changed. I read a few different things that sound similar with unity and Cisco gateways running MGCP so I think you were on the right path to start with.

    Cheers
    Chris
    http://voipnorm.blogspot.com/
    Thursday, April 02, 2009 9:36 PM
  • After testing today this issue is still present with R2 mediation server.

    Cheers
    Chris


    http://voipnorm.blogspot.com/
    Friday, April 03, 2009 6:50 PM
  • Update: This is seems only to be related to Unity voicemail. Other voicemail system tests off the same Cisco cluster prove its Unity only affected by this issue.
    http://voipnorm.blogspot.com/
    Friday, April 03, 2009 7:41 PM
  • Seems this is (OCS) system wide problem. MOC or Tanjay devices does not have this problem. If you trace the Medation stack, you'll see that upon placing the call on hold, MOC devices will triger ProxySDP request, which in turm makes Mediation server to keep the channel alive.

    If SDP is not trigered, after 30 sec., w/o RTP, Mediation will send GOODBY and close the channel.


    Drago
    Friday, April 03, 2009 10:07 PM
  • Update: I am in agreement with Drago statement above. The problem will result if using direct connect between CUCM and OCS or if you have a gateway between the two enviroments. Seems to be an issue for any version of Unity 5.x and below. Not sure about 7.x or any of the Unity connection versions. Cisco have also seen this problem with Unity and MGCP gateways. The solution to that problem is to disable RTCP timers in MGCP. As yet there is no solution to this issue for OCS.
    http://voipnorm.blogspot.com/
    • Proposed as answer by VoIPnorm Wednesday, June 17, 2009 4:09 PM
    Thursday, April 16, 2009 5:20 PM
  • The 30 Second Timeout also occurs between Mediation Server and Asterisk 1.6. I adjust the Asterisk RTP Timeout values but the issue is still there.
    VoIPen
    Tuesday, June 09, 2009 4:22 PM

  • VoIPen - I have Asterisk 1.6.0.1 talking directly to an OCS R2 mediation server - & RTP does not time out on hold.


    Are you using an X-Lite client to connect to Asterisk & then using that client to place the call to OCS?  There is a setting in the default X-Lite client that times out after 30 seconds of silence.


    Regards

    Paul Adams
    Friday, June 12, 2009 10:56 PM
  • Paul

    Setup 1 - OCS Medation server <<SIP>> Asterisk 1.6 <<H323>> Avaya CM. The only time i get this issue is when I call into a Live Meeting or and OCS Conf Call from the Avaya Side and MUTE the Avaya Caller. Any other call scenario works fine.

    Setup 2 - OCS Medation server <<SIP>> Dialogic 2000 <<ISDN>> Avaya CM. There is no issue at all. However Asterisk sounds way better then Dialogic and is less expensive.

    I may research the Proxy SDP angle.


    VoIPen
    Wednesday, June 24, 2009 8:03 PM
  • Interesting link - http://www.dialogic.com/den/forums/p/4895/19487.aspx

    Post by Vic Small

    SIP control 2.0 is not currently supported with OCS R2. SIPcontrol v2.1, due for release within the next couple of months will support R2.

    However although not supported it does generally work OK, the one major issue I am aware of is that calls on hold for more than 30 seconds will be disconnected by OCS.

    Your problem looks different but I don't know what the issue is I'm afraid, it looks like some kind of routing issue in OCS as the call should clearly not be coming back to to SIPcontrol but should be forwarded onto the appropriate OCS end point.


    VoIPen
    Wednesday, June 24, 2009 8:09 PM
  • My fix with Asterisk 1.6

    In SIP.CONF file I added the following in [General] section
    rtptimeout=60
    rtpholdtimeout=300
    rtpkeepalive=20       ;Send a keepalive ever 20 Seconds if using NAT
    nat=yes

    I am not using NAT but Asterisk assumes everything is using NAT and to send keepalives every 20 seconds.

    The Medation Server may have a RTP/RTCP Inactivity Parameter set to 30 Seconds ???
    Before the change to SIP.CONF Asterisk was not sending any RTP/RTCP and therefore the Mediation Server disconnected the caller after 30 seconds.
    After the change Asterisk is sending an RTP keepalive and the Mediation keeps the call up.


    VoIPen
    Friday, June 26, 2009 4:00 PM
  • Same issue here... Call Manager 6... OCS 2007 R2... Call muted in a conf call by MOC... Call is dropped 30 seconds later... debug/trace shows no RTCP

    Cisco TAC support points to MS, MS points to Cisco (implementing old RFC...)... Wonderful world.
    Monday, July 20, 2009 8:26 AM
  • Hi HarMa,

    Your situation is a new one I have never heard of. Whats you setup?

    Cheers
    Chris
    http://voipnorm.blogspot.com/
    Monday, July 20, 2009 10:25 PM
  • Hi,
    setup (for HarMa) is the following :
    OCS 2007 R2 Std Edition
    OCS 2007 R2 Mediation server on direct SIP with Cisco UCM 6.1

    Cisco actually never sends rtcp towards the mediation side (regardless of mute state)

    At another site we have
    OCS 2007 R2 Mediation server on direct SIP with Cisco UCME 4.2 and works perfectly well (rtcp is always sent from Cisco to MS)

    On the 30 seconds, OCS mediation will send a BYE towards cisco (in our problematic environment)
    For these 30 seconds (once the rtp stream has been stopped by the mute command) there is absolutely no incoming traffic from the Cisco system...
    Tuesday, July 21, 2009 2:56 PM
  • Hi,

    I have a similar problem with a Direct SIP Connection between a Alcatel PBX and OCS R2.

    30 second after the call is answer the OCS drops the call.

    This append when a Alcatel IP phone dial to another Alcatel IP phone that is foward to the OCS

    I have seen in the traces that the pbx send a SIP invite to the  mediation server with the PBX IP and when the call is answer in the MOC client the PBX send a Reinvite with  the IP phone and the OCS answer with a SIP error “SIP/2.0 491 Proxy side reinvite failed, pass result to GW.” and 30 seconds later sends a BYE and drops the call.


    It appears that the OCS don´t allow the reinvite of the call when the call is connected

    Thursday, July 30, 2009 5:04 PM
  • Hello, let me comment on a few of the questions above.

    First, at a high level, we are trying very hard to make OCS standard compliant. We feel that OCS is compliant with the letter and the spirit of the various RFC on RTP/RTCP specifically, as these are the ones at the center of this discussion. We actually have a rather strict implementation - I might call it "pure". Part of the complexity is when others (next hops) may not have the same approach.

    At the current stage of our understanding, we believe that the issues encoutered here are caused by the far end (on the outside of the Mediation Server) not providing RTCP when we expect it. It is our understanding of the RFC that RTCP should flow even when RTP is not. This is consistent with (for example) RFC3264: http://www.ietf.org/rfc/rfc3264.txt

    Note that in the case of the Real Time Transport Protocol (RTP) [4], RTCP is still sent and received for sendonly, recvonly, and inactive streams.  That is, the directionality of the media stream has no impact on the RTCP usage.

    Our implementation expects compliance. The Open Interoperability Program is provided to vendors so they can verify and qualify compliance and for customers to identify compliant solutions. It is important to note that several of the solutions mentioned above (in particular Alcatel and Asterisk) have not gone through the OIP at this point. It's unfortunate, but not entirely surprising, that issues might be encountered.

    It is a different issue w/r to solutions that are listed on the OIP page, and in particular w/r to the Cisco OIP qualified solutions, the issues encountered are something that could appropriately be considered a bug. Part of the subtlety is whose bug it is ;)

    Apparently, Cisco's implementations of RTCP are not what we expect from our understanding of the standard. It seems that no RTCP flows when RTP does not, which (as quoted above) is not what we expect. There appears to be broad agreement in the industry on that (see for example http://www.ietf.org/mail-archive/web/sip/current/msg09641.html ). 

    Regardless of whose fault it is, we understand we cannot leave customers hostage of this situation and are endeavoring to find a solution.

    Tuesday, October 27, 2009 8:19 PM
  • Thanks for the detailed post, I look forward to a final resolution.  In the meantime, any known work-arounds?  Current setup is Cisco 2800 series ISR -> Mediation Server. Cisco end-point calls into OCS conference and is placed on mute - not rtcp traffic generaed in the ISR, 30-seconds later call is dropped.  (same as above, but using Cisco ISR versus direct-sip)
    thanks for any suggestions on possible workarounds in the interim.

    Thursday, October 29, 2009 2:21 AM
  • Hi, :)

    I don't know if it is a possible workaround for your implementation with Cisco, but I like to share what snom did:

    snom phone's equipped with the OCS edition firmware had the same issue with exactly 30 sec. call drop when on hold, etc. The workaround in the next, and current firmware releases was (is) pretty simple:

    Sending none-audible RTP short before the 30 seconds time-out. Not the best idea, regarding the slight unneccesary network-load - but it works. :)

    Afaik it has no other side-effects.

    Maybe you can change something at the Cisco side to get a similar workaround in place?

    Regards,
    Jan


    Jan Boguslawski | Consultant IT Infrastructure | MCITP: EA, MCTS OCS, MCTS EXCHANGE | ITaCS Berlin | www.itacs.de
    Thursday, October 29, 2009 9:26 AM
  • Just as a follow on from the earlier post. HarMa comments. What you are describing is correct. Cisco IP phones do not send RTCP when externally muted although this doesnt stop them from working when they mute themselves. This is because the mute function on the phone itself is a physical function of the phone and there is no signalling involved or change in bahaviour on the wire (so to speak) other than not sending RTP. I just wanted to clarify this for people so there was no confusing as to why it works one way and another way doesn't. As Francois pointed out Cisco's implementation is the same throughout their product line for RTCP.

    Cheers
    Chris
    http://voipnorm.blogspot.com/
    Thursday, October 29, 2009 8:44 PM
  • Hello:

    The only supported workaround in the interim would be to use an OIP qualified GW in IP2IP mode between the 2 worlds. Of course that is not free.

    It does not hurt to let the "other" vendors know of the issue and to log bugs with your respective vendors...

    Friday, October 30, 2009 10:28 PM
  • Correct, if the phone mutes itself, no issue. However in a conf call, it is a hassle to ask all participants to mute themselves, this is the function of the host/leader. We have not found any resolution to this. Cisco blaims MS for implementing a Cisco (!!!) RFC but what that is still draft. MS blames Cisco for not following up on their RFC... We had a suggestion from the Cisco side to use HW IP Gwy but this does not work. So to summarize current status: The problem exists for ALL Cisco Call Managers. It does NOT exist though for Call Manager Xpress, as this is HW IP Gwy :)
    Saturday, October 31, 2009 8:05 PM
  • Question is that is anyone going to pick up the tab on this issue and resolve it? (Either MS or Cisco - I believe this is where MS should provide options). Maybe implement a patch that adds a checkbox like "Using Cisco/etc for Call Control" and if checked, OCS does not expect the RTCP signals to be provide when on Mute? This is a huge issue as many companies have investments in Cisco CM and are not ready to rip out the entire system because of a simple Mute issue incompatibility.
    Saturday, November 21, 2009 3:41 PM
  • Has anyone testet this issue with alcatel-lucent OXE ?
    Wednesday, November 25, 2009 9:17 AM
  • That issue cannot exist with OXE since there is no Direct SIP solution with OXE.
    Saturday, December 05, 2009 3:51 AM
  • Ahhh, finnally a solution my friends. Install the latest April mediation server update adn make the recommended changes outlined in the KB article.

    http://support.microsoft.com/kb/981218/

     

    from the KB article

    On the Microsoft Office Communications Server 2007 R2, Mediation Server, a media time-out occurs. This time-out occurs if no Real-Time Transport Protocol (RTP) packets or Real-Time Control Protocol (RTCP) packets are received for 30 seconds. When Office Communications Server 2007 R2, Mediation Server interacts directly through Session Initiation Protocol (SIP) with Cisco Call Manager (CCM), the following scenarios in which no RTP packets or RTCP packets are received for a call occur:

    • For a call that is on hold, the direction attribute is inactive from the perspective of the Mediation Server and the perspective of CCM. In this case, CCM does not send any RTP packets or RTCP packets. Existing Mediation Server code ignored the media time-out. Therefore, the call is not dropped.
    • A CCM user joins in an Office Communications Server 2007 R2 conference, and then mutes the telephone. Additionally, the direction attribute for the Mediation Server for the interaction with CCM issendonly. Additionally, the direction attribute for the phone isrecvonly. In this case, CCM does not send any RTP packets or RTCP packets while the telephone is muted. Therefore, the call is dropped after 30 seconds.
    • An Office Communicator user calls a CCM user who is configured to use Cisco Unity voice mail. When the call is connected to Cisco Unity, the call obtains the original media packets from Cisco Unity. Then, the Office Communicator user is prompted to leave a voice mail. However, Cisco Unity does not send any RTP packets or RTCP packets when the Office Communicator user leaves a voice mail. Therefore, a media time-out occurs after 30 seconds. Then, the call is disconnected, and the Office Communicator user cannot leave a voice mail.

    http://voipnorm.blogspot.com/
    • Proposed as answer by HT-Connect Tuesday, April 20, 2010 7:00 PM
    Friday, April 16, 2010 3:19 PM
  • This fix is provided by Microsoft as part of its commitment to interoperability. Note however that the core issue (non compliance on the Cisco side) is not resolved and that the fix forces us to depart from the standards as well (on the mediation server in question). While this resolves the main issue, it could have unforeseen negative consequences. Therefore this does not remove the need for Cisco to become standard compliant with respect to RTCP, and customers should continue to require all their vendors to strive towards compliance.
    • Proposed as answer by HT-Connect Tuesday, April 20, 2010 7:00 PM
    Friday, April 16, 2010 4:26 PM
  • Absolutly. We tested this fix and it was a success but like FDoremieux mentioned, we would love to get CUCM to actually be compliant so we would not require this fix. We hope that happens sometime soon.
    Tuesday, April 20, 2010 6:59 PM
  • I downloaded the hotifx, and even the cumulative mediation.msp but following the installation we could not get the mediation service to start!

     

    We even restarted the server, but still the service remained stoppped.

    We had to remove the update in order to get the service started!

    Anyone to help  us on that?

    Friday, May 14, 2010 5:24 PM
  • I had the same issue - Mediation Service would not start after applying patch.  Updating the Managed  API 2.0 fixed it. See KB982614 or download the Cumulative Update ServerUpdateInstaller.exe

     <http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=b3b02475-150c-41fa-844a-c10a517040f4>

    Saturday, June 05, 2010 7:15 PM
  • Hi,  this is a common problem in G711.

    try this. Deactivate VAD and CNG and the calls is not droped when dont have media.

    Alejandro torres

     

    Tuesday, July 06, 2010 6:36 PM

  • Ahhh, finnally a solution my friends. Install the latest April mediation server update adn make the recommended changes outlined in the KB article.

    http://support.microsoft.com/kb/981218/

     

    from the KB article

    On the Microsoft Office Communications Server 2007 R2, Mediation Server, a media time-out occurs. This time-out occurs if no Real-Time Transport Protocol (RTP) packets or Real-Time Control Protocol (RTCP) packets are received for 30 seconds. When Office Communications Server 2007 R2, Mediation Server interacts directly through Session Initiation Protocol (SIP) with Cisco Call Manager (CCM), the following scenarios in which no RTP packets or RTCP packets are received for a call occur:

    • For a call that is on hold, the direction attribute is inactive from the perspective of the Mediation Server and the perspective of CCM. In this case, CCM does not send any RTP packets or RTCP packets. Existing Mediation Server code ignored the media time-out. Therefore, the call is not dropped.
    • A CCM user joins in an Office Communications Server 2007 R2 conference, and then mutes the telephone. Additionally, the direction attribute for the Mediation Server for the interaction with CCM issendonly. Additionally, the direction attribute for the phone isrecvonly. In this case, CCM does not send any RTP packets or RTCP packets while the telephone is muted. Therefore, the call is dropped after 30 seconds.
    • An Office Communicator user calls a CCM user who is configured to use Cisco Unity voice mail. When the call is connected to Cisco Unity, the call obtains the original media packets from Cisco Unity. Then, the Office Communicator user is prompted to leave a voice mail. However, Cisco Unity does not send any RTP packets or RTCP packets when the Office Communicator user leaves a voice mail. Therefore, a media time-out occurs after 30 seconds. Then, the call is disconnected, and the Office Communicator user cannot leave a voice mail.

    http://voipnorm.blogspot.com/
    As far I understand the Lync 2010 mediation server still times out calls with inactive or sendonly streams. Basically, I am getting call dropped when putting caller on hold on the Lync client after 30 secs. While I appreciate the the 3rd party gateway doesn't comply by cutting  RTCP I am wondering if anyone else has experienced the same issue.
    There was a fix offered by  Microsoft for OCS 2007 R2 in http://support.microsoft.com/kb/981218/ but it doesn't seem to work in Lync 2010. Has anyone else experienced the same issue and have a possible solution for Lync 2010?
    Irek
    Thursday, December 09, 2010 5:40 AM