Solved: 403 Forbidden on Inbound Calls - Page 2

mumbles202 · ‎02-11-2021

Working on a new install of CUCM cube. ISR 4300 as the gateway. It's a pre-existing CUCM environment with a MGCP gateway is current PsTN access. Setup a trunk from CUBE to CUCM, CSS for the trunk includes the partition with the internal DNs, and DNA shows inbound calls should ring the extension. Outbound calls through the CUBE are working but inbound I seem to be getting a 403 from CUCM. I can upload the debug from the gateway but wondering if something I should be looking at on either the CUCM or VG side. I can post up the configuration from the VG as well.

mumbles202 · ‎02-26-2021

@Roger Kallberg Thanks for following up. I had to take a step away but should be getting back to the configuration of the gateway next week so will be able to provide an update.

mumbles202 · ‎03-04-2021

I was able to update the CUBE and make an inbound test call. I had dead air for about 15 seconds before I got a message that the call didn't go through. I pulled the debug from the cube and see the correct dial peer being selected and the invite being sent to the publisher then to the subscriber when no response received and then eventually a disconnect. The trunk showed as in service previously but i didn't get to check the status at the time of the call or pull the logs from that call. I hope to be able to do this tomorrow.

mumbles202 · ‎03-05-2021

I'm seeing the invite being sent from the CUBE but nothing in the CUCM call logs for the call. The CUCM and the CUBE share a common segment and I have this for the outgoing dial peer to the CUCM:

dial-peer voice 11 voip
description Outgoing calls to CUCM
session protocol sipv2
session server-group 1
destination e164-pattern-map 1
voice-class codec 1
voice-class sip options-keepalive profile 1
voice-class sip bind control source-interface GigabitEthernet0/0/1
voice-class sip bind media source-interface GigabitEthernet0/0/1
dtmf-relay rtp-nte sip-kpml
fax-relay sg3-to-g3
fax rate 14400
fax nsf 000000
fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none
no vad

Roger Kallberg · ‎03-05-2021

Are you saying that you don’t see the call in the SDL traces in CM, or do you mean that it’s not seen in the CDR logs in CM? If it’s the later I would recommend you to look at the incoming CSS on the trunk in CM for the gateway.

Also make sure that the IP that is presented to the CM by the gateway is the same as you have defined on the trunk and that the gateway trusts all of the IPs that CM CPE nodes can present to it. The second is to not get caught up by the security service in the gateway that blocks VoIP traffic from untrusted IPs. This is done either by having the IPs in the server group or by adding them to the trust list under voice service voip. My personal preference is to have the server group with three CMs that would serve the gateway and then list all CM CPE IPs in the trust list. The first is similar as the CM by default will not allow traffic that comes from a unknown IP. Having the IP on a trunk create the trust to allow traffic. There is also a service parameter that can be set to allow traffic from any IP, but that is not recommended as it sets the system in very insecure state.

mumbles202 · ‎03-06-2021

I didnt see the call in the SDL traces. I also tried viewing the call in RTMT as well but didn't see it there. I have the trace level set to detailed in CUCM for both nodes.

I have the dial peer that's bound for CUCM bound to the interface that is on the same subnet as CUCM and that's the ip defined in the trunk, but I'll triple check. I can also defined it under voip services if required. As for the trust list, both pub and sub are defined there as well as in the server group. I repost the config I pulled yesterday as well.

Roger Kallberg · ‎03-06-2021

Apart from the configuration can you please provide a screenshot of trunk configuration and the output of the debug ccsip message and debug voip ccapi inout.

mumbles202 · ‎03-08-2021

I'll try to get the screenshots of the trunk configuration from CUCM in the morning and post. Here is the current VG configuration as well as the output of the debug I captured. The incoming calling number was 1111111111 and the called number was 1112222234. I have a DN in CUCM in a partition that is included in the CSS of the trunk (I created a new CSS w/ just this partition as well to rule out a conflict).

I'll try to post the debug as the attachment is being blocked.

Roger Kallberg · ‎03-08-2021

What is the DN in CM, is it 2234 or 112222234? In the configuration I can’t find any information for how you route traffic to the ITSP, would you mind to share the routing table of the router? You also have logging to the monitor turned off, if you’d want to get the debug output to your terminal session I advise you to turn this on.

TONY SMITH · ‎03-09-2021

Have we ever seen the SIP debug for CUBE<>CUCM? From memory I'm pretty sure you get a 5xx error (Service Unavailable) if the source IP doesn't match the trunk configuration, and a 404 if there's a dial plan issue. Not sure I've ever seen a 403.

Roger Kallberg · ‎03-09-2021

Can't say that I've seen that very often or even ever either. This is the explanation for a 403 from Wikipedia.

Very early in this thread there was some debug information, but I think that this could have been for the ITSP to the Cube. As there have been quite a few alterations made it would be good to have new up to date information to get the current state.

mumbles202 · ‎03-09-2021

The DN in CM is 2234. I've tried it w/ the trunk configured w/ significant digits all and the configuration attached as well as with significant digits set to 4 but getting the same results.

The router is getting a dhcp address on Gi 0/0/0 which is where it is routing traffic destined for the ITSP.

I've been able to capture the debug information; just unable to post it here. If I try to insert it as inline code it's too long, and if I save it as a txt file and try to attach it I get an error that the format doesn't match what is inside. Here's the snippet from the debug that shows the invite to the CUCM. I'm seeing a disconnect code of 102. It's seems the code is disconnect the call after receiving no response from CUCM.

Sent: 
INVITE sip:2234@172.27.32.5 SIP/2.0
Via: SIP/2.0/UDP 172.27.32.8:5060;branch=z9hG4bK2008A26D6
Remote-Party-ID: "WIRELESS CALLER" <sip:1111111111@172.27.32.8>;party=calling;screen=no;privacy=off
From: "WIRELESS CALLER" <sip:1111111111@12.12.12.12>;tag=4DC3EFB3-6DD
To: <sip:2234@172.27.32.5>
Date: Wed, 03 Mar 2021 18:48:01 GMT
Call-ID: D099E335-7B8711EB-9063B395-3E69C694@172.27.32.8
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE:  1800
Cisco-Guid: 3499626173-2072449515-2422059925-1047119508
User-Agent: Cisco-SIPGateway/IOS-16.6.4
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1614797281
Contact: <sip:1111111111@172.27.32.8:5060>
Expires: 300
Allow-Events: kpml, telephone-event
Max-Forwards: 66
Session-ID: 187dde7b6a0353c3886571bd5a8f4582;remote=00000000000000000000000000000000
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 246

v=0
o=CiscoSystemsSIP-GW-UserAgent 4165 7099 IN IP4 172.27.32.8
s=SIP Call
c=IN IP4 172.27.32.8
t=0 0
m=audio 8110 RTP/AVP 0 101
c=IN IP4 172.27.32.8
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20

002815: Mar  3 12:48:02.049: //173222/D0980EBD905D/SIP/Msg/ccsipDisplayMsg:
Sent: 
INVITE sip:2234@172.27.32.5 SIP/2.0
Via: SIP/2.0/UDP 172.27.32.8:5060;branch=z9hG4bK2008A26D6
Remote-Party-ID: "WIRELESS CALLER" <sip:1111111111@172.27.32.8>;party=calling;screen=no;privacy=off
From: "WIRELESS CALLER" <sip:1111111111@12.12.12.12>;tag=4DC3EFB3-6DD
To: <sip:2234@172.27.32.5>
Date: Wed, 03 Mar 2021 18:48:02 GMT
Call-ID: D099E335-7B8711EB-9063B395-3E69C694@172.27.32.8
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE:  1800
Cisco-Guid: 3499626173-2072449515-2422059925-1047119508
User-Agent: Cisco-SIPGateway/IOS-16.6.4
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1614797282
Contact: <sip:1111111111@172.27.32.8:5060>
Expires: 300
Allow-Events: kpml, telephone-event
Max-Forwards: 66
Session-ID: 187dde7b6a0353c3886571bd5a8f4582;remote=00000000000000000000000000000000
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 246

v=0
o=CiscoSystemsSIP-GW-UserAgent 4165 7099 IN IP4 172.27.32.8
s=SIP Call
c=IN IP4 172.27.32.8
t=0 0
m=audio 8110 RTP/AVP 0 101
c=IN IP4 172.27.32.8
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20

002816: Mar  3 12:48:03.049: //173222/D0980EBD905D/SIP/Msg/ccsipDisplayMsg:
Sent: 
INVITE sip:2234@172.27.32.5 SIP/2.0
Via: SIP/2.0/UDP 172.27.32.8:5060;branch=z9hG4bK2008A26D6
Remote-Party-ID: "WIRELESS CALLER" <sip:1111111111@172.27.32.8>;party=calling;screen=no;privacy=off
From: "WIRELESS CALLER" <sip:1111111111@12.12.12.12>;tag=4DC3EFB3-6DD
To: <sip:2234@172.27.32.5>
Date: Wed, 03 Mar 2021 18:48:03 GMT
Call-ID: D099E335-7B8711EB-9063B395-3E69C694@172.27.32.8
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE:  1800
Cisco-Guid: 3499626173-2072449515-2422059925-1047119508
User-Agent: Cisco-SIPGateway/IOS-16.6.4
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1614797283
Contact: <sip:1111111111@172.27.32.8:5060>
Expires: 300
Allow-Events: kpml, telephone-event
Max-Forwards: 66
Session-ID: 187dde7b6a0353c3886571bd5a8f4582;remote=00000000000000000000000000000000
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 246

v=0
o=CiscoSystemsSIP-GW-UserAgent 4165 7099 IN IP4 172.27.32.8
s=SIP Call
c=IN IP4 172.27.32.8
t=0 0
m=audio 8110 RTP/AVP 0 101
c=IN IP4 172.27.32.8
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20

002817: Mar  3 12:48:05.049: //173222/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
   
002818: Mar  3 12:48:05.049: cc_api_get_xcode_stream : 4981
002819: Mar  3 12:48:05.049: //173222/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
   
002820: Mar  3 12:48:05.049: cc_api_get_xcode_stream : 4981
002821: Mar  3 12:48:05.050: //173222/D0980EBD905D/SIP/Msg/ccsipDisplayMsg:
Sent: 
INVITE sip:2234@172.27.32.6 SIP/2.0
Via: SIP/2.0/UDP 172.27.32.8:5060;branch=z9hG4bK2008B2011
Remote-Party-ID: "WIRELESS CALLER" <sip:1111111111@172.27.32.8>;party=calling;screen=no;privacy=off
From: "WIRELESS CALLER" <sip:1111111111@12.12.12.12>;tag=4DC3FD5F-1B31
To: <sip:2234@172.27.32.6>
Date: Wed, 03 Mar 2021 18:48:05 GMT
Call-ID: D099E335-7B8711EB-9063B395-3E69C694@172.27.32.8
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE:  1800
Cisco-Guid: 3499626173-2072449515-2422059925-1047119508
User-Agent: Cisco-SIPGateway/IOS-16.6.4
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 102 INVITE
Timestamp: 1614797285
Contact: <sip:1111111111@172.27.32.8:5060>
Expires: 300
Allow-Events: kpml, telephone-event
Max-Forwards: 66
Session-ID: 187dde7b6a0353c3886571bd5a8f4582;remote=00000000000000000000000000000000
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 246

v=0
o=CiscoSystemsSIP-GW-UserAgent 4165 7099 IN IP4 172.27.32.8
s=SIP Call
c=IN IP4 172.27.32.8
t=0 0
m=audio 8110 RTP/AVP 0 101
c=IN IP4 172.27.32.8
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20

002822: Mar  3 12:48:05.550: //173222/D0980EBD905D/SIP/Msg/ccsipDisplayMsg:
Sent: 
INVITE sip:2234@172.27.32.6 SIP/2.0
Via: SIP/2.0/UDP 172.27.32.8:5060;branch=z9hG4bK2008B2011
Remote-Party-ID: "WIRELESS CALLER" <sip:1111111111@172.27.32.8>;party=calling;screen=no;privacy=off
From: "WIRELESS CALLER" <sip:1111111111@12.12.12.12>;tag=4DC3FD5F-1B31
To: <sip:2234@172.27.32.6>
Date: Wed, 03 Mar 2021 18:48:05 GMT
Call-ID: D099E335-7B8711EB-9063B395-3E69C694@172.27.32.8
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE:  1800
Cisco-Guid: 3499626173-2072449515-2422059925-1047119508
User-Agent: Cisco-SIPGateway/IOS-16.6.4
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 102 INVITE
Timestamp: 1614797285
Contact: <sip:1111111111@172.27.32.8:5060>
Expires: 300
Allow-Events: kpml, telephone-event
Max-Forwards: 66
Session-ID: 187dde7b6a0353c3886571bd5a8f4582;remote=00000000000000000000000000000000
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 246

v=0
o=CiscoSystemsSIP-GW-UserAgent 4165 7099 IN IP4 172.27.32.8
s=SIP Call
c=IN IP4 172.27.32.8
t=0 0
m=audio 8110 RTP/AVP 0 101
c=IN IP4 172.27.32.8
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20

002823: Mar  3 12:48:06.551: //173222/D0980EBD905D/SIP/Msg/ccsipDisplayMsg:
Sent: 
INVITE sip:2234@172.27.32.6 SIP/2.0
Via: SIP/2.0/UDP 172.27.32.8:5060;branch=z9hG4bK2008B2011
Remote-Party-ID: "WIRELESS CALLER" <sip:1111111111@172.27.32.8>;party=calling;screen=no;privacy=off
From: "WIRELESS CALLER" <sip:1111111111@12.12.12.12>;tag=4DC3FD5F-1B31
To: <sip:2234@172.27.32.6>
Date: Wed, 03 Mar 2021 18:48:06 GMT
Call-ID: D099E335-7B8711EB-9063B395-3E69C694@172.27.32.8
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE:  1800
Cisco-Guid: 3499626173-2072449515-2422059925-1047119508
User-Agent: Cisco-SIPGateway/IOS-16.6.4
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 102 INVITE
Timestamp: 1614797286
Contact: <sip:1111111111@172.27.32.8:5060>
Expires: 300
Allow-Events: kpml, telephone-event
Max-Forwards: 66
Session-ID: 187dde7b6a0353c3886571bd5a8f4582;remote=00000000000000000000000000000000
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 246

v=0
o=CiscoSystemsSIP-GW-UserAgent 4165 7099 IN IP4 172.27.32.8
s=SIP Call
c=IN IP4 172.27.32.8
t=0 0
m=audio 8110 RTP/AVP 0 101
c=IN IP4 172.27.32.8
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20

002824: Mar  3 18:48:08.550: %VOICE_IEC-3-GW: SIP: Internal Error (1xx wait timeout): IEC=1.1.129.7.59.0 on callID 173222 GUID=D0980EBD7B8711EB905DB3953E69C694
002825: Mar  3 12:48:08.550: //173222/D0980EBD905D/CCAPI/cc_api_call_disconnected:
   Cause Value=102, Interface=0x7F999FB2B898, Call Id=173222
002826: Mar  3 12:48:08.550: //173222/D0980EBD905D/CCAPI/cc_api_call_disconnected:
   Call Entry(Responsed=TRUE, Cause Value=102, Retry Count=0)
002827: Mar  3 12:48:08.551: //173221/D0980EBD905D/CCAPI/ccCallReleaseResources:
   release reserved xcoding resource.
002828: Mar  3 12:48:08.551: //173222/D0980EBD905D/CCAPI/ccCallSetAAA_Accounting:
   Accounting=0, Call Id=173222
002829: Mar  3 12:48:08.551: //173222/D0980EBD905D/CCAPI/ccCallDisconnect:
   Cause Value=102, Tag=0x0, Call Entry(Previous Disconnect Cause=0, Disconnect Cause=102)
002830: Mar  3 12:48:08.551: //173222/D0980EBD905D/CCAPI/ccCallDisconnect:
   Cause Value=102, Call Entry(Responsed=TRUE, Cause Value=102)
002831: Mar  3 12:48:08.552: //173222/D0980EBD905D/CCAPI/cc_api_call_disconnect_done:
   Disposition=0, Interface=0x7F999FB2B898, Tag=0x0, Call Id=173222,
   Call Entry(Disconnect Cause=102, Voice Class Cause Code=0, Retry Count=0)
002832: Mar  3 12:48:08.552: //173222/D0980EBD905D/CCAPI/cc_api_call_disconnect_done:
   Call Disconnect Event Sent
002833: Mar  3 12:48:08.552: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:
   
002834: Mar  3 12:48:08.552: :cc_free_feature_vsa freeing 7F99A0EC5E58
002835: Mar  3 12:48:08.552: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:
   
002836: Mar  3 12:48:08.552:  vsacount in free is 1
002837: Mar  3 12:48:08.553: //173221/D0980EBD905D/CCAPI/ccCallDisconnect:
   Cause Value=102, Tag=0x0, Call Entry(Previous Disconnect Cause=0, Disconnect Cause=0)
002838: Mar  3 12:48:08.553: //173221/D0980EBD905D/CCAPI/ccCallDisconnect:
   Cause Value=102, Call Entry(Responsed=TRUE, Cause Value=102)
002839: Mar  3 12:48:08.554: //173221/D0980EBD905D/SIP/Msg/ccsipDisplayMsg:
Sent: 
SIP/2.0 408 Request Timeout
Via: SIP/2.0/UDP 8.1.1.1:5060;rport;branch=z9hG4bK+d5378c7bab6ef7eed83b3baf831afe221+sip+1+c565dff0
From: "WIRELESS CALLER" <sip:1111111111@12.12.12.12>;tag=8.1.1.1+1+20d6560d+3fdd2624
To: <sip:1112222234@12.12.12.12>;tag=4DC40B10-2572
Date: Wed, 03 Mar 2021 18:48:01 GMT
Call-ID: 0gQAAC8WAAACBAAALxYAAG42t6ygNPdXPEQS8dGuAVkmqvXBAYLxpeEAd+2qBcfw@8.1.1.1
CSeq: 1036074982 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-16.6.4
Reason: Q.850;cause=102
Session-ID: 00000000000000000000000000000000;remote=187dde7b6a0353c3886571bd5a8f4582
Content-Length: 0


002840: Mar  3 12:48:08.560: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:

Roger Kallberg · ‎03-09-2021

If the traffic reaches CM I think you need to look at you configuration again. It looks like the CM might be seeing the traffic as coming from 12.12.12.12 and that will not be allowed as the trunk IP would be 172.27.32.8.

Can you do a debug voip dialpeer to verify that the call is using the expected dial-peers?

TONY SMITH · ‎03-09-2021

The 403 errors earlier look like they came from the ITSP. Maybe at that time you had overlapping patterns so that after failing to get an answer from either CUCM, the call was then attempted back out to the ITSP. That's not happening now. If that's all correct then the issue is why your CUCM servers aren't responding, or why the CUBE isn't receiving their responses. Are the Invites even reaching them? You can run a capture on the CUCM to see what it thinks it's receiving and sending.

mumbles202 · ‎03-09-2021

Yea, I'm going to get a capture from the CUCM to see if I see the incoming request since I'm not seeing it in the CUCM traces.

mumbles202 · ‎03-19-2021

So I was able to pull captures from both the CUBE and the CUCM yesterday and I don't see the invite being sent out the "LAN" interface of the CUBE which explains why the CUCM isn't receiving them either. The CUBE and the CUCM share a segment and the dial-peer for calls to CUCM has a binding to that interface as well.