VoIP and T1 carrier information

Some useful information about specific VoIP carriers to consider when troubleshooting

Bandwidth.com

Effective 9/11/2008 - Fonality no longer supports Bandwidth.com!!!

Bandwidth provides SIP over T1 access. Often times, customers will request a T1 turn-up with Bandwidth.com, but make sure that it isn't a data & SIP solution.

When registering SIP service, Bandwidth has several requirements and quirks:

  1. The PBXtra must have an external IP address. Certain routers and firewall devices (e.g., Cisco Pix) have the means of directing a specific IP address to an internal unit. This will allow both external IP resolution with the provider and internal IP resolution with SIP phones
  2. VoIP settings do not hold registration. This carrier registers off of a static IP address rather than a registration string, like most other VoIP providers. Make sure Registration = No and username & password fields are blank

If you are having DTMF issues with Bandwidth.com customers, try setting server and fromdomain to 4.79.212.236. It appears their 216.82.224.202 trunk may be using rfc2833 compliancy with Asterisk 1.4. *UPDATE. Bandwidth.com is decommissioning this server in December 2007.

CBeyond

Cbeyond often uses a router that will register through a VPN tunnel back to the carrier, and will appear to resolve their server name to an internal IP address. This can cause problems with NAT, as the PBXtra will have an internal IP address.

Cbeyond has also been known to have an issue if the "Global" section of sip.conf has dtmf=info (as is stock on all PBXtras), and changing to inband seems to work.

Junction Networks

Junction Networks is currently dealing with a configuration error in their switches where multiple INVITES are sent. When PBXtra accepts the second invite, the call drops. As of Jul 27th Michael Oeth, our technical contact at Junction, has stated they are aware and addressing the issue:

There is an issue.  Our system-level SIP capture was able to capture the 
issue as it happened.  We have tracked it down to a strange SIP 
interaction.  We have a maintenance window this weekend and will be 
investigating the issue and could have a resolution as early as Monday.  
If that is too long, a switch to the IAX protocol should resolve the 
issue immediately.  There is no problem with Junction Networks customers 
having both SIP and IAX trunks registered simultaneously and having some 
DIDs SIP and others IAX.
Technical Details:
On some percentage of the inbound calls we are sending you two SIP 
INVITE messages within 0.02 seconds of each other.  This confuses your 
Asterisk system.  Your Asterisk system never properly sets up the call 
(the SIP trace is included below).  The issue we are tracking down is 
why we are sending you two INVITE messages so close together.  Below, 
you'll see the two inbound INVITE messages, and then you'll see your 
system never fully ACK'ing the call.  This is not at all an indictment 
of Asterisk - we should not be sending the duplicate INVITEs.  This is 
in no way a Fonality bug and they can close the ticket on their side.
--Mike

Teliax

Click Teliax for details page.

Broadvoice

Click Broadvoice for details page.

Vonage

Vonage service does not work well with PBXtra. There are very few instances where a customer has made it work, and they were only able to do so by getting to know high-level officials at Vonage personally. Reccommend that customers do not use Vonage with their PBXtra.

Analog lines from Vonage boxes do not work well with PBXtra either. The translation of digital to analog back to digital loses something in the ability for PBXtra to connect to the line. DTMF and volume problems are common.

PlanetAccess

PlanetAccess will sometimes prefer to register over port 5061. This is not supported by PBXtra. Check with tcpdump to see how their requests are resolving.

XO

XO requires the outbound caller ID to be the same as the 'Billed Telephone Number' (BTN). Outbound calls will either get blocked out or the caller ID will get displayed as the phone number on the account.

BabyTel

Babytel cannot register under the hostname sip.babytel.ca, currently this resovles to 216.18.125.3. The address of 216.18.125.7 is the current proxy server or another IP will be provided by Babytel. Usually, Babytel will request the end user updates their /etc/hosts file to map the hostname to the IP addres. THIS IS NOT NECESSARY AND SHOULD NOT BE DONE UNDER ANY CIRCUMSTANCES. Instead, use the web interface Options->voip page and input the IP address in lieu of the hostname. Babytel currently also registers on port 5065, not 5060, this can be changed in the web control panel as well. In the register string input the informaiton in the following format:

username:password@ip.add.res.s:PORT/username

where "PORT" is 5065.

Image:Babytel_5065.jpg

If customer is routing by DID using BabyTel, they may require the following since this carrier uses Virtual DID numbers.
To get DID routing to work for this carrier, the carrier must change their registration to allow each Virtual DID to register.
In our system, you simply add a new VoIP account for each Virtual DID with only one caveat, in the reg. string you must add
:authenticationuser after the password.  The authentication user will be the same as the primary DID number.
For example, if the user in picture above added DID number 12345678901 to their account, set up a new VoIP account but alter
the registration string to match below, everything else in the account will look like the username is 12345678901 but the reg:
 12345678901:ponellax:14166630200@216.18.125.7:5065/12345678901

RNK Telecom

Update: Got an RNK VoIP account working with a PBXtra with nothing more than having to add the username to the "From User". (Wireball, 7/10/08)

 

          • Note: This information appears to be suspect...a customer reported that our internal wiki article was essentially written in regards to his support issues and gathered from their conversations with their carrier and that this information is no longer valid. But I can't positively deny or confirm this....so for now, it's still here.


Officially, RNK Telecom does not provide support for asterisk customers. However, just as bumblebees fly, customers do use this carrier. After a lengthy conversation with one of their engineers, here's what I've learned:

RNK has two methods by which they register. They have a "Peering" platform which receives SIP registration on port 7180 and bounces to one of their many SIP servers, which actually does the SIP registration. This is an older platform.

Next, they have the Nextone session border controller, which allows direct SIP invites. This server authenticates by the customer's external static IP address.

The latter is a preferred method of registering. Newer customers (say, as of mid 2007...?) will likely be set to the Nextone SBC. Make sure they are set to register=no and that they are on an IP address that will register (RNK has a bajillion IP's for SIP reg). Older customers that are on the old version of SIP registration will need to go to RNK and ask to be moved to the Nextone server, in such case they will get the IP of that server.

Unlimitel

This VoIP carrier seems to work quite simple while using their SIP service. IAX is tricky. Compare against other customers using Unlimitel IAX VoIP service. I've also included a sample of what I was able to get work below:

register => 8669439626:3212736@iax03.unlimitel.ca ; 8669439626
[8669439626]
allow=ulaw
allow=alaw
allow=gsm
fromdomain=iax03.unlimitel.ca
fromuser=8669439626
context=incoming
dtmfmode=rfc2833
insecure=very
nat=yes
canreinvite=no
qualify=yes
auth=plaintext
tos=none
type=friend
host=iax03.unlimitel.ca
secret=3212736
username=8669439626

http://www.trixbox.org/forums/trixbox-forums/sip-and-iax-trunks-and-providers/unlimitel-config-trixbox

http://www.unlimitel.ca/support.html

Voiceglobe

Voiceglobe requires that useragent=PBX be entered within the [general] section of sip.conf

Telwest Services

Telwest Services

Technical support inquiries: 866-434-8967

Josh Dowdy is one of their technicians, and his cell is 512-797-2498 (unverified; please use only if absolutely necessary).

Speakeasy

Speakeasy uses SRV lookups and an outbound proxy by default. Currently, Fonality does not support SRV lookups, so the current workaround is:

Edit /etc/hosts to point speakeasy.net at the appropriate host. ex

64.81.79.172    speakeasy.net

Each DID must also register using the following format:

register => number:password:main number@speakeasy.net/number

Example:

; SPEAKEASY SIP TRUNK
register => 9172101770:freeh2o:9172101770@speakeasy.net/9172101770 ; SpeakEzSipTrunk

; SPEAKEASY SIP TRUNK DIDs
register => 9172101760:freeh2o:9172101770@speakeasy.net/9172101760 ; SpeakEzSipTrunk
register => 9172101761:freeh2o:9172101770@speakeasy.net/9172101761 ; SpeakEzSipTrunk
register => 9172101762:freeh2o:9172101770@speakeasy.net/9172101762 ; SpeakEzSipTrunk
register => 9172101763:freeh2o:9172101770@speakeasy.net/9172101763 ; SpeakEzSipTrunk
register => 9172101764:freeh2o:9172101770@speakeasy.net/9172101764 ; SpeakEzSipTrunk

 

NexVortex

Carrier is unwilling to compensate for Asterisk 1.2/1.4 RFC2833 issues as per Teliax above. DTMF WILL NOT WORK for this carrier until they are willing to compensate.

Excel

In order for Excel SIP Service to work properly - we must comment out the localnet statement of 10.0.0.0 in sip.conf

Before

localnet=192.168.0.0/255.255.0.0
localnet=10.0.0.0/255.0.0.0
localnet=172.16.0.0/12
localnet=169.254.0.0/255.255.0.0

After

localnet=192.168.0.0/255.255.0.0
;localnet=10.0.0.0/255.0.0.0   <--- add a semi-colon to the front
localnet=172.16.0.0/12
localnet=169.254.0.0/255.255.0.0 

Naturally this means the customer CANNOT use the 10.0.0.0 network for addressing their phones.  If they need to do so, you must allow the customer's subnet but no other address on the 10.0.0.0 network.

Tag page