SIP Trunk (Bandwidth.com) - List of IPs to add to CCA?

Unanswered Question
Dec 8th, 2009

Hi All -

Wondering if anyone can provide any insight regarding the 'Voice source-group CCA_SIP_SOURCE_GROUP' that is configured in CCA 2.2 for SIP trunks.

In the posted document it states that 'The source IP address of the SIP message is in the From header or the Contact header after the @ sign'.  Additionally, these IPs should be added in the CCA SIP configuration.

When looking at the debug logs from an inbound bandwidth.com call, the From/Contact/To/C= headers after the @ sign do not contain bandwidth.com's signaling servers but rather contain the IP addresses from their carrier providers.

I've contacted their support to request the IPs to add into our configuration and they mentioned we should only need their two signaling servers.  A range of IPs where the RTP packets are coming from is not possible and our system should be referencing the URI field for the correct IP.    The URI field in the debug logs does contain their correct servers.

Any ideas if I am overlooking something? 

Thanks for any info!

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Steven Smith Tue, 12/08/2009 - 13:15

You will only need the signaling servers.  The media servers are not needed.  Are you having problems with the source group?  In CCA, where you configure the SIP trunk, the next tab for advanced configuration is where you would add the extra server IP's.  Again, only signaling.

NYCiscoTech_2 Tue, 12/08/2009 - 13:35

Yup -- I have added bandwidth's IPs under Proxy Server (Primary) and Proxy Server (Secondary).

Under the avanced tab, if I add the IP that appears in the sip debug logs (From/Contact field after the @ sign) then inbound calls work perfectly.   But since I don't have a list of these IPs, not all inbound calls will work.

Wondering if maybe the SIP messages for this provider are formatted differently from 'the norm' and the system is not interpreting them?....

Maulik Shah Tue, 12/08/2009 - 16:37

Typically most SPs have an SBC (Session Border Controller) front ending all the SIP trunk CPE such as a UC500 to ensure their SIP network is secure (SBC is like a SIP trunk firewall). Hence the IP address or DNS for incoming or outgoing calls is almost always the SBC.

Not sure how bandwidth.com's SIP trunk network is setup - most times they will have the signaling traffic come in from a specific set of IP addresses that are in their network, not their peering SP's IP addresses. Can bandwidth.com provide the list of signaling IP addresses they will use (do not care about the media i.e. c= line) - I would be surprised if this is very long list or something they cannot provide to you. You want the UC500 to not allow SIP traffic from any IP address as that is where toll fraud occurs and hence this check is important.

NYCiscoTech_2 Wed, 12/09/2009 - 12:00

Thanks for the information guys.

I opened another ticket with Bandwidth communicated we require the 'signaling servers' and they repeated they can only provide the servers they use for the SIP setup.

Feel like I am missing something here...  Would a debug be helpful?

Maulik Shah Thu, 12/10/2009 - 09:23

So even after adding the IP addresses of the signaling servers from Bandwidth.com you are seeing inbound calls fail? A debug would help but would also need a list of the IP addresses you have configured on the UC500 to accept inbound SIP requests.

NYCiscoTech_2 Wed, 03/03/2010 - 15:34

Just to follow-up on this...Seems we are still experiencing an issue with this. 

After looking at the SIP debug logs, anytime an IP appears in the SIP header in this format   SIP:[email protected]:5060 

We're required to add this IP address into the additional IP field in CCA, otherwise inbound calls fail.

The problem with this is depending on where the call is coming from the IPs change.   Bandwidth cannot provide a list of these IPs as they are dynamic. 

They only send SIP signaling from the primary/secondary proxies and the information from the debug is only part of the header info.

Any suggestions on this?

Thanks

Maulik Shah Thu, 03/04/2010 - 11:28

The check is against the VIA header in the INVITE, not the FROM header:

Via: SIP/2.0/UDP 192.168.1.1:5060;

This UC500 behavior is meant to protect against toll fraud - the way bandwidth.com is setup is not a very secure option in my opinion. Other than having you remove this check, there is no other option it appears unless bandwidth.com can ensure only specific IP addresses send SIP messages to the UC500. This does not leave you completely vulnerable as long as you have used CCA to configure the box as there are 2 other checks added:

- inbound SIP calls to DIDs configured on the UC500 via CCA will only be accepted, inbound calls to any other number will be dropped (for example if the SIP INVITE is for 9011xxxxxxxxx)

- firewall is enabled on UC500 and only permits bandwidth.com IP address (this is NOT the From or Via header, this is the actual Layer 3 IP address which should always be the same) for SIP traffic

Private message your config and can provide further guidance.

JP Rike Tue, 07/12/2011 - 03:20

How did you overcome this issue?

I have done the exact same thing as you with a different provider. I added the IP addresses of the RTP IPs carrying the audio so calls can come through. However, it looks as this does not always work and after 30 minutes of being on the phone with someone, the call will drop. I understand that you do not want to allow "all IPs" to access the voice network because of toll fraud. However, if you just let the IPs of the SIP Registrar Server and RTP Servers pass through on the firewall, would it not prevent toll fraud?

I am also starting to wonder if the SA500 I have in front of the device is causing me even more issues and parsing the SIP header along the way to the UC.

Thanks.

ADAM CRISP Tue, 07/12/2011 - 11:46

Hello.

There are several toll fraud protect measures configured by CCA. To correctly configure your system you need to know the IP addresses used by your Service provider. CCA tries to work it out and may work for SP's with a single IP address and who's SBC has been given a DNS 'A' record, but if that's not the case you will need to tweak your settings.

CCA allows you to add in additional IP's, but does not allow you to add in a range/subnet

The Methods CCA uses to protect itself are

1. WAN access list.

There's a WAN access list which is configured to allow in traffic from the SP.

CCA carries out a DNS A record lookup for the proxy and creates some entries.

Typically access-list 104

2. Voice Source groups. Source groups were intended to group together VoIP sources and treat the calls differently on arrival as configured. The trick used by CCA is that if you're souce IP (The SP) isn't contained within a source group then it's invalid, so the call is dumped. With a SIP call the unit will respond back to the source with a 500.

CCA creates two source groups - one for internal sources - the voice vlan and CUE, and the external one for the SP.

Again, CCA carries out a DNS A record lookup for the SP's SBC and adds this in to the external group. Typicalls Access-list 2 & 3.

3. Black holing incoming calls.

There's a special incoming voip dial peer which matches ALL incoming calls. Calls arriving on this dial peer are dumped.

The ideas is that if somebody's sending you a call to a number that is not allowed on your box, we want to avoid the call being re-sent to a SP for termination.

This is configured using the 'permission term' feature. All incoming DID's need to be explicitally allowed. When configured with CCA, we have a number of incoming dial-peers with better matches.

4. There's another IP souce feaure within the 'voice service voip' section. CCA leaved this feature open and allows anything - look for ip address trusted list - 0.0.0.0 0.0.0.0

To find out the IP addresses used by your SP  you need to check  DNS A records and also SRV.

Here's an example of a A record lookup using nslookup:

C:\>nslookup

Default Server:  UnKnown

Address:  10.200.250.200

> set type=a

> proxy.voip.co.uk

Server:  UnKnown

Address:  10.200.250.200

Non-authoritative answer:

Name:    proxy.voip.co.uk

Address:  193.203.210.38

and here's an example for SRV

> set type=srv

> _sip._udp.proxy.voip.co.uk

Server:  UnKnown

Address:  10.200.250.200

Non-authoritative answer:

_sip._udp.proxy.voip.co.uk      SRV service location:

          priority       = 0

          weight         = 0

          port           = 6060

          svr hostname   = sbc5.a.synergy.voip.co.uk

_sip._udp.proxy.voip.co.uk      SRV service location:

          priority       = 0

          weight         = 0

          port           = 6060

          svr hostname   = sbc5.b.synergy.voip.co.uk

voip.co.uk      nameserver = a.ns.voip.co.uk

voip.co.uk      nameserver = b.ns.voip.co.uk

voip.co.uk      nameserver = ns0.ncuk.net

a.ns.voip.co.uk internet address = 80.249.108.54

b.ns.voip.co.uk internet address = 193.203.210.54

>

we then need to get the A record for sbc5.a and sbc5.b:

> set type=a

> sbc5.a.synergy.voip.co.uk

Server:  UnKnown

Address:  10.200.250.200

Non-authoritative answer:

Name:    sbc5.a.synergy.voip.co.uk

Address:  193.203.210.29

> sbc5.b.synergy.voip.co.uk

Server:  UnKnown

Address:  10.200.250.200

Non-authoritative answer:

Name:    sbc5.b.synergy.voip.co.uk

Address:  193.203.210.39

>



You can  then check your WAN access-list, source groups, etc

I don't understand what is happening with your 30 minute problem, I doubt it's related to the IP address of your SP. -  please can you provide more information - like a SIP trace when it  happens ?

thanks

Adam

tamergabermd Tue, 07/12/2011 - 17:18

Could you tell me how you knew to look for

_sip._udp.proxy.voip.co.uk?

I am trying to add ips to my configuration and would like to get the same info about the proxy server for my vendor - px1.nexvortex.com, but there is no _sip._udp.px1.nexvortex.com. 

JP Rike Tue, 07/12/2011 - 18:29

Adam - Thanks for the reply.

Tamer - use nslookup - nexvortex only uses 5060 for invites

The issue is with a provider such as NexVortex, the invites come from the registration server, and the UDP audio ports come over other IPs. We have all of those IPs.

We have disabled all of the ACLs to allow all incoming IPs through on the UC. The SA500 is in front of everything. We deleted the "permission term" line and have done a few other tweaks. The SA also allows for all the RTP ports.

I am trying to figure out the what next. I was hoping that you might have come up with a resolution. The issues are itermetent, eg - Audio fails after 30 minutes. I will PM a SIP trace to you later.

- JP

ADAM CRISP Wed, 07/13/2011 - 00:31

OK.

When the call drops - is it just audio that's lost - which direction - or does the call hang up ?

Can you gather a SIP trace ?

Adam

JP Rike Tue, 07/19/2011 - 14:46

Hi Adam,

Just returned from vacation and the client has not logged a huge complain since I have left...here is what we did so far.

We made some changes on the SA that seem to be helping. We have allowed for the media IPs to open any RTP port. This seems to have helped a lot. From using these boards, we referenced a case from back in February that was posted on here and Cisco found the info on there side and it said to upgrade the firmware on all of the SPA phones. We have since done this and it has helped out tremendously.

I am not saying any of these solutions are a "home run" yet however, the client has not complained since we have implemented the above.

We were always losing outbound audio or the call would just drop. I will send you a SIP trace so you can see the info.

- JP

wireguided Wed, 07/20/2011 - 13:44

Give these allowed IPs a try for bandwidth.com. If I remember correctly some engineer provided these to me over a year ago.

209.247.16.221

4.55.20.99

4.55.21.99

4.55.4.227

4.55.5.35

4.68.250.148

4.79.212.229

67.231.4.93

67.231.8.93

-Tim

seanrivers Tue, 11/22/2011 - 11:27

Please DO NOT USE the IPs mentioned by Tim. We cannot guarantee they will work (We have a lot more than nine). The way Bandwidth.com handles SIP trunking is very straight forward:

  1. We do not employ an SBC. An SBC is a very inefficient way to route media.
  2. We ALWAYS  send and receive SIP messaging from our Proxies
  3. You can use our SRV ot.bandwidth.com or our IPs (216.82.224.202 or 216.82.225.202)
  4. While setting up the call we will send out a media gateway in the SDP where you can expect the media to come from and where you will need to send media to.
  5. There is no need to pin-hole or write a lot of rules for the firewall. just make sure the firewall is SIP aware and can open and close ports and IP addresses based on what is negotiated in the SIP signaling from the trusted Bandwidth.com proxies.

We usually run into issues when the firewall is not capable or setup to treat SIP properly and is locked down unnecessarily.

For the sake of proper routing we need to be able to route you directly to the media server, for the sake of scale we have thousands of them and for the sake of security trust the proxies to negotiate.

I hope this helps, but if you need more guidance, talk to our support they might not be Cisco experts but they are SIP experts.

ADAM CRISP Wed, 11/23/2011 - 04:59

Hi Sean thanks for this.

With a cisco esq view of this, CCA secures a UC500 by:

1. rejecting calls if send to an unknown DID (permission term dial peer)

2. access-list on WAN side interface which allows SIP signalling from known IP addresses - (this is relavent to the information you have provided and the information is filled into CCA on the advanced tab. CCA currently does not auto-resolve your IP's from SRV records and does not support subnets. Also if you change the IP addresses in the future the information will need to be re-entered)

3. voice source-groups - are implemented to work around the safetly feature in 1. above for calls originating from the customer LAN/ CUE module. If the Service provider IP addresses are not contained within a source group then the UC rejects them - hence this post.

4. ip address trusted list - currently not implemented by CCA but must be soon.

Possible issues arrising from media not coming from your SBC's - (or another set of IP addresses)

1. The WAN access list does allow UDP in the rtp range 16384 - 32767 , but if your source is outside this then there's a possibility incoming audio will be broken

2. There is a firewall configured for generic UDP, so if the router sends to the same media server you should get 2-way audio however there's a chance early media will be broken

Hope this helps somebody.

Adm

Actions

This Discussion