Transferring calls from Exchange UM AA or OCS to PBX - Incoming Caller ID Matters

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: http://terenceluk.blogspot.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.