sip/2.0 403 forbidden

[Sheikh]

Hi, hope you are having good time. I have a VPN between our PK and US office, and I am are facing "sip/2.0 403 forbidden" error when I try to call from US to PK extension numbers. US to US and PK to US dialing is perfectly fine, only US to PK dialing is showing this error. I am attaching show ccsip message and show ccsip calls.

can anyone please adivse?

[Slavik Bialik]

Give us a little more information about your topology. What's the PK you're referring? is PK is another CUCM cluster you have or PK is your ITSP?
If US and PK are both different CUCM clusters, and both of them are connected with a direct SIP trunk between them, so check the SIP trunk configuration towards US on your PK cluster, see if the Inbound CSS is configured, and if so, check that this CSS can "see" the extensions partition.

[Sheikh]

Consider PK one router with CME at one location and US the other router with CME. Both are connected over a GRE tunnel over the vpn. there are few extensions on PK router and few on US routers. both locations can dial each others extension numbers. PK can dial extensions as well as local PSTN numbers on the US side. However US router can dial only extensions on PK in ideal case. now the only problem is US router is not able to dial extensions of PK router, giving fast busy tone, with unknown number message on IP phone. what is CSS?

[Gregory Brunn]

CSS stand for calling search spaces, combined with partitions they are a way to restrict and or grant access to route patterns and other items in CUCM. Now if you talking about CME this is done with cor list. I would not focus on that right now, if you topology is a two routes with a GRE inbetween and you can't call from one side to the other I would post your sanitized configuration as well. Are you using the voice service voip trusted authentication list?

[Gregory Brunn]

Your Q850 cause code is 21 Indicates that the equipment sending this cause code does not wish to accept this call, although it could have accepted the call because the equipment sending the cause is neither busy nor incompatible. Might also be generated by the network indicating that the call was cleared because of a supplementary service constraint. The diagnostic field might contain additional information about the supplementary service and reason for rejection.

[Sheikh]

Well there is no cor list, instead there are dial-peers and translation-rules that are working/matching perfectly fine.

[Gregory Brunn]

Please post your configs to look at the issue in more detial

[Sheikh]

Since the system is in production/live, can you please let me know how to send configs to you in private!

[Gregory Brunn]

Just pull a show run and pull out all public / private IP you feel are sensitive , any passwords and or hashes, and any DID numbers and or identifying information. If you want to start smaller can you send me back the voice service voip sections from both routers first. I want to check you don't have a toll fraud mechanism enabled that might prevent this call.

[Sheikh]

Here you go, Greg.

[Gregory Brunn]

Are the addresses your phones and cme tied to called out in your

voice service voip 67

ip address trusted list

 Ipv4 xxx

ipv4 xxx 

ipv4 xxx 

ipv4 xxx

[Sheikh]

there are 3 IPs, One is Public facing interface, second is private IP, and the third is GRE tunnel IP of PK router. other 3 are public IPs of service provider network, I'm not sure why these are here.

[Gregory Brunn]

They are a toll fraud mechanism for now just do

voice service voip

no ipv4 trusted authenciation list

or whatever the command is to disable it.

Test again and let me know the results

capture debug ccsip messages

debug dial-peer

debub voice ccapi inout on both routers as your a making call and the debugs from each router.

. Also what are your inbound and outbound dial-peers you are trying to match on each router

[Gregory Brunn · Accepted solution]

Ok so phones on US can't call PK correct,  Look at your voice service voip on pki. 

Try the following

voice service voip

 no ip address trusted list

allow-connections h323 to h323
 allow-connections h323 to sip
 allow-connections sip to h323
 allow-connections sip to sip

[Gregory Brunn]

Any update on this one?