Viewing Call Legs

With a fax, modem, or text call through a Cisco IOS gateway matching both inbound and outbound peers and subsequently generating a call leg for each, it is important to understand how to view and extract critical information about these call legs. The most basic IOS commands for viewing both telephony and IP call legs are show call active voice brief and show call active fax brief.

The show call active voice brief command displays both the telephony and IP leg of a call. A lot of information is output by this command, but this section looks at only the information relevant to fax, modem, and text calls. The fax, modem, and text call transport methods that are covered in detail in this section with regard to the output from the show call active voice brief command include modem passthrough, fax pass-through, fax relay, Cisco modem relay, and Cisco text relay. The show call active fax brief command is also covered, but it is used less frequently because it provides only telephony dial-peer information for fax relay calls.

Modem Passthrough Call Legs

Modem passthrough uses an NSE-based switchover mechanism to transport both fax and modem calls. When transporting fax calls, this transport method is often referred to as fax passthrough. The show call active voice brief command offers an easy and efficient means of viewing the call legs before and after a modem passthrough switchover while providing confirmation that the switchover occurred properly.

TIP Although the show call active voice brief command proves helpful in confirming that an appropriate switchover has occurred, better techniques are available for viewing the actual switchover and diagnosing any switchover problems. These techniques are discussed in the next section, "Troubleshooting the Switchover Signaling."

Even before the call is connected the show call active voice brief can provide important information. Example 12-4 is an example of the show call active voice brief command for a modem passthrough call that has been placed through the gateway but has not yet connected.

Example 12-4 show call active voice brief Command Output for a Modem Passthrough Call That Is Connecting

11F1 : 9 2920260ms.1 +-1 pid:2 Answer 100 connected dur 00:00:00 tx:230/6392 rx:115/2233

Tele 0/0/0 (9) [0/0/0] tx:6870/1940/0ms g729r8 noise:-74 acom:66 i/0:-79/-12 dBm

11F1 : 10 2924510ms.1 +-1 pid:1 Originate 200 connecting dur 00:00:00 tx:0/0 rx:230/4552

IP 1.1.1.2:17932 SRTP: off rtt:0ms pl:2290/0ms lost:0/0/0 delay:70/70/70ms g729r8 TextRelay: off media inactive detected:n media contrl rcvd:n/a timestamp:n/a long duration call detected:n long duration call duration:n/a timestamp:n/a

Example 12-4 shows two call legs sharing the same call identifier of 11F1. The first call leg is the POTS call leg because it is associated with telephony port Tele 0/0/0 on the voice gateway. The second call leg is the VoIP call leg because it is associated with an IP address and UDP port number of 1.1.1.2:17932.

The states of the call legs in this example are important to note. The POTS call leg is showing connected, and the VoIP call leg is displaying connecting. The connected state indicates that the POTS leg has completed the initial call setup, and the connecting state means that the VoIP leg is still in the process of connecting but has not yet received answer supervision. In this case, the far-end device connected over the VoIP leg is simply ringing.

When the far-end device answers the call, both call legs move into an active state. The exception to this is for IP call legs set up by the Media Gateway Control Protocol (MGCP) call control protocol. The MGCP IP call legs always remain in the connecting state and never switch to active. Example 12-5 illustrates a modem passthrough call that has active call legs but the switchover has still not occurred. The gateways have yet to detect the 2100 Hz stimuli tone necessary for initiating a transition to modem passthrough mode, so the call at this point is still in voice mode.

Example 12-5 show call active voice brief Command Output for a Modem Passthrough Call Before Switchover

11F1 : 9 2920260ms.1 +14780 pid:2 Answer 100 active dur 00:00:07 tx:253/7017 rx:238/4587

Tele 0/0/0 (9) [0/0/0] tx:16090/4630/0ms g729r8 noise:-73 acom:6 i/0:-77/-79 dBm

11F1 : 10 2924510ms.1 +10530 pid:1 Originate 200 active dur 00:00:07 tx:99/1903 rx:253/4993

Example 12-5 show call active voice brief Command Output for a Modem Passthrough Call Before Switchover (Continued)

IP 1.1.1.2:17932 SRTP: off rtt:0ms pl:4810/0ms lost:0/0/0 delay:60/60/70ms g729r8 TextRelay: off media inactive detected:n media contrl rcvd:n/a timestamp:n/a long duration call detected:n long duration call duration:n/a timestamp:n/a

The key parameter that informs you that the call in Example 12-5 is still a normal VoIP call is the presence of the g729r8 codec. This codec is known for ensuring good voice quality while highly compressing the voice stream. However, the compression scheme this codec uses is optimized for human speech, and it adversely affects fax and modem signals. Consequently, a low compression codec such as G.711 is needed, and this is one of the benefits that modem passthrough provides. Modem passthrough upspeeds any codec that uses compression to G.711. Example 12-6 demonstrates how the call in Example 12-5 appears after the switchover occurs and the modem passthrough feature is now activated.

Example 12-6 show call active voice brief Command Output for a Modem Passthrough Call

11F1 : 9 2920260ms.1 +14780 pid:2 Answer 100 active

dur 00:00:22 tx:1040/137129 rx:1016/128131

Tele 0/0/0 (9) [0/0/0] tx:14270/14270/0ms g711ulaw noise:-66 acom:21 i/0:-69/-48

dBm

11F1 : 10 2924510ms.1 +10530 pid:1 Originate 200 active

dur 00:00:22 tx:877/125447 rx:1040/128809

IP 1.1.1.2:17932 SRTP: off rtt:1ms pl:40/0ms lost:0/0/0 delay

60/60/60ms g711ulaw

TextRelay: off

media inactive detected:n media contrl rcvd:n/a timesamp:n/a

long duration call detected:n long duration call duration:n/a

timestamp:n/a

MODEMPASS

nse buf:0/0 loss 0% 0/0 last 1359s dur:0/0s

In addition to the codec upspeed from g729r8 to g711ulaw in Example 12-6, the IP call leg is now flagged with MODEMPASS. The presence of this parameter informs you immediately that a successful transition has occurred and a modem passthrough call is now in progress.

After a call has transitioned to modem passthrough, you can repeatedly use the show call active voice brief command to monitor the call progress. In addition to basic call information such as packets transmitted and received and call duration, other fields are of particular interest when troubleshooting fax and modem calls. Table 12-3 defines the highlighted items in Example 12-6 and explains their importance.

Table 12-3 Important Parameters in the show call active voice brief Command Output for Modem Passthrough

Field

Value

Description

ID

11F1

Defines a unique call identifier (ID) for POTS and IP call leg pairs.

pid

pid:2 pid:1

Specifies a dial-peer ID (pid) that identifies the matched dial-peer in the configuration file for a particular call leg. In the case of Example 12-6, the POTS call leg is associated with dial-peer 2, and the VoIP call leg with dial-peer 1.

dir

Answer/Originate

Indicates the direction (dir) of the call leg. Originate defines a call leg that is sent from the gateway outbound, and Answer identifies an inbound call leg to the gateway.

addr

100/200

Indicates the address (addr) of the call leg. On the Originate call leg, this value defines the called number (200), and this value on the Answer call leg usually is the calling number (100). Be aware that the gateway dial-peer configuration or other devices in the call path may manipulate these values.

state

active

Defines the state of the call leg. The active state indicates that the call leg is in an established state, with media flowing in both directions.

Tele interface

Tele 0/0/0

Identifies the physical port on the gateway used by the POTS call leg.

codec

g711ulaw

Defines the codec algorithm in use by the call leg.

IP ip:udp

IP 1.1.1.2:17932

Identifies the remote IP address and UDP port for the IP call leg.

lost:lost/early/late

lost:0/0/0

Details lost, early, and late packet counts for the DSP playout buffer. Incrementing values in these counters indicate IP network problems that are negatively impacting the call.

MODEMPASS

method

MODEMPASS nse

Indicates that modem passthrough has been successfully negotiated and established.

Table 12-3 Important Parameters in the show call active voice brief Command Output for Modem Passthrough (Continued)

Field Value Description buf:fills/drains buf:0/0 Shows the number of buffer fill and drain events.

Fill events occur when packets are being received faster than they are being played out, and drain events happen when packets are being played out faster than they are being received. If these counters are incrementing, this indicates that significant jitter is occurring in the IP network and it may be negatively impacting the call.

Details packet loss percentage, number of consecutive packet loss events (multipkt), and the number of packets corrected by the RFC 2198 redundancy algorithm. If these counters are incrementing, IP network problems are negatively impacting the call.

loss overall% multipkt/ loss 0% 0/0 corrected

TIP Whereas Table 12-3 provides additional insight into counters and parameters for a show call active voice brief command during a modem passthrough call, almost all the parameters defined here are also relevant for fax relay and modem relay calls. The only exceptions are the parameters in the table taken specifically from the MODEMPASS line of the IP call leg. These counters are specific to modem passthrough only.

If you are currently proceeding with telephony troubleshooting, you should analyze the POTS call leg for additional information. The codec in use on this call leg is identified as g711ulaw, and the dial-peer that is matched for this call leg is shown as pid:2. The Answer parameter indicates that this POTS call leg "answered" or received the call and that this is the inbound call leg from the gateway's perspective.

When performing IP troubleshooting, you must analyze the IP call leg in Example 12-6. In addition to static call parameters such as the call ID and peer ID, a number of dynamic parameters in the IP leg are important to note. These dynamic items are the ones that should be monitored during a call while troubleshooting.

For example, there is a counter for lost packets in the IP call leg that in the case of Example 12-6 is set to lost:0/0/0. More precisely, the three counters here refer to lost, early, and late packets. If IP network issues are occurring, they are reflected in this counter. Incrementing values here can indicate jitter or packet loss in the IP network that is adversely affecting modem passthrough.

The dial-peer associated with the IP call leg usually contains most of the configuration information for a fax, modem, or text call. So, it is important to do a quick check of the configuration after the show call active voice brief command confirms the exact peer ID that is matched. For the modem passthrough call in Example 12-6, the pid for the IP call leg is 1 (pid:1), and this dial-peer configuration along with the POTS peer configuration is referenced in Example 12-7.

Example 12-7 Dial-Peer Configuration for Modem Passthrough dial-peer voice 1 voip destination-pattern 200 modem passthrough nse codec g711ulaw session target ipv4:1.1.1.2 incoming called-number . fax protocol none

dial-peer voice 2 pots destination-pattern 100 port 0/0/0

In Example 12-7, the configuration command modem passthrough nse codec g711ulaw is present under the VoIP dial-peer, dial-peer voice 1 voip. This configuration command is responsible for the gateway transitioning the call to passthrough and the output of the show call active voice brief in Example 12-6.

Fax Pass-Through Call Legs

Unlike modem passthrough that depends on NSE packets for the switchover, fax pass-through uses the VoIP signaling protocol to make the transition to passthrough mode. This results in a different appearance for the call when the show call active voice brief command is issued.

With modem passthrough, a successful switchover is marked by MODEMPASS in the IP call leg portion of the show call active voice brief command output. However, because fax pass-through uses the voice signaling protocol to handle the switchover, only the codec change can be observed. Example 12-8 shows a fax pass-through call before the switchover occurs. Notice that the codec is g729r8.

After the V.21 fax flags are detected and the call switches over to fax pass-through, the codec changes to g711ulaw to properly handle the transport of the fax messages. Example 12-9 shows a fax pass-through call after the switchover has occurred.

Example 12-8 show call active voice brief Command Output for a Fax Pass-Through Call Before Switchover

126C : 57 11407050ms.1 +14760 pid:2 Answer 100 active dur 00:00:08 tx:307/8548 rx:304/5927

Tele 0/0/0 (57) [0/0/0] tx:19140/5990/0ms g729r8 noise:-74 acom:66 i/0:-79/-12 dBm

126C : 58 11411290ms.1 +10520 pid:1 Originate 200 active dur 00:00:08 tx:112/2154 rx:307/6092

IP 1.1.1.2:17620 SRTP: off rtt:1ms pl:5930/0ms lost:0/0/0 delay:60/60/70ms g729r8 TextRelay: off media inactive detected:n media contrl rcvd:n/a timestamp:n/a long duration call detected:n long duration call duration:n/a timestamp:n/a

Example 12-9 show call active voice brief Command Output for a Fax Pass-Through Call

126C : 57 11407050ms.1 +14760 pid:2 Answer 100 active dur 00:00:41 tx:1953/273736 rx:1869/256327

Tele 0/0/0 (57) [0/0/0] tx:31300/31300/0ms g711ulaw noise:-17 acom:14 i/0:-14/-61 dBm

126C : 58 11411290ms.1 +10520 pid:1 Originate 200 active dur 00:00:41 tx:1677/252554 rx:1953/258112

IP 1.1.1.2:17620 SRTP: off rtt:4ms pl:40/0ms lost:1/0/0 delay:60/60/60ms g711ulaw TextRelay: off media inactive detected:n media contrl rcvd:n/a timestamp:n/a long duration call detected:n long duration call duration:n/a timestamp:n/a

With fax pass-through, you must keep watch for the codec change to confirm a successful transition. Because the switchover happens within the voice signaling protocol, fax pass-through appears like a regular VoIP call to the gateway when using the show call active voice brief command. For more information about fax pass-through and how it transitions using the voice signaling protocol, see the section "Protocol-Based Pass-Through for Fax" in Chapter 4, "Passthrough."

Fax Relay Call Legs

Cisco voice gateways support two types of fax relay: T.38 fax relay and Cisco fax relay. Both of these fax relay types appear almost exactly the same when looking at the call legs using the command show call active voice brief.

A notable caveat applies when viewing call legs for T.38 or Cisco fax relay calls. After the call has made the transition to fax relay, the POTS or telephony call leg is no longer shown using the show call active voice brief command. Instead, the command show call active fax brief must be used. The IP call leg, on the other hand, always remains viewable with the show call active voice brief command.

The switchover to T.38 fax relay can occur with NSEs or within the VoIP signaling protocol. However, from the show call active voice brief command perspective, the switchover mechanism is irrelevant. NSE-based or protocol-based switchovers appear the same. Example 12-10 highlights the show call active voice brief command for a T.38 fax relay call.

Example 12-10 show call active voice brief Command Output for a T.38 Fax Relay Call

11E2 : 4 2956390ms.1 +10500 pid:1 Originate 200 active dur 00:00:46 tx:707/13770 rx:914/12339

IP 1.1.1.2:18496 SRTP: off rtt:3ms pl:4800/0ms lost:0/0/0 delay:60/60/70ms t38 TextRelay: off media inactive detected:n media contrl rcvd:n/a timestamp:n/a long duration call detected:n long duration call duration:n/a timestamp:n/a

In Example 12-10, you can instantly tell that the transition to T.38 has been successful because t38 appears as the codec in the IP call leg. Until the T.38 switchover occurs, this field is populated with the voice codec used for the initial VoIP call.

Cisco fax relay appears practically identical to T.38 fax relay in a show call active voice brief. The only distinguishing characteristic is the presence of the keyword cisco rather than t38 as the codec for the IP leg. Example 12-11 illustrates a show call active voice brief for a Cisco fax relay call. Example 12-11 show call active voice brief Command Output for a Cisco Fax Relay Call

121C : 26 1027355900ms.1 +10510 pid:1 Originate 200 active dur 00:00:45 tx:1113/22164 rx:1001/19972

IP 1.1.1.2:18274 SRTP: off rtt:2ms pl:0/0ms lost:0/0/0 delay:0/0/0ms cisco TextRelay: off media inactive detected:n media contrl rcvd:n/a timestamp:n/a long duration call detected:n long duration call duration:n/a timestamp:n/a

Similar to T.38 fax relay, the presence of cisco as the codec in the IP call leg indicates that the switchover to Cisco fax relay was successful. In addition, as mentioned previously, the POTS call leg is no longer present under the command show call active voice brief for either T.38 or Cisco fax relay. Example 12-12 demonstrates how the fax relay POTS call leg is now viewable with the command show call active fax brief.

Example 12-12 show call active fax brief Command Output for a Fax Relay Call

11E2 : 3 2952150ms.1 +14740 pid:2 Answer 100 active dur 00:00:45 tx:890/19303 rx:311/6019

Tele 0/0/0 (3) [0/0/0] tx:21420/8080/0ms 7200 noise:-74 acom:20 i/0:-14/-11 dBm

The POTS or telephony call leg displayed in Example 12-12 could be for either a T.38 or Cisco fax relay call. Nothing in the POTS call leg distinguishes whether the call is T.38 or Cisco fax relay, so the POTS call leg for any fax relay call always appears in a similar fashion. When it might be necessary to confirm whether the POTS call leg shown in a show call active fax brief command is T.38 or Cisco fax relay, you can note the call identifier (11E2 in the case of Example 12-12) and find the associated IP call leg with the same identifier with the command show call active voice brief. As previously shown in Examples 12-10 and 12-11, the IP call legs designate whether the call is T.38 or Cisco fax relay.

A notable parameter in the fax relay POTS call leg is the speed at which the fax call negotiates. In the case of Example 12-12, this speed is 7200 bps.

Cisco Modem Relay Call Legs

Cisco modem relay is unique in that the switchover uses a two-stage transition process. The initial voice call does not transition directly to Cisco modem relay but instead proceeds to modem passthrough first before finally transitioning to Cisco modem relay. Therefore, Cisco modem relay calls momentarily appear as modem passthrough calls. Example 12-13 shows a call in modem passthrough mode before it ultimately transitions to Cisco modem relay.

Example 12-13 show call active voice brief Command Output for a Cisco Modem Relay Call Transitioning Through Modem Passthrough

11FD : 15 643750ms.1 +5410 pid:2 Answer 100 active

dur 00:00:02 tx:168/8311 rx:87/5217

Tele 0/0/0 (15) [0/0/0] tx:520/520/0ms g711ulaw noise:-78 acom

57 i/0:-71/-13 dBm

11FD : 16 646070ms.1 +3090 pid:1 Originate 200 active

dur 00:00:02 tx:52/4565 rx:168/6967

IP 1.1.1.2:17614 SRTP: off rtt:0ms pl:1770/0ms lost:0/0/0 delay

70/70/70ms g711ulaw

TextRelay: off

media inactive detectedin media contrl rcvd:n/a timestamp:n/a

long duration call detectedin long duration call duration:n/a

timestamp:n/a

MODEMPASS

nse buf:0/0 loss 0% 0/0 last 0s dur:0/0s

For the IP call leg in Example 12-13, MODEMPASS and the g711ulaw codec are displayed. These parameters indicate that the call is currently in modem passthrough mode. The call may remain as a modem passthrough call if the switchover to Cisco modem relay fails.

The trigger that initiates the final switchover from modem passthrough to Cisco modem relay is contained in the calling menu/joint menu (CM/JM) V.8 message exchange. For more information about CM/JM and V.8, see the section "Phase I: Network Interaction" in Chapter 1, "How Modems Work."

Parameters within the CM/JM messages detail information such as the modulation type and even whether the call is a high-speed modem call or a Super G3 fax call. For a call to successfully transition to Cisco modem relay, the CM/JM exchange should ideally indicate a V.34 high-speed modem call. The V.90 modulation should work, too, but it will be forced down to V.34 speeds.

Assuming that V.34 is successfully negotiated between the modems and the gateways, the call ultimately transitions from modem passthrough to Cisco modem relay. Example 12-14 highlights how a Cisco modem relay call appears when the show call active voice brief command is issued after the switchover to Cisco modem relay is complete.

Example 12-14 show call active voice brief Command Output for a Cisco Modem Relay Call

11FD : 15 643750ms.1 +5410 pid:2 Answer 100 active dur 00:32:07 tx:18604/347313 rx:125/10361

Tele 0/0/0 (15) [0/0/0] tx:520/520/0ms modem-relay noise:-78 acom:57 i/0:-71/-13 dBm

MODEMRELAY info:0/464/0 xid:1/1 total:0/942/0

speeds(bps): local 28800/31200 remote 28800/31200 phy/ec v34/v42 gateway-controlled

11FD : 16 646070ms.1 +3090 pid:1 Originate 200 active dur 00:32:07 tx:18752/124381 rx:18604/198481

IP 1.1.1.2:17614 SRTP: off rtt:0ms pl:1770/0ms lost:0/0/0 delay:70/70/70ms modem-relay

TextRelay: off media inactive detected:n media contrl rcvd:n/a timestamp:n/a long duration call detected:n long duration call duration:n/a timestamp:n/a MODEMPASS

In Example 12-14, notice the presence of the modem-relay keyword as the codec in both the POTS and IP call legs. This informs you that this call has completed a successful negotiation and transition to Cisco modem relay.

Also notice additional Cisco modem relay-specific statistics in the POTS call leg that were not present before. These statistics provide important information about the Cisco modem relay call itself and should be checked when troubleshooting Cisco modem relay calls. Table 12-4 details the Cisco modem relay statistics found in a show call active voice brief.

Table 12-4 Important Parameters in the show call active voice brief Command Output for Cisco Modem Relay

Field Value Description info:rcvd/sent/resent info:0/464/0 Specifies the number of received, sent, and re-sent information frames. Information or I-frames are responsible for transporting data over a V.42 connection. V.42 was discussed previously in the section "Error Control" in Chapter 1.

xid:rcvd/sent xid:1/1 Details the number of received and sent exchange identification (XID) frames sent and received during the V.42 capability negotiation. XID frames were previously covered in the section "Error Control" in Chapter 1.

total:rcvd/sent/drops total:0/942/0 Shows the total number of bytes received and sent between the modems and the number of Simple Packet Relay Transport (SPRT) packet drops. More information about SPRT and its format can be found in the section "Modem Relay" in Chapter 5, "Relay."

Specifies the negotiated receive and transmit speeds for the local and remote connections and defines the physical layer and error correction layer protocols. Also, defines the method used for the switchover to modem relay.

speeds(bps): local rx/tx remote rx/tx phy/ec physical/ error-correction mode speeds(bps): local 28800/ 31200 remote 28800/ 31200 phy/ec v34/v42 gateway-controlled

Text Telephony Call Legs

Text telephony can be transported across VoIP networks using Text over G.711 or Cisco text relay. With Text over G.711, the show call active voice brief command looks like a normal G.711 voice call. However, for a Cisco text relay call, the show call active voice brief command appears differently, as illustrated in Example 12-15. Example 12-15 show call active voice brief Command Output for a Cisco Text Relay Call

11F3 : 11 420984780ms.1 +11920 pid:1 Answer 100 active dur 00:31:02 tx:702/13164 rx:5537/109060

IP 1.1.1.1:18286 SRTP: off rtt:0ms pl:108980/0ms lost:0/1/0 delay:60/60/70ms g729r8 TextRelay: on media inactive detected:n media contrl rcvd:n/a timestamp:n/a long duration call detected:n long duration call duration:n/a timestamp:n/a

Example 12-15 show call active voice brief Command Output for a Cisco Text Relay Call (Continued)

11F3 : 12 420984780ms.2 +11920 pid:2 Originate 200 active dur 00:31:02 tx:5537/153356 rx:702/13164

Tele 0/0/0 (12) [0/0/0] tx:1874750/12550/0ms g729r8 noise:-74 acom:29 i/0:-74/-45 dBm

The first thing that you will probably notice in Example 12-15 is that the codec is g729r8. Although g729r8 works well for voice, it is not recommended for modulated communications. However, Cisco text relay does not use the voice codec for relaying the text telephony information, so any codec type can be used for a Cisco text relay call. The codec type is not important because Cisco text relay uses its own packets with a different RTP payload type. For more information about Cisco text relay and how it works, see the section "Cisco Text Relay" in Chapter 5.

What matters in Example 12-15 is the parameter TextRelay: on. This parameter informs you that Cisco text relay is enabled and that any text telephony character will be handled by the Cisco text relay protocol. Because Cisco text relay does not have any sort of switchover, the call leg will never transition to Cisco text relay mode. The Cisco text relay feature is either considered on or off for each IP call leg based on whether the Cisco text relay feature has been enabled in the configuration.

Call Leg Troubleshooting Techniques

There are a couple of helpful troubleshooting techniques when working with call legs. These techniques can prove quite useful when you need to analyze completed calls or you have to deal with large numbers of calls on production gateways.

The show call history voice brief and show call history fax brief commands are useful for analyzing calls that previously occurred on the IOS gateway. These commands provide a means for looking back at fax, modem, or text calls that might have had problems but are no longer active on the gateway. Example 12-16 highlights a show call history voice brief command for a past T.38 fax relay call. Example 12-16 show call history voice brief Command Output for a T.38 Fax Relay Call

1209 : 19 137792170ms.18 +10520 +70420 pid:1 Originate 200 dur 00:00:59 tx:1148/37504 rx:758/11683 10 (normal call clearing (16)) IP 1.1.1.2:16746 SRTP: off rtt:1ms pl:4710/0ms lost:0/0/0 delay:60/60/70ms t38 TextRelay: off media inactive detected:n media contrl rcvd:n/a timestamp:n/a long duration call detected:n long dur callduration :n/a timestamp:n/a FAXRELAY jitter:0 ms/0 mod:0 pages:0

The show call history voice brief command displayed in Example 12-16 provides some additional information that is not included with a show call active voice brief command. For example, because the call has been completed, the gateway can record the disconnect reason for the call. Therefore, in Example 12-16, you can see that the call was disconnected by normal call clearing, which is represented with a clearing cause code of 16. This type of information can be critical when trying to figure out why calls are disconnecting prematurely. The call disconnect information displayed in the IP leg of Example 12-16 is also shown when looking at the completed POTS call leg using the command show call history fax brief.

In addition to the t38 parameter that is found in the output of the command show call active voice brief, the show call history voice brief command displays a FAXRELAY parameter for the T.38 fax relay call in Example 12-16. This FAXRELAY parameter is just another indication that the call switched over successfully to T.38 or Cisco fax relay.

TIP The call history buffer used by the show call history voice brief and show call history fax brief commands is set by default to retain only up to 50 call leg entries for a duration of 15 minutes. However, you can change these settings with the IOS commands dial-control-mib retain-timer and dial-control-mib max-size. Adjusting the call history buffer size and duration may be helpful when troubleshooting intermittent problems or problems when the gateway is experiencing a high call volume.

The ability to quickly parse through large numbers of calls in the output of a show call active voice brief or a show call history voice brief is critical when troubleshooting a problem when a heavy call volume is present. The following technique along with the CLI parsing features available in IOS provide a means for quickly isolating the call that you are interested in troubleshooting.

For example, suppose you are trying to troubleshoot a T.38 fax relay problem on a gateway that has more than 50 simultaneous calls. Manually looking through all 100+ call legs would take too much time. However, if you know a distinguishing characteristic about that T.38 call, such as a unique calling or called number, you can look for the call based on this information. Example 12-17 illustrates how a single call can be isolated from many others within a show call active voice brief.

In Example 12-17, the called number, 100, is unique to the call that is being troubleshot. So, the command show call active voice brief called-number 100 is used to search for lines in the output of show call active voice brief that contain this number. Only one call leg is returned, and the first line of this call leg provides the call ID for our call, 121B. Now you can parse for this call ID of 121B and get all the information for both call legs, as shown in Example 12-18.

Example 12-17 Isolating a Single Call Using the Command show call active voice brief called number

CAE-DH-3845-1# show call active voice brief called-number 100

121B : 26 26182740ms.1 +10490 pid:100 Originate 100 active dur 00:00:27 tx:1389/221304 rx:944/147843

IP 172.18.122.74:17996 SRTP: off rtt:1ms pl:7845/40ms lost:0/0/0 delay:65/60/65ms g711ulaw TextRelay: off media inactive detected:n media contrl rcvd:n/a timestamp:n/a long duration call detected:n long duration call duration:n/a timestamp:n/a MODEMPASS nse buf:0/0 loss 0% 0/0 last 1588s dur:0/0s

Example 12-18 Isolating a Single Call Using the Command show call active voice brief id

CAE-DH-3845-1# show call active voice brief id 121b

121B : 25 26180600ms.1 +12630 pid:0 Answer active dur 00:00:43 tx:1734/288115 rx:2701/431224

Tele 0/1/0 (25) [0/1/0] tx:23870/23870/0ms g711ulaw noise:-11 acom:6 i/0:-14/-31 dBm

121B : 26 26182740ms.1 +10490 pid:100 Originate 100 active dur 00:00:43 tx:2178/347544 rx:1734/274243

IP 172.18.122.74:17996 SRTP: off rtt:2ms pl:21980/40ms lost:0/0/0 delay:65/60/65ms g711ulaw TextRelay: off media inactive detected:n media contrl rcvd:n/a timestamp:n/a long duration call detected:n long duration call duration:n/a timestamp:n/a MODEMPASS nse buf:0/0 loss 0% 0/0 last 4415s dur:0/0s

The command show call active voice brief id 121b parses through the output of the show call active voice brief command and displays the call legs with a call leg ID of 121B. This enables you to clearly see both the POTS and IP call legs for troubleshooting purposes. Repeating this command allows you to monitor this call, including its statistics for its duration without being distracted by the other active calls occurring on the voice gateway.

This same parsing strategy is also applicable to the command show call history voice brief as long as there is a unique call leg component available within the same line as the call ID. Whereas the calling or called number is the most common parameter used for the initial parsing, the dial-peer ID may also be a good choice.

Was this article helpful?

+1 -1

Responses

  • Eleuterio
    How to check active calls in a voice gateway?
    8 months ago
  • JEFFERSON BRIDGER
    How to see a call leg on a cisco gateway?
    6 months ago

Post a comment