Troubleshooting Call Transfers and Call Forwards

Chapter 7, "Connecting Multiple Cisco CMEs with VoIP," covered the call transfer and forward mechanisms and protocols used to implement network call transfers using H.323 and SIP. It is recommended that you review Chapter 7 to effectively troubleshoot any problems in this area. This section discusses how to troubleshoot issues with local and network call transfers and forwards and describes how to detect and fix common configuration issues.

Troubleshooting Call TransfersTransfer Attempts Get Reorder Tone

Transfers to local extensions on a Cisco CME are enabled by default. For all the other transfers, including those to local PSTN numbers, you must configure transfer patterns. Sometimes transfer attempts may not work because either a transfer pattern is not configured or the transfer target's number may not match any transfer patterns configured on the system.

The easiest way to fix this situation is to use the transfer-pattern .T command, which allows transfers to all numbers. However, this solution might be undesirable if you are concerned about fraudulent use of call transfers. To see if a transfer pattern is matched, turn on the Cisco CME debug ephone state command to see which ones are not matching, and fix them with modifications to the transfer patterns for the desired transfer targets. This is shown in the debugs in Example 18-13. The user presses the transfer softkey when the call is in the connected state, gets dial tone, and starts dialing the transfer-to number. However, no transfer pattern matches this nonlocal number, so the caller hears reorder tone.

Example 18-13. Missing Transfer Pattern

CME#debug ephone state
SkinnyTryCall to 8010 instance 1 match DN 1
Feb 22 18:29:42: ephone-1[2]:Call Info DN 1 line 1 ref 244 called 8010 calling
 4085555002 origcalled 8010 calltype 1
Feb 22 18:29:42: ephone-1[2]:Call Info for chan 1
Feb 22 18:29:42: ephone-1[2]:Original Called Name Waugh
Feb 22 18:29:42: ephone-1[2]: lleyton hewitt calling
Feb 22 18:29:42: ephone-1[2]: Waugh
Feb 22 18:29:47: ephone-1[2][SEP003094C29D3C]:SoftKeyEventMessage event 4
 line 1 callref 244
Feb 22 18:29:47: ephone-1[2]:SK TRANSFER line 1 ref 244
Feb 22 18:29:47: ephone-1[2]:TransferButtonPress
Feb 22 18:29:47: ephone-1 TRANSFER using transfer-system full DN 1
 consult transfer
Feb 22 18:29:47: SkinnyGetCallState for DN 1 chan 1 CONNECTED
Feb 22 18:29:47: called DN -1 chan 1, calling DN -1 chan 1 phone 1
 incoming s2s:0
Feb 22 18:29:47: SkinnyGetCallState for DN 1 chan 1 CONNECTED
Feb 22 18:29:47: called DN -1 chan 1, calling DN -1 chan 1 phone 1
 incoming s2s:0
Feb 22 18:29:47: SkinnyGetCallState for DN 3 chan 1 IDLE
Feb 22 18:29:47: called DN 2 chan 1, calling DN -1 chan 1 phone 1 s2s:0
Feb 22 18:29:47: ephone-1[2]:Transfer with consult line 1 DN 1 chan 1
 using second line 2 DN 1 chan 1
Feb 22 18:29:47: ephone-1[2]:Consult for line 1 DN 1 chan 1 using
 line 2 DN 3 chan 1
Feb 22 18:29:47: ephone-1[2]:HoldButtonPress (allow_toggle = 0)
Feb 22 18:29:47: SkinnyGetCallState for DN 1 chan 1 CONNECTED
Feb 22 18:29:47: called DN -1 chan 1, calling DN -1 chan 1 phone 1
 incoming s2s:0
Feb 22 18:29:47: ephone-1[2]:HoldButtonPress HOLD activated for DN 1 chan 1
Feb 22 18:29:47: ephone-1[2]:HoldButtonPress DN 1 chan 1 other DN -1 chan 1
 other ephone-(-1)
Feb 22 18:29:47: ephone-1[2]:Binding ephone-1 to DN 1 chan 1 s2s:0
Feb 22 18:29:47: Adding DN 1 chan 1 to MOH
.........
Feb 22 18:29:47: ephone-1[2]:CloseReceive
Feb 22 18:29:47: ephone-1[2]:StopMedia
Feb 22 18:29:47: ephone-1[2]:HoldButtonPress keep call plane for transfer
Feb 22 18:29:47: called DN -1 chan 1, calling DN -1 chan 1 phone -1
 incoming s2s:0
Feb 22 18:29:47: ephone-1[2]:is_auto_local 0 for DN -1
Feb 22 18:29:47: Skinny StartTone 33 sent on ephone socket [2]
DtInsideDialTone
Feb 22 18:29:47: ephone-1[2][SEP003094C29D3C]:CallPrompt line 1 ref 244:
Feb 22 18:29:47: ephone-1[2]:SelectPhoneSoftKeys set 2 mask FFFF for
 line 1 ref 244
Feb 22 18:29:47: ephone-1[2]:Update Stats Total for DN 1 chan 1
Feb 22 18:29:48: ephone-1[2]:KeypadButtonMessage 5
Feb 22 18:29:48: ephone-1[2]:is_auto_local 0 for DN -1
Feb 22 18:29:48: ephone-1[2]:StopTone sent to ephone
Feb 22 18:29:48: ephone-1[2][SEP003094C29D3C]:CallPrompt line 1
 ref 244: Transfer 5
Feb 22 18:29:48: ephone-1[2]:SkinnyTryCall to 5 instance 1 start at 0
secondary 0
Feb 22 18:29:48: ephone-1[2]:No Transfer-Pattern match for 5
Feb 22 18:29:48: ephone-1[2]:KeypadButtonMessage 0 
Feb 22 18:29:48: ephone-1[2][SEP003094C29D3C]:CallPrompt line 1
 ref 244: Transfer 50
Feb 22 18:29:48: ephone-1[2]:SkinnyTryCall to 50 instance 1 start at 0
 secondary 0
Feb 22 18:29:48: ephone-1[2]:No Transfer DN match for 50
Feb 22 18:29:48: ephone-1[2]:No Transfer-Pattern match for 50
Feb 22 18:29:48: ephone-1[2]:is_auto_local 0 for DN -1
Feb 22 18:29:48: Skinny StartTone 37 sent on ephone socket [2] DtReorderTone
Feb 22 18:29:51: ephone-1[2]:ONHOOK (from phone msgID=7)
Feb 22 18:29:51: ephone-1[2]:TRANSFER quit on line 1 DN 1
Feb 22 18:29:51: ephone-1[2]:Clear DN 1 chan 1 transfer
Feb 22 18:29:51: UpdateCallState DN 1 chan 1 state 10 phone-ref -1 calleddn -1
 calleddn_chan 1
Feb 22 18:29:51: No active phone for DN 1 chan 1 instance 1 (mode 0)
Feb 22 18:29:51: DN 1 chan 1 End Voice_Mode
Feb 22 18:29:51: SetCallInfo calling dn -1 chan 1 dn 1 chan 1
calling [] called []

 

Troubleshooting Network Call TransfersAttempts to Transfer H.323 Calls Fail

Troubleshooting network call transfers and forwards involves understanding the capabilities of all voice over IP (VoIP) devices in the network. This primarily involves identifying which devices support network call transfer protocols and which don't. The devices that support network call transfers are those that also support H.450.2, H.450.3, and H.450.12. The most important aspect of the configuration to verify is that all the devices involved in call transfers or forwards have appropriate call routing dial peers.

Cisco CME 3.1 and later can hairpin incoming H.323 calls to outgoing H.323 calls. Hairpinning calls can be the result of call transfers or forwards involving hybrid network devices or incorrect configuration. Hairpinned calls caused by hybrid network devices are acceptable, but those caused by incorrect configuration should be rectified to optimize call processing and resource consumption.

This section discusses how to troubleshoot such issues and gives possible solutions. Chapter 7 showed the protocol exchange sequence for a call transfer involving two or three devices. The first discussion in this section presents debug output for a successful network call transfer. This should help you understand the call transfer mechanism itself. The discussion following that covers a few scenarios in which call transfers fail or result in hairpinned calls.

Using Debugs to Understand Successful Network Call Transfers

Figure 18-6 shows the sample topology for the troubleshooting in this section. It consists of three sites where Cisco CME 3.2 is running for local call processing. The sites are connected with an IP WAN network engineered to carry H.323 calls between the sites.

Figure 18-6. Topology for Troubleshooting Network Call Transfers

For this example, assume that dialplan-pattern commands are not configured under telephony-service and that all the call setups use extensions. The next section walks through the debug traces of a call transfer scenario involving the three sites. Extension 8010 at Cisco CME1 places a call to extension 6002 at Cisco CME2. This is shown in Example 18-14.

Example 18-14. Transferee Calls the Transferor

CME1#debug voip application supplementary-service
supplementary service debugging is on
CME1#debug ephone state
EPHONE state debugging is enabled
CME1#
Mar 9 14:24:37: ephone-1[2]:OFFHOOK
Mar 9 14:24:37: ephone-1[2]:SIEZE on activeLine 1 activeChan 1
Mar 9 14:24:37: ephone-1[2]:SetCallState line 1 DN 1 chan 1 ref 109 TsOffHook
Mar 9 14:24:37: ephone-1[2]:SpeakerPhoneOffHook mute 0
Mar 9 14:24:37: DN 1 chan 1 Voice_Mode
Mar 9 14:24:37: //-1//APPL:/SSProcessH450CommonInfoEvent:
CI_INFORM featureList=0xC0000000 featureValue[0][0] featureControl=0x0
Mar 9 14:24:37: dn_tone_control DN=1 chan 1 tonetype=36:DtAlertingTone onoff=1
 pid=159
Mar 9 14:24:43: //-1//APPL:/SSProcessH450CommonInfoEvent:
CI_INFORM featureList=0xC0000000 featureValue[0][0] featureControl=0x0
Mar 9 14:24:43: ephone-1[2]:SetCallState line 1 DN 1 chan 1 ref 109 TsConnected
Mar 9 14:24:43: ephone-1[2]:OpenReceiveChannelAck:IP 89.89.89.3,
port=25124, dn_index=1, dn=1, chan=1
Mar 9 14:24:43: ephone-1[2]:StartMedia 89.89.89.1 port=2000
Mar 9 14:24:43: DN 1 chan 1 codec 4:G711Ulaw64k duration 20 ms bytes 160
Mar 9 14:24:43: ephone-1[2]:Call Info DN 1 line 1 ref 109 called 6002 calling
 8010 origcalled 6002 calltype 2
Mar 9 14:24:43: ephone-1[2]:Call Info for chan 1
......

The transferor at Cisco CME 2 receives the call and answers it. The call is now in a connected state with media channels (Real-Time Transport Protocol [RTP]) set up. This is shown in Example 18-15.

Example 18-15. Transferor Receives the Call and Answers It

CME2#debug voip application supplementary-service
CME2#debug ephone state
Mar 9 14:37:26: ephone-2[1]:Ringer Off
Mar 9 14:37:26: ephone-2[1]:ANSWER call
Mar 9 14:37:26: ephone-2[1][SEP0009B7F757AB]:Answer Incoming call from
 ephone-(-1) DN -1 chan 1
Mar 9 14:37:26: ephone-2[1]:OpenReceive DN 2 chan 1 codec 4:G711Ulaw64k duration
 20 ms bytes 160
Mar 9 14:37:26: //-1//APPL:/AppPrepareCommonInfoRequestReceived: Leg
 peer_tag=1000
Mar 9 14:37:26: //-1//APPL:/AppPrepareCommonInfo:
Global H450_2=1 H450_3=1 H450_12_ADV=1 H450_12_USAGE=0
Mar 9 14:37:26: //-1//APPL:/AppPrepareCommonInfoContent:
SS_CI ss_evt=18 featureList=0xC0000000 featureValues=[0][0][0][0]
 featureControl=0x0
Mar 9 14:37:27: ephone-2[1]:Call Info DN 2 line 1 ref 459 called 6002 calling
 8010 origcalled 6002 calltype 1
......
Mar 9 14:37:27: ephone-2[1]:OpenReceiveChannelAck:IP 28.28.28.3,
port=17856, dn_index=2, dn=2, chan=1
Mar 9 14:37:27: ephone-2[1]:StartMedia 28.28.28.1 port=2000
Mar 9 14:37:27: DN 2 chan 1 codec 4:G711Ulaw64k duration 20 ms bytes 160

The transferor at Cisco CME 2 decides to transfer this call to extension 5003 on Cisco CME 3. As you see from the traces shown in Example 18-16, the original call is put on hold and the call to 5003 (the transfer target) is set up using the second line (associated with DN 4 having extension 6004) available on the transferor's phone.

Example 18-16. Consult Call to Transfer Target Is Set Up

CME2#debug voip application supplementary-service
CME2#debug ephone state
Mar 9 14:37:59: ephone-2[1]:TransferButtonPress
Mar 9 14:37:59: ephone-2 TRANSFER using transfer-system full DN 2 consult
 transfer
......
Mar 9 14:37:59: ephone-2[1]:HoldButtonPress (allow_toggle = 0)
Mar 9 14:37:59: ephone-2[1]:HoldButtonPress HOLD activated for DN 2 chan 1
Mar 9 14:37:59: ephone-2[1][SEP0009B7F757AB]:SetCallState line 1 ref 459 state
 10 TsCallTransfer ignored
Mar 9 14:37:59: ephone-2[1]:CloseReceive


Mar 9 14:37:59: ephone-2[1]:StopMedia
Mar 9 14:38:02: PredictTarget no idle match for 5003 after 0 attempts
Mar 9 14:38:02: ephone-2[1]:Consult for line 1 DN 2 chan 1 using line 2 DN 4
 chan 1 to 5003
Mar 9 14:38:02: ephone-2[1][SEP0009B7F757AB]:SkinnyPhoneDeselectLine 0 chan 1
 to 2
Mar 9 14:38:02: ephone-2[1]:OFFHOOK
Mar 9 14:38:02: ephone-2[1]:SIEZE on activeLine 2 activeChan 1
Mar 9 14:38:02: ephone-2[1]:SetCallState line 2 DN 4 chan 1 ref 460 TsOffHook
Mar 9 14:38:02: DN 4 chan 1 Voice_Mode
Mar 9 14:38:02: dn_tone_control DN=4 chan 1 tonetype=33:DtInsideDialTone onoff=1
 pid=154
Mar 9 14:38:02: //-1//APPL:/AppPrepareCommonInfo:
Global H450_2=1 H450_3=1 H450_12_ADV=1 H450_12_USAGE=0
Mar 9 14:38:02: //-1//APPL:/AppPrepareCommonInfoContent:
SS_CI ss_evt=18 featureList=0xC0000000 featureValues=[0][0][0][0]
 featureControl=0x0
Mar 9 14:38:02: ephone-2[1]:SkinnySelectPhoneSoftKeys DN 4 chan 1 change
 TsRingOut to TsCallTransfer
Mar 9 14:38:02: ephone-2[1]:Call Info DN 4 line 2 ref 460 called 5003
 calling 6004 origcalled 5003 calltype 2
.........
Mar 9 14:38:02: //-1//APPL:/AppPrepareCommonInfoRequestReceived: Leg
 peer_tag=20004
Mar 9 14:38:02: //-1//APPL:/AppPrepareCommonInfo: Not voip dialpeer, no common
 info sent.
Mar 9 14:38:02: dn_tone_control DN=4 chan 1 tonetype=36:DtAlertingTone onoff=1
 pid=154
Mar 9 14:38:06: //-1//APPL:/SSProcessH450CommonInfoEvent:
CI_INFORM featureList=0xC0000000 featureValue[0][0] featureControl=0x0
.........
Mar 9 14:38:06: ephone-2[1]:OpenReceiveChannelAck:IP 28.28.28.3,
port=21832, dn_index=4, dn=4, chan=1
Mar 9 14:38:06: ephone-2[1]:StartMedia 28.28.28.1 port=2000
Mar 9 14:38:06: DN 4 chan 1 codec 4:G711Ulaw64k duration 20 ms bytes 160
Mar 9 14:38:07: ephone-2[1]:Call Info DN 4 line 2 ref 460 called 5003
 calling 6004 origcalled 5003 calltype 2

The debug output for the transfer target (Cisco CME 3) is shown in Example 18-17.

Example 18-17. Transfer Target Answers the Consult Call

CME3#debug voip application supplementary-service
CME3#debug ephone state
*Mar 9 22:02:01.543: ephone-2[1]:OFFHOOK
*Mar 9 22:02:01.543: ephone-2[1]:Ringer Off
*Mar 9 22:02:01.543: ephone-2[1]:ANSWER call
......
*Mar 9 22:02:01.555: ephone-2[1]:OpenReceive DN 3 chan 1 codec 4:G711Ulaw64k
 duration 20 ms bytes 160
*Mar 9 22:02:01.559: //-1//APPL:/AppPrepareCommonInfoRequestReceived: Leg
 peer_tag=1000
*Mar 9 22:02:01.559: //-1//APPL:/AppPrepareCommonInfo: Global H450_2=1 H450_3=1
 H450_12_ADV=1 H450_12_USAGE=0
*Mar 9 22:02:01.559: //-1//APPL:/AppPrepareCommonInfoContent:
SS_CI ss_evt=18 featureList=0xC0000000 featureValues=[0][0][0][0]
 featureControl=0x0

*Mar 9 22:02:01.812: ephone-2[1]:Call Info DN 3 line 1 ref 186 called 5003
 calling 6004 origcalled calltype 1
......
*Mar 9 22:02:01.816: ephone-2[1]:OpenReceiveChannelAck:IP 40.40.0.13,
 port=20502, dn_index=3, dn=3, chan=1
*Mar 9 22:02:01.816: ephone-2[1]:StartMedia 40.40.0.1 port=2000
*Mar 9 22:02:01.816: DN 3 chan 1 codec 4:G711Ulaw64k duration 20 ms bytes 160

At this point, the original call between extensions 8010 (Cisco CME 1) and 6002 (Cisco CME 2) is on hold while a call is active between 6004 (Cisco CME 2) and 5003 (Cisco CME 3). The call between 6004 and 5003 is the consultation call for the consult transfer. After the consultation, the transferor on Cisco CME 2 decides to commit the transfer so that extension 8010 (Cisco CME 1) and extension 5003 (Cisco CME 3) can talk. At this point, the H.450.2 call transfer protocol exchanges covered in Chapter 7 take place.

The transferor (Cisco CME 2) requests a consult ID from the transfer target (Cisco CME 3). When it is successful, the transferor gives the consult ID to the transferee (Cisco CME 1). The transferee then sets up a new call to the transfer target, replacing the consult call. In the debug shown in Example 18-18, note the consult ID request that is generated and exchanged and the consult ID of 13 that is returned.

Example 18-18. Transferor Requests and Receives the Consult ID from the Transfer Target

CME2#debug voip application supplementary-service
CME2#debug ephone state
Mar 9 14:38:33: ephone-2[1]:TransferButtonPress
Mar 9 14:38:33: ephone-2[1]:Commit Transfer with Consult for DN 2 chan 1 using
 consult DN 4 chan 1
......
Mar 9 14:38:33: ephone-2[1]:Request Consult ID for DN 2 chan 1 using consult DN 4
 chan 1
Mar 9 14:38:33: ephone-2[1]:SkinnyRequestConsultID for DN 4 chan 1
Mar 9 14:38:33: //3254//APPL:/SSMapEvent:
SS_IDENTIFY_REQUEST: rerouteNo[] invokeID[3256]
Mar 9 14:38:33: //3255//APPL:/AppConsultRequest:
Mar 9 14:38:33: AppLegH450TransferNotSupported: remote end is h450.2 capable
Mar 9 14:38:33: //3255//APPL:/AppIdentifyRequest:
Mar 9 14:38:33: //3255//APPL:/SSMapEvent:
SS_IDENTIFY_RESP: identify[13] rerouteNo[5003] invokeID[1476]
Mar 9 14:38:33: //3254//APPL:/AppConsultResponseSuccess: consuldID[13]
Mar 9 14:38:33: //3254//APPL:/AppSSReturnResult:
Mar 9 14:38:33: ephone-2[1]:SkinnyConsultIDResponse DN 2 chan 1 explicit target
 5003 orig 5003 redirected= []
Mar 9 14:38:33: ephone-2[1]:SkinnyConsultIDResponse ActivateTransfer DN 2 chan 1
 to 5003 id [13]
......
Mar 9 14:38:33: DN 2 Call Transfer ID=[13] for callID 3253 to 5003 (expanded)
Mar 9 14:38:33: ephone-2[1]:Transfer Request OK for DN 2 chan 1
Mar 9 14:38:33: //3253//APPL:/SSMapEvent:
SS_INIT_IND: rerouteNo[5003] identify[13] invokeID[3257] transferringNo[6002]
 peer[0] xto_callID[0]
Mar 9 14:38:33: AppLegH450TransferNotSupported: remote end is h450.2 capable
Mar 9 14:38:33: //3252//APPL:/AppTransferInitiateRequest: to [5003] with ID[13]
Mar 9 14:38:33: //3252//APPL:/AppTransferRequest:
Mar 9 14:38:33: AppLegH450TransferNotSupported: remote end is h450.2 capable
Mar 9 14:38:33: //3252//APPL:/AppTransferRequest: SS_INIT:rerouteNo[5003] ID[13]
Mar 9 14:38:33: //3252//APPL:/SSMapEvent: SS_RETURN_RESULT
Mar 9 14:38:33: //3253//APPL:/AppSSReturnResult:
Mar 9 14:38:33: ephone-2[1]:DN 2 disc reason 16 normal state HOLD

The traces in Example 18-19 show the transfer target (Cisco CME 3) generating and issuing a consult ID to the transferor (Cisco CME 2). Later in this section you will see that after the transferred call is set up, the caller ID is updated on the transfer target, as shown.

Example 18-19. Transfer Target Generates a Consult ID and Issues It to the Transferor

CME3#debug voip application supplementary-service
CME3#debug ephone state
*Mar 9 22:02:28.624: //441//APPL:/SSMapEvent:
SS_IDENTIFY_REQUEST: rerouteNo[] invokeID[1476]
*Mar 9 22:02:28.624: //442//APPL:/AppConsultRequest:
*Mar 9 22:02:28.624: //442//APPL:/AppIdentifyRequest:
*Mar 9 22:02:28.624: //441//APPL:/AppSSGenerateConsultID:
*Mar 9 22:02:28.624: ID=13
*Mar 9 22:02:28.624: //441//APPL:/AppConsultResponseSuccess: consuldID[13]

After the transferor (Cisco CME 2) and the transfer target (Cisco CME 3) exchange the consult IDs, the transferor gives the consult ID to the transferee (Cisco CME 1) to use to set up a new call to replace the consult call on the transfer target.

In Example 18-20, the transferee (Cisco CME 1) receives the consult ID and asks to set up a new call to complete the transfer. In the end, all of the call information is updated to reflect the complete transfer.

Example 18-20. Transferee Receives the Consult ID and Sets Up the Call

CME1#debug voip application supplementary-service
CME1#debug ephone state
Mar 9 14:25:49: //239//APPL:/SSMapEvent: SS_INIT_IND: rerouteNo[5003]
 identify[13] invokeID[1477] transferringNo[6002] peer[0] xto_callID[0]
Mar 9 14:25:49: //-1//APPL:/TRDTransferInitiate:
Mar 9 14:25:49: //238//APPL:/AppTransferRequest:
Mar 9 14:25:49: //-1//APPL:HN00000000:/TRD_transferSetup:
Mar 9 14:25:49: //-1//APPL:HN00000000:/TRDSetState: -->
 []
Mar 9 14:25:49: //-1//APPL:HN00000000:/TRDHndHandler:
Mar 9 14:25:49: //-1//APPL:HN00000000:/TRDHndHandler:
Get event TRD_ev_destroyDone in state 
Mar 9 14:25:49: //-1//APPL:HN00000000:/TRD_destroyDone:
Mar 9 14:25:49: //-1//APPL:LG238:LG239:/AppHandOffLocalTRT:
Leg 238's protocol=1 Leg 239's protocol=2
Mar 9 14:25:49: //-1//APPL:/AppPrepareTransferSetup: SS_SETUP:rerouteNo[5003]
transferringNo[6002] ID[13] peer[0]
Mar 9 14:25:49: //-1//APPL:/AppPrepareCommonInfo:
ssInfo already set by opcode(10), skip common info.
Mar 9 14:25:49: //-1//APPL:HN00000000:/TRDSetState: -->
 []
Mar 9 14:25:49: //-1//APPL:HN00000000:/TRDHndHandler:
Mar 9 14:25:49: //-1//APPL:HN00000000:/TRDHndHandler:
Get event TRD_ev_handlerDone in state 
Mar 9 14:25:49: //-1//APPL:HN00000000:/TRD_handlerDone:
Mar 9 14:25:49: //239//APPL:/AppSSReturnResult:
Mar 9 14:25:49: //-1//APPL:HN00000000:/TRDSetState: -->[]
Mar 9 14:25:49: //-1//APPL:HN00000000:/TRD_returnIfDone:
Mar 9 14:25:49: //-1//APPL:HN00000000:/TRDSetState: -->[]
Mar 9 14:25:49: //-1//APPL:HN00000000:/TRDHndCleanUp:
Mar 9 14:25:49: //-1//APPL:HN00000000:/TRDSetState: -->[]
Mar 9 14:25:49: //-1//APPL:HN00000000:/TRDHndFree:
Mar 9 14:25:50: ephone-1[2]:Call Info DN 1 line 1 ref 109 called 5003
 calling 8010 origcalled 5003 calltype 2

Example 18-21 shows the call information update on the transfer target (Cisco CME 3).

Example 18-21. Caller ID Update on the Transfer Target

CME3#debug voip application supplementary-service
CME3#debug ephone state
*Mar 9 22:02:28.624: //441//APPL:/AppSSReturnResult:
*Mar 9 22:02:28.664: //-1//APPL:/AppPrepareCommonInfoRequestReceived: Leg
 peer_tag=2000
*Mar 9 22:02:28.668: //-1//APPL:/AppPrepareCommonInfo:
Global H450_2=1 H450_3=1 H450_12_ADV=1 H450_12_USAGE=0
*Mar 9 22:02:28.668: //-1//APPL:/AppPrepareCommonInfoContent: SS_CI ss_evt=18
 featureList=0xC0000000 featureValues=[0][0][0][0] featureControl=0x0
......
*Mar 9 22:02:28.840: ephone-2[1]:Call Info DN 3 line 1 ref 186 called 5003
calling 8010 origcalled calltype 1
*Mar 9 22:02:28.840: ephone-2[1]:Call Info for chan 1

 

Troubleshooting Common Problems with Network Call Transfers

So far you have seen how a consult transfer in an H.323 network is implemented and how to interpret the debugs for such a scenario. In some cases, transfer attempts are unsuccessful or result in hairpinned calls. These situations are discussed next.

Assume that you want to use Cisco CME's dialplan-pattern command to implement the internal (extensions) and external (full E.164 numbers) phone number design discussed in Chapter 7. You also want to accept incoming calls dialed using the complete E.164 number of a phone number. The Cisco CME configuration for implementing these features looks in part like the one shown in Example 18-22.

Example 18-22. dialplan-pattern Commands

CME3#show telephony-service
CONFIG (Version=3.1)
=====================
Version 3.1
Cisco CallManager Express
ip source-address 40.40.0.1 port 2000
max-ephones 10
max-dn 20
max-conferences 3
max-redirect 5
dialplan-pattern 1 4085555... extension-length 4 extension-pattern 5...
dialplan-pattern 2 4155556... extension-length 4 extension-pattern 6...
dialplan-pattern 3 6505558... extension-length 4 extension-pattern 8...

CME2#show telephony-service
CONFIG (Version=3.1)
=====================
Version 3.1
Cisco CallManager Express
ip source-address 28.28.28.1 port 2000
max-ephones 100
max-dn 228
max-conferences 6
max-redirect 5
dialplan-pattern 1 4155556... extension-length 4 extension-pattern 6...
dialplan-pattern 2 4085555... extension-length 4 extension-pattern 5...
dialplan-pattern 3 6505558... extension-length 4 extension-pattern 8...
voicemail 3200

CME1#show telephony-service
CONFIG (Version=3.1)
=====================
Version 3.1
Cisco CallManager Express
ip source-address 89.89.89.1 port 2000
load 7960-7940 P00303010102
max-ephones 24
max-dn 120
max-conferences 8
max-redirect 5
dialplan-pattern 1 6505558... extension-length 4 extension-pattern 8...
dialplan-pattern 2 4155556... extension-length 4 extension-pattern 6...
dialplan-pattern 3 4085555... extension-length 4 extension-pattern 5...
voicemail 8900

The next discussion steps through the same call transfer scenario that was discussed in the preceding section. The call goes from extension 8010 on Cisco CME 1 to extension 6002 on Cisco CME 2. The person at extension 6002 wants to transfer to extension 5003 on Cisco CME 3. He presses the transfer key, gets dial tone, and dials 5003. He hears fast-busy tone instead of ringback. You will look at how this new configuration affects call forwarding in the section "Troubleshooting Common Problems with Network Call Forward."

Example 18-23 shows the debug voip ccapi inout and debug ephone state output of this call transfer attempt. As you can see in the debug output, the Cisco IOS call control application programming interface (API) processes a call for 408.555.5003 as the digits come in.

Example 18-23. Call Transfer Attempt Fails Because of the Lack of an E.164 Dial Peer

CME2#debug voip ccapin inout
CME2#debug ephone state
Mar 9 15:01:08: ephone-2[1]:TransferButtonPress
Mar 9 15:01:08: ephone-2 TRANSFER using transfer-system full DN 2 consult
 transfer
Mar 9 15:01:08: ephone-2[1]:Transfer with consult line 1 DN 2 chan 1 using second
 line 2 DN 2 chan 1
Mar 9 15:01:08: ephone-2[1]:Consult for line 1 DN 2 chan 1 using line 2 DN 4
 chan 1
Mar 9 15:01:08: ephone-2[1]:HoldButtonPress (allow_toggle = 0)
Mar 9 15:01:08: ephone-2[1]:HoldButtonPress HOLD activated for DN 2 chan 1
Mar 9 15:01:08: ephone-2[1][SEP0un al009B7F757AB]:
SetCallState line 1 ref 473 state 10 TsCallTransfer ignored
Mar 9 15:01:08: ephone-2[1]:CloseReceive
Mar 9 15:01:08: ephone-2[1]:StopMedia
Mar 9 15:01:10: PredictTarget no idle match for 5003 after 0 attempts
Mar 9 15:01:10: ephone-2[1]:Consult for line 1 DN 2 chan 1 using line 2 DN 4
 chan 1 to 5003
Mar 9 15:01:10: ephone-2[1]:SetCallState line 1 DN 2 chan 1 ref 473 TsHold
Mar 9 15:01:10: ephone-2[1][SEP0009B7F757AB]:
SkinnyPhoneDeselectLine 0 chan 1 to 2
Mar 9 15:01:10: ephone-2[l
c3725-NM#1]: Mar 9 15:01:10: ephone-2[1]:SIEZE on activeLine 2 activeChan 1
Mar 9 15:01:10: ephone-2[1]:SetCallState line 2 DN 4 chan 1 ref 474 TsOffHook
Mar 9 15:01:10: //-1/xxxxxxxxxxxx/CCAPI/ccTDConstructTDUsrContainer:
TD Container Constructed <<<<<< container-0x64F5D55C >>>>>>
Mar 9 15:01:10: //-1/xxxxxxxxxxxx/CCAPI/ccTDUtilAddDataToUsrContainer:
container=0x64F5D55C, tagID=6, dataSize=16, instID=-1,modifier=1
Mar 9 15:01:10: //-1/xxxxxxxxxxxx/CCAPI/ccTDConstructDataObject:
TD Data Object Cons
c3725-NM#
c3725-NM#tructed 0x63C227D8<>
Mar 9 15:01:10: //-1/xxxxxxxxxxxx/CCAPI/ccTDConstructInstanceTDObject:
TD Queuable Instance Constructed 0x63C6317C[0x0,t-6,o-0x63C227D8<>]
Mar 9 15:01:10: //-1/xxxxxxxxxxxx/CCAPI/ccTDPvtAddObjectToContainer:
Inserting Queuable TDObject into Container; [tagID-6, container-0x64F5D55C,
 Queuable-TDObject-0x63C6317C]
Mar 9 15:01:10: //-1/xxxxxxxxxxxx/CCAPI/cc_api_display_ie_subfields:
Mar 9 15:01:10: cc_api_call_setup_ind_common:
Mar 9 15:01:10: cisco-username=
Mar 9 15:01:10: ----- ccCallInfo IE subfields -----
Mar 9 15:01:10: cisco-ani=4155556004
Mar 9 15:01:10: cisco-anitype=0
Mar 9 15:01:10: cisco-aniplan=0
Mar 9 15:01:10: cisco-anipi=0
Mar 9 15:01:10: cisco-anisi=0
Mar 9 15:01:10: dest=
Mar 9 15:01:10: cisco-desttype=0
Mar 9 15:01:10: cisco-destplan=0
Mar 9 15:01:10: cisco-rdn=
Mar 9 15:01:10: cisco-rdntype=0
Mar 9 15:01:10: cisco-rdnplan=0
Mar 9 15:01:10: cisco-rdnpi=0
Mar 9 15:01:10: cisco-rdnsi=0
Mar 9 15:01:10: cisco-redirectreason=0
Mar 9 15:01:10: //-1/xxxxxxxxxxxx/CCAPI/cc_api_call_setup_ind_common:
 (vdbPtr=0x643D9BE4, callInfo={called=,called_oct3=0x80,calling=4155556004,
calling_oct3=0x0, calling_oct3a=0x0,calling_xlated=false,
subscriber_type_str=RegularLine,fdest=0,peer_tag=20115, prog_ind=3,
callingIE_present 1, src_route_label=,
tgt_route_label= clid_transparent=0},callID=0x650EE1EC)
.........
Mar 9 15:01:10: //3288/xxxxxxxxxxxx/CCAPI/ccSetDigitTimeouts: initial=-1000,
 inter=-1000
Mar 9 15:01:10: //3288/xxxxxxxxxxxx/CCAPI/ccCallReportDigits: (callID=0xCD8,
 enable=0x1)
Mar 9 15:01:10: //3288/xxxxxxxxxxxx/CCAPI/cc_api_call_report_digits_done:
(vdbPtr=0x643D9BE4, callID=0xCD8, disp=0)
Mar 9 15:01:10: DN 4 chan 1 Voice_Mode
Mar 9 15:01:10: dn_tone_control DN=4 chan 1 tonetype=33:DtInsideDialTone onoff=1
 pid=154
Mar 9 15:01:10: dn_tone_control DN=4 chan 1 tonetype=0:DtSilence onoff=0 pid=154
Mar 9 15:01:10: //3288/xxxxxxxxxxxx/CCAPI/cc_api_call_digit_begin:
(dstVdbPtr=0x0, dstCallId=0xFFFFFFFF, srcCallId=0xCD8,
 digit=4, digit_begin_flags=0x0, rtp_timestamp=0x641130
 rtp_expiration=0x0, dest_mask=0x1)
Mar 9 15:01:10: dn_tone_control DN=4 chan 1 tonetype=0:DtSilence onoff=0 pid=154
Mar 9 15:01:10: //3288/xxxxxxxxxxxx/CCAPI/cc_api_call_digit_end:
(dstVdbPtr=0x0, dstCallId=0xFFFFFFFF, srcCallId=0xCD8,
 digit=4,duration=100,xruleCallingTag=0,xruleCalledTag=0, dest_mask=0x1),
 digit_tone_mode=0
Mar 9 15:01:10: //3288/xxxxxxxxxxxx/CCAPI/cc_api_call_digit_begin:
(dstVdbPtr=0x0, dstCallId=0xFFFFFFFF, srcCallId=0xCD8,
 digit=0, digit_begin_flags=0x0, rtp_timestamp=0x648E30
 rtp_expiration=0x0, dest_mask=0x1)
Mar 9 15:01:10: //3288/xxxxxxxxxxxx/CCAPI/cc_api_call_digit_end: (dstVdbPtr=0x0,
 dstCallId=0xFFFFFFFF, srcCallId=0xCD8,
 digit=0,duration=100,xruleCallingTag=0,xruleCalledTag=0, dest_mask=0x1),
 digit_tone_mode=0
Mar 9 15:01:10: //3288/xxxxxxxxxxxx/CCAPI/cc_api_call_digit_begin: (dstVdbPtr=0x0,
 dstCallId=0xFFFFFFFF, srcCallId=0xCD8,
 digit=8, digit_begin_flags=0x0, rtp_timestamp=0x650B30
 rtp_expiration=0x0, dest_mask=0x1)
Mar 9 15:01:10: //3288/xxxxxxxxxxxx/CCAPI/cc_api_call_digit_end: (dstVdbPtr=0x0,
 dstCallId=0xFFFFFFFF, srcCallId=0xCD8,
 digit=8,duration=100,xruleCallingTag=0,xruleCalledTag=0, dest_mask=0x1),
 digit_tone_mode=0
Mar 9 15:01:10: //3288/xxxxxxxxxxxx/CCAPI/cc_api_call_digit_begin: (dstVdbPtr=0x0,
 dstCallId=0xFFFFFFFF, srcCallId=0xCD8,
 digit=5, digit_begin_flags=0x0, rtp_timestamp=0x658830
 rtp_expiration=0x0, dest_mask=0x1)
Mar 9 15:01:10: //3288/xxxxxxxxxxxx/CCAPI/cc_api_call_digit_end: (dstVdbPtr=0x0,
 dstCallId=0xFFFFFFFF, srcCallId=0xCD8,
 digit=5,duration=100,xruleCallingTag=0,xruleCalledTag=0, dest_mask=0x1),
 digit_tone_mode=0
Mar 9 15:01:10: //3288/xxxxxxxxxxxx/CCAPI/cc_api_call_digit_begin: (dstVdbPtr=0x0,
 dstCallId=0xFFFFFFFF, srcCallId=0xCD8,
 digit=5, digit_begin_flags=0x0, rtp_timestamp=0x660530
 rtp_expiration=0x0, dest_mask=0x1)
Mar 9 15:01:10: //3288/xxxxxxxxxxxx/CCAPI/cc_api_call_digit_end: (dstVdbPtr=0x0,
 dstCallId=0xFFFFFFFF, srcCallId=0xCD8,
 digit=5,duration=100,xruleCallingTag=0,xruleCalledTag=0, dest_mask=0x1),
 digit_tone_mode=0
Mar 9 15:01:10: //3288/xxxxxxxxxxxx/CCAPI/cc_api_call_digit_begin: (dstVdbPtr=0x0,
 dstCallId=0xFFFFFFFF, srcCallId=0xCD8,
 digit=5, digit_begin_flags=0x0, rtp_timestamp=0x668230
 rtp_expiration=0x0, dest_mask=0x1)
Mar 9 15:01:10: //3288/xxxxxxxxxxxx/CCAPI/cc_api_call_digit_end: (dstVdbPtr=0x0,
 dstCallId=0xFFFFFFFF, srcCallId=0xCD8,
 digit=5,duration=100,xruleCallingTag=0,xruleCalledTag=0, dest_mask=0x1),
 digit_tone_mode=0
Mar 9 15:01:10: //3288/xxxxxxxxxxxx/CCAPI/cc_api_call_digit_begin: (dstVdbPtr=0x0,
 dstCallId=0xFFFFFFFF, srcCallId=0xCD8,
 digit=5, digit_begin_flags=0x0, rtp_timestamp=0x66FF30
 rtp_expiration=0x0, dest_mask=0x1)
Mar 9 15:01:10: //3288/xxxxxxxxxxxx/CCAPI/cc_api_call_digit_end: (dstVdbPtr=0x0,
 dstCallId=0xFFFFFFFF, srcCallId=0xCD8,
 digit=5,duration=100,xruleCallingTag=0,xruleCalledTag=0, dest_mask=0x1),
 digit_tone_mode=0
Mar 9 15:01:10: //3288/xxxxxxxxxxxx/CCAPI/cc_api_call_digit_begin: (dstVdbPtr=0x0,
 dstCallId=0xFFFFFFFF, srcCallId=0xCD8,
 digit=0, digit_begin_flags=0x0, rtp_timestamp=0x677C30
 rtp_expiration=0x0, dest_mask=0x1)
Mar 9 15:01:10: //3288/xxxxxxxxxxxx/CCAPI/cc_api_call_digit_end:
Mar 9 15:01:10: //3288/xxxxxxxxxxxx/CCAPI/ccTDUtilGetDataByValue: CallID[3288],
 tagID[31], instID[-1]
Mar 9 15:01:10: dn_tone_control DN=4 chan 1 tonetype=37:DtReorderTone onoff=1
 pid=154
Mar 9 15:01:10: ephone-2[1]:DN 4 disc reason 28 invalid number state SIEZE
Mar 9 15:01:10: ephone-2[1]:SkinnySelectPhoneSoftKeys DN 4 chan 1 change
 TsRingOut to TsCallTransfer
Mar 9 15:01:10: //3288/xxxxxxxxxxxx/CCAPI/cc_api_call_disc_cause_update:
 (callID=0xCD8, cause=0x10)
Mar 9 15:01:10: //3288/7DB9A8D89271/CCAPI/cc_api_call_disc_cause_update:
 setting disc_cause to 0x10

The reason for this failed call transfer attempt is that Cisco CME takes the transfer target number (5003) and matches it with any dialplan-pattern commands configured. If there is a match, Cisco CME expands the transfer target extension (5003) to its complete E.164 number (408.555.5003) and uses that for call transfer instead of just the extension. The reason for this is that if the incoming call is from a PSTN gateway, it may not know about the extensions at all. All it might know is the phones' E.164 external numbers.

The attempt to set up a call to 408.555.5003 will fail, because Cisco CME 2 does not have a dial peer with destination pattern 408.555.5003 to route this call to Cisco CME 3.

To solve this problem, configure a dial peer on Cisco CME 2 with destination pattern 4085555... pointing to Cisco CME 3, as shown in Example 18-24. With this configuration, the transfer works fine. However, more adjustments may still be needed, as discussed next.

Example 18-24. Dial Peer from Cisco CME 2 to Cisco CME 3

CME2#show running-config
dial-peer voice 101 voip
 destination-pattern 4085555...
 session target ipv4:40.40.0.1

In Example 18-25, the transferor (Cisco CME 2) now can set up the consult call to the expanded E.164 number of extension 5003, which is 408.555.5003. However, when the transferor (Cisco CME 2) commits the transfer after the consultation call, an error occurs, even though the end-to-end consult call transfer worked. What happens is that the transferor (Cisco CME 2) asks the transferee (Cisco CME 1) to set up a call to the transfer target (Cisco CME 3), passing the complete E.164 number of the transfer target (408.555.5003). However, the transferee (Cisco CME 1) does not have a dial peer for that destination pattern, so it returns an error indicating that it cannot set up the transferred call.

After receiving the error from the transferee (Cisco CME 1), the transferor (Cisco CME 2) hairpins the transferee-transferor (Cisco CME 12) call leg to the transferor-transfer target (Cisco CME 23) call leg. Two call legs exist on the transferor (Cisco CME 2) even though the transferor phone is no longer part of the call. You can verify this situation by using the show voip rtp connections command on the transferor node, as shown in Example 18-25.

Example 18-25. Hairpin Call Caused by the Lack of an E.164 Dial Peer on the Transferee

CME2#debug voip ccapin inout
CME2#debug ephone state
Mar 10 14:51:38: ephone-2[1]:TransferButtonPress
Mar 10 14:51:38: ephone-2[1]:Commit Transfer with Consult for DN 2 chan 1 using
 consult DN 4 chan 1
Mar 10 14:51:38: ephone-2[1]:HoldButtonPress (allow_toggle = 0)
......
Mar 10 14:51:38: //3298//APPL:/AppConsultRequest:
Mar 10 14:51:38: AppLegH450TransferNotSupported: remote end is h450.2 capable
Mar 10 14:51:38: //3298//APPL:/AppIdentifyRequest:
Mar 10 14:51:38: //3298//APPL:/SSMapEvent: SS_IDENTIFY_RESP: identify[17]
 rerouteNo[4085555003] invokeID[1508]
Mar 10 14:51:38: //3297//APPL:/AppConsultResponseSuccess: consuldID[17]
Mar 10 14:51:38: //3297//APPL:/AppSSReturnResult:
Mar 10 14:51:38: ephone-2[1]:SkinnyConsultIDResponse DN 2 chan 1 explicit target
 4085555003 orig 5003 redirected= []
Mar 10 14:51:38: ephone-2[1]:SkinnyConsultIDResponse ActivateTransfer DN 2 chan 1
 to 4085555003 id [17]
Mar 10 14:51:38: ephone-2[1]:Bator Call Transfer DN 2 chan 1 consult_dn 4 chan 1
 to 4085555003 id [17]
Mar 10 14:51:38: ephone-2[1]:SkinnyConsultIDResponse DN 2 chan 1 Fix Up eDSP
 state can't find local transferee DN (resetting)
Mar 10 14:51:38: DN 2 Call Transfer ID=[17] for callID 3296 to 4085555003
 (expanded)
Mar 10 14:51:38: ephone-2[1]:Transfer Request OK for DN 2 chan 1
Mar 10 14:51:38: //3296//APPL:/SSMapEvent: SS_INIT_IND: rerouteNo[4085555003]
 identify[17] invokeID[3300] transferringNo[6002] peer[0] xto_callID[0]
Mar 10 14:51:38: AppLegH450TransferNotSupported: remote end is h450.2 capable
Mar 10 14:51:38: //3295//APPL:/AppTransferInitiateRequest: to [4085555003] with
 ID[17]
Mar 10 14:51:38: //3295//APPL:/AppTransferRequest:
Mar 10 14:51:38: AppLegH450TransferNotSupported: remote end is h450.2 capable
Mar 10 14:51:38: //3295//APPL:/AppTransferRequest: SS_INIT:rerouteNo[4085555003]
 ID[17]
Mar 10 14:51:38: //3295//APPL:/SSMapEvent: SS_RETURN_ERROR [10]
Mar 10 14:51:38: AppRedirectStatusUpdateAVlist:
Mar 10 14:51:38: //3295//APPL:/AppRedirectStatusUpdateAVlist: unable to get CallID
 to update AVlist
Mar 10 14:51:38: RD_Transferring_FAILED: ***** convert SSXFER 10 to RD status 14
 *********

Mar 10 14:51:38: //-1//APPL:LG3295:/AppHandOffLocalTRT: Leg 3295's protocol=2
 Leg -1's protocol=-1
Mar 10 14:51:38: //-1//APPL:HN4CC44348:LG3295:/AppHandOffLocalTRT:
ccSetupIndQueryRegistration
Mar 10 14:51:38: //3295//APPL:/AppHandOffLocalTRT: handoff to local TRT, transfer
 is done

CME2#show voip rtp connections
VoIP RTP active connections :
No. CallId dstCallId LocalRTP RmtRTP LocalIP RemoteIP
1 3295 3298 18768 17956 1.3.28.28 1.3.6.26 
2 3298 3295 18810 17720 1.3.28.28 1.3.6.33 
Found 2 active RTP connections

Note

The transferor (Cisco CME 2) has two RTP streams: one to the transferee (Cisco CME 1) and one to the transfer target (Cisco CME 3). This is undesirable if all the devices involved in the call transfer can support the H.450.2 protocol, because this can consume more bandwidth on your WAN than it is engineered for. To fix this problem, configure a dial peer on the transferee (Cisco CME 1) with destination pattern 4085555... pointing to the transfer target (Cisco CME 2). This dial peer is exactly the same as the one you added on Cisco CME 2, as shown in Example 18-24.

 

Using Hairpinned Calls

The previous discussion covered how an erroneous configuration can lead to a transfer failure or an inefficient transfer. There are some scenarios where you may have to use hairpinned calls and plan for the additional bandwidth and resource use. An example of such a scenario is a PSTN gateway that is running an old version of Cisco IOS, such as 12.2.8T, or you have a non-Cisco H.323 device in the network. These devices don't support the H.450 protocol.

If any of the Cisco CME nodes receives a call from such a gateway and that call is transferred to another gateway, using hairpinned calls is the only option. However, you may notice in such cases that after you commit the transfer, it takes a few seconds for the transfer to complete. That is because the transferor is waiting for the transferee to acknowledge the successful call setup between transferee and transfer target. Because the transferee cannot use H.450, it cannot set up that call, and the transferor waits for a timeout period before it hairpins the transfer. To avoid this delay, configure H.450.12 on the transferor Cisco CME, as discussed in Chapter 7.

Troubleshooting Common Problems with Network Call Forward

In the preceding sections, you learned how some configuration items affect network call transfers. This section explores how configurations affect network call forwards.

Cisco CME supports three types of H.323 call forward implementations:

• A Cisco-proprietary method implemented before the industry-standard H.450 suite of protocols was supported by Cisco IOS
• An H.450-based call forward method
• A method called a hairpinned call forward, in which the forwarding gateway sets up a call leg to the forward-to target and then bridges it with the call leg that was supposed to be forwarded

The H.450 method is the recommended and most efficient call forwarding mechanism, provided that all the network devices in your network support it. For this method to be invoked by Cisco CME, a call-forward pattern configuration is required, as shown in Example 18-26. This configuration informs Cisco CME which calling numbers support the H450.3 method of call forwarding. If every network device in your network supports this method, using call-forward pattern .T is the easiest way to configure the feature globally to apply to all calls. If this configuration is missing in Cisco CME, call forwards may not work.

Example 18-26. Configuring and Displaying the Call Forward Pattern

CME3(config)#telephony-service
CME3(config-telephony)#call-forward pattern .T
......
CME#show telephony-service
CONFIG (Version=3.1)
=====================
Version 3.1
Cisco CallManager Express
ip source-address 40.40.0.1 port 2000
max-ephones 10
max-dn 20
max-conferences 3
max-redirect 5
dialplan-pattern 1 4085555... extension-length 4 extension-pattern 5...
dialplan-pattern 2 6505558... extension-length 4 extension-pattern 8...
dialplan-pattern 3 4155556... extension-length 4 extension-pattern 6...
dialplan-pattern 4 5105559... extension-length 4 extension-pattern 9...
voicemail 7200
mwi relay
mwi expires 68000
time-format 12
date-format mm-dd-yy
call-forward pattern .T 

There is another common scenario in which H.450.3 call forward fails. Assume that Cisco CME1 in Figure 18-6 has an analog PSTN line with a caller ID blocking configuration. A call from this line arrives at a far-end Cisco CME, such as Cisco CME2, with no calling number. For Cisco IOS to complete an incoming call, it must have an incoming dial peer to associate with the call so that it can negotiate call attributes. The problem being faced here is that the Cisco CME receiving this call (CME2) cannot identify an incoming dial peer to associate with the call, because it arrives with no calling number. So the attributes selected for this call are from default dial peer 0, where H.450 is disabled. You can see this problem in the debug shown in Example 18-27. Notice the empty calling number.

Example 18-27. H450.3 Is Disabled When a Call Arrives with No Caller ID

CME2#debug voip ccapin inout
CME2#debug voip ivr supplementary-service
Dec 13 20:29:00.860: //-1/529ACE8D8189/CCAPI/cc_api_display_ie_subfields:
 cc_api_call_setup_ind_common:
 cisco-username=1.4.14.28
 ----- ccCallInfo IE subfields -----
 cisco-ani=
 cisco-anitype=0
 cisco-aniplan=0
 cisco-anipi=0
 cisco-anisi=0
 dest=5002
 cisco-desttype=0
 cisco-destplan=0
 cisco-rdn=
 cisco-rdntype=-1
 cisco-rdnplan=-1
 cisco-rdnpi=-1
 cisco-rdnsi=-1
 cisco-redirectreason=-1
Dec 13 20:29:00.860: //-1/529ACE8D8189/CCAPI/cc_api_call_setup_ind_common:
 Interface=0x4481252C, Call Info(
 Calling Number=(TON=Unknown, NPI=Unknown, Screening=Not Screened,
 Presentation=Allowed),
 Called Number=5002(TON=Unknown, NPI=Unknown),
 Calling Translated=FALSE, Subsriber Type Str=Unknown,
 FinalDestinationFlag=TRUE,
 Incoming Dial-peer=0, Progress Indication=ORIGINATING SIDE IS NON ISDN(3),
 Calling IE Present=FALSE,
 Source Trkgrp Route Label=, Target Trkgrp Route Label=,
 CLID Transparent=FALSE), Call Id=14501
......
Dec 13 20:29:05.868: //-1/xxxxxxxxxxxx/CCAPI/ccUpdateRedirectNumber:
 Original Called Number=5002, Calling Number=, Calling DN=-1,
 Redirect Number=7200, Redirect Reason=2
Dec 13 20:29:05.868: ephone-1[3]:SetCallState line 2 DN 2 chan 1 ref 2620 TsOnHook
Dec 13 20:29:05.868: dn_tone_control DN=2 chan 1 tonetype=0:DtSilence onoff=0
 pid=160
Dec 13 20:29:05.868: //14502/529ACE8D8189/CCAPI/cc_api_call_disconnect_done:
 Disposition=0, Interface=0x44F05038, Tag=0x0, Call Id=14502,
 Call Entry(Disconnect Cause=19, Voice Class Cause Code=0, Retry Count=0)
Dec 13 20:29:05.868: //14502/529ACE8D8189/CCAPI/cc_api_call_disconnect_done:
 Call Disconnect Event Sent
Dec 13 20:29:05.868: ephone-1[3]:SpeakerPhoneOnHook
Dec 13 20:29:05.868: ephone-1[3]:Ringer Off
Dec 13 20:29:05.872: AppLegH450CallFwdNotSupported: h450.3 is being disabled on 
 this voip dial-peer
Dec 13 20:29:05.872: //-1//APPL:/AppPrepareForwardSetup:

The first thing to do to fix this problem is to assign (on CME1) a caller ID on the incoming analog PSTN line using the station-id number and station-id name commands in Cisco IOS under the voice-port for corresponding analog voice ports on Cisco CME1, as shown in Example 18-28.

The next thing to do is to configure (on CME2) an explicit VoIP dial peer to match the caller ID that will be delivered by the analog trunks on CME1. Or, if all the devices in your network support H.450.3, and there is no specific pattern for calling numbers, the easiest way is to have a VoIP dial peer that matches all calling numbers. Explicit VoIP dial peers have H.450.3 enabled by default. The added dial peer should also have other parameters, such as codec and DTMF relay configurations, according to your needs. Example 18-28 shows a sample configuration.

Example 18-28. Configuration to Match the Incoming Dial Peer for H.450

!On Cisco CME1
CME1(config)#voice-port 2/1/0
CME1(config-voiceport)#station-id number 9
CME1(config-voiceport)#station-id name PSTN

!On Cisco CME2
CME2(config)#dial-peer voice 1 voip
CME2(config-dial-peer)#incoming called-number .
CME2(config-dial-peer)#dtmf-relay h245-alphanumeric

Troubleshooting Transcoding