cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2140
Views
0
Helpful
3
Replies

UC540 SIP Trunk Questions

blizmanyu
Level 1
Level 1

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

3 Replies 3

ADAM CRISP
Level 4
Level 4

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

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

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.

Cheers, David Trad. **When you rate a persons post, you are indicating a thank you or that it helped, but at the same time you are also helping to maintain the community spirit - You don't have to rate posts and you wont be looked down upon :) *