* Hint:Please note that some of the screenshots and outputs in this post have been recreated in a lab

This was another interesting case that was raised with me by one of our clients. This client has a PBX (Aastra Communications server) integrated with Cisco Call Manager via a Sip Trunk.

The client configured Single-number-reach or mobile connect. The way the client configured it was such that an internal CUCM number of 5737 had 07578334371 configured as one of  its remote destinations. The second  remote destination was configured as 875737. This extension is the user’s other extension that is  hosted on the SIP-PBX.

So in essence each user had three phones, a  Cisco phone, a Sip-based mobile PBX phone, and a normal mobile phone.   As you might already know, the way presence works on  mobile-connect  is that when a user calls into the company with his Sip-based mobile PBX phone or normal mobile phone, their internal line (cisco)   presence status would be updated to ‘off hook or ‘On a call’. So what I mean is that  if a user calls from his Sip PBX phone to another internal user’s internal number, everyone would be able to see the external caller’s status as on ‘ on a call’ or ‘off hook’ .

However, this was not working for my client. The presence status was triggering fine when calling into the network from mobile phones but it was not triggering from the Sip-based mobile PBX phones.

In order to test this, I told the client to call an internal   Cisco IP-phone (extension 3250) using his PBX phone (extension 785737) which is mapped to his internal number of 5737 as a remote destination or mobile connect number.

I collected the trace of the call and this is what I found:

 

:::::::::::::::

:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

INVITE sip:3250@10.xx.96.x8 SIP/2.0

Via: SIP/2.0/UDP 10.xx.6.x02:5060;rport;branch=z9hG4bK2013Apr1753552443250

To: <sip:3250@10.xx.96.x8>

From: “Mark o’neil” 7@10.xx.96.x8>;tag=AI51E9A11E80AFDF6C

Call-ID: AIBD1912FE6B7F686C@10.xx.6.x02

CSeq: 1 INVITE

Max-Forwards: 70

Contact: sip:5737@10.xx.6.x02>

Accept: application/sdp

Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,UPDATE

Allow-Events: dialog,message-summary,refer

Privacy: none

Supported: timer

User-Agent: Aastra 400

Session-Expires: 1800

Min-SE: 300

Content-Type: application/sdp

Content-Length: 316

v=0

o=aastra400 442514688 442514688 IN IP4 10.xx.6.x02

s=call

c=IN IP4 10.xx.7.x01

t=0 0

m=audio 16380 RTP/AVP 0 8 18 4 101

a=rtpmap:0 PCMU/8000

a=rtpmap:8 PCMA/8000

a=rtpmap:18 G729/8000

04/17/2013 15:53:55.370 CCM|//SIP/SIPCdpc(0,0,0)/ci=0/ccbId=0/scbId=0/globalize: Performing stripAndPrependDigits — Prefix data = , Strip Data = 0|

04/17/2013 15:53:55.370 CCM|//SIP/SIPCdpc(0,0,0)/ci=0/ccbId=0/scbId=0/globalize: CallingNumber after stripAndPrependDigits 5737|

04/17/2013 15:53:55.370 CCM|SPROC getCtrlPid – callingNum=5737, inputCtrlPid=(5,100,175,1)|

04/17/2013 15:53:55.370 CCM|DbMobility: getMatchedRemDest starts: cnumber = 5737|

04/17/2013 15:53:55.370 CCM|DbMobility: getMatchedRemDest: full match case|

04/17/2013 15:53:55.370 CCM|DbMobility: can’t find remdest 5737 in map|

:::::::::::::::

:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

Did you notice what was wrong with that call? Did you noticed that the  in-coming caller-ID was 5737 instead of 875737?   Did you also notice that the wrong caller-ID  which   later caused a problem? If you look at this part of the trace copied below;

‘: getMatchedRemDest starts: cnumber = 5737’

‘can’t find remdest 5737 in map’

You will noticed that after the call came in and the digit manipulation that is configured on the sip trunk had been completed, the call manager was actually trying to check whether the in-coming caller-ID was actually configured as a remote destination for any user on the system. But in the end, the call manager  decided that the number was not configured as a remote destination for any user so the presence status of any internal number was never triggered.  For the internal line presence status to change, the incoming caller-ID needs to match one of the numbers already configured as a remote destination of an internal number.

I got the PBX engineer to make sure that the PBX was sending the full number and after that I collected another trace for the call. This is what I found:

:::::::::::::::

:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

INVITE sip:3250@10.xx.96.x8 SIP/2.0

Via: SIP/2.0/UDP 10.xx.6.x02:5060;rport;branch=z9hG4bK2013Apr2647493143250

To: <sip:3250@10.xx.96.x8>

From: “Mark o’neil” <sip:875737@10.xx.96.x8>;tag=AIB932DDBF63C8339D

Call-ID: AIC245C802CF7BDC00@10.76.6.102

CSeq: 1 INVITE

Max-Forwards: 70

Contact: <sip:875737@10.xx.6.x02>

Accept: application/sdp

Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,UPDATE

Allow-Events: dialog,message-summary,refer

Privacy: none

Supported: timer

User-Agent: Aastra 400

Session-Expires: 1800

Min-SE: 300

Content-Type: application/sdp

Content-Length: 318

v=0

o=aastra400 1213022154 1213022154 IN IP4 10.xx.6.x02

s=call

c=IN IP4 10.xx.6.x03

t=0 0

m=audio 16386 RTP/AVP 0 8 18 4 101

a=rtpmap:0 PCMU/8000

a=rtpmap:8 PCMA/8000

a=rtpmap:18 G729/8000

a=fmtp:18 annexb=no

a=rtpmap:4 G723/8000

09:47:50.116 CCM|//SIP/SIPCdpc(0,0,0)/ci=0/ccbId=0/scbId=0/globalize: Performing stripAndPrependDigits — Prefix data = , Strip Data =

04/26/2013 09:47:50.116 CCM|//SIP/SIPCdpc(0,0,0)/ci=0/ccbId=0/scbId=0/globalize: CallingNumber after stripAndPrependDigits 87573704/26/2013 09:47:50.116 CCM|SPROC  getCtrlPid – callingNum=875737,

04/26/2013 09:47:50.116 CCM|DbMobility: getMatchedRemDest starts: cnumber = 875737

04/26/2013 09:47:50.116 CCM|DbMobility:initRemDest: device pkid [97c71d1f-24f7-1f82-107d-

04/26/2013 09:47:50.116 CCM|DbMobility: found DN association for remdest [875737]| 04/26/2013 09:47:50.116 CCM|DbMobility: found remdest cnumber = 875737, devicepkid =

-1f82-107d-4c77053bc79f found in RemoteDeviceInfo hashmap – PID(s)=2 Name=875737:RDP-marko-5737 is Active=1 Protocol=Remote Destination

:::::::::::::::

:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

Notice that the incoming caller-ID was sent in full and the result was that  a remote destination match was discovered by the call-manager  as be seen in the output copied below?

(‘-1f82-107d-4c77053bc79f found in RemoteDeviceInfo hashmap – PID(s)=2 Name=875737:RDP-marko-5737 is Active=1 Protocol=Remote Destination ’)

As soon as the match was made, the presence status of internal extension of 5737 was trigger and updated to ‘ off hook’ or ‘on a call’ and everyone in the company could now see extension 5737 as being on the phone even though the user  was using his remote destination phone of  875737.

. . . and that was how my client was instantly made happy and of course I was glad to have gotten to the bottom of it.

Cheers folks,

Hope it has been an interesting read