SIP Cancel for softphones but not deskphones

[the-lebowski]

Have a strange issue that just came up.  No changes made to CUCM whatsoever but end users in Europe reported that they cannot call internationally from their ip communicators but they can from their desk phones.  End users states they get the generic "call cannot be completed as dialed."

I have complete debugs from the cube...below is what I believe the problem is but I don't know why.  

INVITE sip:+33616246567@10.191.11.2:5061 SIP/2.0
Via: SIP/2.0/UDP 10.159.11.21:5060;branch=z9hG4bK4f81f932884faa
From: "local user 01" <sip:31203999150@10.159.11.21>;tag=5396948~356500b6-1e0f-4141-88c3-d1dd79d80f06-66277440
To: <sip:+33616246567@10.191.11.2>

INVITE sip:+33616246567@10.131.11.2:5061 SIP/2.0
Via: SIP/2.0/UDP 10.159.11.21:5060;branch=z9hG4bK4f80b74741a7b1
From: "local user 02" <sip:+31203999102@10.159.11.21>;tag=5396613~356500b6-1e0f-4141-88c3-d1dd79d80f06-66277426
To: <sip:+33616246567@10.191.11.2>

[Chris Deren]

Can you post same debug from the working desk phone?

[the-lebowski]

Yeah, just may take me a little while to get someone local to make the call.  

[the-lebowski]

Two fresh debugs attached.both from the same user using his CIPC and his desk phone.    Clear as day 'CANCEL' in the CIPC log but normal call flow in the desk phone log.  

[Chris Deren]

Your desk phone debug is incomplete as it does not start from the beginning missing the initial INVITE which is the most important message to compare.

[the-lebowski]

One more time...

005622: Jan 11 16:54:06.223 CET: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received: 
INVITE sip:+33616246567@10.191.11.2:5061 SIP/2.0
Via: SIP/2.0/UDP 10.159.11.21:5060;branch=z9hG4bK4f7ef941ae0b90
From: "local user" <sip:+31203999102@10.159.11.21>;tag=5396151~356500b6-1e0f-4141-88c3-d1dd79d80f06-66277412
To: <sip:+33616246567@10.191.11.2>
Date: Wed, 11 Jan 2017 15:54:06 GMT
Call-ID: 2d236880-8761551e-4e6140-150b810a@10.159.11.21
Supported: 100rel,timer,resource-priority,replaces
Min-SE: 1800
User-Agent: Cisco-CUCM10.5
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
CSeq: 101 INVITE
Expires: 180
Allow-Events: presence, kpml
Supported: X-cisco-srtp-fallback,X-cisco-original-called
Call-Info: <sip:10.159.11.21:5060>;method="NOTIFY;Event=telephone-event;Duration=500"
Call-Info: <urn:x-cisco-remotecc:callinfo>;x-cisco-video-traffic-class=VIDEO_UNSPECIFIED
Cisco-Guid: 0757295232-0000065536-0000056587-0353075466
P-Charging-Vector: icid-value="2D236880000100000000DD0A150B810A";icid-generated-at=beat-cucm-02;orig-ioi="IMS Inter Operator Identification"
Session-Expires: 1800
P-Asserted-Identity: "local user" <sip:+31203999102@10.159.11.21>
Remote-Party-ID: "local user" <sip:+31203999102@10.159.11.21>;party=calling;screen=yes;privacy=off
Contact: <sip:+31203999102@10.159.11.21:5060>
Max-Forwards: 70
Content-Type: application/sdp
Content-Length: 364

[Chris Deren]

Is there a reason the SIP out to ITSP is going out with different interface of your CUBE?

CIPC:

c=IN IP4 188.200.170.84

desktop:

c=IN IP4 188.200.170.104

How are your SIP bindings configured? Can you post your config?

[the-lebowski]

delete this.

[the-lebowski]

Nah, its the same I just fat fingered the IP when I cleaned it up.

[Chris Deren]

Looking at the debug closer it appears the CANCEL is coming from CUCM to CUBE. @15:59:56 CUBE sends 183 to CUCM, but ~5 seconds later CUCM sends CANCEL back to CUBE.

We would need to look at CUCM SIP traces for more clues. 

Are you sure the last desk phone call you provided trace for was successful as I don't see proper signaling exchange and Cancel in that one as well?

[the-lebowski]

At this point I don't know, I had so many debugs that I lost track of which is which.

However I think its fixed, just waiting on remote users to confirm.  You can see here FROM numbers below, one with the + and one without, first one would fail and the second wouldn't.

INVITE sip:+33616246567@10.191.11.2:5061 SIP/2.0
Via: SIP/2.0/UDP 10.159.11.21:5060;branch=z9hG4bK4f81f932884faa
From: "local user 01" <sip:31203999150@10.159.11.21>;tag=5396948~356500b6-1e0f-4141-88c3-d1dd79d80f06-66277440
To: <sip:+33616246567@10.191.11.2>

INVITE sip:+33616246567@10.131.11.2:5061 SIP/2.0
Via: SIP/2.0/UDP 10.159.11.21:5060;branch=z9hG4bK4f80b74741a7b1
From: "local user 02" <sip:+31203999102@10.159.11.21>;tag=5396613~356500b6-1e0f-4141-88c3-d1dd79d80f06-66277426
To: <sip:+33616246567@10.191.11.2>

Turns out some DN's had an 'External Phone Number Mask' some didn't.  The ones that had an external mask with '+' were able to call internationally, the ones that were blank or didn't were not able to.  You could see in the logs which one didn't and which one did by looking at the calling party number.   I went through and added the external mask to my soft phone and I was then able to place the call.  It seems to me the provider changed something to reject calls without the + or whatever we are sending when nothing is specified there. 

[Chris Deren · Accepted solution]

That was the first thing I compared between your traces and both had the same CLID being sent which eliminated that as a cause. However seeing that the traces were inconsistent this is definitely a potential for the issue as lots of carriers screen ANI digits and reject calls when they are invalid or don't belong on that trunk.

[the-lebowski]

Understood and thanks for your help.   I figured it had to be a provider issue as nothing had changed on our side to cause this. 

[Ayodeji Okanlawon]

First of all great job to you and Chris ( as always).

One suggestion I will give to you is this, there is no need to use external number mask on your phones since you are using e164 number format. All you need to do is ensure that you do not have use external number mask on your "Route List". Your phones already have the format you want to send out which is the full E164 number, if you dont change anything on your route list settings, then you dont need any additional configuration. This will save you time in having to add external mask for every device..

[Chris Deren]

Deji,

I have had SIP providers in US that do not like to see "+" and require we send only 10 digit CLID on couple of occasions, so unfortunately that varies here.