Thursday, August 19, 2010

Transferring calls from Exchange UM AA or OCS to PBX - Gateway Passed # Matters

Here’s another interesting problem I came across awhile ago. During New Orleans TechEd and CS 14 training, I actually asked the Microsoft representatives about manipulating SIP addresses and REFER fields and got different answers. From New Orleans, they said that there’s more control and might be able to modify them but from CS 14 training in Arizona, I was told by one of the MCS consultants who was also a trainer that this cannot be done. Since CS 14 is still in beta refresh right now, I’m going to wait till it comes out to do some testing:

Problem – DID passed to AA without a “+”

Call Flow

External PSTN number mapped to AA: 6095

Cisco 2801 Gateway receives the PSTN number and passes it to the mediation server as: 6095

Mediation server passes the number to OCS as: 6095

OCS server passes the number to Exchange UM AA as: 6095

Dial by extension is selected and the extension dialed is: 291

Number is translated to: +5492 (user’s DID)

Call fails with: ms-diagnostics: 1003;reason="User does not exist";source="SomeServer-OCS01.inside.domain.com";TargetUri="+5492@domain.com"

The following screenshot of the snooper logs show the inbound call:

image

Important strings found in the logs:

1. FROM: mailto:+2892596319@domain.com;user=phone

2. TO: mailto:phone-context=Toronto.inside.domain.com@domain.com;user=phone

3. ms-diagnostics: 1003;reason="User does not exist";source="SomeServer-OCS01.inside.domain.com";TargetUri=+5492@domain.com

Carefully reviewing the logs show that the call flow ends up as described in the following:

1. AA is represented as 416-xxx-6095 externally.

2. Cisco 2801 Gateway receives the PSTN number as 6095 and passes it to the mediation server as 6095. The logs show the following entries:

INVITE sip:6095@10.10.10.2:5060 SIP/2.0

FROM: <sip:+289XXX6319@10.10.10.1>;tag=5A74AC0-1F39

TO: <sip:6095@10.10.10.2>

**Where 10.10.10.2 is the mediation server and 10.10.10.1 is the Cisco 2801 gateway.

image

3. Mediation server passes the number to OCS as 6095. The log shows the following entries:

Outgoing SipMessage c=[<SipTlsConnection_19408CD>], 192.168.1.116:50867->192.168.1.115:5061

FROM: ""<sip:+289xxx6319@domain.com;user=phone>;epid=F58B7DF87F;tag=fc93a58819

TO: <sip:6095;phone-context=Toronto.inside.domain.com@domain.com;user=phone>

image

4. OCS signals Exchange UM and the mediation server passes the number to Exchange UM AA as 6095. The log shows the following entries:

<<<<<<<<<<<<Incoming SipMessage c=[<SipTlsConnection_19408CD>], 192.168.1.116:50867<-192.168.1.115:5061

CONTACT: <sip:SomeServer-UM01.inside.domain.com:5066;transport=Tls>;automata

FROM: ""<sip:+289xxx6319@domain.com;user=phone>;epid=F58B7DF87F;tag=fc93a58819

TO: <sip:6095;phone-context=Toronto.inside.domain.com@domain.com;user=phone>

image

5. Dial by extension is selected and the extension dialed is 291. The log shows the following entries:

REFER-TO: <mailto:phone-context=Toronto.inside.domain.com@domain.com;user=phone>

FROM: 6095;phone-context

FROM: sip+2892596319…

image

6. Number is translated to +5492 (user’s DID). The log shows the following entries:

ms-diagnostics: 14011;reason="Called Number translated";source="SomeServer-OCS01.inside.domain.com";RuleName="291 to +5492";RuleDN="CN={3191FB78-32F6-4328-9538-AB608F295191},CN=Location Normalization Rules,CN=RTC Service,CN=Services,CN=Configuration,DC=inside,DC=domain,DC=com";CalledNumber="291";TranslatedNumber="+5492";appName="TranslationService"

------------EndOfIncoming SipMessage

image

7. The call gets sent from Exchange AA to OCS Front-End, then from OCS Front-End to Mediation, then back to OCS Front-End. The call finally fails with:

ms-diagnostics: 1003;reason="User does not exist";source="Domain-OCS01.inside.domain.com";TargetUri=+5492@domain.com

image

Resolution

The resolution for this problem was to have the gateway send the 6095 as +6095 thus rendering the sip address as:

TO: mailto:phone-context=Toronto.inside.domain.com@domain.com;user=phone

The log shows the following entries during the successful transfer:

INVITE mailto:+5492@SomeServer-MED01.inside.domain.com:5061;user=phone;maddr=SomeServer-MED01.inside.domain.com SIP/2.0

FROM: ""<sip:+2892596319@domain.com;user=phone>;epid=F58B7DF87F;tag=3677ff378a

TO: <sip:291;phone-context=Toronto.inside.domain.com@domain.com;user=phone>

image

Reviewing the snooper trace logs, the TO field is now populated with sip:+6095@10.10.10.2 with the +6095.

image

Note: Please let me know if some of the screenshots don’t appear to match with the description as I may have made some mistakes copying and pasting the images when I had to blank out the domain names. Thanks.

------------------------------------------------------------------------

I happened to talk about this problem I encountered with our Cisco UC practice lead awhile ago and he asked me to present this to our consultants so I ended up creating a PowerPoint presentation:

image

image

image

image

image

image

image

image

image

image

image

image

image

image

image

image

image

image

image

image

image

image

image

image

image

I will try to find some time to write up a post about a similar problem we had with anonymous calls.

No comments: