Yes,I've gone through it, i

Yannick Vranckx · ‎02-23-2015

Dear all,

We are having issues at one of our customer sites to dial out of the office.

The reponse we are getting from the provider via sip is 403 forbidden

Scenario: Call Manager (8.6) -- CUBE -- ISTP

Trace: Outbound call from CUCM to local number outside

As i see it:

First invite is from Call Manager to CUBE, the CUBE relays this invite towards the provider and we get a forbidden in return.

The provider tells us to change the headers to their trunk name: c-se-19149.btrunk.se, i can see with the invite to provider that both From & To headers are OK

Can someone help debugging this, i can provider all the logs & config if needed

sevas-wan-rt01#
sevas-wan-rt01#
*Feb 23 11:46:14: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:+46201908070@10.90.49.10:5060 SIP/2.0
Via: SIP/2.0/TCP 10.3.26.11:5060;branch=z9hG4bK17afa21054fdc
From: <sip:23088389@10.3.26.11>;tag=467416~5eaf8f8c-6191-4e99-9578-b6d8606e956f-40844183
To: <sip:+46201908070@10.90.49.10>
Date: Mon, 23 Feb 2015 10:46:19 GMT
Call-ID: 31bed500-4eb104fb-4d8a-b1a030a@10.3.26.11
Supported: 100rel,timer,resource-priority,replaces
Min-SE: 1800
User-Agent: Cisco-CUCM8.6
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.3.26.11:5060>;method="NOTIFY;Event=telephone-event;Duration=500"
Cisco-Guid: 0834589952-0000065536-0000015400-0186254090
Session-Expires: 1800
P-Asserted-Identity: <sip:23088389@10.3.26.11>
Remote-Party-ID: <sip:23088389@10.3.26.11>;party=calling;screen=yes;privacy=off
Contact: <sip:23088389@10.3.26.11:5060;transport=tcp>
Max-Forwards: 70
Content-Type: application/sdp
Content-Length: 386

v=0
o=CiscoSystemsCCM-SIP 467416 1 IN IP4 10.3.26.11
s=SIP Call
c=IN IP4 10.110.251.170
b=TIAS:64000
b=AS:64
t=0 0
m=audio 24582 RTP/AVP 0 8 116 18 101
a=rtpmap:0 PCMU/8000
a=ptime:20
a=rtpmap:8 PCMA/8000
a=ptime:20
a=rtpmap:116 iLBC/8000
a=ptime:20
a=maxptime:60
a=fmtp:116 mode=20
a=rtpmap:18 G729/8000
a=ptime:20
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

*Feb 23 11:46:14: //205713/31BED5000000/SIP/Msg/ccsipDisplayMsg:
Sent:
INVITE sip:+46201908070@c-se-19149.btrunk.se:5060 SIP/2.0
Via: SIP/2.0/UDP 10.90.1.2:5060;branch=z9hG4bK5395BDB
From: <sip:23088389@c-se-19149.btrunk.se>;tag=4D258598-2356
To: <sip:+46201908070@c-se-19149.btrunk.se>
Date: Mon, 23 Feb 2015 10:46:14 GMT
Call-ID: 596359A-BA8011E4-9621DA8E-6E23C3C9@c-se-19149.btrunk.se
Supported: 100rel,timer,resource-priority,replaces
Min-SE: 1800
Cisco-Guid: 0834589952-0000065536-0000015400-0186254090
User-Agent: Cisco-SIPGateway/IOS-15.3.3.M3
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1424688374
Contact: <sip:23088389@10.90.1.2:5060>
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 69
Session-Expires: 1800
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 246

v=0
o=CiscoSystemsSIP-GW-UserAgent 474 116 IN IP4 10.90.1.2
s=SIP Call
c=IN IP4 10.110.251.170
t=0 0
m=audio 24582 RTP/AVP 8 101
c=IN IP4 10.110.251.170
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20

*Feb 23 11:46:14: //205713/31BED5000000/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.90.1.2:5060;branch=z9hG4bK5395BDB
From: <sip:23088389@c-se-19149.btrunk.se>;tag=4D258598-2356
To: <sip:+46201908070@c-se-19149.btrunk.se>
Call-ID: 596359A-BA8011E4-9621DA8E-6E23C3C9@c-se-19149.btrunk.se
CSeq: 101 INVITE
Timestamp: 1424688374

*Feb 23 11:46:14: //205713/31BED5000000/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 403 Forbidden
Via: SIP/2.0/UDP 10.90.1.2:5060;branch=z9hG4bK5395BDB
From: <sip:23088389@c-se-19149.btrunk.se>;tag=4D258598-2356
To: <sip:+46201908070@c-se-19149.btrunk.se>;tag=SD7olkc99-1773143977-1424688379800
Call-ID: 596359A-BA8011E4-9621DA8E-6E23C3C9@c-se-19149.btrunk.se
CSeq: 101 INVITE
Timestamp: 1424688374
Content-Length: 0
P-Charging-Vector: icid-value=02855c0903aa823110b8c27452f7dade
P-Charging-Function-Addresses: ccf="aaa://charging.node:3868;transport=tcp"

*Feb 23 11:46:14: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
ACK sip:+46201908070@c-se-19149.btrunk.se:5060 SIP/2.0
Via: SIP/2.0/UDP 10.90.1.2:5060;branch=z9hG4bK5395BDB
From: <sip:23088389@c-se-19149.btrunk.se>;tag=4D258598-2356
To: <sip:+46201908070@c-se-19149.btrunk.se>;tag=SD7olkc99-1773143977-1424688379800
Date: Mon, 23 Feb 2015 10:46:14 GMT
Call-ID: 596359A-BA8011E4-9621DA8E-6E23C3C9@c-se-19149.btrunk.se
Max-Forwards: 70
CSeq: 101 ACK
Allow-Events: telephone-event
Content-Length: 0

Yannick Vranckx · ‎02-23-2015

*Update:

It seems that a local call from the site is working perfect, the above trace was with a Cisco IP Communicator over a VPN.

Do you think the ISTP could be not allowing a specific subnet for media to not pass them?

I've attached both traces for reference

the 403 is from a CIPC from the VPN Subnet

The working trace is a local phone onsite

Amit Sharawat · ‎02-23-2015

Hi Yannick,

I looked at both the traces, i do not find anything different apart from "From" field in the INVITE sent to ITSP.

Here is working one.

From: "SEVAS 23088380 Reception" <sip:+46850441880@c-se-19149.btrunk.se>;tag=4D714C34-25D

Here is non-working one.

From: <sip:23088389@c-se-19149.btrunk.se>;tag=4D258598-2356

Could you please configure the working extension and Name on your CIPC and test the call.

~Amit

Yannick Vranckx · ‎02-23-2015

Hello,

Ok no problem i'll configure it so it looks more clearly.

I have a feeling that the provider doesn't accept all the subnets that are streaming media, has anyone seen something like this before. Where the provider limits the subnets that are allowed to initiate calls. But would this then not be signalling traffic?

Amit Sharawat · ‎02-23-2015

Hi Yannick,

SIP provider cannot reject call based on the RTP streaming media address. This is a call set-up process, and during this if we are not able to establish the call, then it definitely due to some unlikeliness in the call step-up messages only not the media addresses.

Please check with the service provider what they don't like in the non-working call.

~Amit

Yannick Vranckx · ‎02-24-2015

Hello Amit,

I think i have found the issue, in the documentation they state that they accept only e.164 format numbers also on the from headers.

In the call that isn't working, this is an internal extension, this is wrong and that's why to me it isn't working.

I have a quick question about this, i know i can change this via the external phone number mask. But say someone forgets to fill this in, can't we do this one upper level via a transformation pattern.

I have never worked with this before? Or can we make a rule on the CUBE

Brandon Pierce · ‎02-24-2015

Translation patterns on CUCM or voice translation rules on the CUBE. I would personally do it on the CUBE if I was going to set this up. You have to make sure you are applying the rules to the dial peers though or it won't work.

Yannick Vranckx · ‎02-24-2015

Do you have a sort of example for this?

These are SIP profiles no?

Brandon Pierce · ‎02-24-2015

http://www.cisco.com/c/en/us/support/docs/voice/call-routing-dial-plans/64020-number-voice-translation-profiles.html

Type of phone is irrelevant. I would personally do everything at the CUBE but that is just preference. Translation patterns or even prefixing on the route patterns on CUCM would also accomplish this. Route pattern prefixing would be preferred so it is only applied outbound.

Amit Sharawat · ‎02-25-2015

Yannick,

Did you go through the following document completely and thoroughly:

http://www.cisco.com/c/en/us/support/docs/voice/call-routing-dial-plans/64020-number-voice-translation-profiles.html

~Amit

Yannick Vranckx · ‎02-25-2015

Yes,

I've gone through it, i have an idea on how to translate an internal extension to a e.164 number before it leaves the CUBE.

Someone told me that there was an option within CUCM called Transformation Patterns, does anyone use these. They say it's simpler than making translation rules on the CUBE.

Amit Sharawat · ‎02-24-2015

Yannick,

you can use translation profiles on the CUBE, apply it on the outbound dial-peer to change the numbers( calling and called). Use the following document:

http://www.cisco.com/c/en/us/support/docs/voice/call-routing-dial-plans/64020-number-voice-translation-profiles.html

~Amit

George Thomas · ‎02-23-2015

It would be great if you could set the external phone number mask on CIPC to something that is in your DID range and try again.

Please rate useful posts.

Problems dialling out SIP: 403 Forbidden