Sign in
Microsoft.com
 
Microsoft
 
 
 

locked
best practice for queuing outbound calls RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote

     

    Hello,

    What is the best practice for queuing outbound calls to msmq in 2007?  For example, we may identify 100 calls that need to be made.  We are interfaced to a pbx via a 4 port gateway.  Should you just dump all 100 messages into the queue at once?  Or is there a way to monitor/communicate withspeech server to know when to submit the next message?

     Thanks!

    Jon

    Wednesday, April 30, 2008 6:51 PM

Answers

  • Question
    Sign in to vote
    0
    Sign in to vote

    The intent of MSMQ support is that you dump all the messages into the queue at once & SpeechServer will work through them as fast as it can.  If you set MaxOutgoingCalls, Speech Server will limit the number of simultaneous calls to this setting. 

     

    If you want to share the 4 ports between incoming & outgoing such that either incoming or outgoing can use any of the 4 ports, then Speech Server can handle this, and will throttle the outgoing calls if a port is not available, but it's ability to do so is hampered by having no direct knowledge of the current state of the gateway.  It relies on the SIP error code returned from the outgoing INVITE.  You will probably need to look at the SipPeerException from the MakeCallActivity & set ShouldThrottleMsmqCalls yourself based on this error code.

     

    If you want to control the rate at which Speech Server places outbound calls yourself, then you are probably better off sending a POST to the .speax page to initiate your application, rather than using MSMQ.  There are no inbuilt mechanisms for communication with Speech Server, but since your Speech Server app is just .Net code, you can implement this yourself.  You can monitor Speech Server via it's perf counters.

    Thursday, May 1, 2008 9:30 AM

All replies

  • Question
    Sign in to vote
    0
    Sign in to vote

    The intent of MSMQ support is that you dump all the messages into the queue at once & SpeechServer will work through them as fast as it can.  If you set MaxOutgoingCalls, Speech Server will limit the number of simultaneous calls to this setting. 

     

    If you want to share the 4 ports between incoming & outgoing such that either incoming or outgoing can use any of the 4 ports, then Speech Server can handle this, and will throttle the outgoing calls if a port is not available, but it's ability to do so is hampered by having no direct knowledge of the current state of the gateway.  It relies on the SIP error code returned from the outgoing INVITE.  You will probably need to look at the SipPeerException from the MakeCallActivity & set ShouldThrottleMsmqCalls yourself based on this error code.

     

    If you want to control the rate at which Speech Server places outbound calls yourself, then you are probably better off sending a POST to the .speax page to initiate your application, rather than using MSMQ.  There are no inbuilt mechanisms for communication with Speech Server, but since your Speech Server app is just .Net code, you can implement this yourself.  You can monitor Speech Server via it's perf counters.

    Thursday, May 1, 2008 9:30 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Thank you Anthony.  Glad to know we've been on the right track...  Do you have any guidance on which SipPeerExceptions should be throttled and which ones not?

     

    Thanks

    Jon

     

    Thursday, May 1, 2008 11:57 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    SIP error codes are defined in the SIP RFC http://www.ietf.org/rfc/rfc3261.txt.  Unfortunately the use of these error codes varies across SIP implementations.  SpeechServer exposes the ResponseCode on SipPeerException so that you can tailor your app to the Sip Peer that you're using, if appropriate.

     

    As for throttling, Speech Server throttles on 503 by default, described here:

     

    21.5.4 503 Service Unavailable

       The server is temporarily unable to process the request due to a
       temporary overloading or maintenance of the server.  The server MAY
       indicate when the client should retry the request in a Retry-After
       header field.  If no Retry-After is given, the client MUST act as if
       it had received a 500 (Server Internal Error) response.

       A client (proxy or UAC) receiving a 503 (Service Unavailable) SHOULD
       attempt to forward the request to an alternate server.  It SHOULD NOT
       forward any other requests to that server for the duration specified
       in the Retry-After header field, if present.

       Servers MAY refuse the connection or drop the request instead of
       responding with 503 (Service Unavailable).


    This was the best generalisation that we could make.  Unfortunately behaviour differs between gateways, and use of 503 is not consistent, which is why we allow setting of SipPeerException.ShouldThrottleMsmqCalls in OpenCompleted, so that you can tailor your application to the gateway being used. 

     

    Note that ShouldThrottleMsmqCalls has to be set within ITelephonySession.OpenCompleted.  I'm not sure off-hand if you'll still be within OpenCompleted when a workflow fault handler executes, you'll have to look at the callstack in the debugger.  Or, to be sure, wire up to OpenCompleted manually before MakeCall executes, and put this logic in your handler.

     

    Sorry I can't be more help; you need to find out what your gateway does to get a definitive answer.

    Thursday, May 1, 2008 1:15 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    I can't figure out how to set ShouldThrottleMsmqCalls.  Can you provide an example?

     

    Monday, May 19, 2008 6:03 PM