SRST Features

SRST supports numerous features that are fairly intuitive. For example, you can configure the SRST gateway to play a secondary dial tone after a caller dials the access code, to mimic the behavior of CallManager, using the secondary-dialtone digit command. This section details the configuration of the less intuitive SRST features.

Auto Attendant

Auto attendant (AA) functionality in SRST is provided using a Tcl script. Existing AA scripts are available on Cisco.com for both SRST and CallManager Express (CME). Obtaining and applying Tcl scripts is described in detail in Chapter 14, "DSP Resources." If the router has a Cisco Unity Express (CUE) module, you can also use that to provide AA functionality.

Maximum Line Appearances

Sometimes the number of extensions on your IP phones might exceed the number of e-phone-dns that the SRST gateway supports. For example, a 3845 supports 720 IP phones but only 960 e-phone-dns. If you have 720 IP phones with two lines each, not all of them will be able to register with the 3845. To prevent multiline IP phones from using all the available e-phone-dns, you can configure a maximum number of lines per model of phone:

limit-dn phone-model max-lines

 

Conferencing

SRST currently supports only ad-hoc three-party conferences. Digital signal processors (DSP) do not handle these audio streams for the conferencesthe gateway mixes them. To enable conferencing, you configure the maximum number of simultaneous conferences you want to support using the max-conferences command.

To initiate a conference, the IP phone must have two lines. If your IP phones do not have two lines, you can use the dual-line keyword on the max-dn configuration:

max-dn 24 [dual-line]

This creates two audio channels for each virtual voice port that is providing support for call waiting and consultative transfer, in addition to conferencing.

If you have IP phones with multiple lines, using the dual-line option on the max-dn command can result in undesirable behavior. If the first line is busy and a call comes in, it hunts to the second channel of the first line instead of hunting to the second line. The huntstop channel command prevents calls from hunting to the second channel.

Transferring Calls

SRST supports transfers to other IP phones that are registered to the gateway. Additional configuration is required to transfer calls to external numbers.

Transfer-Pattern

If you want to allow calls to be transferred to numbers other than IP phones, you must specifically allow these numbers using the transfer-pattern command. A common request is to allow your users to transfer their calls to their mobile phone. To allow this, configure the transfer pattern to allow a specific number or a range of numbers using wildcards, as shown in Example 13-5. You can configure up to 32 transfer patterns.

Miami(config)#call-manager-fallback
!
! Transfer pattern to permit calls to a single long-distance number
!
Miami(config-cm-fallback)#transfer-pattern 918135550199
!
! Transfer pattern to permit calls to a range of local numbers
!
Miami(config-cm-fallback)#transfer-pattern 9555....

 

A transfer pattern allows all IP phones to initiate transfers to the specified numbers. If you want to limit who can initiate transfers to certain numbers, you can accomplish this using COR.

Consultative Transfers

In a blind transfer, the call is connected to the destination prior to the ringing tone. In a consultative transfer, the person who is initiating the transfer is connected to the destination. This allows the transfer initiator to make sure that the recipient is available and willing to accept the transfer. SRST supports four transfer methods that are configured using the transfer-system command. They are as follows:

• Blind Blind uses a Cisco proprietary transfer method and a single line. It is recommended that you use either full-blind or consultative transfers.
• Full-blind Full-blind uses H.450.2 standards to initiate the transfer.
• Full-consult Full-consult uses H.450.2 standards to initiate a consultative transfer. A second line is required for a consultative transfer. If a second line is not available, the transfer is initiated as a full-blind.
• Local-consult Local-consult also uses H.450.2 to initiate a consultative transfer but only for local callsthat is, calls to other IP phones. Calls to nonlocal numbers use blind.

Note

H.450.2 is standard for providing call transfer supplementary services in an H.323 network that is defined by the International Telecommunications Union (ITU).

 

Forwarding Calls

Call forwarding is restricted to local IP phones by default. To allow users to forward their phones to nonlocal numbers, you configure specific numbers or ranges of numbers by using the call-forward command just like you did for transfer patterns.

call-forward pattern number

You can also use the call-forward command to specify where a call should be forwarded if the IP phone is busy or does not answer:

call-forward busy digits
call-forward noan digits [timeout sec]

 

Voice-Mail Integration

Several possibilities exist for providing voice-mail services to IP phones that are registered to an SRST router. The router can be equipped with a CUE module to provide local voice-mail services, or a centralized voice-mail system, such as Unity, can be used.

Integrating with CUE

To effectively integrate with CUE, the IP phones should be configured to use CUE for voice mail whether they are registered with CallManager or the SRST router. You can use Voice Profile for Internet Mail (VPIM) to network up to 500 CUE locations. You can also use VPIM to network CUE and Cisco Unity systems.

For more information on configuring CUE and VPIM networking, refer to Cisco IP Communications Express: CallManager Express with Cisco Unity Express by Cisco Press.

Integrating with a Centralized Voice-Mail System

Several components are involved in configuring voice mail to integrate with a centralized voice-mail system. The first is forwarding the IP phones correctly, which was discussed in the previous section. You also configure the number that the system should dial when the Messages button is pressed:

voicemail digit-string

Depending on your PSTN connectivity, these two steps might be sufficient to support having the centralized voice-mail system answer calls.

If the connection to the PSTN is a BRI or PRI, the voice-mail system routes calls to the correct mailbox by looking at the ANI or Redirected Dialed Number Information Service (RDNIS) fields. If the call is forwarded to the voice-mail system because of no answer or a busy condition, the forwarding phone number is placed in the RDNIS field. If the RDNIS matches a mailbox address in the voice-mail system, the greeting for that mailbox is played, and the caller can leave a message. If the Messages button on the IP phone is pressed, the extension of the phone is placed in the ANI field. If this matches a mailbox, the voice-mail system plays the login prompt for that mailbox. If neither the DNIS nor the ANI matches a mailbox, the default opening greeting is played.

Note

You might need to select Redirecting Number IE Delivery Outgoing on the Gateway Configuration page in CallManager for the gateway at the central location to support RDNIS delivery to the voice-mail system.

If the connection to the PSTN is via analog or channel-associated signaling (CAS) circuits, additional steps are required. In this case, dual tone multifrequency (DTMF) tones are used to route the call to the appropriate mailbox. Different voice-mail vendors expect different formats for these DTMF tones. Because no standard format exists, you need to instruct the SRST gateway how to send the appropriate DTMF tones using the vm-integration command from global config mode. To understand how vm-integration works, you need to define the participants in a call and the possible call flows. Figure 13-5 shows the participants and the possible call flows.

Figure 13-5. Voice-Mail Call Flows

The call participants are defined from the perspective of the voice-mail system. Calling number (CGN) is the original calling party. Forwarding number (FDN) is the extension that forwarded the call to voice mail. Called number (CDN) is the called party, which in this case is the voice-mail system.

The vm-integration command defines how the DTMF tones are sent based on the call flow. This is done using the pattern command. Each of the possible call flows has a pattern command. Example 13-6 shows a configuration for integrating SRST with a voice-mail system over analog circuits.

Miami(config)#vm-integration
Miami(config-vm-int)#pattern direct * CGN
Miami(config-vm-int)#pattern ext-to-ext no-answer # FDN #2
Miami(config-vm-int)#pattern ext-to-ext busy # FDN #2
Miami(config-vm-int)#pattern trunk-to-ext no-answer # FDN #2
Miami(config-vm-int)#pattern trunk-to-ext busy # FDN #2

 

In this example, when a user presses the Messages button, a call is placed to the voice-mail system. When voice mail answers, a DTMF tone for * is played, followed by the CGN. For all other call flows, the DTMF tones sent are # followed by the extension of the forwarding phone followed by #2.

Some carriers do not propagate RDNIS, which results in the default opening greeting being played. If you cannot get RDNIS through your service provider network, you might be able to use the vm-integration commands in conjunction with the forward-digits extra inband command. This should be configured on the POTS dial peer that is used to forward the call to the voice-mail system. Example 13-7 shows the configuration for integrating SRST with a voice-mail system over a PRI circuit that does not support RDNIS.

Miami(config)#dial-peer voice 50 pots
Miami(config-dial-peer)#destination-pattern 912125553000
Miami(config-dial-peer)#prefix 12125553000
!
! Send digits after call setup inband as DTMF
!
Miami(config-dial-peer)#forward-digits extra inband
!
Miami(config-dial-peer)#port 1/0/0:23
!
Miami(config)#vm-integration
Miami(config-vm-int)#pattern direct * CGN
Miami(config-vm-int)#pattern ext-to-ext no-answer # FDN #2
Miami(config-vm-int)#pattern ext-to-ext busy # FDN #2
Miami(config-vm-int)#pattern trunk-to-ext no-answer # FDN #2
Miami(config-vm-int)#pattern trunk-to-ext busy # FDN #2

 

This solution is available in Cisco IOS Release 12.3(11)T and later.

Music on Hold

The SRST gateway can play Music on Hold (MoH) from a file on flash, but only for G.711 VoIP or PSTN calls. Internal calls between IP phones will hear tone on hold. To enable MoH from flash, use the moh filename command. Your MoH file can be a wav or au file, but it must be 8-bit, 8 KHz.

You can also use a live audio feed for MoH. The live audio feed is connected to an E&M port in the SRST gateway. Connect the standard RCA jack to pins 3 and 6 of the Ear and Mouth (E&M) port, and disable E&M signaling using the signal-immediate and auto-cut-through commands. After you have physically connected the audio feed to the E&M port, create a dial peer that you can use to "call" the audio feed. The final step is the moh-live command. This command creates a dummy number that initiates the MoH. Example 13-8 shows how to configure a live audio MoH feed.

Miami(config)#voice-port 0/1/0
Miami(config-voiceport)#input gain 3
Miami(config-voiceport)#auto-cut-through
Miami(config-voiceport)#operation 4-wire
Miami(config-voiceport)#signal immediate
!
Miami(config)#dial-peer voice 5555 pots
Miami(config-dial-peer)#destination-pattern 5555
Miami(config-dial-peer)#port 0/1/0
!
Miami(config)#call-manager-fallback
Miami(config-cm-fallback)#moh-live dn-number 4444 out-call 5555
!

 

Note

The moh-live command uses one of the virtual voice ports that the max-dn command creates.

You can also use a Foreign Exchange Office (FXO) port for a live MoH feed. This requires an external adapter such as the ST-TC1 Telephone System Coupler from Radio Design Labs to provide normal telco battery voltage.