Parlez-vous français?

Se habla español? Hmmm …

Well, do you speak SIP?

 

A few years ago, the author of today's haiku took his mother, his aunt, his sister, and a few assorted groupies and hanger-ons on a vacation to London and Paris.

 

Note. Do people at Microsoft really make enough money to take all those people on a European vacation? Now that the bills have finally finished rolling in, the author of today's haiku can answer that question: not even close.

 

After spending a few fun-filled days in London, it was time to head to Paris. Everyone in the group was excited about going to Paris, but apprehensive as well: after all, people in Paris don't speak English. How can you survive in a country where you don't speak the language?

 

As it turned out, surviving the first day was easy: no matter where they went that first day in seemed like everyone spoke English. On day 2, however, they wandered into a little French restaurant where no one spoke English: not the waitress, not the cook, not even the other patrons. French only.

 

Note. This particular restaurant also sold only one thing: crepes. Based on that menu alone, it might very well be the best restaurant in the entire world.

 

And if you've tried their crepes smothered in dark chocolate sauce and whipped cream then you'll know why we feel confident in proclaiming it the best restaurant in the entire world.

 

At any rate, there was some initial consternation in the group, but not to worry: the author of today's haiku had tried to learn a little French before embarking on the trip (which consisted mainly of learning how to pronounce the phrase "I'm sorry, but I don't speak French"). Somehow or another, though, he managed to get everyone through the meal. Everyone told him what they wanted, he would translate that into pseudo-French for the waitress, then try to translate anything the waitress said back into English. It all seemed to go pretty well, and everyone left the restaurant happy. (Except for the author, who really could have used another one of those crepes.) And, of course, everyone congratulated the author on being able to switch back and forth between French and English, although to this day he still worries that his conversations with the waitress actually sounded like this:

 

WAITRESS: Are you enjoying your lunch?

AUTHOR: Yes, everything is delicious. The trombones are porcupine!

WAITRESS: OK …. Well, let me know if you need anything.

WAITRESS: Yes, we will; thank you. And trombone to you, too.

 

The point of all this is that we don't all speak the same language; because of that, it's useful to have someone who can translate from one language to another. That's true when you go to Paris for a vacation. And it's also true when you set up Mediation Servers and PSTN gateways.

 

Why is it true when you set up Mediation Servers and PSTN gateways? Well, without going into a lot of detail, when you try to make a call from your internal Enterprise Voice network to the external PSTN network, that call passes through a PSTN gateway. Suppose that call fails. In that case, the PSTN gateway reports an ISDN User Part (ISUP) cause code. For example, maybe the gateway issues the ISUP cause code 4915 meaning, "The call could not be completed because the gateway is currently on fire." (Note: As far as we know, that's not a real ISUP cause code.)

 

So what's wrong with that? Nothing; that's what gateways are supposed to do when a call fails. However, Lync Server doesn't understand ISUP cause codes; instead, Lync Server works with SIP response codes. Consequently, when a Mediation Server trunking peer receives an ISUP cause code, it converts that code to a SIP response code; that SIP response code is then sent to the Mediation Server itself. From there, Lync Server uses these response codes to make its outbound routing decisions. For example, a malfunctioning gateway might automatically be assigned a "less-preferred" status; this minimizes the use of the malfunctioning gateway, and thus maximizes the chance of a call being successfully completed.

 

So what's wrong with that? Nothing, as long as the gateway uses the same ISUP cause code to SIP response code mapping that Lync Server uses. But take our hypothetical example. The gateway just sent cause code 4915, which says, "Help, I'm on fire!" But suppose that Lync Server converts cause code 4915 to a SIP response code (say, 7811) that says, "No problems here. And I'm definitely not on fire." In this case, cause code 4915 should have been translated to another pretend SIP response code 2424. Because it wasn't, Lync Server assumes that the gateway is working properly and continues to route calls in that direction, calls that are doomed to fail.

 

That's what we said: trombone!

 

Obviously what's needed here is a translator: we need to take the cause code 4915 reported by the gateway and convert it to its SIP response code equivalent (2424). That's where the CsSipResponseCodeTranslationRule cmdlets (Get-CsSipResponseCodeTranslationRule, New-CsSipResponseCodeTranslationRule, Remove-CsSipResponseCodeTranslationRule, and Set-CsSipResponseCodeTranslationRule ) come in.

 

As the name implies (sort of), the CsSipResponseCodeTranslationRule cmdlets enable you to create translation rules: rules that can take a cause code like 4915 and convert it to the corresponding SIP response code (2424). These rules can be configured at the global scope, the site scope, or the service scope (that is, on the PSTN gateway itself). Is that useful? You bet it is. For example, suppose you have one gateway that doesn't support the Lync Server SIP response codes. In that case, you can configure translation rules for that gateway only. Or suppose none of the gateways in your Dublin site support the Lync Server SIP response codes. That's fine: set up a series of translation rules for the Dublin site. Etc., etc.

 

So how hard is it to create one of these translation rules? As you can see, it's not hard at all:

 

New-CsSipResponseCodeTranslationRule -Identity "PstnGateway:192.168.0.240/Rule503" -ReceivedISUPCauseCode 34 -TranslatedResponseCode 503

 

In this command, we're creating a translation rule for the PSTN gateway 192.168.0.240; this rule is given the Name Rule503.

 

Note. The rule's Identity consists of the scope where the rule is to be applied plus the rule name. What if we wanted to assign Rule503 to the Dublin site? Then our command might look like this:

 

New-CsSipResponseCodeTranslationRule -Identity "site:Dublin/Rule503" -ReceivedISUPCauseCode 34 -TranslatedResponseCode 503

 

 

In this case, we know that the gateway reports an ISUP cause code of 34 that, to the gateway, means "No circuit/channel is available." That cause code should be converted to the SIP response code 503, which would tell Lync Server to bypass the gateway (which is unavailable anyway) and find another way to route calls. By default, though, cause code 34 is not converted to response code 503. Therefore, we need to "manually" tell Lync Server that any time a gateway in the Dublin site reports a cause code of 34 then that value should be converted to SIP response code 503.

 

Make sense? It's like this: if you go to a French restaurant and your mom wants an apple crepe, you need to translate the English word apple into its French equivalent: pomme. It's the exact same thing when you're working with PSTN gateways.

 

Except that nobody ends up getting crepes.

 

And, of course, you can use the other CsSipResponseCodeTranslationRule cmdlets to manage these translation rules. Want to see all the rules created for the Dublin site? No problem:

 

Get-CsSipResponseCodeTranslationRule –Identity "site:Dublin"

 

Or maybe you've installed new gateways and no longer need translation rules in the Dublin site. Again, no problem:

 

Remove-CsSipResponseCodeTranslationRule –Identity "site:Dublin"

 

Etc, etc.

 

That's all we have for today. It's Friday; have a nice trombone everyone.