In part 1, I explained how a SIP Trunk is really just a virtual connection between your Asterisk PBX and the VoIP service provider. Standard SIP signalling is used on the trunk, but more than one simultaneous call is allowed and you may have more than one DDI number.
We're moving!Blogspot has been a great way to start blogging, but it has limitations. We've just completed a brand new annex to the smartvox web site called the Smartvox Knowledgebase - it is a combined blog plus a complete archive of all the blogs and VoIP articles I've written in the last few years. Please visit the new Smartvox Knowledgebase at:http://kb.smartvox.co.uk/. To read the latest revision of this article on SIP trunks in Asterisk at the new site, follow this link: http://kb.smartvox.co.uk/index.php/asterisk/telephony-connections/sip-trunks-telephony-connections/taking-the-plunge-with-sip-trunks-part-2/ |
Basic requirements to enable your SIP trunk
A SIP Trunk may be used for both inbound and outbound call traffic. To make outbound calls, your Asterisk or other PBX has to send a SIP INVITE request to the VoIP service provider's equipment; when you receive an inbound call, the service provider is sending an INVITE to your PBX. While there are some subtle differences between the delivery of outbound calls and receipt of inbound calls, both share the following basic requirements:
- Location - knowing the address of the far-end equipment
- Authentication - the ability to confirm the identity of the sender
Authentication is especially important for outbound calls because these will generally incur service provider charges.
Resolving equipment location
The address of the VoIP service provider's equipment is very predictable and unlikely to change over time. But how does the VoIP service provider know the address of your PBX? Some users will have a static IP address, but this is not universal and NAT can add further complications. For this reason, most VoIP service providers will require that your PBX registers itself on their equipment.
Your PBX does this by sending a SIP REGISTER request to the service provider at regular intervals (typically every 30 to 60 minutes). In so doing it provides up-to-date information about the location of your PBX. Keep-alive messages may also be sent to keep the route open through a NAT device or firewall.
Registration for Asterisk or Trixbox
In Asterisk, registration information is provided in a single line placed in the general section of sip.conf. Using Trixbox, this line appears at the end of the trunk definition form. Here is an example of the register line:
register => 43212345:mysecret@mysipsp.com/1234
The register line includes a host name (mysipsp.com) which tells Asterisk where to send the registration request; the number at the beginning of the line (43212345) is the user ID and mysecret is the password; finally, the number 1234 shown at the end of the line - after a forward slash - is an optional parameter that tells the service provider to use this number when sending INVITE requests to Asterisk.
Authentication
The user ID and password included in the registration line above are used to provide authentication during registration - to identify to the provider that you are the correct account holder. However, take note that inbound calls do not use password authentication at the time the call is delivered - instead, Asterisk knows the request is coming from your service provider by matching the sending IP address with the host parameter stored in sip.conf.
Some examples of Asterisk configuration
In Trixbox or FreePBX, the sections for dealing with inbound calls and registration are found at the end of the SIP trunk configuation form:
If you are using raw Asterisk, the register string will look the same and the equivalent peer section in sip.conf would look like this:
[smartvox-in]
type=user
context=from-trunk
insecure=invite
host=mysipsp.com
The use of the insecure parameter as shown above is simply a way of telling Asterisk that it should not challenge for user ID and password when a new inbound call INVITE arrives. Omitting this parameter can break delivery of inbound calls.
More on dealing with inbound calls in part 3.
No comments:
Post a Comment