Hard coding speed & duplex 一定是對的嗎? 那可不一定哦!!

 

為了避免 speed/duplex mismatch 的問題, 很多 configuration guide 都會建議在 switch 端 和 end node 端把 speed/duplex 固定住 , 以免產生 duplex mismatch 的問題。這個原則我也已經奉行很久了, 一直沒有遇到什麼問題, 直到那天.....

事情要先從某個 branch office 要 deploy video conference 設備說起。因為 MPLS WAN 的 BW 有限, 所以目前是讓 video conf 跑在 Internet 上, 因此也採購了 firewall , router 和 10M Internet circuit。

FW (e0/0-outside) <-------> (f0/1-LAN ) Router (f0/0-WAN) <----------> ISP BB

根據前面提的經驗法則, 很自然的把 FW, Router Interfaces 的 speed/duplex 都設成 100/full。經過簡單的測試後 Video Conf 的 call 也都能 setup 成功, 因此很快就結案。

But, 當系統啟用後, 有大頭級的使用者抱怨 quality 不好, 所以就開始進行 troubleshooting。透過 Video conference device 的管理介面發現有 packet loss 的問題, 便開始先從 Internet 檢查起。 先確定是否有 asymmetric routing issue (因為兩個 site 在不同國家), 也請 ISP re-route 看是否能解決, 但是都沒有用, packet loss issue 依然存在。

因為 packet loss 的問題只有 one-way, 開始懷疑packet是不是被ISP drop(CIR 10M)了?  因此重新設定了 Video conference 和 router 的 QoS, 結果還是一樣。

正在納悶的時候, 突然注意到在 FW (ASA OS8.0.4) 的 e0/0 (outside) 是 100/half, 看來是我老了, 忘了在 fw 端設成 100/full了, 當下就趧快把它改過來了。

Ya~ 搞定了嗎!?.....................NO, 才怪! Router 和 FW outside 連線竟然斷了!!

再確認一次 FW 和 Router 的介面設定, 設定都對。心裏有種見鬼了的感覺。

ASA(config-if)# sh run int e0/0
!
interface Ethernet0/0
speed 100
duplex full
nameif outside
security-level 0

Router#sh run int f0/1
interface FastEthernet0/1
description To_Customer_LAN
load-interval 30
duplex full
speed 100

FW介面是 down/down, 而 Router 則是 up/down。 我是在作夢嗎?

ASA(config-if)# sh int e0/0
Interface Ethernet0/0 "outside", is down, line protocol is down
  Hardware is i82546GB rev03, BW 1000 Mbps, DLY 10 usec
        Auto-Duplex(Half-duplex), Auto-Speed(100 Mbps)
        MAC address c84c.7552.15b8, MTU 1500
        IP address 203.117.9.146, subnet mask 255.255.255.240
        42260544 packets input, 32562517068 bytes, 0 no buffer
        Received 103466 broadcasts, 0 runts, 0 giants
        0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
        0 L2 decode drops
        34853064 packets output, 10635547375 bytes, 0 underruns
        0 output errors, 71776 collisions, 2 interface resets
        0 babbles, 86297 late collisions, 437184 deferred
        0 lost carrier, 0 no carrier
        input queue (curr/max packets): hardware (0/17) software (0/0)
        output queue (curr/max packets): hardware (0/0) software (0/0)

SGSIN-B01F09C01-RTI01#sh int f0/1
FastEthernet0/1 is up, line protocol is down
  Hardware is MV96340 Ethernet, address is fcfb.fba0.6541 (bia fcfb.fba0.6541)
  Description: To_Customer_LAN
  Internet address is 203.117.9.145/28
  MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Full-duplex, 100Mb/s, 100BaseTX/FX
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 03:19:21, output 00:00:09, output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  30 second input rate 0 bits/sec, 0 packets/sec
  30 second output rate 0 bits/sec, 0 packets/sec
     34853769 packets input, 1906329303 bytes
     Received 1 broadcasts, 80319 runts, 0 giants, 0 throttles
     163190 input errors, 82871 CRC, 0 frame, 0 overrun, 0 ignored
     0 watchdog
     0 input packets with dribble condition detected
     42656842 packets output, 2314899508 bytes, 0 underruns
     0 output errors, 0 collisions, 2 interface resets
     0 unknown protocol drops
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier
     0 output buffer failures, 0 output buffers swapped out

Bounce 了幾次 interface 都沒用, 最後乾脆都改成 auto/auto, 沒想到一改居然通了, 不信邪又改回 100/full , 結果又斷了。

我想應該是 bug 吧, 不過這又再一次印證了 troubleshooing 雖然有經驗法則, 但是實務上還是要靈活一點, 不要預設任何設定一定都是對的, 否則可能會浪費很多時間。

Troubleshooting Echo Problems between IP Phones and IOS Gateways

 

Introduction

This document describes how to troubleshoot and eliminate echo where possible in IP Telephony networks with Cisco IOS® gateways.

There are two sources of echo:

• Hybrid echo

• Acoustic echo

Hybrid echo is caused by an impedance mismatch in the hybrid circuit, such as a two-wire to four-wire interface. This mismatch causes the Tx signal to appear on the Rx signal.

Acoustic echo is caused by poor acoustic isolation between the earpiece and the microphone in handsets and hands-free devices.

Echo is perceived as annoying when all of these conditions are true:

• Signal leakage between the analog Tx and Rx paths.

• Sufficient delay in echo return.

• Sufficient echo amplitude.

Echo in Packet Voice Networks

The packet segment of the voice connection introduces a significant delay (typically 30 ms in each direction). The introduction of delay causes echoes (from analog tail circuits), that were normally indistinguishable from the side tone, to be now perceived by the user.

The delay introduced by packet voice is unavoidable. Therefore, the voice gateways must prevent the echo. This diagram illustrates how the gateway can reduce the echo before it can enter the packet voice network with the use of an echo canceler.

Refer to Echoed Voice for more information on echo in voice networks.

Prerequisites

Requirements

There are no specific prerequisites for this document.

Components Used

This document is not restricted to specific software and hardware versions.

Conventions

Refer to Cisco Technical Tips Conventions for more information on document conventions.

PSTN Phone User Hears Echo

The problem exists when the PSTN phone user hears echo which is caused by acoustic coupling between the earpiece and the microphone in the IP phone handset.

The solution is to use a load ID on the IP phone, which includes echo suppression on the handset and headset. Currently, available load IDs only include echo cancellation on the speaker phone. However, there are some known issues such as talker echo and acoustic echo from IP phone to IP phone with an older load ID. Refer to Release Notes for Cisco IP CallManager Firmware for 7960, 7940, and 7910 Series Phones if you experience such issues in order to decide if an upgrade to the latest load ID can resolve the issue.

IP Phone User Hears Echo

The problem exists when IP phone users hear echo caused by hybrids in a PSTN network.

The solution is to configure and verify echo cancellation operation on a Cisco IOS gateway. The echo canceler in the voice gateway cancels the echo heard by the IP phone user.

Troubleshoot Echo in Gateways with Cisco IOS Software Releases 12.4

Intermittent echo can be heard on voice gateways that run Cisco IOS Software Release 12.4 with DSPWare 4.4.13 or 4.4.14. This is a known issue documented in Cisco bug ID CSCsd54344 ( registered customers only) . In order to resolve this issue, you need to downgrade DSPware to 4.4.12 or earlier. Contact the Cisco Systems Technical Assistance Center (TAC) in order to obtain assistance in downloading the DSPware image.

Hardware ECAN (MFT-EC-32/MFT-EC-64) on VWIC2-xMFT-T1E1 does not cancel voice echo. This is a known issue documented in Cisco bug ID CSCsb59252 ( registered customers only) .

Troubleshoot Echo Problems with these DSP Voice Quality Metrics

• Check the delay (DSP/DL) and R-factor (DSP/RF) statistics. You can potentially find perceptible delay between when the originating signal is transmitted and when the echo returns. In most telephones, sidetone helps mask some of the echo. Echos must be delayed by at least 20 milliseconds in order to be perceived.

• Check the level (DSP/LE) statitstic for sufficient echo amplitude. If the amplitude of the echo is low, it can go unnoticed.

Troubleshoot Echo in Gateways with Cisco IOS Software Releases Prior to 12.2.11T

Cisco IOS Gateway Parameters for when you Troubleshoot Echo

It is important to make sure that the echo canceler has enough information to distinguish between echo and voice conversation. The available parameters to control the distinction are:

• Input Level—Input gain of a signal is performed before the echo canceler sees the echo.

• Output Level—Output attenuation of a signal is performed after the echo canceler sees the original output signal.

• Echo Canceler Coverage—The amount of time the echo canceler remembers a signal that has been output. This parameter must be set to a value greater than the time the echo needs to return to the gateway.

Step-by-step Procedure to Troubleshoot and Eliminate Echo

Complete these steps to eliminate echo.

1. Verify that echo cancellation is enabled on the voice port. Echo cancellation is enabled by default.

   Gateway(config-voiceport)#echo-cancel
      coverage   Echo Cancel Coverage 
      enable     Echo Cancel Enable

   
   

   
   
   

   Note: You must shut, then no shut the voice port for the changes to take effect.

   
   



2. 
   

   Configure the echo canceler coverage to a value greater than the time the echo needs to return to the gateway, so that it is long enough to cover the worst case for your environment, but not longer.

   
   
   

   
   

   Gateway(config-voiceport)#echo-cancel coverage
      16  16 milliseconds echo canceler coverage 
      24  24 milliseconds echo canceler coverage 
      32  32 milliseconds echo canceler coverage 
      8   8 milliseconds echo canceler coverage

   
   

   
   
   

   Note: You must shut, then no shut the voice port for the changes to take effect.

   
   
   

   Note: The default coverage is set to 8 ms, but you can increase it up to 32 ms. If the PSTN delay (tail length) is more than 32 ms, current echo cancelers in Cisco IOS gateways are not able to cancel the echo. In Cisco IOS Software Release 12.2.13T and later, the echo coverage can be configured up to 64 ms. See the Echo Canceler Enhancements in Cisco IOS releases 12.2.11T and 12.2.13T section of this document.

   
   



3. 
   

   Measure the echo and adjust the echo signal level as required.

   
   
   

   Insufficient echo return loss (ERL) to handle the echo might cause these problems:

   
   
   
   
   
   • 
     

     Echo canceler does not cancel, but not enough to make echo inaudible.

     
     
     

     If the ERL value is too low, the total echo return loss seen by the IP network (ACOM) might be insufficient to suppress the echo. ERL needs to be approximately 20 dB (at least 15 dB).

     
     
     

     Note: Acombined (ACOM) is the total echo return loss seen across the incoming and outgoing terminals of the echo canceler (incoming terminal = signal into the ECAN toward the PSTN (voice), and outgoing terminal = signal out of the ECAN toward the IP network (echo)). ACOM is the sum of ERL + ERLE, or the total echo return loss seen by the network.

     
     
     

     Note: ACOM (Total loss) = ERL (Tail loss) + ERLE (ECAN loss)

     
     
   
   
   
   • 
     

     Echo canceler does not cancel.

     
     
     

     If the ERL value is too low, the echo signal that returns to the gateway might be too loud (within 6 dB of the talker signal). This causes the echo canceler to consider it as voice (double-talk) instead of echo. As a consequence, the echo canceler does not cancel it. ERL needs to be approximately 6 dB or higher for the echo canceler to engage. In Cisco IOS Software Release 12.2.13T, you can configure this ERL level. See the Echo Canceler Enhancements in Cisco IOS Software Releases 12.2.11T and 12.2.13T section of this document.

     
     
     

     In order to prevent these problems, measure the ERL and signal levels. Then adjust the signal levels on the Cisco IOS gateway based on the results. Configure positive values for output attenuation and negative values for input gain to adjust these levels. Input gain is performed before the echo canceler sees the echo signal, and output attenuation is performed after the echo canceler sees the original output signal.

     
     
     

     
     

     voice-port 1/1:15 
        input gain -3 
        output attenuation 3

     
     

     
     
   
   
   
   
   

   Note: You must shut, then no shut the voice port for the changes to take effect.

   
   
   

   Note: In Cisco IOS Software Release 12.2(1) and later, output attenuation can be set to a negative value which actually amplifies the output signal.

   
   



4. 
   

   Echo can also be caused by an impedance mismatch if both sides are not configured identically. Verify, and modify if needed, the impedance configured in the voice port. A default of 600 ohms is consistent with most lines on the PSTN and PBXs.

   
   
   

   
   

   Gateway(config-voiceport)#impedance
     600c 600 Ohms complex
     600r 600 Ohms real
     900c 900 Ohms complex
     complex1 complex 1
     complex2 complex 2

   
   

   
   

Echo Canceler Enhancements in Cisco IOS Software Releases 12.2.11T and 12.2.13T

Echo Suppressor

Enable echo suppressor to reduce the echo during the first two to three seconds of a call, while the echo canceler converges.

Configuration

gateway(config-voiceport)#echo-cancel ? 
  coverage    Echo Cancel Coverage 
  enable      Echo Cancel Enable 
  suppressor  echo suppressor

Software and Hardware Platforms Supported

Echo suppressor is supported in Cisco IOS Software Releases 12.2(11)T, 12.2(12), and 12.2(8)T5. The echo suppressor can only be used on T1 digital signal processors (DSPs) when the default Cisco G.165 EC is used. The echo suppressor cannot be used with the extended EC or on NextPort (Cisco AS5350 and Cisco AS5400) platforms. Except for the extended EC or on NextPort (Cisco AS5350 and Cisco AS5400) platforms, echo suppressor is supported in all platforms and all complexities (c549, c542 and c5409).

Extended Echo Canceler

Configuration

In addition to the default echo canceler used in the Cisco voice gateways (G.165 compliant), a new echo canceler is available in some of the platforms (G.168 compliant). The extended echo canceler provides:

• 
  

  Tail coverage of up to 64 ms.

  
  
  

  Enable the extended echo canceler to eliminate the echo when the tail coverage is greater than 32 ms.

  
  



• 
  

  Faster convergence.

  
  
  

  Enable the extended echo canceler to reduce the echo during the first two to three seconds of a call, while the echo canceler converges. Echo suppressor is not required anymore when you enable the extended echo canceler.

  
  



• 
  

  ERL can be tuned.

  
  
  

  Enable the extended echo canceler to eliminate the echo when ERL cannot be tuned lower than 6 dBm.

  
  

Extended echo cancellation is configured differently based on the version of Cisco IOS software you use. If you use Cisco IOS Software Release 12.3(4)XD or later, you do not have to use any Cisco IOS commands to enable the Enhanced ITU-T standard G.168 Echo Cancellation feature because the extended G.168 EC is the only available echo canceller. You have the option to disable the extended EC, but Cisco highly recommends that you leave it enabled.

The Cisco Enhanced ITU-T G.168 ECAN feature can be run either on the dedicated ECAN modules or the general voice resources that reside on the platform, network module, or advanced integration module. For example, Cisco 2800 Series and 3800 Series integrated services routers can use either the packet voice DSP modules (PVDM2s) mounted in the router chassis or the digital signal processor (DSP) resources on network modules to run the G.168 ECAN feature. When the G.168 ECAN feature is run on general voice resources, processing and memory constraints limit it to have at most 64-ms echo tailcoverage. Although this is adequate in most network conditions, a largerecho tail coverage is sometimes required. In these situations, the dedicated ECAN modules, attached to the appropriate MFT VWIC2, can be used. The processing and memory resources of the dedicated ECAN modules enable the echo canceller to be configured with predefined settings and an extended 128-ms echo tail buffer, which provides robust echo cancellation performance.

Reference:

http://www.cisco.com/en/US/tech/tk652/tk698/technologies_tech_note09186a0080149a1f.shtml

Troubleshoot Legacy Voice Mail Integration with Cisco CallManager

Introduction

This document troubleshoots the integration of legacy voice messaging systems with Cisco CallManager that utilize Simplified Message Desk Interface (SMDI) and Digital PBX Adaptor (DPA) 7630/7610.

Prerequisites

Requirements

Readers of this document should have knowledge of these topics:

• Cisco CallManager 3.x or 4.x

• Telcordia GR 283-core Issue 2 (SMDI)

• Octel Voice Mail, if applicable (DPA -7630/7610)

Components Used

The information in this document is based on these software and hardware versions:

• Cisco CallManager 3.x and 4.x

• Cisco MCS-7835

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Conventions

Refer to the Cisco Technical Tips Conventions for more information on document conventions.

SMDI Integration with Cisco CallManager

The Cisco Messaging Interface is a service within Cisco CallManager that allows legacy voice mail platforms to connect to Cisco CallManager with the use of SMDI. The Cisco Messaging Interface provides information to a legacy voice mail system about the called and calling party, the reason why the call is presented, and which port the voice mail system should expect the call on. This allows the voice mail system to answer the call correctly.

There are two call types with SMDI:

• Direct call

• Forwarded call

Direct Call Format

The direct call SMDI format is:

• <CR><LF>MDXXXLLLLT<0x20>YYYY<0x20><CR><LF><^Y>

<CR>
Carriage Return

<LF>
Line Feed

MDXXX
Message Desk. This is a 3 digit field, usually 001

LLLL
Logical Terminal Number (0001 ? 4096)

T
Reason Code - D equals Direct Call

<0x20>
Space

YYYY
Calling Party Number

<0x20>
Space

<CR>
Carriage Return

<LF>
Line Feed

<^Y>
End of Medium

This is an example of a direct call from extension 2000. It was presented to the voice messaging system on LTN 0002, or port 2.

• <CR><LF>MD0010002D<0x20>2000<0x20><CR><LF><^Y>

Troubleshoot a Direct Call

When a caller places a direct call, the caller expects to be prompted to enter their password. In order for that to occur, the gateway, route list and route group to the voice mail system must be configured as Configuring Cisco CallManager 3.0(x) for Integration to Voice Mail Systems via SMDI describes. The most common reason for a direct call to fail is a misconfiguration between either the Message Desk or the Logical Terminal Number (LTN). The Cisco Messaging Interface uses the Message Desk of 001 by default. If you have been given another message desk by either a Private Branch Exchange (PBX) vendor or a central office (CO), you must specify that in the Cisco Messaging Interface configuration.

If the MessageDeskNumber is correct, verify that the LTN is correct. On the Cisco CallManager side, the LTN equates to the ports you configured in the route group. The first port is LTN 1, the second port is LTN 2, and so on. This is why it is essential to configure the Port and Order drop-downs as Configuring Cisco CallManager 3.0(x) for Integration to Voice Mail Systems via SMDI describes. If all ports are chosen, the LTN generated by the Cisco Messaging Interface is LTN 1. This results in failed integration. On the voice mail side, it is essential to ensure that the cabling is correct between the gateway and voice mail ports. Since the SMDI message indicates which port (LTN) the call is being presented to the voice mail system on, all Layer 1 issues have to be resolved.

A second common reason why a direct call to voice mail fails is a misconfiguration of the VoiceMailPartition field in the Cisco Messaging Interface.

The VoiceMailPartition field needs to contain the name of the partition that is assigned to the route pattern that points to the route list for voice mail. If this information is incorrect, the intercept for the VoiceMailDn is not triggered and no SMDI message is generated. Consequently, the voice mail system does not have the proper information to process the call as desired, and answers with a generic greeting.

Verify that the SMDI link is UP on the voice mail side, if your voice mail system relies upon this. Cisco CallManager runs on a standard PC, which means it has nine pins that are actually wired to the serial port. However, Cisco Messaging Interface only uses three of the RS-232 lines: TD, RD, and GND. There are two outbound control lines: RTS and DTR. These are both asserted when the port is opened, but Cisco Messaging Interface does not care if the lines are ignored or not. There are four incoming control lines: DCD, CTS, DSR, and RI. All of these lines are also ignored.

Direct Call Trace from CMI

For troubleshooting issues with SMDI, examine the Cisco Messaging Interface trace files located in the C:/Program Files/Cisco/Trace/CMI directory.

19:27:58.578 Cisco Messaging Interface|   CMISsapiClient::RecvSsCallInfoResMsg()
Received RecvSsCallInfoResMsg userdata = 5996360, Key = 7864, DSL2 = 2,
calledparty =3500, callingparty =2000
19:27:58.578 Cisco Messaging Interface|   CMISsapiClient::RecvSsCallInfoResMsg()
Direct Call port - 2, callingparty -2000
19:27:58.578 Cisco Messaging Interface|-->CMISsapiClient::SendDirectCall()
19:27:58.578 Cisco Messaging Interface|   CMISsapiClient::SendDirectCall()

This is an example of a direct call from extension 2000. It was presented to the voice messaging system on LTN 0002, or port 2.

• 
  

  Send direct call : [<CR><LF>MD0010002D<0x20>2000<0x20><CR><LF><^Y>]

  
  

Once you validate that the Cisco Messaging Interface intercepts the VoiceMailDn and generates SMDI messages, you can work with the voice mail vendor to ensure that the message is received. If the voice mail system does not receive any SMDI messages, even though the Cisco Messaging Interface generates them, a PC with hyper terminal can be used to demonstrate whether they leave the Cisco CallManager server.

Forwarded Call Format

Cisco CallManager 3.0 supports the forward reason code of A for All Calls forward. In Cisco CallManager 3.1 and later, the reason codes B and N are added for Busy and No Answer, respectively.

The forwarded call format is:

• 
  

  <CR><LF>MDXXXLLLLTDDDDDDD<0x20>CCCCCCC<0x20><CR><LF><^Y>

  
  

<CR>

Carriage Return

<LF>

Line Feed

MDXXX

Message Desk. Number xxx is normally 001

LLLL

Logical Terminal Number (0001 - 4096)

T

Call Type. A is All Calls Forwarded (supported by CM 3.0), B is Busy Forward (CM 3.1), N is for Ring No Answer (CM 3.1)

DDDDDDD

Called Party

<0x20>

Space

CCCCCCC

Calling Party

<0x20>

Space

<CR>

Carriage Return

<LF>

Line Feed

<EM>

End of Medium

This is an example of a forwarded call from extension 2000 to extension 2001. The call is sent to voice mail because the called party's phone is in a Call Forward All state. The call is presented to the voice messaging system on LTN 0002, or port 2.

• 
  

  [<CR><LF>MD0010002A2001<0x20>2000<0x20><CR><LF><^Y>]

  
  

Troubleshoot a Forwarded Call

When a caller places a call to another party and is forwarded to voice mail, the expectation is that they receive the called party's greeting. In order for that to occur, gateway to the voice mail system must be configured as described in Configuring Cisco CallManager 3.0(x) for Integration to Voice Mail Systems via SMDI. Ensure that direct calls work before you try to troubleshoot forwarded calls.

When you troubleshoot forwarded calls, check to ensure that the legacy voice mail system supports the forwarded reason code. Some voice mail systems allow for the programming of the various reason codes. In some cases, where the Cisco CallManager was deployed before version 3.1, the voice mail system may not have been programmed to accept the Busy and No Answer forwarded reason code, since Cisco CallManager did not support them at that time.

Forwarded Call Trace from Cisco Messaging Interface

When you troubleshoot issues with SMDI, examine the Cisco Messaging Interface trace files located in the C:/Program Files/Cisco/Trace/CMI directory.

18:33:28.187 Cisco Messaging Interface|   CMISsapiClient::RecvSsCallInfoResMsg()
Received RecvSsCallInfoResMsg fOriginalCdpn = 2001, fCgpn = 2000 fCallingPattern
= 2000
18:33:28.187 Cisco Messaging Interface|   CMISsapiClient::RecvSsCallInfoResMsg()
Received RecvSsCallInfoResMsg userdata = 5996336, Key = 7864, DSL2 = 2,
calledparty = 2001, callingparty = 2000
18:33:28.187 Cisco Messaging Interface|   CMISsapiClient::RecvSsCallInfoResMsg()
Forwarded Call port - 2, calledparty - 2001, callingparty - 2000
18:33:28.187 Cisco Messaging Interface|-->CMISsapiClient::SendCallForwardAll()
18:33:28.187 Cisco Messaging Interface|   CMISsapiClient::SendCallForwardAll()
Send call forward all: [<CR><LF>MD0010002A2001<0x20>2000<0x20><CR><LF><^Y>]
18:33:28.187 Cisco Messaging Interface|-->CMISerialWorker::SendBuffer()
18:33:28.187 Cisco Messaging Interface|   CMISerialWorker::SendBuffer()
Send Buffer - <CR><LF>MD0010002A2001<0x20>2000<0x20><CR><LF><^Y>
18:33:28.197 Cisco Messaging Interface|<--CMISerialWorker::SendBuffer()
18:33:28.197 Cisco Messaging Interface|<--CMISsapiClient::SendCallForwardAll()

This is an example of a forwarded call from extension 2000 to extension 2001. The call is sent to voice mail because the called party's phone is in a Call Forward All state. The call is presented to the voice messaging system on LTN 0002, or port 2.

Once you validate that the Cisco Messaging Interface intercepts the VoiceMailDn and generates SMDI messages, you can work with the voice mail vendor to ensure that the message is received. If the voice mail system does not receive any SMDI messages, even though the Cisco Messaging Interface generates them, a PC with hyper-terminal can be used to demonstrate whether they are leaving the Cisco CallManager server.

MWI Format

The format for message waiting on and off commands is:

MWI On: OP:MWI<0x20>XXXX!<EOT>

OP:MWI

Operate Message Waiting Indicator

<0x20>

Space

XXXX

Extension number

<EOT>

End of Transmission

Example:

OP:MWI<0x20>2001!<EOT>


A request to turn on message waiting for extension 2001.

MWI Off: RMV:MWI<0x20>XXXX!<EOT>

RMV:MWI

Remove Message Waiting Indicator

<0x20>

Space

XXXX

Extension number

<EOT>

End of Transmission

Example:

RMV:MWI<0x20>2001!<EOT>


A request to turn off message waiting for extension 2001.

Troubleshoot MWI

When you troubleshoot MWI issues with SMDI, the first step is determine whether or not the request is received by Cisco CallManager. The Cisco Messaging Interface trace files located at C:/Program Files/Cisco/Trace/CMI reveal whether or not the SMDI message is sent by the voice mail system and received by Cisco CallManager.

If the request is received by the Cisco CallManager, but MWI does not work correctly, verify that the MWI SearchSpace field in the Cisco Messaging Interface contains the partition that belongs to the phone whose lamp is being requested to be turned on/off. The MWISearchSpace field needs to contain the names of the partitions separated by a colon. This field is case sensitive.

MWI Traces from Cisco Messaging Interface

MWI On

18:33:47.846 Cisco Messaging Interface|   CMISerialWorker::SerialThread()
Saw EOT, inbound message: [OP:MWI<0x20>2001!<EOT>]
18:33:47.846 Cisco Messaging Interface|-->CMISsapiClient::OnLampOn()
18:33:47.846 Cisco Messaging Interface|   CMISsapiClient::OnLampOn()
Lamp On - 2001
18:33:47.846 Cisco Messaging Interface|   CMISsapiClient::OnLampOn()
Processed number = 2001
18:33:47.906 Cisco Messaging Interface|<--CMISsapiClient::OnLampOn()

MWI Off

18:33:47.846 Cisco Messaging Interface|   CMISerialWorker::SerialThread()
Saw EOT, inbound message: [RMV:MWI<0x20>2001!<EOT>]
18:33:47.846 Cisco Messaging Interface|-->CMISsapiClient::OnLampOff()
18:33:47.846 Cisco Messaging Interface|   CMISsapiClient::OnLampOff()
Lamp Off - 2001
18:33:47.846 Cisco Messaging Interface|   CMISsapiClient::OnLampOff()
Processed number = 2001
18:33:47.906 Cisco Messaging Interface|<--CMISsapiClient::OnLampOff()

Known Issues

• 
  

  FXS ports on the 6624 blade and AT-x gateway do not go on-hook in a timely manner.

  
  
  

  The default behavior of these devices is to go on-hook when they receive reorder tone. However, many voice mail systems do not disconnect on reorder, but rather dialtone. You can modify the Call Restart Timer from its default value of 5000 to 1234 in order to change the behavior of the gateway.

  
  
  

  

  
  



• 
  

  Error messages about the Cisco Messaging Interface in event viewer.

  
  
  

  
  

  Error:  CMyProcessConfigList::GetSafeIntegerParam() catch 
  handler Parameter MessageDeskNumber not found in database, using 
  default value of 1. 

  
  

  
  
  

  In early releases of Cisco CallManager, the Message Desk parameter was hard coded to 1. In Cisco CallManager 3.0(7), support for configurable Message Desk numbers was introduced. If you do not define a Message Desk Number, Cisco CallManager uses Message Desk 1.

  
  



• 
  

  Cisco Messaging Interface does not stay running.

  
  
  

  With the release of Cisco CallManager 3.0(7), the VoiceMailDn field is required.

  
  



• 
  

  No MWI with Octel 250/350 when Octel uses multiple SMDI links.

  
  
  

  When Octel voice mail systems use multiple SMDI links, it is necessary to specify over which link the MWI command needs to be sent. In the mailbox profile, you can edit the Int. Link Number field to correspond to the SMDI link that connects the Octel to the Cisco CallManager.

  
  

Cisco DPA 7630/7610

The Cisco DPA 76xx Voice Mail Gateway is a VoIP gateway that enables legacy voice mail equipment to connect to a Cisco IP Telephony solution network. The Cisco DPA 7610 allows Octel voice mail systems that currently use Digital Station Emulation to connect to a Nortel Meridian 1 PBX, to instead connect to a Cisco IP CallManager system. The Cisco DPA 7630 allows Octel voice mail systems that currently use Digital Station Emulation to connect to an Avaya Definity PBX, to instead connect to a Cisco IP CallManager system without any changes to the voice mail system.

The Cisco CallManager views the Cisco DPA 76xx as a collection of 30 VIP phones and the PBX's Avaya G3 views the DPA as a collection of 7504D digital phones. The Nortel Meridian M1 views the DPA as a collection of 2616 phone sets.

Troubleshoot Calls to Voice Mail through a Cisco DPA 7630/7610

The Cisco DPA 76xx gateways have very precise wiring requirements. It is essential to verify cabling when you troubleshoot issues with the Cisco DPA76xx.

• 
  

  You can find the Cisco DPA 7630 requirements in Connecting to the Octel and Definity Systems on a Cisco DPA 7630.

  
  



• 
  

  You can find the the Cisco DPA 7610 requirements in Connecting to the Octel and Meridian 1 Systems on a Cisco DPA 7610.

  
  

Once you are certain that the Layer 1 issues are resolved, you can investigate these suggestions.

• 
  

  Symptom: Reorder tone is played out to the caller when a call is placed to voice mail.

  
  
  
  
  
  • 
    

    Suggestion: If the DPA is configured beyond twelve ports, the thirteenth caller can receive reorder if the first twelve ports are in use. Cisco CallManager has a service parameter titled ForwardMaximumHopCount. By default, this field is set to a value of 12.

    
    
    

    

    
    
    

    Set this value to the number of ports configured on the DPA.

    
    
  
  
  
  



• 
  

  Symptom: Callers get the main greeting (open trees) rather than the greeting for the subscriber's mailbox.

  
  
  
  
  
  • 
    

    Suggestion: The DPA relies upon the value entered into the Cisco CallManager 'Pilot' directory number field for deployments of more than one DPA. The CallManager 'Pilot' directory number should be the first port of the first DPA. While the first DPA knows the directory numbers (DNs) associated with its own ports, subsequent DPAs need this information to ensure correct integration.

    
    
    

    Note: The most common misconfiguration is when a customer configures a CTI route point or a hunt group that forwards to the DPA. This is not necessary, as you can simply assign the appropriate DN to the first DPA port.

    
    
  
  
  
  

Troubleshoot MWI with a Cisco DPA 7630/7610

In order for message waiting notification to work correctly, Cisco CallManager and the DPA must be configured to use the same DNs for MWI.

The values that are entered under Service > Service parameters > Cisco CallManager, for MessageWaitingOn DN and MessageWaitingOffDN must match the values entered in the DPA under Configure > CallManager.

• 
  

  Symptom: MWIs do not turn on or off.

  
  
  
  
  
  • 
    

    Suggestion: Ensure that the MWI on/off DNs are not part of a more generic pattern. For example, check that there is not a route pattern of 1xxx that points to a gateway.

    
    
  
  
  
  



• 
  

  Symptom: MWIs do not turn off on the Octel 250/350 platform.

  
  
  
  
  
  • 
    

    Suggestion: For MWIs to function properly, the Message Waiting Timeout feature in menu 6.2, In-Band Integration of the Octel system must be set to the 1 - Timeout = Positive Acknowledgment setting. The 2 - Timeout = Negative Acknowledgment setting directs the Octel system to interpret the lack of a confirmation tone as an error indication. The DPA 7630/7610 requires that the 1 - Timeout = Positive Acknowledgment option be used.

    
    
  
  
  
  



• 
  

  Symptom: With the Cisco DPA 7630, MWIs do not turn on or off.

  
  
  
  
  
  • 
    

    Suggestion: The Avaya G3 PBX makes use of feature codes to set message waiting on the PBX. The Octel voice mail system consequently uses them also. These are traditionally *4 and #4 for Leave Word Calling Activate and Cancel, respectively. On the Octel 250/350 platform, in menu 6.2, In-Band Integration, there are two parameters: Dialing Sequence to Activate MWI and Dialing Sequence to Deactivate MWI. These values should be the same as those configured in the DPA under Configure > Octel/Definity integration.

    
    
    

    

    
    
    

    For one reason or another, many Octel systems have the Dialing Sequence to Activate MWI and Dialing Sequence to Deactivate MWI configured as *4PN and #4PN, rather than simply *4N and #4N. The P represents a pause, usually of 500 ms, and this delay can cause issues with MWI before DPA code 1.2(1).

    
    
  
  
  
  

Reference:

http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_tech_note09186a00800a8956.shtml#format

Troubleshooting EM_PARK Issues for E&M Digital CAS Signaling

Introduction

In digital E&M signaling on Cisco 2600, 3600, and MC3810 router platforms, some T1/E1 time slots can get stuck in the EM_PARK state. This is visible when you issue the show voice call summary command. This document explains how to troubleshoot this issue.

This output shows that some time slots are in the EM_PARK state. A time slot in the EM_PARK state is not used for voice calls.

Router#show voice call summary 
PORT      CODEC     VAD    VTSP STATE     VPM STATE
=====     ======    ===    ==========     ==========
1/0:0.1     -        -          -         EM_ONHOOK 
1/0:0.2     -        -          -         EM_PARK 
1/0:0.3     -        -          -         EM_PARK 
1/0:0.4     -        -          -         EM_ONHOOK 
1/0:0.5     -        -          -         EM_ONHOOK

Prerequisites

Requirements

There are no specific requirements for this document.

Components Used

The information in this document is based on these software and hardware versions:

• 
  

  Hardware—Cisco 2600, Cisco 3600, Cisco VG200, and MC3810 routers

  
  



• 
  

  Software—All

  
  

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Background Theory

In T1 CAS, for example, wink start signaling, when the PBX goes offhook, the router/gateway side time slot remains in the idle (EM_ONHOOK) state until the call is answered by a remote destination. The router time slot state changes to EM_OFFHOOK when the call is answered by the remote destination.

If the call does not connect, the router/gateway plays the inband reorder tones to the caller. Since the channel state on the router side is still EM_ONHOOK, the router is unable to hang up the channel. After the caller hangs up, the PBX needs to change its channel state from offhook to onhook.

In some cases, the PBXs do not send the onhook messages, with the help of the ABCD transitions. The router has a workaround for this called fake answer. Without the fake answer workaround, the channels hang in a state of EM_PARK indefinitely. See the Fake Answer section for more information.

Note: Calls can be stuck in the EM_PARK state on some T1 channels if the voice gateway router chasis is not electrically grounded properly. Refer to the hardware installation guide for more information about electrical grounding.

Conventions

Refer to Cisco Technical Tips Conventions for more information on document conventions.

Problem

There are two possible, major reasons that the time slot is stuck in the EM_PARK state:

• 
  

  The digital signal processor (DSP) is bad and has either hardware or software issues.

  
  



• 
  

  The PSTN switch/PBX sends a continuous offhook signal to the router and does not release it.

  
  

Solution

These are the solutions to this problem:

If the time slots in your system are stuck in the EM_PARK state, check the DSPs. Refer to Troubleshooting the DSP on NM-HDV for Cisco 2600/3600 Series Routers in order to check the DSPs.

If the DSPs are alive, the problem can be on the PSTN switch/PBX side or the Cisco IOS^® (router/gateway does not start the Fake Answer procedure). See the Fake Answer section for more information.

Fake Answer

The Cisco router/gateway waits for a default value of 30 seconds (use the timeouts wait-release and timeouts call-disconnect commands in order to change these values) after it knows that the time slot needs to be set from the PBX to onhook while it plays the reorder tone.

If this does not happen, the router moves the time slot to the EM_PARK state and starts another timer with a duration of 10 seconds. If the PBX still does not go onhook after the 10-second duration, the router tricks the PBX. The router sends a fake answer of a one second duration and then goes onhook.

After the router sends the fake answer signal, the router starts another timer of five minutes. If the PBX goes onhook, the timer stops and the router transitions the time slot to the EM_ONHOOK state. Otherwise, after five minutes it sends another fake answer signal of a one-second duration. The router repeats this process until the PBX goes onhook. The router forces the PBX to clear the call.

Note: This answering transition is not updated to any accounting record since the actual call is cleared. But, the PBX understands it as an answer and the user is probably charged for the one-second duration call.

If the DSP associated with the time slot in the EM_PARK state is alive and healthy and the problem persists, run the debug vpm all and debug vtsp all commands in order to see if Cisco IOS attempts to send the fake answer.

Note: You need to run the debugs for more than five minutes.

Note: In most cases, if the DSP is bad, the router does not perform the fake answer workaround. Refer to Troubleshooting the DSP on NM-HDV for Cisco 2600/3600 Series Routers for more information.

This debug output shows how a time slot becomes stuck in EM_PARK and how the fake answer workaround works.

Jan 11 17:19:00.767: htsp_dsp_message: SEND/RESP_SIG_STATUS: state=0xC timestamp
=44262 systime=31305235
Jan 11 17:19:00.767: htsp_process_event:
[4/1:1(10), EM_ONHOOK, E_DSP_SIG_1100]em_onhook_offhook htsp_setup_ind

!--- Offhook signal is received from the switch.

Jan 11 17:19:00.767: [4/1:1(10)] get_local_station_id calling num= calling name=
calling time=01/11 17:19 
Jan 11 17:19:00.767: vtsp_tsp_call_setup_ind (sdb=0x62BB7B14, tdm_info=0x0, tsp_
info=0x62BB4050, calling_number= calling_oct3 = 0x0, called_number= called_oct3 
= 0x81, oct3a=0x0): peer_tag=0
Jan 11 17:19:00.767: : ev.clg.clir is 0
ev.clg.clid_transparent is
0
ev.clg.null_orig_clg is 1
ev.clg.calling_translated is false

Jan 11 17:19:00.767: htsp_timer - 3000 msec
Jan 11 17:19:00.767: vtsp_do_call_setup_ind
Jan 11 17:19:00.767: vtsp_allocate_cdb,cdb 0x62DCEA70
Jan 11 17:19:00.767: vtsp_do_call_setup_ind: Call ID=112722, guid=62DC4230
Jan 11 17:19:00.767: vtsp_do_call_setup_ind: type=0, under_spec=1640890368, 
name=, id0=10, id1=1, id2=25038, calling=, called= subscriber=RegularLine
Jan 11 17:19:00.767: vtsp_do_normal_call_setup_ind
Jan 11 17:19:00.771: cc_api_call_setup_ind (vdbPtr=0x62BB7FA0, 
callInfo={called=
,called_oct3=0x81,calling=,calling_oct3=0x0,calling_oct3a=0x0,calling_xlated=fal
se,subscriber_type_str=RegularLine,fdest=0,peer_tag=0, prog_ind=3},callID=0x62DC
40DC)
Jan 11 17:19:00.771: cc_api_call_setup_ind type 1 , prot 0
Jan 11 17:19:00.771: vtsp_insert_cdb,cdb 0x62DCEA70
Jan 11 17:19:00.771: vtsp_open_voice_and_set_params 
Jan 11 17:19:00.771: dsp_close_voice_channel: [4/1:1:32995] packet_len=8 channel
_id=3 packet_id=75
Jan 11 17:19:00.771: dsp_open_voice_channel_20: [4/1:1:32995] 
packet_len=16 channel_id=3 packet_id=74 alaw_ulaw_select=0 
associated_signaling_channel=130 time_slot=2 serial_port=0
Jan 11 17:19:00.771: vtsp_modem_proto_from_cdb: cap_modem_proto 1073741824
Jan 11 17:19:00.771: vtsp_modem_proto_from_cdb: cap_modem_proto 1073741824
Jan 11 17:19:00.771: dsp_encap_config: [4/1:1:32995] packet_len=30 channel_id=3 
packet_id=92 
TransportProtocol 2 t_ssrc=0x0 r_ssrc=0x0 t_vpxcc=0x0 r_vpxcc=0x0
sid_support=1, tse_payload=65535, seq_num=0x0, redundancy=0
Jan 11 17:19:00.771: dsp_set_playout_delay
Jan 11 17:19:00.771: dsp_set_playout: [4/1:1:32995] packet_len=18 channel_id=3 p
acket_id=76 mode=1 initial=60 min=40 max=200 fax_nom=300 
dsp_set_playout_delay_config
Jan 11 17:19:00.771: dsp_set_playout_config
Jan 11 17:19:00.771: mode 0, init 60, min 40, max 200 playout default 
Jan 11 17:19:00.771: dsp_set_playout_config:mode 0, init 60, min 40, max 200 
Jan 11 17:19:00.771: dsp_set_playout_config: [4/1:1:32995] packet_len=18 channel
_id=3 packet_id=76 mode=1 initial=60 min=40 max=200 fax_nom=300 
Jan 11 17:19:00.771: dsp_echo_canceler_control: echo_cancel: 1
Jan 11 17:19:00.771: dsp_echo_canceler_control: [4/1:1:32995] echo_cancel 1, 
disable_hpf 0, flags=0x0, threshold=-21
Jan 11 17:19:00.771: dsp_echo_canceler_control: [4/1:1:32995] packet_len=12 
channel_id=3 packet_id=66 flags=0x0, threshold=-21
Jan 11 17:19:00.771: set_gains: FXx/E&M: msg->message.set_codec_gains.out_gain=0
Jan 11 17:19:00.771: dsp_set_gains: [4/1:1:32995] packet_len=12 channel_id=3 
packet_id=91 in_gain=0 out_gain=0
Jan 11 17:19:00.771: dsp_vad_enable: [4/1:1:32995] enable: packet_len=12 channel
_id=3 packet_id=78 thresh=-38
Jan 11 17:19:00.771: cc_process_call_setup_ind (event=0x62E63ACC)
Jan 11 17:19:00.771: >>>>CCAPI handed cid 32995 with tag 0 to app "DEFAULT"
Jan 11 17:19:00.771: sess_appl: ev(24=CC_EV_CALL_SETUP_IND), cid(32995), disp(0)
Jan 11 17:19:00.771: sess_appl: ev(SSA_EV_CALL_SETUP_IND), cid(32995), disp(0)
Jan 11 17:19:00.771: ssaCallSetupInd 
Jan 11 17:19:00.771: ccCallSetContext (callID=0x80E3, context=0x62DFBCF0)
Jan 11 17:19:00.771: ssaCallSetupInd cid(32995),
 st(SSA_CS_MAPPING),oldst(0), ev
(24)ev->e.evCallSetupInd.nCallInfo.finalDestFlag = 0
Jan 11 17:19:00.771: ccCallSetupAck (callID=0x80E3)
Jan 11 17:19:00.771: ccGenerateTone (callID=0x80E3 tone=8)
Jan 11 17:19:00.771: ccCallReportDigits (callID=0x80E3, enable=0x1)
Jan 11 17:19:00.771: vtsp_report_digit_control: enable=1: 
digit reporting enabled
Jan 11 17:19:00.771: cc_api_call_report_digits_done (vdbPtr=0x62BB7FA0, 
callID=0x80E3, disp=0)
Jan 11 17:19:00.771: : vtsp_get_digit_timeouts
Jan 11 17:19:00.771: sess_appl: ev(52=CC_EV_CALL_REPORT_DIGITS_DONE), 
cid(32995), disp(0)
Jan 11 17:19:00.771: cid(32995)st(SSA_CS_MAPPING)ev
(SSA_EV_CALL_REPORT_DIGITS_DONE)
oldst(SSA_CS_MAPPING)cfid(-1)csize(0)in(1)fDest(0)
Jan 11 17:19:00.771: ssaReportDigitsDone cid(32995) peer list: (empty)
Jan 11 17:19:00.771: ssaReportDigitsDone callid=32995 Enable succeeded
Jan 11 17:19:00.771: ccGenerateTone (callID=0x80E3 tone=8)
Jan 11 17:19:00.771: vtsp:[4/1:1:32995, S_SETUP_INDICATED, E_CC_SETUP_ACK]
Jan 11 17:19:00.775: act_setup_ind_ack 
Jan 11 17:19:00.775: vtsp_modem_proto_from_cdb: cap_modem_proto 0
Jan 11 17:19:00.775: vtsp_modem_proto_from_cdb: cap_modem_proto 0
Jan 11 17:19:00.775: dsp_encap_config: [4/1:1:32995] packet_len=30 channel_id=3 
packet_id=92 TransportProtocol 2 t_ssrc=0x0 r_ssrc=0x0 t_vpxcc=0x0 r_vpxcc=0x0
sid_support=1, tse_payload=65535, seq_num=0x0, redundancy=0
Jan 11 17:19:00.775: dsp_voice_mode: [4/1:1:32995] cdb 62DCEA70, 
cdb->codec_params.modem 2, inband_detect flags 0x21
Jan 11 17:19:00.775: map_dtmf_relay_type--digit relay mode: 2
Jan 11 17:19:00.775: dsp_voice_mode: [4/1:1:32995] packet_len=24 channel_id=3 
packet_id=73 coding_type=1 voice_field_size=160 VAD_flag=0 
echo_length=256 comfort
_noise=1 inband_detect=33 digit_relay_mode=2 
AGC_flag=0act_setup_ind_ack: modem_mode = 0, fax_relay_on = 1
Jan 11 17:19:00.775: act_setup_ind_ack(): dsp_dtmf_mode()
 dsp_dtmf_mode(VTSP_TONE_DTMF_MODE)

Jan 11 17:19:00.775: dsp_dtmf_mode: [4/1:1:32995] packet_len=10 channel_id=3 
packet_id=65 dtmf_or_mf=0
Jan 11 17:19:00.775: vtsp_timer: 31305236
Jan 11 17:19:00.775: vtsp:[4/1:1:32995, S_DIGIT_COLLECT, E_CC_GEN_TONE]
Jan 11 17:19:00.775: act_gen_tone
Jan 11 17:19:00.775: dsp_cp_tone_off: [4/1:1:32995] packet_len=8 channel_id=3 
packet_id=71
Jan 11 17:19:00.775: dsp_cp_tone_on: [4/1:1:32995] packet_len=38 channel_id=3 
packet_id=72 tone_id=4 n_freq=2 freq_of_first=350 freq_of_second=440 
amp_of_first=5514 amp_of_second=5514 direction=1 on_time_first=65535 
off_time_first=0 on_time_second=0 off_time_second=0
Jan 11 17:19:00.775: vtsp:[4/1:1:32995, S_DIGIT_COLLECT, E_CC_GEN_TONE]
Jan 11 17:19:00.775: act_gen_tone
Jan 11 17:19:00.775: dsp_cp_tone_off: [4/1:1:32995] packet_len=8 channel_id=3 
packet_id=71
Jan 11 17:19:00.775: dsp_cp_tone_on: [4/1:1:32995] packet_len=38 channel_id=3 
packet_id=72 tone_id=4 n_freq=2 freq_of_first=350 freq_of_second=440 
amp_of_first=
5514 amp_of_second=5514 direction=1 on_time_first=65535 off_time_first=0 
on_time4_second=0 off_time_second=0
Jan 11 17:19:00.775: htsp_process_event: [4/1:1(10), EM_WAIT_SETUP_ACK, 
E_HTSP_SETUP_ACK]em_wait_setup_ack_get_ack 
Jan 11 17:19:00.775: htsp_timer_stop 
Jan 11 17:19:00.775: htsp_timer2 - 172 msec
Jan 11 17:19:00.947: htsp_process_event: [4/1:1(10), EM_WAIT_SETUP_ACK, 
E_HTSP_EVENT_TIMER2]em_wait_prewink_timer 
Jan 11 17:19:00.947: em_offhook (0)[recEive and transMit4/1:1(10)] set signal st
ate = 0x8em_onhook (200)[recEive and transMit4/1:1(10)] set signal state = 0x0

!--- A wink of duration 200 msec is sent out to the switch.

Jan 11 17:19:01.471: vtsp_process_dsp_message: MSG_TX_DTMF_DIGIT_BEGIN: digit=9,
rtp_timestamp=0xED31C493

Jan 11 17:19:01.471: vtsp:[4/1:1:32995, S_DIGIT_COLLECT, E_DSP_DTMF_DIGIT_BEGIN]
Jan 11 17:19:01.471: act_report_digit_begin 
Jan 11 17:19:01.471: cc_api_call_digit_begin (dstVdbPtr=0x0, dstCallId=0xFFFFFFF
F, srcCallId=0x80E3,
digit=9, digit_begin_flags=0x1, rtp_timestamp=0xED31C493 
rtp_expiration=0x0, dest_mask=0x1)
Jan 11 17:19:01.471: sess_appl: ev(10=CC_EV_CALL_DIGIT_BEGIN), cid(32995), disp(0)
Jan 11 17:19:01.471: cid(32995)st(SSA_CS_MAPPING)ev(SSA_EV_DIGIT_BEGIN)
oldst(SSA_CS_MAPPING)cfid(-1)csize(0)in(1)fDest(0)
Jan 11 17:19:01.471: ssaIgnore cid(32995), st(SSA_CS_MAPPING),oldst(0), ev(10)
Jan 11 17:19:01.503: vtsp_process_dsp_message: MSG_TX_DTMF_DIGIT_OFF: 
digit=9, duration=65
Jan 11 17:19:01.503: vtsp:[4/1:1:32995, S_DIGIT_COLLECT, E_DSP_DTMF_DIGIT]
Jan 11 17:19:01.503: act_report_digit_end 
Jan 11 17:19:01.503: vtsp_timer_stop: 31305308
Jan 11 17:19:01.503: dsp_cp_tone_off: [4/1:1:32995] packet_len=8 channel_id=3 pa
cket_id=71
Jan 11 17:19:01.503: cc_api_call_digit_end (dstVdbPtr=0x0, dstCallId=0xFFFFFFFF,
srcCallId=0x80E3,
digit=9,duration=65,xruleCallingTag=0,xruleCalledTag=0, dest_mask=0x1), digi
t_tone_mode=0
Jan 11 17:19:01.503: htsp_digit_ready: digit = 39
Jan 11 17:19:01.503: vtsp_timer: 31305308
Jan 11 17:19:01.503: htsp_process_event: [4/1:1(10), 
EM_OFFHOOK, E_VTSP_DIGIT]em_offhook_digit_collect 
Jan 11 17:19:01.503: sess_appl: ev(9=CC_EV_CALL_DIGIT_END), cid(32995), disp(0)
Jan 11 17:19:01.503: cid(32995)st(SSA_CS_MAPPING)ev(SSA_EV_CALL_DIGIT)
oldst(SSA_CS_MAPPING)cfid(-1)csize(0)in(1)fDest(0)
Jan 11 17:19:01.503: ssaDigit
Jan 11 17:19:01.503: ssaDigit, 0. sct->digit , sct->digit len 0, 
usrDigit 9, digit_tone_mode=0
Jan 11 17:19:01.503: ssaDigit,1. callinfo.called , digit 9, 
callinfo.calling , x
rulecallingtag 0, xrulecalledtag 0
Jan 11 17:19:01.503: ssaDigit, 7. callinfo.calling , sct->digit 9, result 1
Jan 11 17:19:01.603: vtsp_process_dsp_message: MSG_TX_DTMF_DIGIT_BEGIN: 
digit=1, rtp_timestamp=0xED31C493

Jan 11 17:19:01.603: vtsp:[4/1:1:32995, S_DIGIT_COLLECT, E_DSP_DTMF_DIGIT_BEGIN]
Jan 11 17:19:01.603: act_report_digit_begin 
Jan 11 17:19:01.603: cc_api_call_digit_begin (dstVdbPtr=0x0, 
dstCallId=0xFFFFFFF
F, srcCallId=0x80E3,
digit=1, digit_begin_flags=0x1, rtp_timestamp=0xED31C493 rtp_expiration=0x0, 
dest_mask=0x1)
Jan 11 17:19:01.603: sess_appl: ev(10=CC_EV_CALL_DIGIT_BEGIN), cid(32995), 
disp(0)
Jan 11 17:19:01.603: cid(32995)st(SSA_CS_MAPPING)ev(SSA_EV_DIGIT_BEGIN)
oldst(SSA_CS_MAPPING)cfid(-1)csize(0)in(1)fDest(0)
Jan 11 17:19:01.603: ssaIgnore cid(32995), st(SSA_CS_MAPPING),oldst(0), ev(10)
Jan 11 17:19:01.643: vtsp_process_dsp_message: MSG_TX_DTMF_DIGIT_OFF: 
digit=1, duration=75
Jan 11 17:19:01.643: vtsp:[4/1:1:32995, S_DIGIT_COLLECT, E_DSP_DTMF_DIGIT]
Jan 11 17:19:01.643: act_report_digit_end 
Jan 11 17:19:01.643: vtsp_timer_stop: 31305322
Jan 11 17:19:01.643: cc_api_call_digit_end (dstVdbPtr=0x0, 
dstCallId=0xFFFFFFFF,
srcCallId=0x80E3,
digit=1,duration=75,xruleCallingTag=0,xruleCalledTag=0, 
dest_mask=0x1), digit_tone_mode=0
Jan 11 17:19:01.643: htsp_digit_ready: digit = 31
Jan 11 17:19:01.643: vtsp_timer: 31305322
Jan 11 17:19:01.643: htsp_process_event: [4/1:1(10), 
EM_OFFHOOK, E_VTSP_DIGIT]em_offhook_digit_collect 
Jan 11 17:19:01.643: sess_appl: ev(9=CC_EV_CALL_DIGIT_END), cid(32995), disp(0)
Jan 11 17:19:01.643: cid(32995)st(SSA_CS_MAPPING)ev(SSA_EV_CALL_DIGIT)
oldst(SSA_CS_MAPPING)cfid(-1)csize(0)in(1)fDest(0)
Jan 11 17:19:01.643: ssaDigit
Jan 11 17:19:01.643: ssaDigit, 0. sct->digit 9, sct->digit 
len 1, usrDigit 1, digit_tone_mode=0
Jan 11 17:19:01.643: ssaDigit,1. callinfo.called , digit 91, callinfo.calling , 
xrulecallingtag 0, xrulecalledtag 0
Jan 11 17:19:01.643: ssaDigit, 7. callinfo.calling , sct->digit 91, result 1
Jan 11 17:19:01.743: vtsp_process_dsp_message: 
MSG_TX_DTMF_DIGIT_BEGIN: digit=8, rtp_timestamp=0xED31C493

Jan 11 17:19:01.743: vtsp:[4/1:1:32995, S_DIGIT_COLLECT, 
E_DSP_DTMF_DIGIT_BEGIN]
Jan 11 17:19:01.743: act_report_digit_begin 
Jan 11 17:19:01.743: cc_api_call_digit_begin (dstVdbPtr=0x0, 
dstCallId=0xFFFFFFF
F, srcCallId=0x80E3,
digit=8, digit_begin_flags=0x1, rtp_timestamp=0xED31C493
rtp_expiration=0x0, dest_mask=0x1)
Jan 11 17:19:01.743: sess_appl: ev(10=CC_EV_CALL_DIGIT_BEGIN), cid(32995), 
disp(0)
Jan 11 17:19:01.743: cid(32995)st(SSA_CS_MAPPING)ev(SSA_EV_DIGIT_BEGIN)
oldst(SSA_CS_MAPPING)cfid(-1)csize(0)in(1)fDest(0)
Jan 11 17:19:01.743: ssaIgnore cid(32995), st(SSA_CS_MAPPING),oldst(0), ev(10) 
radius_decrypt: null length 
Jan 11 17:19:01.843: vtsp_process_dsp_message: MSG_TX_DTMF_DIGIT_OFF: 
digit=8, duration=75
Jan 11 17:19:01.843: vtsp:[4/1:1:32995, S_DIGIT_COLLECT, E_DSP_DTMF_DIGIT]
Jan 11 17:19:01.843: act_report_digit_end 
Jan 11 17:19:01.843: vtsp_timer_stop: 31305342
Jan 11 17:19:01.843: cc_api_call_digit_end (dstVdbPtr=0x0, dstCallId=0xFFFFFFFF,
srcCallId=0x80E3,
digit=8,duration=75,xruleCallingTag=0,xruleCalledTag=0, dest_mask=0x1), digi
t_tone_mode=0
Jan 11 17:19:01.843: htsp_digit_ready: digit = 38
Jan 11 17:19:01.843: vtsp_timer: 31305342
Jan 11 17:19:01.843: htsp_process_event: [4/1:1(10), 
EM_OFFHOOK, E_VTSP_DIGIT]em_offhook_digit_collect 
Jan 11 17:19:01.843: sess_appl: ev(9=CC_EV_CALL_DIGIT_END), cid(32995), disp(0)
Jan 11 17:19:01.843: cid(32995)st(SSA_CS_MAPPING)ev(SSA_EV_CALL_DIGIT)
oldst(SSA_CS_MAPPING)cfid(-1)csize(0)in(1)fDest(0)
Jan 11 17:19:01.843: ssaDigit
Jan 11 17:19:01.843: ssaDigit, 0. sct->digit 91, sct->digit len 2, usrDigit 8, d
igit_tone_mode=0
Jan 11 17:19:01.843: ssaDigit,1. callinfo.called , digit 918, callinfo.calling ,
xrulecallingtag 0, xrulecalledtag 0
Jan 11 17:19:01.843: ssaDigit, 7. callinfo.calling , sct->digit 918, result -1
Jan 11 17:19:01.843: ccCallDisconnect (callID=0x80E3, cause=0x1C tag=0x0)
Jan 11 17:19:01.843: vtsp:[4/1:1:32995, S_DIGIT_COLLECT, E_CC_DISCONNECT]
Jan 11 17:19:01.843: act_pre_con_disconnect 
Jan 11 17:19:01.843: vtsp_ring_noan_timer_stop: 31305342
Jan 11 17:19:01.843: dsp_cp_tone_off: [4/1:1:32995] packet_len=8 channel_id=3 pa
cket_id=71
Jan 11 17:19:01.843: dsp_voice_mode: [4/1:1:32995] cdb 62DCEA70, cdb->codec_para
ms.modem 2, inband_detect flags 0x21
Jan 11 17:19:01.843: map_dtmf_relay_type--digit relay mode: 2
Jan 11 17:19:01.843: dsp_voice_mode: [4/1:1:32995] packet_len=24 channel_id=3 pa
cket_id=73 coding_type=1 voice_field_size=160 VAD_flag=0 echo_length=256 comfort
_noise=1 inband_detect=33 digit_relay_mode=2 AGC_flag=0
Jan 11 17:19:01.843: dsp_cp_tone_on: [4/1:1:32995] packet_len=38 channel_id=3 pa
cket_id=72 tone_id=3 n_freq=2 freq_of_first=480 freq_of_second=620amp_of_first=
5206 amp_of_second=2928 direction=1 on_time_first=250 off_time_first=250 
on_time_second=0 off_time_second=0
Jan 11 17:19:01.843: vtsp_timer: 31305342
Jan 11 17:19:01.843: htsp_pre_connect_disconnect, cdb = 62DCEA70 cause = 1C

!--- Since the call is disconnected because the number received  is "unassigned" 
!--- or "invalid" the router  starts to play the reorder 
!--- tone and a timer, which is the wait-release
!--- timeout timer, starts with default 30 seconds. 
!--- This call is disconnected 
!--- prior to the connect state.

Jan 11 17:19:01.843: htsp_process_event: [4/1:1(10), EM_OFFHOOK, 
E_HTSP_PRE_CONN_DISC]
Jan 11 17:19:31.844: vtsp_main: timer: 31308342

!--- The wait-release timer expires after 30 seconds.

Jan 11 17:19:31.844: vtsp:[4/1:1:32995, S_WAIT_RELEASE_NC, E_TIMER]

!--- The VTSP module is in a wait release state for that call. It also receives 
!--- event timer, which means that the timer expires so that it 
!--- goes into another state.

Jan 11 17:19:31.844: act_pre_con_disc_rel htsp_release_req: cause 28, no_onhook 
0
Jan 11 17:19:31.844: htsp_process_event: [4/1:1(10), EM_OFFHOOK, 
E_HTSP_RELEASE_REQ]em_offhook_release 
Jan 11 17:19:31.844: htsp_timer_stop2 em_onhook (0)[recEive and transMit4/1:1(10
)] set signal state = 0x0
Jan 11 17:19:31.844: htsp_timer_stop 
Jan 11 17:19:31.844: em_start_timer: 400 ms 
Jan 11 17:19:31.844: htsp_timer - 400 msec

!--- HTSP receives an event  that requests the release of 
!--- the time slot and it goes into EM wait 
!--- onhook state. But, it cannot do anything since it says I am onhook already. 
!--- Also, the router starts a timer of 400 msec.

Jan 11 17:19:32.296: htsp_process_event: [4/1:1(10), EM_WAIT_ONHOOK, 
E_HTSP_EVENT_TIMER]em_wait_timeout 
Jan 11 17:19:32.296: em_stop_timers 
Jan 11 17:19:32.296: htsp_timer_stop 
Jan 11 17:19:32.296: em_start_timer: 400 ms 
Jan 11 17:19:32.296: htsp_timer - 400 msec

!--- When the 400 msec timer expires, HTSP gets into EM clear pending state. 
!--- It also starts another timer of 400 msec.

Jan 11 17:19:32.696: htsp_process_event: [4/1:1(10), EM_CLR_PENDING, 
E_HTSP_EVENT_TIMER]em_clr_timeout 
Jan 11 17:19:32.696: em_stop_timers 
Jan 11 17:19:32.696: htsp_timer_stop 
Jan 11 17:19:32.696: em_start_timer: 10000 ms 
Jan 11 17:19:32.696: htsp_timer - 10000 msec
Jan 11 17:19:32.700: htsp_dsp_message: SEND/RESP_SIG_STATUS: 
state=0xC timestamp=1533 systime=31308428
Jan 11 17:19:32.700: htsp_process_event: [4/1:1(10), EM_PARK, 
E_DSP_SIG_1100]em_park_offhook

!--- When the 400 msec timer expires, the router puts the time slot into 
!--- the EM_PARK state, and it starts another timer of 10 seconds. 
!--- The router  still sees the ABCD=1100 from the switch.

Jan 11 17:19:42.760: htsp_process_event: [4/1:1(10), 
EM_PARK, E_HTSP_EVENT_TIMER]em_park_timerhtsp_report_onhook_sig
Jan 11 17:19:42.760: em_offhook (0)[recEive and transMit4/1:1(10)] set signal st
ate = 0x8em_onhook (1000)[recEive and transMit4/1:1(10)] set signal state = 0x0
Jan 11 17:19:42.760: htsp_timer2 - 300000 msec
Jan 11 17:19:42.760: htsp_process_event: [4/1:1(10), 
EM_PARK, E_HTSP_EVENT_TIMER]em_park_timerhtsp_report_onhook_sig
Jan 11 17:19:42.760: em_offhook (0)[recEive and transMit4/1:1(10)] 
set signal state = 0x8em_onhook (1000)[recEive and
transMit4/1:1(10)] set signal state = 0x0
Jan 11 17:19:42.760: htsp_timer2 - 300000 msec

!--- As seen from the timestamps, when the timer expires in ten seconds,
!--- the router goes offhook for one second (1000 msec) and then onhook. 
!--- It also starts another timer of 300000 msec (5 minutes).

Reference:

http://www.cisco.com/en/US/tech/tk652/tk653/technologies_tech_note09186a0080112323.shtml

FXO Disconnect Failure (fxo port 咬線問題)

 

When loop-start signaling is used, a router's FXO interface looks like a phone to the switch (private branch exchange (PBX), public switched telephone network (PSTN), Key-System) it connects to. The FXO interface closes the loop to indicate off-hook. The switch always provides a battery so there is no disconnect supervision from the switch side. Since a switch expects a phone user (example of an FXO interface) to hang up the phone when the call is terminated (on either side), it also expects the FXO port on the router to hang-up. This "human intervention" is not built into the router. The FXO port expects the switch to tell it when to hang-up (or remove the battery to indicate on-hook). Because of this, there is no guarantee that a near-end or far-end FXO port disconnects the call once either end of the call hangs-up.

The most common symptoms of this problem are phones that continue to ring when the caller has cleared, or FXO ports that remain busy after the previous call should have been cleared.

Common Scenarios

As a simple rule-of-thumb, if the local router has an FXO port and it originates the call out of an FXO port, it has control over that call and can provide the local disconnect. If the local router has an FXO port and it receives the call, it requires that the connected switch provide this disconnect signal.

Note: All scenarios assume that no Supervisory Disconnect features are configured on the PBXes.

Scenario 1

Phone-A calls phone-B. Phone-B does not answer. Phone-A then goes on-hook, but phone-B continues to ring because the router's FXO has no signaling information of the change (going on-hook) made by phone-A. If the call is answered, it stays active until phone-B hangs-up, regardless of the actions of phone-A.

Scenario 2

Phone-B calls phone-A. When the users hang-up, or if phone-B hangs-up before phone-A answers, the call is disconnected because the router's FXO port originated the call. However, if phone-A hangs-up before phone-B, the call remains up until phone-B hangs-up.

Scenario 3

This is the worst possible scenario because calls placed in either direction results in the router receiving a call on its' FXO port. In the case of a call that comes in from the PSTN, it might not be as bad. This is because the PSTN switch often provides a disconnect (ground-start or power-denial) and the far-end router ends the call from its' FXO port. However, calls to the PSTN will have the same problems that are discussed throughout this document, because the call comes into the router's FXO port.

Understand Supervisory Disconnect Signaling Methods

Ground-start Signaling Disconnect

Ground-start signaling can be used on the FXO port of the router if the switch is capable of providing a ground-start connection. When configured, the switch removes the ground from the connection and the FXO port goes on-hook. This option is available on the Cisco 1750, 2600, 3600, 3700 and MC3810 series multiservice routers.

Power Denial-based Supervisory Disconnect

Power denial detection is an interruption of line power from the switch or PBX to the FXO port, which lasts at least 350 ms. The FXO interface on the router detects that power is no longer present and interprets this as a supervisory disconnect indication. This is available on the Cisco 1750, 2600, 3600, 3700 and MC3810 series router analog FXO ports in all versions of Cisco IOS which have voice support. This figure provides an illustration:

Battery Reversal

Battery reversal is implemented by reversing the battery polarity on the PBX. This is done initially when the call is connected (far-end answer), with the polarity reversed throughout the entire conversation. When the far-end disconnects, the battery polarity is changed back to normal to indicate call disconnect. PBX uses the battery reversal indication to start billing.

Note: Foreign Exchange Station (FXS) ports normally reverse the battery upon call connection. Therefore, if an FXS port is connected to an FXO port that does not support battery reversal detection, you should disable battery reversal on the FXS port to prevent unexpected behavior.

Tone-based Supervisory Disconnect

Supervisory Tone is the audible frequencies that a PBX can produce to indicate that a call has been released (caller back on-hook) and the connection should be disconnected. The tones are different in most countries. The router's FXO port can be configured to interpret the tones as Supervisory Disconnect and disconnect the call.

In this Supervisory Tone Disconnect example figure, the call is made to the far-end.

Configure Supervisory Disconnect Signaling

Configure the FXO Port to Support Power Denial in Cisco IOS Software Release 11.3MA and Later

The supervisory disconnect signal command turns on support for power denial recognition. This is the default configuration. Configuring the no supervisory disconnect signal command turns off support for power denial in this release, and also enables support for basic supervisory tone disconnection. Refer to Configure the FXO Port to Support Supervisory Tone Disconnection.

FXO_Paper(config)#voice-port 2/1/1
FXO_Paper(config-voice)#supervisory disconnect signal
FXO_Paper(config-voice)#end
FXO_Paper#

Configure the FXO Port to Support Battery Reversal Detection in Cisco IOS Software Release 12.0(7)XK and Earlier

To configure support for battery reversal, the battery-reversal command is applied to the voice port. This feature was supported on the Cisco MC3810 series router from launch. The Cisco 2600/3600 platforms were first supported in Cisco IOS Software Release 12.0(7)XK (integrated in Cisco IOS Software Release 12.1(3)T) and needs the addition of special FXO hardware VIC-2FXO-M1 and VIC-2FXO-M2.

FXO_Paper(config)#voice-port 2/1/1
FXO_Paper(config-voice)#battery-reversal
FXO_Paper(config-voice)#end
FXO_Paper#

For more information on the VIC-2FXO-M1 and VIC-2FXO-M2, refer to Understanding FXO Voice Interface Cards.

For more information on configuring battery-reversal, refer to Voice Port Enhancements in Cisco 2600 and 3600 Series Routers and MC3810 Series Concentrators.

Configure the FXO Port to Support Supervisory Tone Disconnection in Cisco IOS Software Release 11.3MA

Supervisory tone disconnection was first supported in Cisco IOS Software Release 11.3MA. Activation was with the configuration of the no supervisory disconnect signal command. In this release the detection was minimal, with the FXO only being able to detect a 600 hertz tone as the disconnect signal.

FXO_Paper(config)#voice-port 2/1/1
FXO_Paper(config-voice)#no supervisory disconnect signal
FXO_Paper(config-voice)#end
FXO_Paper#

Configure the FXO Port to Support Supervisory Tone Disconnection in Cisco IOS Software Release 12.1(3)T

The supervisory tone detection was changed in Cisco IOS Software Release 12.1(3)T to give more detailed support. The command line interface (CLI) was also changed. From this release, it is now possible to configure the disconnect tones to be detected either continuously during calls (by configuring the mid-call command), or only during call setup (by using the pre-connect command in the configuration). Detection of anytone (configured by the anytone command) operates only during call set-up. If you configure detection of anytone, you must also enable echo cancellation to prevent disconnection due to the detection of the router's own ringback tone.

Another new feature is the ability to create voice classes. This allows the various components that are used to construct a tone to be configured to match the tone created by PBXs from various countries. Because there are numerous commands that can make a voice class, it is beyond the scope of this document to explain their functionality. Consult the release documentation for detailed information.

FXO_Paper #configure terminal  
FXO_Paper(config)#voice-port 3/1/1
FXO_Paper(config-voiceport)#supervisory disconnect dualtone pre-connect voice-class 90
FXO_Paper(config-voiceport)#end

 FXO_Paper(config)# voice class dualtone 90
     FXO_Paper(config-voice-class)# freq-pair 1 350 440
     FXO_Paper(config-voice-class)# freq-pair 2 480 850
     FXO_Paper(config-voice-class)# freq-pair 3 1000 1250
     FXO_Paper(config-voice-class)# freq-max-deviation 10
     FXO_Paper(config-voice-class)# freq-max-power 6
     FXO_Paper(config-voice-class)# freq-min-power 25
     FXO_Paper(config-voice-class)# freq-power-twist 15
     FXO_Paper(config-voice-class)# freq-max-delay 16
     FXO_Paper(config-voice-class)# cadence-min-on-time 50 
     FXO_Paper(config-voice-class)# cadence-max-off-time 500
     FXO_Paper(config-voice-class)# cadence-list 1 100 100 300 300 100 200 200 200
     FXO_Paper(config-voice-class)# cadence-list 2 100 200 100 400 100 200 300 300
     FXO_Paper(config-voice-class)# cadence-variation 8
     FXO_Paper(config-voice-class)# exit

Note: All the commands other than the freq-pair command under the voice class dualtone command mode are hidden.

Note: The supervisory disconnect dualtone command is modified and improved from Cisco IOS Software Releases 12.1(5)XM and 12.2(2)T.

Configure the FXO Port to Support Supervisory Tone Disconnection from Cisco IOS Software Releases 12.1(5)XM and 12.2(2)T

Cisco IOS Software Releases 12.1(5)XM and 12.2(2)T introduced many improvements and changes. These include a change to the command line, the addition of "Tone Detection Tolerance" Classes, changes to the custom voice class configuration, enabling the creation of Customized Cptones, and the ability to use the predefined country specific call progress tones. The predefined country specific call progress tones provide a means of not having to configure a custom voice class. This significantly reduces the overall configuration needed to deploy the feature. This is configured by applying the cptone locale command to the voice port. It is recommended that this method be initially tried first before attempting to use any custom configurations.

This is a sample configuration. Note the inclusion of the commands timeouts wait-release 5 and timeouts call-disconnect 5. The defaults of these timers are thirty seconds and sixty seconds, which can prove to be excessive in normal use. Therefore, the timers should be reduced to suit the local condition. As a guide, five seconds can be considered as a more satisfactory value for both.

FXO_Paper#configure terminal  
FXO_Paper(config)#voice-port 3/1/1
FXO_Paper(config-voiceport)#supervisory disconnect dualtone mid-call
FXO_Paper(config-voiceport)#cptone us
FXO_Paper(config-voiceport)#timeouts wait-release 5
FXO_Paper(config-voiceport)#timeouts call-disconnect 5
FXO_Paper(config-voiceport)#exit

Note: The timeouts call-disconnect command is hidden in Cisco IOS Software Release 12.1(5)XM.

FXO disconnect supervision is not supported on local hair pinned calls between analog voice ports (FXS and FXO) on Cisco MC3810 series concentrators because the digital signal processor (DSP) is bypassed. If hair pinning is turned off with the no voice local-bypass global configuration command, FXO disconnect supervision is supported.

The Cisco MC3810 series concentrators must be equipped with high-performance compression modules (HCMs) to support tone detection. Standard voice compression modules (VCMs) do not support the FXO Disconnect Supervision feature.

Note: To configure non-default tone detection tolerances, use the voice class dualtone-detect-params command. For more information, refer to FXO Disconnect Supervision.

Note: For more information on any of the commands in this document, refer to the Command Lookup Tool ( registered customers only) .

 

Reference:

http://www.cisco.com/en/US/tech/tk652/tk653/technologies_tech_note09186a00800ae2d1.shtml

http://www.cisco.com/en/US/docs/ios/12_1/12_1xm/feature/guide/dt_dscon.html#wp61588

http://docwiki.cisco.com/wiki/Cisco_IOS_Voice_Troubleshooting_and_Monitoring_--_FXO_Interfaces

Caller ID is not supported on FXO if GW configured as MGCP

 

Introduction

This document is a working example of the use of Media Gateway Control Protocol (MGCP) between a Cisco IOS® Gateway (for example, VG200, 2600, 3600, IAD2400) and a Cisco CallManager Media Convergence Server (MCS). It covers the configuration of one foreign exchange office (FXO) connection to the public switched telephone network (PSTN), as well as foreign exchange station (FXS) connections to analog hand sets. This document also shows VoIP connectivity to Cisco 7960 IP phones. When this configuration is complete, it will be possible to make calls between all of the phones used in this configuration. It will also be possible to route calls over the PSTN from any of the phones used in this configuration.

This document assumes that the reader is already familiar with how to configure Cisco IP phones in CallManager. This document also assumes that there is at least one IP phone already active on the Cisco CallManager server.

Symptoms

You can potentially encounter these symptoms when you configure Cisco CallManager with IOS MGCP gateways with analog FXO and FXS ports:

• The MGCP gateway does not register with Cisco CallManager. Refer to MGCP Gateway Registration Failure with Cisco CallManager.

• Caller ID does not work on FXO ports. This is because caller ID is not supported with FXO ports when configured for MGCP. Instead, configure the gateway in H.323 mode.

• Overhead paging locks up the FXO port when doing hookflash unless users go completely off-hook. Perform a shut, no shut to reset the port. This is related to Cisco bug ID CSCef62275 ( registered customers only) and is fixed in Cisco IOS Software Release 12.3(14)T and later.

Prerequisites

Requirements

There are no specific requirements for this document.

Components Used

This configuration was tested with Cisco CallManager versions 3.x and 4.x and various versions of Cisco IOS Software 12.2 images. The screen shots found in the links within this document and the Cisco IOS configurations listed were captured using the software, hardware and other equipment listed here.

• Cisco VG200 / 2 X FXS / 2 X FXO / 1 FastEthernet 10/100 port

• Various versions of Cisco IOS Software Release 12.2

• Cisco CallManager (specific versions are listed in the individual documents below)

• Analog handsets

• Cisco 7960 IP Phones

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

For recommended compatibility software versions between Cisco CallManager and the IOS Gateway, refer to the Cisco CallManager Compatibility Matrix. If your network has special needs, consult with your Cisco Account Manager before you change any Cisco IOS Software.

Note: Cisco recommends Cisco IOS Software Release 12.2(11)T or later based on the ccm-manager command enhancements. The ccm-manager command requires Cisco IOS Software Release 12.1(5)XM or later on all routers (2600, 3600) and the VG200.

Cisco 2600 and 3600 routers support MGCP if they run Cisco IOS Software Release 12.1(3)T or later. The release and version that you require will be based on the features that you need to enable. The router configuration is the same for all types of routers. See the Document Contents section for documentation on specific features and requirements related to Cisco CallManager.

Note: NM-HD-2V on an MGCP gateway is supported only from Cisco CallManager 3.3(3)SR4a and later. The NM-HD-2V is not listed as an MGCP Gateway option in Cisco CallManager versions earlier than 3.3(3)SR4a.

Conventions

Refer to Cisco Technical Tips Conventions for more information on document conventions.

Document Contents

1. Introduction

2. Configuring the Cisco IOS MGCP Gateway

3. Configuring the Cisco CallManager Server

4. Verifying and Troubleshooting the Cisco IOS MGCP Gateway

5. Sample of Debug MGCP Packets

6. Monitor, Reset, and Delete MGCP Gateways for Cisco CallManager

You can use this document as a guide to configure the devices for use in a real network or as a workbook example to use in a lab environment for learning or testing purposes. Sections 4 and 5 are provided for additional information. If the tasks in sections 2 and 3 result in a working configuration, it is not necessary to refer to sections 4, 5 or 6.

Reference:

http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_tech_note09186a008009428e.shtml