CUCME 9 - ITSP SIP INVITE messages from different SIP providers

tonypearce1 · ‎06-15-2012

I have a CUCME v9 setup in my home lab whilst I train for CCNP Voice. Recently I've started playing with SIP ITSP's and I currently have two separate SIP trunks configured on this device. One to CallCentric and one to an Australian company called Faktortel which I use for local calls back to my home in England, which is where the CUCME is located.

I have everything working fine but I noticed that incoming calls are never to my DID number which I have, from either ITSP. The "incoming called number" is always my SIP username. For logical reasons on my part, I use translation rules to change this back to my DID, which is then matched to a hunt pilot which in turn rings a bunch of phones in parallel.

To investigate this, I captured some SIP INVITE messages from my SIP ITSPs using debug ccsip message. I notice they are both SIPv2 but they look different.

Faktortel

002193: Jun 15 07:27:18.856 GMT: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:0953456646@192.168.192.253:5060 SIP/2.0
Via: SIP/2.0/UDP 202.43.66.5:5060;branch=z9hG4bK2fd94f27;rport
Max-Forwards: 70
From: "0401999081" <sip:NULL@202.43.66.5>;tag=as6dcbd05f
To: <sip:0953456646@192.168.192.253:5060>
Contact: <sip:NULL@202.43.66.5>
Call-ID: 37ac24b0701e0d536300a88e7e72344c@202.43.66.5
CSeq: 102 INVITE
User-Agent: Asterisk PBX 1.6.2.20
Remote-Party-ID: "0401999081" <sip:0401999081@202.43.66.5>;privacy=off;screen=no
Date: Fri, 15 Jun 2012 06:27:18 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 353

CallCentric

002204: Jun 15 07:29:53.143 GMT: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:17774552435320@192.168.192.253:5060 SIP/2.0
v: SIP/2.0/UDP 204.11.192.22:5080;branch=z9hG4bK-113932baa49d06fdbd144e638a6ade87
f: <sip:61401999081@66.193.176.35>;tag=3548730592-612072
t: <sip:18455845013@ss.callcentric.com>
i: 24383076-3548730592-612040@msw1.telengy.net
CSeq: 1 INVITE
Max-Forwards: 15
m: <sip:4f3be9aa1255edc4211fec09999d6232@204.11.192.22:5080;transport=udp>
Supported: timer
c: application/sdp
l: 348

As you can see, the INVITE on both of them is at my SIP username. This must be what the system uses for "incoming called number".

However the CallCentric capture shows that the TO part of the message is in fact TO my DID which is different to the other.

Why would the messages look different? Is it purely because of the type of PBX they are using?

I can have Cisco UBE write the TO part of the SIP message into the actual called number in case of more than one DID, although I don't think I can use a CME router as a CUBE also. (I'll try it!)

The Faktortel SIP invite message looks slightly odd or malformed, especially since the from looks like sip:NULL.

What are others findings with this? I think it's odd the invites look different also.

Mohammed al Baqari · ‎06-15-2012

As you know that SIP is open protocol and its normal to see different vendors having different implementations of the protocol keeping the overall structure of the protocol same.

I haven't worked with other vendors rather than Cisco, but I have seen many similar concerns raised like this in different forums. Therefore it shouldn't be and issue.

In CUCM/CME itself you can modify the INVITE message to contain a string rather than phone number.

If you are interested in changing this behaviour, you take it up with ITSP to do modifications.

If you are worried as well about security (looks as malformed as you said), you can start with enabling SIP Digest authentication as first step which can be done in CME.

"If you find the post helpful, please rate it"

tonypearce1 · ‎06-16-2012

I was thinking rather if I were to purchase multiple DID numbers, how the system would know how to route those based on the SIP messages.

Thanks for the info and I'm aware its an open protocol. Although my system must know what to do with the messages to be able to act on them. For example, I found it strange that one message says "From" and the other says "f". There must be a base standard to work from.