09-01-2012 06:25 PM - edited 03-21-2019 06:14 AM
Hello,
I recently purchased a SIP trunk from Voice Pulse. I have a Cisco UC500 that I configured the sip trunk on, this is registered with the Voice Pulse SIP server. The UC500 appears to be registered with the Voice Pulse SIP server. I can make outgoing calls. In bound calling is where I'm having the problem. I can call the number I have registered with the SIP service provider from an external phone, I see the call coming in across the SIP trunk and connecting to the UC500 using debugs. On the phone I'm calling from that connects to the PSTN I receive a message saying the number I'm attempting to call is not in service. The 7961 the I have registered to the UC 500 does not ring nor does the CIPC phone on my laptop. However I do see the call coming in via the debugs.
I've enclosed a text doc that shows the output from the debugs.
Any advise would be appreciated.
Thanks
Andy
Message was edited by: Andy Blaylock I decided to delete the config and rebuild form scratch using the CCA. The SIP trunk has registered but still not able to receive incoming calls. I've attached the latest debugs and config. The latest debug file attachment is "UC540 Debugs after rebuild with CCA". Andy
Solved! Go to Solution.
09-04-2012 12:03 AM
Hi Andy,
Please read http://www.voip.co.uk/ciscoccatoolsecurity/ and then check your confirguration.
1. Check you have an incoming call route for 17202247707 as
2. Check that access list 3 contains a match for your ITSP - i.e. 24.8.157.192
etc
Adam
09-04-2012 09:25 AM
Hello Andy,
This looks like an Access List error. Since the UC returns a 500 server error when the invite is received the most likely issue is that the IP we receive the call from isn't in the Access List to permit that traffic inbound. You can fix this in CCA by adding the IP address to the toll fraud configuration. From what I can tell, it looks like you need to add this IP: 64.61.93.170
Hope this helps.
Thanks,
-john
09-04-2012 12:03 AM
Hi Andy,
Please read http://www.voip.co.uk/ciscoccatoolsecurity/ and then check your confirguration.
1. Check you have an incoming call route for 17202247707 as
2. Check that access list 3 contains a match for your ITSP - i.e. 24.8.157.192
etc
Adam
09-05-2012 05:29 AM
Hello Adam,
Thanks for your help. Im a lot nearer now. So it is something to do with the toll Fraud protection and the ACL's it applies.
I removed the toll fraud and it now works. I then re applied Toll fraud and editded the ACL's. It apprears that ACL 2 is not permiting something. I added the permit any above the deny any and sure enough the inbound calls now work. I added the log statement to see if I could see what it being permitted when I call inbound. I was hoping to see the traffic in the log, be for some reason it does not show up, I see not hits on the permit, strange.
Anyway thanks for pointing me in the right direction. I'll continue to trouble shoot. ACL 3 seems to be permitting all it needs too.
Thanks
Andy
Standard IP access list 2
10 permit 192.168.10.1 log
20 permit 10.1.10.0, wildcard bits 0.0.0.3 log
30 permit 192.168.10.0, wildcard bits 0.0.0.255 log
40 permit 10.1.1.0, wildcard bits 0.0.0.255 log
50 permit any log
50 deny any log
Standard IP access list 3
20 permit 64.61.93.0
10 permit 67.108.9.160
40 permit 64.61.93.190
50 permit 209.31.18.12
30 permit 209.31.18.0
60 deny any log
09-04-2012 09:25 AM
Hello Andy,
This looks like an Access List error. Since the UC returns a 500 server error when the invite is received the most likely issue is that the IP we receive the call from isn't in the Access List to permit that traffic inbound. You can fix this in CCA by adding the IP address to the toll fraud configuration. From what I can tell, it looks like you need to add this IP: 64.61.93.170
Hope this helps.
Thanks,
-john
09-05-2012 05:30 AM
Hello John,
Thanks for your help. Im a lot nearer now. So it is something to do with the toll Fraud protection and the ACL's it applies.
I removed the toll fraud and it now works. I then re applied Toll fraud and editded the ACL's. It apprears that ACL 2 is not permiting something. I added the permit any above the deny any and sure enough the inbound calls now work. I added the log statement to see if I could see what it being permitted when I call inbound. I was hoping to see the traffic in the log, but for some reason it does not show up, I see not hits on the permit, strange.
Anyway thanks for pointing me in the right direction. I'll continue to trouble shoot. ACL 3 seems to be permitting all it needs too.
Thanks
Andy
Standard IP access list 2
10 permit 192.168.10.1 log
20 permit 10.1.10.0, wildcard bits 0.0.0.3 log
30 permit 192.168.10.0, wildcard bits 0.0.0.255 log
40 permit 10.1.1.0, wildcard bits 0.0.0.255 log
50 permit any log
50 deny any log
Standard IP access list 3
20 permit 64.61.93.0
10 permit 67.108.9.160
40 permit 64.61.93.190
50 permit 209.31.18.12
30 permit 209.31.18.0
60 deny any log
09-05-2012 12:06 PM
Hi Andy,
Access 2 is used to match your internet subnets, so if a call arrives from a source within access 2 space - then the internal number translation profile is processed before an incoming dial match. In operation a prefix is added to an incoming call which then means a special incoming dial-peer is matched. The purpose of all of this is to work around the catch all dial-peer that drops calls to unknown numbers (permission term)
Since you have permit any in access 2 - this needs to be removed.
Access 3 has a typo - should be 64.61.93.170, not 64.61.93.160
(sorry if I said 24.8.157.192 above, I mis read something)
Adam
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide