locked
No media operations are allowed because the call is not connected RRS feed

  • Question

  • When a VXML transfer fails for some reason (trying to generate all failure points so we can have corresponding handlers), getting the following error in the event log. This results in the speech server recylcing the process and all the active sessions are lost. Is there any workaround for this?

     

     

    The following unhandled exception has occurred: 'No media operations are allowed because the call is not connected.'. This process will terminate abruptly and any active sessions will be lost. Office Communications Server 2007 Speech Server Service will create a replacement process within 10 minutes or when an incoming call arrives.

    Tuesday, July 17, 2007 3:15 PM

Answers

  • Thanks for this further information, we are looking into this problem.  Please do send us etl logs and also your detailed packet logging.

     

    From your information, I think it is reasonable to assume that the problem is limited to use of the transferaudio attribute.  How important is this for you?  Can you live without transferaudio? 

    Thursday, July 19, 2007 11:21 PM
  • Sorry about that; email located.

     

    When the Speech Server VXML interpreter performs a supervised transfer it puts the 1st leg on hold before placing a call on the 2nd leg.  This is done because some gateways require this behaviour because they re-use the incoming channel to perform the transfer. 

     

    Thus, in order to play a prompt during the transfer, it is necessary to start it before the hold, and then we're dependent on the gateway's implementation of hold as to whether or not the prompt will continue to play after the hold.

     

    The "transferaudio" is initiated before the hold, however it would appear that you have the FetchAudioDelay property set.  This causes the prompt to be delayed until after the hold, hence the exception.

     

    So, the workaround should be to remove FetchAudioDelay.  Let me know if this works.  Otherwise, try as you suggest, to play a fake hold music yourself.

     

     

    As to your other comment: "It seems that this error is not just limited to using transferaudio attribute, the process recycling occurs anytime there is an error during transfer. Please update us on the status."  The specific error that is occuring with transferaudio should only happen if using both transferaudio and fetchaudiodelay.  If you have recycles due to other errors, please send the logs for these also.

    Monday, August 6, 2007 10:29 PM
  •  

    Hello Anthony,

     

    The on-hold audio playback problem was resolved.

     

    At first your response threw me off as I wasn't using fetchaudiodelay anywhere. But adding the following at the begining of the VXML form solved it though:

     

    <property name="fetchaudiodelay" value="0s"/>

     

    no errors in the event log, no process recycling occured. Many thanks for looking into this....

    Tuesday, August 7, 2007 1:53 PM

All replies

  • Ouch.  I suggest that you use Analytics & Tuning Studio to look at the etl logs for this call, to see if they reveal to you where in your application this failure is occurring.  Please also send these etl logs to mssbeta@microsoft.com, with a comment to forward to "Anthony Bearon". 

     

    To capture etl logs, use the Speech Server Admin console, go to the "Trace Logging" tab for your server, and ensure that "Enable trace logging" is checked.  For this issue, ensure that "Platform events", "Analytics and tuning events" and "Application Events" are all checked, and that "Recognizer audio" and "All audio" are not checked.  Start a new log file (under All Tasks on the Right-click menu for your server) before and after repro'ing the issue. Compress the logs before emailing.

    Tuesday, July 17, 2007 5:02 PM

  • Looking at the detailed packets between Speech Server and Gateway, it appears that the inbound call leg is put on hold, then the outbound transfer leg is placed and connects, but audio is only flowing from the callee  (the gateway here) to OCS: the caller is still in hold, and the audio from the callee is not relayed to the caller. It seems that OCS staying stuck in a state where the transfer is deemed neither a success nor a failure.

     

    If I remove the "transferaudio" attribute from the <transfer> element, the transfer goes through. Very strange!

    I will work on getting the .etl log files to you.

     

    Also:

    1. Is there any way to set the ANI of the call during transfer?
    2. Is the aai (link) attribute supported?

    Thanks.

    Tuesday, July 17, 2007 8:05 PM
  • Thanks for this further information, we are looking into this problem.  Please do send us etl logs and also your detailed packet logging.

     

    From your information, I think it is reasonable to assume that the problem is limited to use of the transferaudio attribute.  How important is this for you?  Can you live without transferaudio? 

    Thursday, July 19, 2007 11:21 PM
  • Audio playback is highly desirable feature during the call transfer for us. In the absense of that feature, I was thinking I might queue up a "hold music" prompt just before the transfer; thereby creating a fake transfer music [something is better than long dead air].

     

    It seems that this error is not just limited to using transferaudio attribute, the process recycling occurs anytime there is an error during transfer. Please update us on the status.

    Thanks.

    Monday, August 6, 2007 6:37 PM
  • I haven't received any etl logs from you, please send them.  Also, please capture the NT Application event log as a .evt and include that.  

    Monday, August 6, 2007 7:16 PM
  • I re-sent the email, the previous one was sent on Tuesday, July 17, 2007 4:48 PM.

    Monday, August 6, 2007 7:57 PM
  • Sorry about that; email located.

     

    When the Speech Server VXML interpreter performs a supervised transfer it puts the 1st leg on hold before placing a call on the 2nd leg.  This is done because some gateways require this behaviour because they re-use the incoming channel to perform the transfer. 

     

    Thus, in order to play a prompt during the transfer, it is necessary to start it before the hold, and then we're dependent on the gateway's implementation of hold as to whether or not the prompt will continue to play after the hold.

     

    The "transferaudio" is initiated before the hold, however it would appear that you have the FetchAudioDelay property set.  This causes the prompt to be delayed until after the hold, hence the exception.

     

    So, the workaround should be to remove FetchAudioDelay.  Let me know if this works.  Otherwise, try as you suggest, to play a fake hold music yourself.

     

     

    As to your other comment: "It seems that this error is not just limited to using transferaudio attribute, the process recycling occurs anytime there is an error during transfer. Please update us on the status."  The specific error that is occuring with transferaudio should only happen if using both transferaudio and fetchaudiodelay.  If you have recycles due to other errors, please send the logs for these also.

    Monday, August 6, 2007 10:29 PM
  •  

    Hello Anthony,

     

    The on-hold audio playback problem was resolved.

     

    At first your response threw me off as I wasn't using fetchaudiodelay anywhere. But adding the following at the begining of the VXML form solved it though:

     

    <property name="fetchaudiodelay" value="0s"/>

     

    no errors in the event log, no process recycling occured. Many thanks for looking into this....

    Tuesday, August 7, 2007 1:53 PM