FreeSWITCH 1.2
上QQ阅读APP看书，第一时间看更新
上一章目录下一章

Connecting to the world with gateways

The counterpart to having a user register to your FreeSWITCH server is to have your server register as a user on a remote server. This is accomplished using gateways. A gateway is quite simply a way to authenticate with another SIP server. This includes authentication challenges to SIP REGISTER attempts as well as INVITE messages. Telephone service providers use very large servers (including some running FreeSWITCH!) to provide SIP trunks to their subscribers. In FreeSWITCH, we can use a gateway to connect to a SIP provider. We can also use a gateway to connect to another SIP server, such as another FreeSWITCH server or any SIP-compliant IP-PBX.

Setting up a new gateway

A gateway simply connects to a SIP server just like a SIP phone connects to FreeSWITCH. As such, a gateway configuration bears some resemblance to a SIP phone configuration. Like a SIP phone registering to FreeSWITCH, a gateway has some minimum requirements. They are as follows:

  • Username and password
  • Server address or IP, and port

These values are supplied by the service provider. Occasionally there are other parameters, like a proxy server and port. If you already have an account with a SIP provider then you can use it for your gateway. In this example, we will use an account from iptel.org.

Tip

Visit http://www.iptel.org/service to sign up for a free SIP account.

To add a new gateway, perform the following steps:

  1. Create a new XML file in conf/sip_profiles/external. This example will use iptel.org.xml. Add the following lines, inserting the proper values for your provider: 
    <include>
 <gateway name="iptel">
  <param name="username" value="MY_USER_NAME"/>
  <param name="password" value="MY_PASSWORD"/>
  <param name="realm" value="iptel.org"/>
  <!-- iptel.org requires a 'proxy' parameter -->
  <param name="proxy" value="sip.iptel.org"/>
 </gateway></include>
  2. Save the file and then launch fs_cli.
  3. Issue the command /log 6 to decrease the verbosity of debug messages.
  4. Simply reloading the XML configuration will not add the new gateway. Issue the following command: sofia profile external restart reloadxml.

    The output will look as follows:

    freeswitch@internal> sofia profile external restart reloadxml
Reload XML [Success]
restarting: external
freeswitch@internal> 2012-09-14 16:29:23.509986 [INFO] mod_enum.c:808 ENUM Reloaded
2012-09-14 16:29:23.511578 [INFO] switch_time.c:661 Timezone reloaded 530 definitions
2012-09-14 16:29:24.118566 [NOTICE] sofia_reg.c:85 UN-Registering iptel
2012-09-14 16:29:24.713768 [NOTICE] sofia.c:1218 Waiting for worker thread
2012-09-14 16:29:24.713768 [NOTICE] sofia_glue.c:3690 deleted gateway example.com
2012-09-14 16:29:24.713768 [NOTICE] sofia_reg.c:2237 Added gateway 'iptel' to profile 'external'
2012-09-14 16:29:24.713768 [NOTICE] sofia_reg.c:2237 Added gateway 'example.com' to profile 'external'
2012-09-14 16:29:24.713768 [NOTICE] sofia.c:3149 Started Profile external [sofia_reg_external]
2012-09-14 16:29:25.736445 [NOTICE] sofia_reg.c:333 Registering iptel
  5. Confirm that the gateway is registered properly. Issue the command sofia status. The output should look similar to the following: 
    freeswitch@internal> sofia status
 Name Type Data State
==============================================================================================
 external profile sip:mod_sofia@10.15.0.91:5080 RUNNING (0)
 example.com gateway sip:joeuser@example.com NOREG
 iptel gateway sip:MY_USER@sip.iptel.org REGED
 internal profile sip:mod_sofia@10.15.0.91:5060 RUNNING (0)
 internal-ipv6 profile sip:mod_sofia@[::1]:5060 RUNNING (0)
 10.15.0.91 alias internal ALIASED
==============================================================================================
3 profiles 1 alias

The gateway's state should be REGED, which means that the registration was successful. If it says something else, like FAIL_WAIT, most likely there is a configuration problem. Confirm your settings and try again.

Tip

Warning: Restarting a profile will disconnect all active calls that are currently routed through that profile. An alternate command to add a newly created gateway without restarting the entire profile is: sofia profile <profile name> rescan reloadxml.

Now that our gateway is added, we need to modify the Dialplan so that we can make and receive calls.

Making calls

We will make a simple Dialplan entry that sends calls out to our new gateway. Our new extension will accept the digit 9 and then the digit 1, followed by exactly 10 more digits representing the telephone number to be dialed. (In a production environment there are many other possible strings, which can even be alphanumeric. Some of these will be considered in Chapter 5, Understanding the XML Dialplan.)

To get started with making outbound calls, add your new extension to the Dialplan, by performing the following steps:

  1. Create a new file in conf/dialplan/default named 01_custom.xml.
  2. Add the following text to the file: 
    <include>
  <extension name=" iptel-outbound">
    <condition field="destination_number" 
      expression="^9(1\d{10})$">
      <action application="bridge" 
        data="sofia/gateway/iptel/$1"/>
    </condition>
  </extension>
</include>
  3. Save the file. Launch fs_cli and press F6 or issue the reloadxml command.

The new extension is now ready to be tested. From a phone that is registered to FreeSWITCH, dial 9 plus a 10-digit phone number. For example, dial 9, 1-800-555-1212. It may take a moment for the call to be established. Confirm that audio is flowing in both directions and that each party can hear the other. If audio is flowing in only one direction, most likely there is a problem with the NAT device on your local network. NAT traversal is discussed in more detail in Chapter 14, Handling NAT.

Receiving calls

Generally, when you register your gateway with a SIP provider, the provider allows you to receive calls. (Telephones that register with FreeSWITCH are an example of this.) In the example configuration, FreeSWITCH treats incoming calls as inherently untrusted, even if they come from the corresponding end of a registered gateway. These calls come into the public Dialplan context. From there they can be discarded or routed as needed. Let's set up a simple Dialplan entry for handling inbound calls to our iptel.org account. This works for any SIP trunk or gateway connection you have created.

  1. Create a new file in conf/dialplan/public named 01_iptel.xml.
  2. Add these lines to the file, using your account name as follows: 
    <include>
  <extension name="iptel-inbound">
    <condition field="destination_number" 
      expression="^(MY_IPTEL_USERNAME)$">)$">
      <action application="set"
        data="domain_name=${domain}"/>
      <action application="bridge" data="1000 XML default"/>
    </condition>
  </extension>
</include>
  3. Save the file. Launch fs_cli and press F6 or issue the reloadxml command.

Be sure to use your actual iptel username. Inbound calls will now be routed to extension 1000. You can route calls to any valid extension, including all the extensions we tested in Chapter 3, Test Driving the Example Configuration.

Making calls without a gateway

Sometimes it is not necessary to use a gateway. For example, not all services require digest authorization. An example of this is the FreeSWITCH public conference server. In fact, the default Dialplan contains an extension for dialing the conference: 9888. (Actually, there are several different conference rooms on the public FreeSWITCH conference server.) Let's look at this extension. Open conf/dialplan/default.xml in an editor and locate the freeswitch_public_conf_via_sip extension. Note the bridge line:

<action application="bridge"
  data="sofia/${use_profile}/$1@conference.freeswitch.org"/>

In the example configuration, the value in ${use_profile} is set to internal (as defined in conf/vars.xml). When a user dials 9888 the dialstring that is sent out is actually as follows:

sofia/internal/888@conference.freeswitch.org

Notice that there is no mention of a gateway. Instead, FreeSWITCH simply sends the call out to the internal SIP profile. In other words, the local FreeSWITCH server sends a call to conference.freeswitch.org without actually authorizing it. This is possible because the server at conference.freeswitch.org does not require authorization for incoming calls. (This is where the gateway comes in—if the target server issues a challenge then the gateway will respond to that challenge with authorization credentials, namely the username and password.)

Not all SIP providers explicitly require digest authorization of calls; some perform IP authorization instead. In those cases you do not need to create a gateway. Instead, simply send the call out to a SIP profile. Usually, the internal SIP profile is sufficient for these kinds of calls.

上一章目录下一章