Welcome to GotSpeech.NET Sign in | Join | Help

Integrating Speech Server with Office Communications Server

A great post from Michael Dunn on Integrating Speech Server with Office Communications Server...

 
 

Sent to you by Brandon Tyler via Google Reader:

 
 

via Search results for '"Speech Server"' by midunn@microsoft.com on 6/16/08

While Speech Server is apart of Office Communications Server, the two do not rely on each and actually do not integrate with each other out of the box. However that doesn't mean it can not be done.

There are two main scenarios which I am always asked about are:

1.) Communicator Calls to Speech Server
2.) Transferring Speech Server calls to Communicator

Calling Speech Server from Communicator

The first thing you need to do is setup a static route in OCS to Speech Server. Here you will need to assign a sub domain, something like ivr.domain.com. This tells OCS to route all calls where the domain contains ivr.domain.com to Speech Server.

 

Next in the Speech Server administrator console you will need to add the OCS Front End Server as a Trusted SIP Peer on non default ports, such as 5068 for TCP and  5069 for TLS. This is required as OCS doesn't handle the 302 Redirect Messages that Speech Server uses, by assigning non default ports we "turn off" these SIP messages. You will also need to enable Mutual TLS.

Note: This will be using TLS, OCS will already have a certificate installed, but Speech Server probably won't, now would be the time to install a certificate on Speech Server.

Next you will need to deploy your application and again assign non defaults ports, these ports should be the same ports as the Trusted SIP Peer. You can assign a "telephone number" to the application as well.

Now you can dial the Speech Server application from Communicator by dialing the static route, like 411@ivr.domain.com.
411 being the extension that you assigned to your application and ivr.domain.com being the sub domain you specified in the OCS routing tab.

Transferring Calls to OCS users

When trying to create a transfer type Speech Server application, you need to know one rule. You can only transfer via the SIP Peer in which the call orginated.

Let's take the static route example we setup previously, if my Speech Server application does a transfer to another OCS user, it would transfer back to the OCS Front End Server and would transfer apporiately via a specified SIP URI. However you couldn't transfer the call to say a PSTN, as the call orginated via OCS.

Note: To do this type of "internal" transfer, make sure to add Speech Server to the Host Authorization tab in the Front End Properties of OCS.

Back to the orginal scenario, a call comes in via the PSTN to probably a VoIP Gateway, meaning when we do a transfer it will be routed back to that same gateway. Depending on your VoIP Gateway, you need to have rules, one or more numbers assigned to forward to Speech Server, and the rest of the numbers should get routed to the Mediation Server.

Typically you do not want Speech Server to sit behind the Mediation Server but next it, as shown in the diagram below.

In your Speech Server application when we do a transfer, instead of transferring to a SIP URI like: sip:midunn@microsoft.com;transport=tcp, you need to transfer to a TEL URI, like tel:+16128591899@microsoft.com;transport=tcp.  Using the TEL URI, the gateway will correctly route it to the mediation server and the mediation server will in turn route it to the correct user.

Tip: Depending on your VoIP Gateway, SIP Proxy, PBX, whatever, specificing the transport parameter is a good idea. I've run into issues where the some 3rd party SIP applications revert back to UDP if this isn't specified.

 


 
 

Things you can do from here:

 
 
Published Wednesday, June 18, 2008 12:17 AM by brandontyler

Comments

# re: Integrating Speech Server with Office Communications Server

Great article - forced me to recheck this solution again (I've allredy done the same trick before).

Not everything is correct here.

Scenario 1. Communicator user wants to call to Speech server.

As this scenario is the most interesting one for me - I've digged it a little.

First point to clarify (this will simply explain the design):

Quote: This is required as OCS doesn't handle the 302 Redirect Messages that Speech Server uses, by assigning non default ports we "turn off" these SIP messages.

Not fully true - OCS & Speech do their work absolutely correctly!

Suppose we issue the static route from OCS to Speech on standart port (5061 for TLS) - all the rest is the same.

Then SIP flow is as follows:

1. Communicator calls OCS, OCS determines, that this URI corresponds to Speech static route.

2. OCS addresses SIP INVITE to Speech server on default port

3. The Speech Telephony Application Host (actually listens on it) determines, what application will serve the request (based on application precedence & called party address), if the application is on the default port - opens connection on random port, if not - the application is allready listening on its' fixed port.

4. Then Speech server really issues 302 - temporary moved.

5. OCS handles this message correcly - sending it to the client (communicator).

6. Communicator agrees with such a change, but it sends the next INVITE back to OCS.

7. OCS have a static route to default port (this is new session sequence)

8. Steps 1-7 loop...

Why this scenario (on default Speech port) does not work for OCS & why it is important?

Does not work: because Communicator cannot contact Speech directly on received port - it cannot use Mutual TLS communication.

So it addresses this problem to OCS server.

But if we use TCP communication instead of TLS everything is working - with only one exclusion - Communicator clients' PC must be added to Speech trusted peers without TLS. This is not the solution - adding ALL communicator clients & ALL servers to trusted peers on Speech can be time consuming and probably resource consuming (cause of Speech internal peers management),

Important because: if you use non-standart port route to Speech, than you must create as many routes from OCS to Speech as applications (each route will need it's own subdomain - (CS will not let you to enter full uri of application - only domain.

Maybe it is normal, but administering can be difficult.

So, instead of calling

app1@speech.ocsdomain.com, app2@speech.ocsdomain.com

...

you will call

app1@speech1.ocsdomain.com, app2@speech2.ocsdomain.com ...

in this scenario.

Sunday, June 29, 2008 4:01 PM by dgp

# re: Integrating Speech Server with Office Communications Server

Second point - when you enter OCS as trusted sip peer to Speech the way it is described (on same non-standart port as application), calls back to OCS (attended transfers, so on) will not work - OCS by default is listening on 5061 port MTLS - not 5069.

Marshall - can you correct me if I'm wrong - SIP peers' ports are used in Speech server for OUTBOUND connections, not INBOUND.

They are equal to Hext hop ports in terminology of OCS and describe ports the peer is listening at.

So for above we need to use one of two options:

1. Add OCS as trusted peer with ports 5060 & 5061 (standart)

2. Add OCS as trusted peer with ports 5068 & 5069 (non-standart) & Make OCS Front End listen on 5068 tcp & 5069 mtls additionally.

I cannot give any motivation for choosing second option for now.

P.S.

You can easily check this - change the peer's ports in Speech to whatever you want and you will hear Speech applications in any way.

Blind transfers will also work, but outbound calls trough the peer will fail.

Sunday, June 29, 2008 4:23 PM by dgp

# re: Integrating Speech Server with Office Communications Server

Point number three.

Tel URI is really for OCS Mediation service, but I could not manage for now to transfer to TEL: URI to OCS Front end - but SIP: URI works well.

Sunday, June 29, 2008 4:28 PM by dgp

# re: Integrating Speech Server with Office Communications Server

& point # 5 - there is a more correct way.

In fact OCS & Speech are allready integrated.

But this will be (I hope) my post...

Monday, June 30, 2008 9:33 PM by dgp
Anonymous comments are disabled