09-07-2011 07:59 AM - edited 03-21-2019 04:37 AM
I'm trying to get inbound calls to work with NexVortex, but the questions themselves are general. I set up the SIP in CLI according to their guide and went through some troubleshooting that I found on the web, but there are a few things I'm unable to set for some reason.
The first is the SIP Domain Name within the SIP Trunk config in CCA. The guide and screenshots of working setups show that it's set to "66.23.129.253" (the same IP as proxy and registrar), and I feel like it definitely needs to be set because I'm using NexVortex's dynamic routing setting which uses their DNS to look up my account username (which is each phone number on my account). Where and how can I set this? I attached a screenshot of what I'm talking about.
The second question is with the access list. According to the NexVortex setup guide, it says that CCA builds the access list incorrectly. CCA adds "access-list 2 permit 66.23.129.253" instead of "access-list 2 permit 66.23.129.253 255.255.255.255". This is a hairpin ACL to prevent toll-fraud. But when I try to add the wildcard bits to the line, it doesn't add it, and I get no error message. The guide actually says to remove and add the ACL, but when I did that, it would just adds "permit any" whenever I try to add "access-list 2 permit 66.23.129.253 255.255.255.255". Am I doing something wrong here? I attached the section of the NexVortex setup guide as well as my current access list where it does NOT work.
Thanks in advance for any info/advice.
-Yutaka
09-09-2011 09:17 AM
Hello.
I don't know about Netvortex, so my response is generic.
1. I suspect you don't need to fill in the domain name IF their userguide is indicating that you should use IP addresses for host resolutions.
Imagine for one moment that in a pure SIP network, sessions could be routed via DNS - so we could dial yourname@yourisp.net. The phone making the call would 'do a dns lookup' for yourisp.net and send the call over there.
In reality we don't really have a global SIP network based on DNS alone. There are descrite SP networks interconnected with PSTN and we use old style phone numbers.
Filling in the DNS domain name makes calls originating from your router come from something like myDID@mydomainname.net. If you leave this blank I suspect calls will come from myDID@
I don't think your SP won't mind what you do.
2. Their guide is wrong. CCA is correct assuming that the IP address is correct.
Access list 2 is bound to a voice source group. If you want to receive a call from an IP address, the IP address must be within a source group if you have source groups defined on the router.
CCA creates two source groups, one for internal speakers (CUE) and one for external - your SP.
You should have
access-list 2 permit 66.23.129.253
You access list is like this:
access-list 2 remark CCA_SIP_SOURCE_GROUP_ACL_EXTERNAL
access-list 2 remark SDM_ACL Category=1
access-list 2 permit 66.23.129.253
access-list 2 deny any
access-list 2 remark CCA_SIP_SOURCE_GROUP_ACL
access-list 2 remark SDM_ACL Category=1
access-list 2 permit any
access-list 2 permit 192.168.10.0 0.0.0.255
access-list 2 permit 10.1.1.0 0.0.0.255
access-list 2 permit 10.1.10.0 0.0.0.3
Looks like things have become a little confused. I suspect you have been copying and pasteing ang got your access-list 2 & 3's mixed up. Should be:
access-list 2 remark CCA_SIP_SOURCE_GROUP_ACL_EXTERNAL
access-list 2 remark SDM_ACL Category=1
access-list 2 permit 66.23.129.253
access-list 2 deny any
!
access-list 3 remark CCA_SIP_SOURCE_GROUP_ACL
access-list 3 remark SDM_ACL Category=1
access-list 3 permit 192.168.10.0 0.0.0.255
access-list 3 permit 10.1.1.0 0.0.0.255
access-list 3 permit 10.1.10.0 0.0.0.3
Adam
09-10-2011 12:06 PM
Adam,
Wow that makes incredible sense to me now. Thanks for the insight, that definitely gives me a few things to try and fix when I get back to it on Monday.
-Yutaka
09-13-2011 03:26 PM
Hi Yutaka,
I just caution you on making modifications to your ACL, if an ITSP says that CCA builds the ACL incorrectly, take the advise on board but do not act upon it without being fully aware of the ramifications in doing so, you can resolve your issues at least 90% of the time with slight modifications and just some thought in understanding on what you need to put into CCA to make it work right... If you still have issues, you then should involve SBS (Small Business Support) and have them guide you through the CLI modifications, this way it is a supported CLI modification and may not invalidate any support contract you have on the system, it will also prevent you legally from being responsible if the system becomes compromised because of the modifications you have made on your own merit, following guide lines helps you in more than one way, and usually the ways that is often forgotten.
In my experience CCA programs most ITSP setups correctly from the word go, however it might miss extra information because it is not aware of it, such as any other SBC's that the ITSP might have on their network for redundancy or load balancing, I always ask them for any extra IP addresses that need to be authorized and then add that list in to CCA and CCA will manage this on the ACL and configuration level, which means it is added into the places that count.
Just some food for thought
Cheers,
David.
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