Page 86 / 286 Scroll up to view Page 81 - 85
Configuring Phone Lines and Calling Routing Behavior
Call Transfer Support on SPA9000
SPA9000 Voice System Administration Guide
84
4
Call Transfer Support on SPA9000
You can configure the bridge mode for call forward and call transfer.
Call Forward Bridge Mode
The normal way of performing the call forwarding operation is for the SPA9000 to
send a (blind) SIP REFER to the calling device to let it contact the target number
directly. It then drops out of the call completely. This requires the calling device to
understand the SIP signaling involved and the operation permitted by the
underlying service provider. The SPA400 cannot handle this operation.
With bridging, the SPA9000 maintains two separate call legs throughout the call:
one with the caller and one with the call forward target. The two call peers
connect only with the SPA9000, while the SPA9000 acts as a proxy for the RTP
packets exchanged between the two parties. On the
Voice > Line N
page,
Proxy
and Registration
section, the
CWFD Bridge Mode
field has two possible values:
none—Do not bridge forwarded calls (use the normal REFER method)
all—Bridge all forwarded calls
Call Transfer Bridge Mode
The normal way of performing this operation is for the SPA9000 to send a SIP
REFER method to the calling device to let it contact the transfer target directly. The
SPA9000 then drops out of the call completely. This requires the calling device
(the transferee) and the target device to understand the SIP signaling involved and
the operation permitted by the underlying service providers. Note that the call
legs with transferee and the transfer target might be with different ITSP. The
SPA400, for instance, cannot handle this operation.
With bridging, the SPA9000 maintains two separate call legs throughout the call:
one with the transferred call and one with the transfer target. The two call peers
connect only with the SPA9000, while the SPA9000 acts as a proxy for the RTP
packets exchanged between the two parties. On the
Voice > Line N
page,
Proxy
and Registration
section, the
XFER Bridge Mode
field has three possible values:
none: Do not bridge call transfer (use the normal REFER method)
all: Bridge all call transfer
all except same line: Bridge call transfer only between different line interfaces
Downloaded from
www.Manualslib.com
manuals search engine
Page 87 / 286
Configuring Phone Lines and Calling Routing Behavior
Managing Inbound Calls with the Contact List
SPA9000 Voice System Administration Guide
85
4
Managing Inbound Calls with the Contact List
You can use the Contact List to route inbound calls to the Auto Attendant, to a
receptionist, to a client station, to a group of stations, or to a combination of these.
“Routing an Inbound Call to the Auto Attendant,” on page 85
“Routing an Inbound Call to a Receptionist or Client Stations,” on page 85
“Example Contact List Rules,” on page 86
“Entering a Contact List Rule,” on page 91
Routing an Inbound Call to the Auto Attendant
By default, all inbound calls are routed to the Auto Attendant (
aa
). This automated
system answers inbound calls by playing pre-recorded voice message that asks
the caller to enter the desired extension. If you want only the Auto Attendant to
receive a call, keep the default setting,
aa
, in the
Contact List
field on the
Voice >
Line N
page,
Subscriber Information
section, for each line interface. For more
information, see
Chapter 7, “Configuring the Auto Attendant.”
Routing an Inbound Call to a Receptionist or Client Stations
You can route an inbound call to a receptionist or to client stations by using a
Contact List. You specify the Contact List for each line interface (Line 1, Line 2, Line
3, Line 4). For example, if Line1 is configured for an ITSP account, and a call is
placed to a Direct Inward Dialing (DID) number for that account, then the call is
routed to the Contact List that is specified on the Line 1 configuration page.
Likewise, if Line 2 is configured for a SPA400 that has PSTN lines attached, and a
call is placed to the associated PSTN phone number, then the call is routed as
specified in the
Voice > Line
page,
Subscriber Information
section,
Contact List
field.
Downloaded from
www.Manualslib.com
manuals search engine
Page 88 / 286
Configuring Phone Lines and Calling Routing Behavior
Managing Inbound Calls with the Contact List
SPA9000 Voice System Administration Guide
86
4
Example Contact List Rules
The following examples show rules that you can enter to route incoming calls.
NOTE
The SPA9000 alerts all registered clients stations if * is used in the Contact List
(
SPA9000 Voice > Line N
page >
Subscriber Information
section).
Routing calls to a receptionist
EXAMPLE:
100
An incoming call to any DID number on this line interface causes station 100 to
ring. The receptionist answers the call. If the call is not answered, it
automatically goes to the voice mailbox for station 100, assuming that voice
mail is configured.
Routing calls simultaneously to two or more stations
EXAMPLE:
100, 104
An incoming call to any DID number on this line interface causes station 100
and station 104 to ring. Either station can answer the call.
NOTE
The list of extension numbers may include * to represent multiple wildcard
characters or ? to represent a single wildcard character. For example, 10?
represents all stations numbered 100 through 109.
Special routing for different DID numbers
EXAMPLE:
9725550155:100|9725550156:101, 102
An incoming call to 972-555-0155 causes station 100 to ring. An incoming call
to 972-555-0156 causes station 101 and station 102 to ring simultaneously.
NOTE
In this example, the rules are separated by a pipe character (|) to indicate an
“or” condition.
Downloaded from
www.Manualslib.com
manuals search engine
Page 89 / 286
Configuring Phone Lines and Calling Routing Behavior
Managing Inbound Calls with the Contact List
SPA9000 Voice System Administration Guide
87
4
Routing calls to a station and forwarding unanswered calls to voice mail
EXAMPLE 1:
5300, cfwd=vm25300
An incoming call through this line interface causes station 5300 to ring. If there
is no answer, the call is forwarded to the voice mail server on line interface 2,
mailbox number 5300. The time interval is determined by the value
Cfwd No
Ans Delay
field, which is located below the
Contact List
field on the
Voice >
Line
page. The default value is 20 seconds.
EXAMPLE 2:
4085550122:5001|4085550123:5000,cfwd=aa
An incoming call to 408-555-0122 causes station 5001 to ring. An incoming call
to 408-555-0123 causes station 5000 to ring. If station 5000 does not answer
its call, the call is forwarded to the Auto Attendant. The time interval is
determined by the value
Cfwd No Ans Delay
field, which is located below the
Contact List
field. The default value is 20 seconds.
Routing a call with a hunt rule
EXAMPLE:
530?,hunt=ra;10;2,cfwd=vm25404
An incoming call through this line interface causes one station in the group
5300 through 5309 to ring. The station is chosen randomly (
ra
). After 10
seconds, if the call is unanswered, then another station is chosen randomly
from the remaining stations. The system cycles through the list two times. If the
call is unanswered, it is forwarded to the voice mail server on line interface 2,
mailbox 5404.
NOTE
A hunt rule in the contact list applies only to calls on the selected line
interface. You also can create hunt groups that apply to all lines. For more
information and additional examples of syntax that can be used in a hunt rule
in the Contact List, see
“Managing Inbound Calls with Hunt Groups,” on
page 92
.
Supporting Multiple DID Numbers Per Line Interface
An ITSP can provide a block of DID numbers, for example with a main number of
4085553000, and additional DID numbers from 4085553001–4084443009. The
ITSP can identify the local client stations to which an external incoming call should
be routed. Linksys recommends including this information in the TO header of the
incoming INVITE while the request-URI is addressed to the line interface user-id. In
the INVITE, the ITSP indicates the DID number in the TO header user-id field.
Downloaded from
www.Manualslib.com
manuals search engine
Page 90 / 286
Configuring Phone Lines and Calling Routing Behavior
Managing Inbound Calls with the Contact List
SPA9000 Voice System Administration Guide
88
4
EXAMPLE SIP Header 1:
INVITE sip:[email protected] SIP/2.0
Alternatively, the DID number can be indicated as a parameter in the TO header
with a configurable parameter name, such as
didn
.
EXAMPLE SIP Header 2:
INVITE sip:[email protected] SIP/2.0
To: <sip:[email protected]>;didn=4089993003
You can identify the field to use for the DID number and the parameter name on the
Voice > SIP
page,
PBX Parameters
section,
SIP DIDN
and
SIP DIDN Param
Name
fields. For the first example above, these two fields are ignored; for the
second example, SIP DIDN is set to
TO Param
and SIP DIDN Param Name is set to
didn
.
The Contact List is used to route the calls to a client station based on DID numbers
that are embedded in the INVITE message.
EXAMPLE Contact List Rule:
4089993000:aa|4089993001:3001|4089993002:3002|…|4089993009:3
009
An incoming call to the main number is answered by the Auto-Attendant, while
calls to the other nine DID numbers are routed to dedicated private extensions.
Supporting Direct Inward Dialing to Phone Extensions
Direct Inward Dialing allows the external users to dial directly any phone extension
in the SPA9000 Voice System, without passing through the Auto Attendant or the
receptionist.
Before proceeding with the configuration you need to have the full
correspondence between the external (DID) number and the extension number.
Table 1, “DID-to-Extension Mapping Example,” on page 89
provides an example.
Downloaded from
www.Manualslib.com
manuals search engine

Rate

3.5 / 5 based on 2 votes.

Bookmark Our Site

Press Ctrl + D to add this site to your favorites!

Share
Top