Delay in call setup when using Response Groups and A/V with https Inspection

For the past few days I’ve been working with Microsoft on an issue with Response Group agents seeing a delay between when they click answer in MOC and when the call controls actually show up and audio starts.  The delay is typically between 4 and 8 seconds from the time the agent presses answer and the time they can actually hear the audio and see call controls. 

Let’s start with what a trace in communicator shows us, here is the text from communicator.etl file (%userprofile%\tracing ).

063 TRACE_LEVEL_INFORMATION [1]1100.1604::06/30/2009-16:19:59.583 (CStreamingEngineApi::Invoke:engineapi_cpp2495)<O_TRC><TS>34553891995826784</TS><ADR>0x00BE8608</ADR><MSG>Engine[0x00BE8608].eSetTransportParameter({cid:3,tid:157016104,tt:undef,-,ver:0},mstp_set_server_info=2,(turn_tcp,’10.10.X.X:443′,cred:(,realm:*domain:*)pri:9),(turn_udp,’10.10.X.X:d96′,cred:(,realm:*domain:*)pri:9),0,)=0x0</MSG></O_TRC>

068 TRACE_LEVEL_ERROR [1]1100.1600::06/30/2009-16:19:59.661 (Pipe::Connect:pipe_cpp84)<O_TRC><TS>34553891996602316</TS><ADR>0x00CB0260</ADR><MSG>[ConnectFailed][Position=0][HRESULT=3221504059][PipeElement=0x0962CE78]</MSG></O_TRC>
We tested from the client and verified that we could telnet to the edge servers internal IP on port 443 with no issue.  We also removed the A/V Authentication from the pool and restarted the front end services and there was no delay.  So what we know for sure here is we should be talking to MRAS from the client on TCP port 443, but for some reason we don’t.  We tested again this time capturing a network trace as well with Net Mon, and we never see the TCP connection attempted, but we still see the error above on the client. 

So why would we see a failure on the client but no attempts at the network level you ask?  In our case the culprit just so happened to be Kaspersky A/V which was configured to monitor port 443 (https).  As soon as we disabled this the delay was gone. 

I’m definitely not going to pick on Kaspersky here; it’s a solid product and was just doing as it was told.  However, I did want to point this out as we need to be careful.  It’s very important to keep your client machines and networks protected, you just need to keep https monitoring/inspection and https filtering in mind when you are deploying OCS.

If you’d like to see more of the details on this feel free to ping back, I’ll put a doc together detailing the troubleshooting with examples from snooper and net mon if folks would like to see it.

Also, a quick test to see if this is happening to you is to call to a Tanjay phone that isn’t USB connect in a response group and see if there is a difference between the time it takes to hear audio on the Tanjy and a MOC client.


About Kevin Peters

My name is Kevin Peters.
This entry was posted in Uncategorized and tagged , , , , , , , , , , . Bookmark the permalink.

10 Responses to Delay in call setup when using Response Groups and A/V with https Inspection

  1. Andre Mueller says:


    i have the same delay issue with rgs! could you shortly explain how i can remove a/v authentication?


    • Kevin Peters says:


      There are a couple of places to set this both in the OCS Admin Console:
      #1 – Right Click the forest>Properties>Global Properties>Edge Servers Tab>A/V Edge Servers
      #2 – Right Click the pool>Properties>Pool Properties>A/V Authentication Service
      #3 – Expand Mediation Servers>Right Click the mediation server>Properties>A/V Edge Servers

      I’d remove it from all 3, bounce the boxes and see if that helps the issue.

      Hope this helps!


      • Andre Mueller says:

        Hi Kevin,

        i can try this tommorrow… sametime i opened a support call by ms with the following result:

        „ After the call comes in we generate a CallID, after picking up the phone we create a new call with a new CallID with the Mediation Server and to establish this call will take 5-7 seconds. we are using a supervised transfer to connect the agent with the caller. This means that once the agent accepts the call from RGS, RGS will transfer the call. The agent’s client will then establish a new call (thus the new call ID). We also will lose the old CallID and we cannot use only 1 CallID, as we have to do this because RGS needs to accept the incoming call to play music and prompts (and play questions too)“

        so this is by Design and could not be changed!!!


  2. Kevin Peters says:


    Although what the engineer is describing to you is in fact by design and defined in an RFC, the delay you are experiencing is neither by design or expected.
    Are you having this delay with Tanjay phones or MOC clients?


    • Andre Mueller says:

      Hi Kevin,

      we have this delay with both Tanjay and MOC clients… so there should be no issue on the clients.


      • Kevin Peters says:

        Andres, Here are a couple of the common things to check:
        • Common Certificate Problems
        o MD5 based cert (should be RSA)
        o CRL not valid or accessible
        o SANs on access edge cert
        • Antivirus
        o HTTP inspection blocking traffic to access edge

        Those are the most common issues. How long has your case been open with MSFT?

  3. Like Central says:

    hey, I added ur site to my RSS reader. the posts are awesome! 🙂

  4. Erwin says:

    I have a similar problem with initiating calls from the Tanjay (IP8540). When I get a connection, it takes from 2 to 4 seconds before I hear the other side. Or is this the same problem?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s