Missing Transfer Patterns

Call transfer is one of most commonly used functions in Cisco CME. Transferring calls between multiple Cisco CME systems or to PSTN destinations requires the necessary configuration. This section describes some of the common mistakes made during system configuration (when integrating multiple sites) that prevent call transfer from working.

Call Transfer Doesn't Work

With further business growth, the company adds another office in a new location, and a third Cisco CME system is installed in this location. Figure 17-2 shows the new network configuration for the company with this additional office.

Figure 17-2. System Configuration with the New Office

The configuration of the Cisco CME in the new location is not much different from the customer support site, except for the numbers assigned to the ephone-dns and the local PSTN DID number. Appropriate dial peers are added to the headquarters and customer support sites for full connectivity. The relevant dial peer configurations for all three Cisco CME routers are shown in the following examples. Example 17-4 shows the dial peer configuration for the headquarters site.

Example 17-4. Headquarters Site Configuration

HQ_Router#show running-config dial-peer voice 1 voip destination-pattern 1... session target ipv4:10.10.10.1 dtmf-relay h245-alphanumeric ! dial-peer voice 2 voip destination-pattern 3... session target ipv4:10.10.10.2 dtmf-relay h245-alphanumeric

Example 17-5 shows the configuration for the customer support center site.

Example 17-5. Customer Support Center Configuration

CS_router#show running-config dial-peer voice 1 voip destination-pattern 2... session target ipv4:10.10.10.2 dtmf-relay h245-alphanumeric ! dial-peer voice 2 voip destination-pattern 3... session target ipv4:10.10.10.3 dtmf-relay h245-alphanumeric

Example 17-6 shows the configuration for the new site (site 3).

Example 17-6. Site 3 Configuration

Branch_Router#show running-config dial-peer voice 1 voip destination-pattern 1... session target ipv4:10.10.10.1 dtmf-relay h245-alphanumeric ! dial-peer voice 2 voip destination-pattern 2... session target ipv4:10.10.10.2 dtmf-relay h245-alphanumeric ! telephony-service load 7960-7940 P00303020214 max-ephones 24 max-dn 48 ip source-address 10.10.10.3 port 2000 create cnf-files version-stamp Jan 01 2002 00:00:00 dialplan-pattern 1 5553333... extension-length 4 extension-pattern 3... max-conferences 4 transfer-pattern 1... transfer-pattern 2...

Employees at each site now can call each other and receive calls from the PSTN. A new problem is reported, however. Employees at the headquarters and customer support sites cannot transfer calls to the new site 3 office even though they can make a direct call to the same destination extension. An incoming call from the new site 3 office can be transferred successfully to the headquarters or customer support sites.

To understand why the call transfer is failing, turn on the debug ephone detail command for the CS_router. Example 17-7 shows the relevant portions of the output of the debug ephone detail command for a call from an HQ_router phone to a CS_router phone.

Example 17-7. Output of the debug ephone detail Command for the Incoming Call

CS_router#debug ephone detail !Output omitted for brevity ... 06:45:57: SetCallInfo DN 1 chan 1 is not skinny-to-skinny 06:45:57: SkinnyGetCallState for DN 1 chan 1 IDLE 06:45:57: called DN -1 chan 1, calling DN -1 chan 1 phone -1 incoming s2s:0 06:45:57: SkinnyUpdateDnState by EFXS_RING_GENERATE for DN 1 chan 1 to state RINGING !Output omitted for brevity ... 06:45:57: ephone-1[1]:Call Info DN 1 line 1 ref 31 called 1001 calling 5552222001 origcalled 1001 calltype 1 06:45:57: ephone-1[1]:Original Called Name CS Engineer1 06:45:57: ephone-1[1]: Janet Phillip calling 06:45:57: ephone-1[1]: CS Engineer1 06:45:57: ephone-1[1]:External RINGING 06:45:57: ephone-1[1]:Ringer Outside Ring On 06:45:57: SkinnyGetCallState for DN 1 chan 1 RINGING 06:45:57: called DN -1 chan 1, calling DN -1 chan 1 phone -1 incoming s2s:0 06:45:57: ephone-1[1]:SetLineLamp 1 to BLINK 06:45:57: Check AUTO phone -1 06:46:03: ephone-1[1]:OFFHOOK 06:46:03: ephone-1[1]:Disable Ringer line 1 06:46:03: ephone-1[1]:STOP RINGING 06:46:03: ephone-1[1]:Ringer Off 06:46:03: SkinnyGetCallState for DN 1 chan 1 RINGING 06:46:03: called DN -1 chan 1, calling DN -1 chan 1 phone -1 incoming s2s:0 06:46:03: ephone-1[1][SEP0007EB46299E]:Auto select answer line 1 dn -1 chan 1 06:46:03: ephone-1[1]:ANSWER call ... 06:46:03: defer_start for DN 1 chan 1 at CONNECTED 06:46:03: Skinny Call State change for DN 1 chan 1 CONNECTED from RINGING 06:46:03: ephone-(1) DN 1 chan 1 calledDn -1 chan 1 callingDn -1 chan 1 0.0.0.0 port=0 incoming !Output omitted for brevity ... 06:46:03: dn_support_g729 true DN 1 chan 1 ephone-1 06:46:03: dn_support_g723 false DN 1 chan 1 ephone-1 06:46:03: SetDnCodec clear_defer media start 06:46:03: SetDnCodec DN 1 chan 1 codec 11:G729 vad 250 size 20 06:46:03: Skinny clear media defer_start 06:46:03: DN 1 chan 1 Voice_Mode 06:46:03: SkinnyGetCallState for DN 1 chan 1 CONNECTED ... 06:46:03: SkinnyUpdateDnState by EFXS_OPEN_VOICE_PATH for DN 1 chan 1 to state CALL_START 06:46:03: calling= 5552222001 called= 1001 origCalled= 06:46:03: callingName= Janet Phillip, calledName= , redirectedTo = 06:46:03: ephone-1[1][SEP0007EB46299E]:refreshDisplayLine for line 1 DN 1 chan 1 06:46:03: ephone-1[1]:OpenReceiveChannelAck:IP 10.10.10.141, port=27358, dn_index=1, dn=1, chan=1 06:46:03: ephone-1[1]:StartMedia 10.10.10.1 port=2000 06:46:03: DN 1 chan 1 codec 11:G729 duration 20 ms bytes 20 06:46:03: ephone-1[1]:Original Called Name CS Engineer1 06:46:03: ephone-1[1]: Janet Phillip calling 06:46:03: ephone-1[1]: CS Engineer1

A quick look at the debug shows that Janet Phillip (at headquarters number 555.222.2001) called CS Engineer1 at extension number 1001. The call was answered after it entered the ringing state, and the codec selected for the call is G.729 with 20 milliseconds (ms) sampling.

Example 17-8 shows the output of the debug ephone detail command during the call transfer to a phone at site 3.

Example 17-8. debug ephone detail Command Output During Call Transfer

CS_router#debug ephone detail !Output omitted for brevity ... 07:12:21: ephone-1[1][SEP0007EB46299E]:SoftKeyEventMessage event 4 line 1 callref 31 07:12:21: ephone-1[1]:SK TRANSFER line 1 ref 31 07:12:21: ephone-1[1]:TransferButtonPress 07:12:21: ephone-1 TRANSFER using transfer-system local DN 1 blind transfer 07:12:21: ephone-1[1]:HoldButtonPress (allow_toggle = 0) 07:12:21: SkinnyGetCallState for DN 1 chan 1 CONNECTED 07:12:21: called DN -1 chan 1, calling DN -1 chan 1 phone 1 incoming s2s:0 07:12:21: ephone-1[1]:HoldButtonPress HOLD activated for DN 1 chan 1 07:12:21: ephone-1[1]:HoldButtonPress DN 1 chan 1 other DN -1 chan 1 other ephone-(-1) 07:12:21: ephone-1[1]:UpdateCallState DN 1 chan 1 state 9 calleddn -1 chan 1 07:12:21: ephone-1[1]:Binding ephone-1 to DN 1 chan 1 s2s:0 07:12:21: Adding DN 1 chan 1 to MOH 07:12:21: Skinny Call State change for DN 1 chan 1 HOLD from CONNECTED !Output omitted for brevity ... 07:12:21: SkinnyGetCallState for DN 1 chan 1 HOLD 07:12:21: called DN -1 chan 1, calling DN -1 chan 1 phone -1 incoming s2s:0 07:12:21: ephone-1[1]:SetLineLamp 1 to WINK 07:12:21: UnBinding ephone-1 from DN 1 chan 1 07:12:21: ephone-1[1]:CloseReceive 07:12:21: ephone-1[1]:StopMedia 07:12:21: ephone-1[1]:HoldButtonPress keep call plane for transfer !Output omitted for brevity ... 07:12:21: Skinny StartTone 33 sent on ephone socket [1] DtInsideDialTone 07:12:21: ephone-1[1][SEP0007EB46299E]:CallPrompt line 1 ref 31: 07:12:21: ephone-1[1]:SelectPhoneSoftKeys set 2 mask FFFF for line 1 ref 31 07:12:22: ephone-1[1]:Update Stats Total for DN 1 chan 1 07:12:22: ephone-1[1]:KeypadButtonMessage 3 07:12:22: ephone-1[1]:is_auto_local 0 for DN -1 07:12:22: ephone-1[1]:StopTone sent to ephone 07:12:22: ephone-1[1][SEP0007EB46299E]:CallPrompt line 1 ref 31: Transfer 3 07:12:22: ephone-1[1][SEP0007EB46299E]:SkinnyTryCall to 3 instance 1 start at 0 07:12:22: ephone-1[1]:No Transfer DN match for 3 07:12:22: ephone-1[1]:No Transfer-Pattern match for 3 07:12:22: ephone-1[1]:is_auto_local 0 for DN -1 07:12:22: Skinny StartTone 37 sent on ephone socket [1] DtReorderTone 07:12:23: ephone-1[1]:KeypadButtonMessage 0 07:12:23: ephone-1[1][SEP0007EB46299E]:CallPrompt line 1 ref 31: Transfer 0 07:12:23: ephone-1[1][SEP0007EB46299E]:SkinnyTryCall to 0 instance 1 start at 0 07:12:23: ephone-1[1]:No Transfer DN match for 0 07:12:23: ephone-1[1]:No Transfer-Pattern match for 0 07:12:23: ephone-1[1]:is_auto_local 0 for DN -1 07:12:23: Skinny StartTone 37 sent on ephone socket [1] DtReorderTone 07:12:23: ephone-1[1]:KeypadButtonMessage 0 07:12:23: ephone-1[1][SEP0007EB46299E]:CallPrompt line 1 ref 31: Transfer 0 07:12:23: ephone-1[1][SEP0007EB46299E]:SkinnyTryCall to 0 instance 1 start at 0 07:12:23: ephone-1[1]:No Transfer DN match for 0 07:12:23: ephone-1[1]:No Transfer-Pattern match for 0 07:12:23: ephone-1[1]:is_auto_local 0 for DN -1 07:12:23: Skinny StartTone 37 sent on ephone socket [1] DtReorderTone 07:12:23: ephone-1[1]:KeypadButtonMessage 1 07:12:23: ephone-1[1][SEP0007EB46299E]:CallPrompt line 1 ref 31: Transfer 1 07:12:23: ephone-1[1][SEP0007EB46299E]:SkinnyTryCall to 1 instance 1 start at 0 07:12:23: ephone-1[1]:No Transfer-Pattern match for 1 CS_router#

The debug output in Example 17-8 shows that Janet pressed the transfer softkey on her phone. This action automatically puts the original call on hold and starts playing dial tone. The phone then collects the digits (3001) of the destination where the call should be transferred. Each digit pressed generates a KeypadButtonMessage message, followed by the actual digit pressed.

A couple of lines below the KeypadButtonMessage 3 you can see the messages "No transfer DN match for 3" and "No transfer-pattern match for 3." This explains why the call wasn't transferred successfully. Even though necessary dial peers were added on both the headquarters and customer service Cisco CME routers, the transfer pattern necessary to enable transfer between these sites is still missing.

Fixing Transfer Patterns

The addition of the command transfer-pattern 3... on both the headquarters and customer service Cisco CME routers allows users to transfer a call to the phones connected to the site 3 Cisco CME. For each transfer destination, you should have a matching transfer pattern to enable a successful transfer to that extension. You can also use the .T dial peer terminology in the transfer-pattern command to match all possible numbering schemes.