Asterisk: The Future of Telephony, 2nd Edition

Connecting to a SIP Service Provider

With the advent of Internet telephony, there has been an influx of Internet-based phone companies springing up all over the world! This gives you a large number of choices from which to choose. Many of these service providers allow you to connect your Asterisk-based system to their networks,^[66] and some of them are even running Asterisk themselves!

The following configuration should get you connected with an Internet Telephony Service Provider (ITSP),^[67] although it is impossible to know the unique configurations each service provider will require from you, and ideally the provider will give you the configuration required to connect your system with its own. However, not all are going to support Asterisk, so we’re going to provide you with a generic configuration which should help you get on your way and, ideally, going in a matter of minutes:

[my_service_provider]
type=peer
host=10.251.55.100
fromuser=my_unique_id
secret=my_special_secret
context=incoming_calls
dtmfmode=rfc2833
disallow=all
allow=gsm
allow=ulaw
deny=0.0.0.0/0
permit=10.251.55.100/32
insecure=invite

Configuring a Local Firewall

If you’re running iptables on the same machine as the Asterisk box, then you can run the following commands to open port 5060 for SIP signaling, and ports 10,000 through 20,000 for the RTP traffic. You can also narrow the range of RTP ports in the rtp.conf file located in /etc/asterisk. An excellent book on iptables firewalls is Linux Firewalls by Steve Suehring and Robert Ziegler (Novell Press).

# iptables -I RH-Firewall-1-INPUT -p udp --dport 5060 -j ACCEPT
# iptables -I RH-Firewall-1-INPUT -p udp --dport 10000:20000 -j ACCEPT
#service iptables save

Be aware that this will allow all UDP traffic from any source access to ports 5060 and 10,000 through 20,000.

Most of the previous configuration may be familiar to you by now, but in case it’s not, here is a brief rundown.

By defining the type as a peer, we are telling Asterisk not to match on the [my_service_provider] name, but rather to match on the IP address in the INVITE message (when the provider is sending us a call). The host parameter is the IP address that we’ll place our calls to, and the IP address we’ll be matching on when receiving a call from the provider.

Matching on Username Instead of IP Address

Some service providers may instead be sending their calls to you via multiple IP addresses, requiring you to create a separate peer account for each IP address. If you don’t know each of these IP addresses, you may need to match on the username instead. The format for the service provider definition needs to only change slightly, but the biggest change to note is that you will need to set the [service_provider_header] as the username your service provider is going to send the call to. We have also changed the type from a peer to a friend, which from the viewpoint of Asterisk creates both a type user and type peer, where the type user will be matched before the peer:

[my_unique_id]
type=friend
host=10.251.55.100
fromuser=my_unique_id
secret=my_special_secret
context=incoming_calls
dtmfmode=rfc2833
disallow=all
allow=gsm
allow=ulaw
insecure=invite

Note that we’ve removed the deny and permit parameters since we may not know the IP addresses the calls will be coming from. If you do happen to know them and still wish to match them, you can add back in the deny and permit(s) for the IP addresses.

The fromuser parameter is going to affect the way our INVITE message is structured when sending the call to the provider. By setting our username in the fromuser parameter, we will modify the From: and Contact: fields of the INVITE when sending a call to the provider. This may be required by the provider if it’s using these fields as part of its authentication routine. You can see the places Asterisk modifies the header in the next two code blocks.

Without the fromuser:

Audio is at 66.135.99.122 port 18154
Adding codec 0x2 (gsm) to SDP
Adding codec 0x4 (ulaw) to SDP
Adding non-codec 0x1 (telephone-event) to SDP
Reliably Transmitting (no NAT) to 10.251.55.100:5060:
INVITE sip:15195915119@10.251.55.100 SIP/2.0
Via: SIP/2.0/UDP 66.135.99.122:5060;branch=z9hG4bK32469d35;rport
From: "asterisk" <sip:asterisk@66.135.99.122>;tag=as4975f3ff
To: <sip:15195915119@10.251.55.100>
Contact: <sip:asterisk@66.135.99.122>
Call-ID: 58e3dfb2584930cd77fe989c00986584@66.135.99.122
CSeq: 102 INVITE
User-Agent: Asterisk PBX
Max-Forwards: 70
Date: Fri, 20 Apr 2007 14:59:24 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Content-Type: application/sdp
Content-Length: 265

With the fromuser:

Audio is at 66.135.99.122 port 11700
Adding codec 0x2 (gsm) to SDP
Adding codec 0x4 (ulaw) to SDP
Adding non-codec 0x1 (telephone-event) to SDP
Reliably Transmitting (no NAT) to 10.251.55.100:5060:
INVITE sip:15195915119@10.251.55.100 SIP/2.0
Via: SIP/2.0/UDP 66.135.99.122:5060;branch=z9hG4bK635b0b1b;rport
From: "asterisk" <sip:my_unique_id@66.135.99.122>;tag=as3186c1ba
To: <sip:15195915119@10.251.55.100>
Contact: <sip:my_unique_id@66.135.99.122>
Call-ID: 0c7ad6156f92e70b1fecde903550a12f@66.135.99.122
CSeq: 102 INVITE
User-Agent: Asterisk PBX
Max-Forwards: 70
Date: Fri, 20 Apr 2007 15:00:30 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Content-Type: application/sdp
Content-Length: 265

The deny and permit statements are used to deny all incoming calls to this peer except the IP address defined by the permit parameter. This is simply a security measure used to make sure nothing else matches on this peer except traffic coming from the IP address we expect.

At the end is insecure=invite, which may be required for your provider. This is because the source of the INVITE may originate from its backend platform, but could be directed through its SIP proxy server. Basically what this means is that the IP address that the peer is coming from, and which you are matching on, may not be the IP address that is in the Contact line: field of the INVITE message when you are accepting a call from your provider. This tells Asterisk to ignore this inconsistency and to accept the INVITE anyway.

Tip

You may need to set invite=invite,port if the port address is also inconsistent with what Asterisk is expecting.

Now we need one additional parameter set in the [general] section of our sip.conf file: register. register is going to tell the service provider where to send calls when it has a call to deliver to us. This is Asterisk’s way of saying to the service provider, “Hey! If you’ve got a call for me, send it to me at IP address 10.251.55.100.” The register parameter takes the following form:

register => username:[e-mail]_provider.tld

Now we just need to configure a simple dialplan to handle our incoming calls and to send calls via the service provider. We’re going to modify the simple dialplan we started building in the Setting Up the Dialplan for Some Test Calls” section of this chapter. The italicized sections are the new parts that we’re adding to the dialplan, with everything else existing previously.^[68]

[globals]

[general]

[default]
exten => s,1,Verbose(1|Unrouted call handler)
exten => s,n,Answer()
exten => s,n,Wait(1)
exten => s,n,Playback(tt-weasels)
exten => s,n,Hangup()

[incoming_calls]
exten => _X.,1.NoOp()
exten => _X.,n,Dial(SIP/1000)

[outgoing_calls]
exten => _X.,1,NoOp()
exten => _X.,n,Dial(SIP/my_service_provider/${EXTEN})

[internal]
exten => 1000,1,Verbose(1|Extension 1000)
exten => 1000,n,Dial(SIP/1000,30)
exten => 1000,n,Hangup()

exten => 500,1,Verbose(1|Echo test application)
exten => 500,n,Echo()
exten => 500,n,Hangup()

[phones]
include => internalinclude => outgoing_calls

---

^[66] Be sure to check the policy of any service provider you are looking to connect with, as some of them may not allow you to use a PBX system with its service.

^[67] Also known as a VoIP Service Provider (VSP).

^[68] We also assume you have configured at least one SIP extension from the previous section.