Transfering a call places the targets call on hold RRS feed

  • Question

  • We have a setup of OCS 2007, CUPS 6.0.4, and CallManager 6.1.2.  All is working great with the exception of, if a person A is on the phone with person B and person C transfers a call from person D, The conversation between person A and Person B is put on hold and the transfered call from person C rings.  We are using RCC only and have disabled EV from Group Policy. Has anyone seen this before and how do we rectify this?  Thanks.

    • Edited by dmc874 Monday, December 15, 2008 11:01 PM
    Thursday, December 11, 2008 8:36 PM

All replies

  • I received a reply last night that is missing now (I assume from moving the forum)  The suggestion was to add the device to the tel URI line.  Although all users only have one device, we have tested with the device specified and it did not make a difference.  Thanks for the suggestion.

    Friday, December 12, 2008 3:05 PM

  • A little more info on this.  I opened up a TAC case and they are saying that MOC is sending a HOLD to CUPS.  Looking through the logs it has this entry:

    CUPS log snippets:


    [Thu Dec 11 17:10:25 2008] PID(17818) mod_sip.c(375) ipc handler 1 msgs

    PID(17824) sip_protocol.c(5663) Received 931 bytes TCP packet from

    INFO sip:David@;transport=TCP SIP/2.0

    Via: SIP/2.0/TCP;branch=z9hG4bK856DE25F.256418B0;branched=FALSE

    Max-Forwards: 69

    Via: SIP/2.0/TLS;ms-received-port=60572;ms-received-cid=800

    From: <sip:David@xxxxxxx.com>;tag=016e04f41e;epid=402686e493

    To: <sip:David@aepintappp01.xxxxxxxx.com>;tag=76173855-740a0b3b

    Call-ID: 0f23a361dd494bc4a8e84532c7b1d382

    CSeq: 35 INFO

    Route: <sip:David@;maddr=;transport=tcp;lr>

    User-Agent: UCCP/2.0.6362.97 OC/2.0.6362.97 (Microsoft Office


    Content-Disposition: signal;handling=required

    Supported: timer

    Content-Type: application/csta+xml

    Content-Length: 227


    <?xml version="1.0"?>






    I took the domain name out of the forum.  In the actual log the domain is correct.

    77609 is the extension we did the test on.

    Any insight?



    Friday, December 12, 2008 10:41 PM
  • We have made some progress.  We stumbled upon the fact (One person was setup this way and worked) that if you have thier name in the under the directory number it does not place the call on hold any longer.  One would think, well great, just change them and we are good.  THe problem with that is that we have about one third of our branches that if you have anything in that field they cannot make 911 calls.  Any insight would be greatly appreciated.  Thanks.

    Monday, December 15, 2008 10:49 PM
  • Well, we thought we had the solution.  The handful of people we tried it on worked.  We rolled it out to additional people today and it failed even with the field populated so we still have not found it.  We did find however, if the initial call is placed while MOC is shut down, you bring up MOC, and the call is transfered while it is up it does not place the call on hold.  This problem gets stranger by the minute.

    Tuesday, December 16, 2008 11:59 PM
  • How can I turn on logging from the OCS/MOC side so I can see exactly what is going on?  I would like to see the series of events from the Microsoft side to try to figure this out.  Thanks.

    Wednesday, December 17, 2008 12:02 AM
  • OK.  We have narrowed it down further.  Setting the ASCII text works for individuals.  If you transfer directly to them the call is not put on hold.  Where we are running into the issue is using a Hunt Pilot.  If the line group is set to broadcast, anyone that is on that line group and on the phone at the time that a call is transfered to the group gets thier calls put on hold.  If we have it on longest idle then of course it does not ring anyone that is on a call.  Still looing for solutions.  Thanks.


    Thursday, December 18, 2008 7:55 PM
  • Dave,

    This Hotfix was just released and has a lot of RCC fixes in it.  I am familar with the situation you are in, but have not tested it - to see if it resolves the exact issues you are seeing.


    Monday, December 29, 2008 11:42 PM
  • Thanks for the heads up on the patch.  I installed the patch and still have the same result.  There were basically two things it fixed, one being the call forwarding with RCC, and Chinese characters.  The rest were fixed in prior patches.  I have a case open with Microsoft now so we will see what they say.  Thanks again for the reply.

    Monday, December 29, 2008 11:53 PM
  • Ok let me know if I can look into anything for you.

    Monday, December 29, 2008 11:57 PM
  • Oh, I hate to tell you this... but we've been around the block with Microsoft on this one.  We did the same, called TAC who said it was Microsoft sending the HOLD command.  Microsoft admits its them.  They also say that HOLD is a generic response to a state or error it doesn't understand.  I'd have preferred they drop the call rather than stick people in a hold state they can't get out of , but hey.  Microsoft also said we basically weren't a big enough enterprise for them to even attempt to fix it.  They suggested we wait until R2.... but oh, yeah.... if you're using shared lines or hunt groups... it still will happen.  Thus if you're a big company, pound on Microsoft's door to help you... maybe you can get them to fix it for all the rest of us.  *sigh*.
    Wednesday, February 4, 2009 8:40 PM
  • We have been round and round with both.  As you state, MS puts any call on hold it does not understand the command for.  I asked if there was any way to make it disregard anything it doesn't recognize and the answer was no.  Now for the reason it is getting the command it does not understand.  Cisco is sending duplicate CTI requests on anything that does not have an ASCII Display set, of which Hunt Groups is one.  It is Cisco bug  CSCsu84568.  Unfortunately the earliest they will have it fixed will be in CUCM 8 which is September at best.  So basically niether care enough to get it fixed.  Especially MS in this case because they only see the bug in this case as not being thier fault where MOC in my opinion should treat unknowns in a different way, or at least give me the choice to.

    Wednesday, February 18, 2009 10:07 PM
  • MSFT will place a call on hold if there is an existing call in progress and an EstablishedEvent is received.  There cannot be two simultaneous calls (outside of say a conference) so if you have one call and another in *answered* then the first has to be placed on hold.

    Typically this undesired state happens because Cisco sends and EstablishedEvent (which does not mean a call has been placed, it does not mean a call is ringing, it means a call has been *answered*).

    I'm not sure where the idea of "hold in response to something unexpected" comes up.  There are errors that can be sent if unexpected events occur.  If you get an EstablishedEvent before a ClearedEvent then something is going on hold.  This is expected behavor.

    MSFT publishes the exact CSTA flow that it will follow via their UCOIP program.  Most big vendors such as Cisco are part of this program and have access to this spec doc.  If the doc isn't followed then it's garbage-in-garbage-out.
    Wednesday, September 30, 2009 5:20 PM