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?
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.
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?
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.
2008年5月19日 18:03I can't figure out how to set ShouldThrottleMsmqCalls. Can you provide an example?