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:
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.
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>
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>
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…
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
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
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>
Reviewing the snooper trace logs, the TO field is now populated with sip:+6095@10.10.10.2 with the +6095.
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:
I will try to find some time to write up a post about a similar problem we had with anonymous calls.
