cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
834
Views
5
Helpful
20
Replies

SIP Cancel for softphones but not deskphones

the-lebowski
Level 4
Level 4

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>

20 Replies 20

Hey Chris,

Agreed and I have had similar issues with some of the providers I have worked with around Europe .However this can easily be taken care of by using voice translation rules on the gateway to localize the calling number. This is what I have done in similar situation. I personally find this better than having to configure masks on phones.

Thus is just how I have approached my deployments.

Please rate all useful posts

This SIP provider is in the Netherlands so hence the +.  Ayodeji when I don't have anything in the external mask it doesn't work.  I have to send something which means what?  I have a route list doing it for me?

dpatten78,

Here is how things work.

When you make a call from the phone through the gateway, the route list/route group settings ( either use external mask or don't use it) will determine the CLI that is displayed for outbound calls.By default the route lists/route group details is set to use external number mask.

Since your DN are configured as full E164 numbers, if you do not configure anything on your phone number mask, then the CLI sent for all calls will have the full DN as it is. i.e +31XXXXXX ( this will be the default phone number mask and this is what you will see displayed on the phone)

What I am suggesting is in your case, since you dont want to send the E164 number with the + to your provider you can do this without configuring phone number mask on each phone.

On your voice gateway just configure voice translation rules that strips the + before the call is sent to your ITSP

eg

voice translation-rule 10
rule 1 /^\+\(.*\)/ /\1/ 

voice translation-profile INT-PSTN-OUT
translate calling 10

then apply it to your outbound dial-peer to the ITSP

dial-peer voice xxx voip
translation-profile outgoing INT-PSTN-OUT

As you can see, this configuration saves you the headache of having to configure phone number mask for every phone and in a case where someone forgets to configure it like it happened for this issue, then you wont have any issues

Hope it is clear

Please rate all useful posts

I think either you have it backwards or I am confused.  

If I don't have anything in the external mask it sends the DN as '31XXXXXX' without the + and the international call fails.  If I add an external mask as +31XXXXXX the call works.  That would lead me to believe that I am sending the DN without the + when no mask is specified.  Meaning I am not sending full e164 to the provider because if I was I would not have run into this issue for users without an external mask. 

Does that make sense?

 

Ah I see. Then you have confused us a little. Here is what you said. From this I assumed calls with the + were failing

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.

Please rate all useful posts

Yeah that is right.  My first example no + which fails, second has + and it works.  I think my wording confused you.  

:D