This problem is similar to the problem in my previous blog post: Transferring calls from Exchange UM AA or OCS to PBX – Gateway Passed # Matters found here: https://blog.terenceluk.com/2010/08/transferring-calls-from-exchange-um-aa.html
Problem – External user calls in via PSTN with a blocked number
Call Flow
External PSTN call comes in with the caller ID blocked. The blocked caller ID is passed to the gateway as blank.
Cisco 2801 Gateway receives the PSTN call with the caller ID blocked and pass it to the mediation server with a blank caller ID.
Mediation server passes the number to OCS as: mailto:anonymous@domain.com
OCS server passes the number to Exchange UM AA as: mailto:anonymous@domain.com
Dial by extension is selected and the extension dialed is: 291
Number is translated to: +5492 (user’s DID)
Call fails with: ms-diagnostics: 1022;reason=”Cannot process routing destination”;source=”SomeServer-OCS01.inside.domain.com”;Destination=”mailto:phone-context=Toronto.inside.domain.com@192.168.1.115;user=phone“
————EndOfIncoming SipMessage
The following screenshot of the snooper logs show the inbound call:
Important strings found in the logs:
1. INVITE sip:+800@10.10.10.2:5060 SIP/2.0
2. FROM: “anonymous” <sip:anonymous@10.10.10.1>;tag=104C61A8-828
3. TO: <sip:+800@10.10.10.2>
4. ms-diagnostics: 1022;reason=”Cannot process routing destination”;source=”SomeServer-OCS01.inside.domain.com”;Destination=”mailto:phone-context=Toronto.inside.domain.com@192.168.1.115;user=phone”
5. ————EndOfIncoming SipMessage
As shown in the above strings, while the TO field has an address with a +xxx number, the FROM field is now set to anonymous.
Carefully reviewing the logs show that the call flow ends up as described in the following:
1. AA is represented as +800 with the gateway translating the external number of 6095 to +800 to get pass the other problem with the TO field as number without a +.
2. Cisco 2801 Gateway receives the PSTN number as 6095 and passes it to the mediation server as +800. However, the FROM field now has an address of sip:anonymous@10.10.10.1. The logs show the following entries:
INVITE sip:+800@10.10.10.2:5060 SIP/2.0
FROM: “anonymous” <sip:anonymous@10.10.10.1>;tag=104C61A8-828
TO: <sip:+800@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:
TL_INFO(TF_PROTOCOL) [2]085C.0E44::01/15/2010-20:57:03.444.00010246 (S4,SipMessage.DataLoggingHelper:sipmessage.cs(531))
>>>>>>>>>>>>Outgoing SipMessage c=[<SipTlsConnection_12212D0>], 192.168.1.116:50184->192.168.1.115:5061
INVITE mailto:+800@domain.com;user=phone SIP/2.0
FROM: “anonymous”<sip:anonymous@domain.com;user=phone>;epid=F9C5342898;tag=70b9ddd639
TO: <sip:+800@domain.com;user=phone>
4. OCS signals Exchange UM and the mediation server passes the number to Exchange UM AA as +800 with a FROM address as sip:anonymous@10.10.10.2. The log shows the following entries:
TL_INFO(TF_PROTOCOL) [5]085C.0E38::01/15/2010-20:57:04.179.00010430 (S4,SipMessage.DataLoggingHelper:sipmessage.cs(581))
<<<<<<<<<<<<Incoming SipMessage c=[<SipTlsConnection_12212D0>], 192.168.1.116:50184<-192.168.1.115:5061
SIP/2.0 200 OK
FROM: “anonymous”<sip:anonymous@domain.com;user=phone>;tag=70b9ddd639;epid=F9C5342898
TO: <sip:+800@domain.com;user=phone>;epid=7F0379AFD1;tag=aefea27dc
CSEQ: 134 INVITE
CALL-ID: 87ec3f0c-0e4c-4d9e-ba6e-81fa3c946e34
VIA: SIP/2.0/TLS 192.168.1.116:50184;branch=z9hG4bKffeb327d;ms-received-port=50184;ms-received-cid=34B00
RECORD-ROUTE: <sip:SomeServer-OCS01.inside.domain.com:5061;transport=tls;opaque=state:T;lr>
CONTACT: <sip:SomeServer-UM01.inside.domain.com:5066;transport=Tls>;automata
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@192.168.1.115;user=phone>
6. The dialed extension 419 doesn’t even make it to the normalization rule that is supposed to translate it to a 4-digit DID and fails with a SIP/2.0 504 Server time-out. The log shows the following entries:
SIP/2.0 504 Server time-out
FROM: “anonymous”<sip:anonymous@domain.com;user=phone>;epid=F9C5342898;tag=97c5974872
TO: <sip:419;phone-context=Toronto.inside.domain.com@192.168.1.115;user=phone>;tag=81D2DBAF0A35A006E2070899EC12AB7C
CSEQ: 135 INVITE
CALL-ID: baf77a8d-3a58-42b5-8abf-a13b7523b836
VIA: SIP/2.0/TLS 192.168.1.116:50185;branch=z9hG4bK1499847;ms-received-port=50185;ms-received-cid=34E00
CONTENT-LENGTH: 0
ms-diagnostics: 1022;reason=”Cannot process routing destination”;source=”SomeServer-OCS01.inside.domain.com”;Destination=”sip:419;phone-context=Toronto.inside.domain.com@192.168.1.115;user=phone”
————EndOfIncoming SipMessage
**Note that the error here shows: Destination=”mailto:phone-context=Toronto.inside.domain.com@192.168.1.115;user=phone“
If the call is successfully routed, the @192.168.1.115;user=phone should be replaced with dialplan.domain.com@ForestFQDN.
Resolution
The resolution for this problem was to have the gateway send rewrite all calls coming in from the PSTN with a blocked caller ID to a bogus number. In our case, we rewrote it to +4165555555 thus rendering the FROM sip address as:
FROM: “anonymous” <sip:+4165555555@10.10.10.1>;tag=24FE0010-8CA
The initial connection for the call would look like this:
INVITE sip:+800@10.10.10.2:5060 SIP/2.0
FROM: “anonymous” <sip:+4165555555@10.10.10.1>;tag=24FE0010-8CA
TO: <sip:+800@10.10.10.2>
The log shows the following entries during the successful transfer:
TL_INFO(TF_PROTOCOL) [5]085C.0E38::01/19/2010-21:23:14.411.00011679 (S4,SipMessage.DataLoggingHelper:sipmessage.cs(581))
<<<<<<<<<<<<Incoming SipMessage c=[<SipTcpConnection_3FF2357>], 10.10.10.2:5060<-10.10.10.1:58223
INVITE sip:+800@10.10.10.2:5060 SIP/2.0
FROM: “anonymous” <sip:+4165555555@10.10.10.1>;tag=24FE54A4-2029
TO: <sip:+800@10.10.10.2>
CSEQ: 101 INVITE
CALL-ID: F1944E13-47711DF-9C05FA5F-32802FEB@10.10.10.1
MAX-FORWARDS: 70
VIA: SIP/2.0/TCP 10.10.10.1:5060;branch=z9hG4bK3191DF
ALLOW-EVENTS: telephone-event
CONTACT: <sip:anonymous@10.10.10.1:5060;transport=tcp>
Reviewing the snooper trace logs, the FROM field is now rewritten with sip:+4165555555.
Here is a side-by-side snooper logs with a failed and a successful call with a blocked ID and a valid caller ID:
Note that this problem isn’t specific to AA. If a user dials an OCS user’s direct line bypassing the AA with a blocked ID, when the OCS user tries to transfer the call over to the BCM, the transfer will fail. There aren’t any issues if the OCS user transfers to another OCS user though.
I’m anxious to test this out when CS 14 RTMs.
One Response
It is good to know that Pacifica tribune celebrates the first Pacifica baby with their family. The Pacifica tribune is doing a great job by solving the issues of the family but transcription youtube video provides well assistance. And I think it is a good way to call the hospital to know about the new members of the Pacifica and get the information.