Shared Line Appearances
In Asterisk, Shared Line Appearances (SLA)—sometimes also referred to in the industry as Bridged Line Appearances (BLA)—can be used. This functionality can be used to satisfy two primary use cases, which include emulating a simple key system and creating shared extensions on a PBX.
Building key system emulation is what these applications were primarily designed for. In this environment, you have some small number of trunks coming into the PBX, such as analog phone lines, and each phone has a dedicated button for calls on that trunk.
You may refer to these trunks as line 1, line 2, and line 3, for example.
Another use case is for creating shared extensions on your PBX. This use case seems to be the most common these days. There are many reasons you might want to do this; for example, you may want an extension to appear on the phones of both an executive and her administrative assistant. Another example would be if you want the same extension to appear on all the phones in the same lab.
Installing the SLA Applications
The SLA applications are built on two key technologies in Asterisk. The first is device state processing, and the second is conferencing. Specifically, the conferencing used by these applications is the MeetMe() application. The SLA applications come with the same module as the MeetMe() application, so you must install the app_meetme module.
You can check at the Asterisk CLI to see if you already have the module:
pbx*CLI> module show like app_meetme.so
Module Description user count
0 modules loaded
In this case, the module is not present. The most common reason an Asterisk system would not have the app_meetme module is if DAHDI had not been installed. The MeetMe() application uses DAHDI to perform conference mixing.
Once DAHDI is installed , rerun the Asterisk configure script, recompile with make, and reinstall with sudo make install. Once the module has been properly installed (you can use module load app_meetme.so from the Asterisk console), you should be able to see it at the CLI:
*CLI> module show like app_meetme.so
Module
app_meetme.so Description user count
1 modules loaded MeetMe conference bridge 0
Once the app_meetme module is loaded, you should have both the SLAStation() and SLATrunk() applications available:
*CLI> core show applications like SLA
-= Matching Asterisk Applications =-
SLAStation: Shared Line Appearance Station.
SLATrunk: Shared Line Appearance Trunk.
-= 2 Applications Matching =-
Configuration Overview
The two main configuration files that must be edited to set up SLA are /etc/asterisk/ extensions.conf and /etc/asterisk/sla.conf. The sla.conf file is used for defining trunks and stations. A station is any SIP phone that will be using SLA. Trunks are the literal trunks
or shared extensions that will be appearing on two or more stations. The Asterisk dialplan, extensions.conf, provides some important glue that pulls an SLA configuration together. The dialplan includes some extension state hints and extensions that define
how calls get into and out of an SLA setup. The next few sections provide detailed examples of the configuration for a few different use cases.
Key System Example with Analog Trunks
This usage of SLA comes with the simplest configuration. This scenario would typically be used for a fairly small installation, where you have a few analog lines and SIP phones that all have line keys directly associated with the analog lines. For the purposes of this example, we will say we have two analog lines and four SIP phones. Each SIP phone will have a button for line1 and a button for line2 . This section will assume that you have done some configuration up front, including:
• Configuring the four SIP phones. For more information on setting up SIP phones.
• Configuring the two analog lines. Fore more information on setting up analog lines with Asterisk.
For this example, we will use the following device names for the SIP phones and analog lines. Be sure to adapt the examples to match your own configuration:
• SIP/station1
• SIP/station2
• SIP/station3
• SIP/station4
• DAHDI/1
• DAHDI/2
sla.conf
As mentioned previously, sla.conf contains a configuration that maps devices to trunks and stations. For this example, we will start by defining the two trunks:
[line1]
type = trunk
device = DAHDI/1
[line2]
type = trunk
device = DAHDI/2
Next, we will set up the station definitions. We have four SIP phones, which will each use both trunks. Note that the section names in sla.conf for stations do not need to match the SIP device names, but it is done that way here for convenience:
[station1]
type = station
device = SIP/station1
trunk = line1
trunk = line2
[station2]
type = station
device = SIP/station2
trunk = line1
trunk = line2
[station3]
type = station
device = SIP/station3
trunk = line1
trunk = line2
[station4]
type = station
device = SIP/station4
trunk = line1
trunk = line2
The station configuration is a bit repetitive. Asterisk configuration-file template sections come in handy here to collapse the configuration down a bit. Here is the station configuration again, but this time using a template:
[station](!)
type = station
trunk = line1
trunk = line2
[station1](station)
device = SIP/station1
[station2](station)
device = SIP/station2
[station3](station)
device = SIP/station3
[station4](station)
device = SIP/station4
After making changes to sla.conf and saving them, be sure to reload the app_meetme.so module in order for the changes to take effect. You can do this with module reload app_meetme.so from the Asterisk console.
extensions.conf
The next configuration file required for this example is /etc/asterisk/extensions.conf. There are three contexts. First, we have the line1 and line2 contexts. When a call comes in on one of the analog lines, it will come in to one of these contexts in the dialplan and
execute the SLATrunk() application. This application will take care of ringing all of the appropriate stations:
[line1]
exten => s,1,SLATrunk(line1)
[line2]
exten => s,1,SLATrunk(line2)
The next section of the dialplan is the sla_stations context. All calls from the SIP phones should be sent to this context. Further, the SIP phones should be configured so that as soon as they go off-hook, they immediately make a call to the station1 extension (or station2 , station3 , etc., as appropriate). If the line1 key on the phone is pressed, a call should be sent to the station1_line1 extension (or station2_line1 , etc.).
Any time that a phone goes off-hook or a line key is pressed, the call that is made will immediately connect it to one of the analog lines. For a line that is not already in use, the analog line will be providing a dialtone, and the user will be able to send digits to make a call. If a user presses a line key for a line that is already in use, that user will be bridged into the existing call on that line. The sla_stations context looks like this:
[sla_stations]
exten => station1,1,SLAStation(station1)
exten => station1_line1,hint,SLA:station1_line1
exten => station1_line1,1,SLAStation(station1_line1)
exten => station1_line2,hint,SLA:station1_line2
exten => station1_line2,1,SLAStation(station1_line2)
exten => station2,1,SLAStation(station2)
exten => station2_line1,hint,SLA:station2_line1
exten => station2_line1,1,SLAStation(station2_line1)
exten => station2_line2,hint,SLA:station2_line2
exten => station2_line2,1,SLAStation(station2_line2)
exten => station3,1,SLAStation(station3)
exten => station3_line1,hint,SLA:station3_line1
exten => station3_line1,1,SLAStation(station3_line1)
exten => station3_line2,hint,SLA:station3_line2
exten => station3_line2,1,SLAStation(station3_line2)
exten => station4,1,SLAStation(station4)
exten => station4_line1,hint,SLA:station4_line1
exten => station4_line1,1,SLAStation(station4_line1)
exten => station4_line2,hint,SLA:station4_line2
exten => station4_line2,1,SLAStation(station4_line2)
After making your changes, be sure to reload your dialplan with dialplan reload.
Additional phone configuration tasks
The previous section covered the dialplan for trunks and stations. There are some specific things to keep in mind when setting up phones for use with this setup. First, each phone should be configured to send a call as soon as it is taken off-hook.
The other important item is the configuration of the line keys. Asterisk uses extension state subscriptions to control the LEDs next to the line buttons. Beyond that, each line key should be configured as a speed dial. Use the following checklist for your line key configuration (how you accomplish these tasks will depend on the specific phones you are using):
• Set the label of the key to be Line 1 (etc.), or whatever you deem appropriate.
• Set up the keys so that the Line 1 key on station1 subscribes to the state of station1_line1 , and so on. This is required so Asterisk can make the LEDs reflect the state of the lines.
• Ensure that if the Line 1 key on station1 is pressed, a call is sent to the station1_line1 extension, and so on.
Key System Example with SIP Trunks
This example is intended to be identical in functionality to the previous example. The difference is that instead of using analog lines as trunks, we will use a connection to a SIP provider that will terminate the calls to the PSTN. For more information on setting up Asterisk to connect to a SIP provider.
sla.conf
The sla.conf file for this scenario is a bit tricky. 3 You might expect to see the device line in the trunk configuration have a SIP channel listed, but instead we’re going to use a Local channel. This will allow us to use some additional dialplan logic for call processing. The purpose of the Local channel will become clearer in the next section, when the dialplan example is discussed. Here are the trunk configurations:
[line1]
type = trunk
device = Local/disa@line1_outbound
[line2]
type = trunk
device = Local/disa@line2_outbound
The station configuration is identical to the last example, so let’s get right to it:
[station](!)
type = trunk
trunk = line1
trunk = line2
[station1](station)
device = SIP/station1
[station2](station)
device = SIP/station2
[station3](station)
device = SIP/station3
[station4](station)
device = SIP/station4
extensions.conf
As in the last example, you will need line1 and line2 contexts to process incoming calls on these trunks:
[line1]
exten => s,1,SLATrunk(line1)
;
; If the provider specifies your phone number when sending you
; a call, you will need another rule in the dialplan to match that.
;
exten => _X.,1,Goto(s,1)
[line2]
exten => s,1,SLATrunk(line2)
exten => _X.,1,Goto(s,1)
This example requires an sla_stations context, as well. This is for all calls coming from the phones. It’s the same as it was in the last example:
[sla_stations]
exten => station1,1,SLAStation(station1)
exten => station1_line1,hint,SLA:station1_line1
exten => station1_line1,1,SLAStation(station1_line1)
exten => station1_line2,hint,SLA:station1_line2
exten => station1_line2,1,SLAStation(station1_line2)
exten => station2,1,SLAStation(station2)
exten => station2_line1,hint,SLA:station2_line1
exten => station2_line1,1,SLAStation(station2_line1)
exten => station2_line2,hint,SLA:station2_line2
exten => station2_line2,1,SLAStation(station2_line2)
exten => station3,1,SLAStation(station3)
exten => station3_line1,hint,SLA:station3_line1
exten => station3_line1,1,SLAStation(station3_line1)
exten => station3_line2,hint,SLA:station3_line2
exten => station3_line2,1,SLAStation(station3_line2)
exten => station4,1,SLAStation(station4)
exten => station4_line1,hint,SLA:station4_line1
exten => station4_line1,1,SLAStation(station4_line1)
exten => station4_line2,hint,SLA:station4_line2
exten => station4_line2,1,SLAStation(station4_line2)
The last piece of the dialplan that is required is the implementation of the line1_out bound and line2_outbound contexts. This is what the SLA applications use when they want to send calls out to a SIP provider. The key to this setup is the usage of the Read() application. In the last example, phones were directly connected to an analog line, al‐ lowing the upstream switch to provide a dialtone, collect digits, and complete the call.
In this example, we use the Read() application locally to provide a dialtone and collect digits. Normally the Read() application would play a sound file, but with the use of the i option, we can specify which indication to play from the indications.conf file. In this case, we’ll use dial , which plays a dialtone. The number dialed will be saved to the Request channel variable, and we’ll stop collecting digits either after a timeout, or after a maximum of 11 digits have been dialed.
Once a complete number has been dialed, the call will proceed to go out to a SIP provider:
[line1_outbound]
exten => disa,1,NoOp()
same => n,Read(Request,dial,11,i)
same => n,Goto(${Request},1)
; Add extensions for whatever numbers you would like to
; allow to be dialed.
;
exten => _1NXXNXXXXXX,1,Dial(SIP/${EXTEN}@myprovider)
[line2_outbound]
exten => disa,1,NoOp()
same => n,Read(Request,dial,11,i)
same => n,Goto(${Request},1)
exten => _1NXXNXXXXXX,1,Dial(SIP/${EXTEN}@myprovider)
Alternate Key System Example with SIP Trunks
In order to help demonstrate some of the flexibility with regard to line configuration, we’ll show an example of implementing line key functionality with SIP trunks and stations. We’ll be using the same concepts as in the previous sections, so it might be useful to review those before continuing. What we’ll be building could be described as a sort of hybrid model, in that we’ll have a single registration line that can be used just like a standard line on your Asterisk system. It won’t have any limitations to its functionality, including the ability to transfer calls. The additional lines we’ll define will act more like the traditional SLA system in that transfers are not possible, but the sharing of trunks will be possible.
For our example, we’ll be defining separate lines for each of our stations in sla.conf. This alternative method lets us subscribe line keys on our phone to each of the different lines that have been defined. First, we define our trunks as we have previously (slightly modified, however):
[T1] ; Line 1
type=trunk
device=Local/trunk1@sla_trunks/n
[T2] ; Line 2
type=trunk
device=Local/trunk2@sla_trunks/n
We then need to define our lines, which we’ll associate with the phones. In order not to be overly verbose, we’ll be defining lines for two stations and two lines for each:
[L1-0000FFFF0005] ; Line 1
type=station
device=SIP/0000FFFF0005
trunk=T1
[L2-0000FFFF0005] ; Line 2
type=station
device=SIP/0000FFFF0005
trunk=T2
[L1-0000FFFF0006] ; Line 1
type=station
device=SIP/0000FFFF0006
trunk=T1
[L2-0000FFFF0006] ; Line 2
type=station
device=SIP/0000FFFF0006
trunk=T2
As you can see, there are four stations defined, from the viewpoint of Asterisk. We’ve logically separated each of the trunks into separate line keys that can be subscribed to from any device. It is implied here that our stations are SIP/0000FFFF0005 and SIP/ 0000FFFF0006 and they will each contain two line keys that associate with trunks T1 and T2 . After making our changes to sla.conf we must be sure to reload app_meetme.so with module reload app_meetme.so from the Asterisk console.
Next is to configure our dialplan. We’ll add to the existing LocalSets context since we want the phones to be able to place calls normally in addition to using the SLA line keys. In our example, we’ll just show the parts relevant to SLA:
[LocalSets]
include => SLA_Outbound
exten => L1-0000FFFF0005_T1,hint,SLA:L1-0000FFFF0005_T1
exten => L2-0000FFFF0005_T2,hint,SLA:L2-0000FFFF0005_T2
exten => L1-0000FFFF0006_T1,hint,SLA:L1-0000FFFF0006_T1
exten => L2-0000FFFF0006_T2,hint,SLA:L2-0000FFFF0006_T2
Here we’ve included a new context called SLA_Outbound that will process requests made by the phone when the line key is pressed. We’ve included our SLA hints as well, which will be used by the SLA dialplan applications to control the line-key lights.
Now let’s add the SLA_Outbound context:
[SLA_Outbound]
exten => _LX!,1,NoOp()
same => n,SLAStation(${EXTEN})
same => n,Hangup()
And we’ll also need the sla_trunks context, which is used to actually place the outbound calls. We defined what is using this context earlier in the sla.conf file when we created our trunks.
[sla_trunks]
exten => _tru[n]kX,1,NoOp()
same => n,Read(Request,dial,10,i)
same => n,Dial(SIP/my_itsp/${Request})
The last bit of dialplan we need to add is for inbound calls for the SLA trunks. We can add this with the following bit of dialplan:
[SLA_Inbound]
exten => _LX!,1,NoOp()
same => n,Set(slaLineId=${EXTEN:1:1})
same => n,SLATrunk(T${slaLineId})
same => n,Hangup()
After making changes to extensions.conf you’ll want to perform a dialplan reload from the Asterisk console.
At this point, we’ve completed the configuration of Asterisk for SLA usage, but configuration of the phones is really the trickiest part. We can’t really delve into the configuration of every manufacturer, but we can at least give you a starting point. On the Polycom phones (tested with Soundpoint IP450 and Soundpoint IP650), you can use the attendant configuration in order to create line keys that subscribe to the state of the SLA hints we created. When placing calls via these lines, they use the first line key defined for the phone, so you will actually have three line keys configured. The first line key will be the standard one that can perform transfers and other standard functionality. The other two line keys will act like SLA lines.
A sample configuration we used in the lab looks like the following. This might give you enough data to get started:
<?xml version=”1.0″ encoding=”UTF-8″ standalone=”yes”?>
<!– Generated reg-basic.cfg Configuration File –>
<polycomConfig xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”
xsi:noNamespaceSchemaLocation=”polycomConfig.xsd”>
<call call.callsPerLineKey=”24″>
</call>
<reg reg.1.address=”0000FFFF0005″
reg.1.auth.password=”welcome”
reg.1.auth.userId=”0000FFFF0005″
reg.1.label=”ATDG5″
reg.1.lineKeys=”1″
reg.1.outboundProxy.address=””>
</reg>
<attendant
attendant.reg=”1″
attendant.behaviors.display.spontaneousCallAppearances.normal=”1″
attendant.behaviors.display.remoteCallerID.normal=”1″
attendant.resourceList.1.address=”L1-0000FFFF0005_T1″
attendant.resourceList.1.label=”L1″
attendant.resourceList.1.type=”normal”
attendant.resourceList.2.address=”L2-0000FFFF0005_T2″
attendant.resourceList.2.label=”L2″
attendant.resourceList.2.type=”normal”
/>
</polycomConfig>
Shared Extension Example
The previous two examples were for small key system emulation. For this example, we’ll try something quite different. Many PBX vendors offer the ability to have the same extension shared across multiple phones. This is not simply a matter of having multiple phones ring when an extension is called: it is deeper integration than that. The behavior of the line key for a shared extension is similar to that of a line key on a key system. For example, you can simply put a call on hold from one phone and pick it up from another. Also, if multiple phones press the key for the shared extension, they will all be bridged into the same call. That is why this functionality is often also referred to as Bridged Line Appearances (BLA).
In the previous two examples, we had two trunks and four stations. For this example, we’re going to set up a single shared extension on two phones. The shared extension will be referred to as extension 5001 .
sla.conf
Every usage of the SLA applications requires trunk and station definitions. This example, like the previous ones, will be making use of the Read() application, and the sla.conf file will look very similar:
[5001]
type = trunk
device = Local/disa@5001_outbound
[5001-phone1]
device = SIP/5001_phone1
trunk = 5001
[5001-phone2]
device = SIP/5001_phone2
trunk = 5001
extensions.conf
The first part of the dialplan required is what will be executed when extension 5001 is dialed on the PBX. Normally, to call a phone you would use the Dial() application. In this case, we’re going to use the SLATrunk() application. This will take care of ringing
both phones and keeping them bridged together:
exten => 5001,1,SLATrunk(5001)
Next, we will need a context that will be used for making outbound calls from this shared extension. This assumes that 5001_phone1 and 5001_phone2 have been configured with their context options set to 5001 in sip.conf:
[5001]
;
; This extension is needed if you want the shared extension to
; be used by default. In that case, have this extension dialed
; when the phone goes off-hook.
;
exten => 5001-phone1,1,SLAStation(5001-phone1)
;
; This is the extension that should be dialed when the 5001 key is
; pressed on 5001_phone1.
;
exten => 5001-phone1_5001,hint,SLA:5001-phone1_5001
exten => 5001-phone1_5001,1,SLAStation(5001-phone1_5001)
exten => 5001-phone2,1,SLAStation(5001-phone2)
exten => 5001-phone2_5001,hint,SLA:5001-phone2_5001
exten => 5001-phone2_5001,1,SLAStation(5001-phone2_5001)
Finally, we need an implementation of the 5001_outbound context. This will be used to provide a dialtone and collect digits on the bridged line:
[5001_outbound]
exten => disa,1,Read(Request,dial,,i)
same => n,Goto(${Request},1)
;
; This context will also need to be able to see whatever
; extensions you would like to be reachable from this extension.
;
include => pbx_extensions
Additional Configuration
The /etc/asterisk/sla.conf file has some optional configuration parameters that were not used in any of the examples in this chapter. To give you an idea of what other behavior can be configured, the options are covered here. This file has a [general] section that is reserved for global configuration options. Currently, there is only a single option that can be specified in this section:
attemptcallerid = yes
This option specifies whether or not the SLA applications should attempt to pass caller ID information. It is set to no by default. If this is enabled, the display of the phones may not be what you would expect in some situations. The trunk definitions in the previous examples only specified the type and device. Here are some additional options that can be specified for a trunk:
autocontext = line1
If this option is set, Asterisk will automatically create a dialplan context using this name. The context will contain an s extension that executes the SLATrunk() application with the appropriate argument for this trunk. By default, all dialplan entries must be created manually.
ringtimeout = 20
This option allows you to specify the number of seconds to allow an inbound call on this trunk to ring before the SLATrunk() application will exit and consider it an unanswered call. By default, this option is not set.
barge = no
The barge option specifies whether or not other stations are allowed to join a call that is in progress on this trunk by pressing the same line button. Barging into a call on a trunk is allowed by default.
hold = private
The hold option specifies hold permissions for this trunk. If this option is set to open , any station can place this trunk on hold and any other station is allowed to take it back off hold. If this option is set to private , only the station that placed the trunk on hold is allowed to take it back off hold. This option is set to open by default.
When we defined the stations in the previous examples, we only supplied the type , device , and a list of trunks. However, station definitions accept some additional configuration options as well. They are listed here:
autocontext = sla_stations
If this option is specified, Asterisk will automatically create the extensions required for calls coming from this station in the context specified. This is off by default, which means that all extensions must be specified manually.
ringtimeout = 20
A timeout may be specified in seconds for how long this station will ring before the \ call is considered unanswered. There is no timeout set by default.
ringdelay = 5
A ring delay in seconds can be specified for a station. If a delay is specified, this station will not start ringing until this number of seconds after the call first came in on this shared line. There is no delay set by default.
hold = private
Hold permissions can be specified for a specific station as well. If this option is set to private , any trunks put on hold by this station can only be picked back up by this station. By default, this is set to open .
trunk = line1,ringtimeout=20
A ringtimeout can be applied to calls coming from only a specific trunk.
trunk = line1,ringdelay=5
A ringdelay can also be applied to calls from a specific trunk.
Limitations
While Asterisk makes many things easy, SLA is not one of them. This functionality was intended to emulate simple features, but the configuration required to make it work is fairly complex. Someone who is new to Asterisk and only wants a simple key-system setup will have to learn a lot of complex Asterisk and SIP phone concepts to get it working.
Another feature that still needs some development before it will work seamlessly with SLA is caller ID. At the time that this functionality was written, Asterisk did not have the appropriate infrastructure in place to be able to update caller ID information throughout the duration of the call. Based on how this functionality is implemented, this infrastructure is required to make the display on the phones useful. It does exist as of Asterisk 1.8, but the SLA applications have not yet been updated to use it. The end
result is that you can either have no caller ID information at all, or you can enable it and understand that the phone displays are not always going to display correctly as changes happen throughout the duration of a call.
Another limitation, most relevant to usage of shared extensions, is that transfers do not work. The main reason is that transfers generally involve putting a call on hold for a short time. Call hold is processed in a special way with SLA, in that the held call is not controlled by the phone that initiated the hold. This breaks transfer processing.
In summary, SLA is not necessarily simple to set up, and it comes with some significant limitations. With that said, if what does exist suits your needs, by all means go for it.
Creating a Callback Service
After a call has failed due to the destination being busy or otherwise unavailable, a callback service lets you give the caller the option to be called back automatically when the destination becomes available. Call Completion Supplementary Services (CCSS) allows you to request that Asterisk call you back after an unanswered or busy call attempt. This section shows how to enable this feature for use between phones connected to the same Asterisk system.
For this example we will enable this service for two SIP phones. To do so, add the following to /etc/asterisk/sip.conf:
[phone1]
…
cc_agent_policy = generic
cc_monitor_policy = generic
[phone2]
…
cc_agent_policy = generic
cc_monitor_policy = generic
Now add the following extensions to the dialplan:
[phones]
;
; The extensions for dialing phones do not need to be changed.
; These are just simple examples of dialing a phone with a
; 20-second timeout.
;
exten => 7101,1,Dial(SIP/phone1,20)
same => n,Hangup()
exten => 7102,1,Dial(SIP/phone2,20)
same => n,Hangup()
;
; Dial *30 to request call completion services for the last
; call attempt.
;
exten => *30,1,CallCompletionRequest()
same => n,Hangup()
;
; Dial *31 to cancel a call completion request.
;
exten => *31,1,CallCompletionCancel()
same => n,Hangup()
In this example, we have used the generic agent and monitor policies. This method of configuration is the easiest to get working, but it only works for calls between phones connected to the same Asterisk system. The agent is the part of the system that operates
on behalf of the caller requesting call-completion services. The monitor is the part of the system in charge of monitoring the device (or devices) that were called to determine when they become available.
Using this dialplan, let’s go through an example where CCSS is used. We’ll start by having 7001 call 7002 , but we’ll let the call time out after the configured 20 seconds. In this case, the call has failed due to no response. The caller, 7001 , can now request CCSS by dialing *30 . This is referred to as Call Completion No Response (CCNR). You can verify the CCNR request at the Asterisk CLI:
*CLI> cc report status
1 Call completion transactions
Core ID Caller Status
20 SIP/Phone1 CC accepted by callee
|–>7102@phones
|–>SIP/phone2(CCNR)
At this point, Asterisk is using its generic monitor implementation to wait for SIP/ phone2 to become available. In the case of CCNR, it determines availability by waiting for the phone to make a call. When that call ends, Asterisk will initiate a call between SIP/phone1 and SIP/phone2 , and the CCNR request will have been completed. Another scenario is Call Completion Busy Subscriber (CCBS). This is the case when the called party is already on the phone. Requesting call-completion services in this scenario works the same as before. The generic monitor will determine availability by waiting for the call that the device is on to end.
Asterisk also supports extending CCSS across multiple servers using either SIP or ISDN (specifically ISDN in Europe). However, the configuration and operation of the protocol-specific methods is outside the scope of this recipe. For more information about using CCSS with Asterisk, see the sample Asterisk configuration files, as well as the information on the Asterisk wiki.
