2017 03 09- V1.

1
Mar, 2017

Document control

date Version no. author change/addition

23 May 2013 1.0 Ibrahim Dwidar Document creation
09 Mar 2017 1.1 Ibrahim Dwidar Document Update
 CONTENTS

1) Document Objectives ................................................................................................... 3

2) IOS Voice Architecture ................................................................................................. 3
3) Different call flow scenarios........................................................................................... 4
3.1) POTS to VOIP call flow .............................................................................................. 5
3.2) POTS to POTS call flow ............................................................................................. 6
3.3) VOIP TO VOIP Call Flow............................................................................................ 6
4) Different Debugs .......................................................................................................... 7
5) Enable logging and capturing logs on VG ..................................................................... 12

Page 2 of 13
This document discusses the Cisco VG IOS architecture, different call flow scenarios and lists most
of the debugs required for troubleshooting Voice and Fax calls together with the best approach to
enable logging and capture traces from Cisco VGs.

Below Figure (Figure 1) shows the IOS Voice Architecture for any cisco VG and how the call is
processed inside the cisco VG between its different layers

(Figure 1)

Page 3 of 13
Any voice call should have 2 call legs on the VG, inbound call leg and outbound call leg.
Except for some special cases when the VG is used as a media resource.

When the VG is used as a media resource ( conference, Transcoding , MTP) , CUCM trigger a skinny
call to the VG requesting the VG to invoke a media resource ( Conference, Transcoder, MTP).
In that case the VG will have one or more call legs depending on the media resource type used.

To realize which debugs you should enable on the VG for troubleshooting any call flow problems,
you have 1st to know the detailed call path, call control protocols used, each node involved in the
call flow, hence enable the related debug of each leg of the call on each node according to the leg
type ( POT/VOIP), the protocol used for that call leg ( SIP, SKINNY, H323,MGCP) and the call type (
Voice/FAX)

Below are different scenarios for call flow on VG

Page 4 of 13
 3.1) POTS to VOIP call flow

(Figure 2)

This is the most common call scenario , where call comes for example from PSTN or PBX through
analog ( FXS/ FXO) or digital trunk ( E1/T1) to the Cisco TDM VG like Cisco 2900,3900, 2800 ISRs
and then the VG sends the call through data network to the CUCM server or CVP server directly or
through SIP proxy (Call Center solution) using different VOIP protocols ( SIP, H323, MGCP, SKINNY) .

In this case the Inbound call leg ( dial-peer) will be POTS and the outbound call leg
(dial-peer) will be VOIP or vice versa. (Figure 2)

Page 5 of 13
 3.2) POTS to POTS call flow

(Figure 3)

This scenario is used also sometimes, and mostly used in VGs like CISCO VG248 or CISCO VG248 ,
where the VG has 24 or more FXS ports connecting different Analog phones and FAXs.

In this scenario, the analog phone calling another analog phone connected to same VG, hence the 2
call legs will be POTS and the inbound and outbond dial-peer will be pots dial-peer. (Figure 3)

VG DSP may or may not be involved in this call according to your VG configuration.

3.3) VOIP TO VOIP Call Flow

(Figure 4)

This is special case where the Inbound call leg to the VG will be VOIP and the outbound call leg will
be also VOIP, here the VG is as what’s call Cisco Unified Border Element or CUBE. (Figure 4)

Page 6 of 13
Below is list of frequently needed debugs in troubleshooting most of Voice/ Fax calls problems on
Cisco IOS VGs platform according to the protocol used for each call leg.

Remember you should always enable at least the 2 call legs protocol debugs beside the main VG
Call Control debug ( CCAPI) as minimum requirement for troubleshooting any voice/fax call
problem.

Never enable one call leg protocol debugs only and never enable
even the 2 calls legs debugs without the main VG Control debug
(CCAPI) as this will most probably miss lead you in isolating the
fault.

Main VG Call Control API

- Debug voice ccapi inout

SIP

- Debug ccsip messages

H323

- Debug cch323 all

- Debug h245 asn1
- Debug h225 asn1

Page 7 of 13
MGCP

- Debug mgcp Packets

# In case of PRI/BRI Backhauling , use also the below debugging below

- Debug ccm-manager backhaul packets

SKINNY Media Resources

- Debug voice ccapi inout

- Debug sccp all
Or
- Debug sccp messages

# You may also need DSP debugging mentioned later here in case you suspect DSP problem in the
VG

SKINNY Endpoints
- Debug sccp all
- Debug voip application stcapp all

Analog Trunks

- Debug vpm signal

Or
- Debug vpm all  better

- Debug voip vtsp all

- Debug voip dialpeer all

Page 8 of 13
Digital Trunks

# CCS ( Ex: ISDN PRI/ BRI)

- Debug isdn q931

- Debug isdn q921  For ISDN L2 problems

# CAS ( Ex: E1 R2)

- Debug VPM all

- Debug vtsp all

# Other Debugs for CAS ( Ex: E1 R2) ( Not all of them currently valid for recent IOSs)

- Debug cas −>For line signaling.

- Debug csm voice −> For interregister signaling.

- debug voip ccapi indevedual 80

- debug voip ccapi indevedual 10 or 100

- debug q241

CME - Phone Registration

- Debug ephone register

- Debug tftp events

CME - Call debugging

- Debug voip ccapi inout
- Debug vpm signal
- Debug voip vtsp all
- Debug voip dialpeer all

Page 9 of 13
DTMF

# RFC 2833 ( Aka RTP-NTE) ( SIP, MGCP, H.323)

- Debug voip rtp session named-event

# SIP-Notify
- Normal sip debugging mentioned earlier

# H.323 DTMF (H245- alphanumeric ,H.245-signal)

- Debug H245 asn1

# MGCP DTMF (MGCP- Notify)

- Normal MGCP debugging mentioned earlier

DSP Issues

- Debug dsp-resource-manager flex all

- Debug voip dspapi

RTP Issues ( Like Voice quality issues, Voice stream delay or one-way voice or no
voice stream)

- Debug voip rtp  This debug is very processor intensive , it should be done OBH and in call
by call basis not while there are many calls on the VG

Or

- Debug cch323 rtp  ( Occasionally used) This debug is very processor intensive , it should
be done OBH and in call by call basis not while there are many calls on the VG

Page 10 of 13
Fax Calls
- Debug fax relay t30 all-level-1
- Debug voip dsm all
- Debug voip dsmp all
- Debug voip hpi all
- Debug voip vtsp all

# For NSE-Based Switchover (FAX Passthrough or FAX Relay), enable also below debug

- Debug voip rtp session nse

# In case of Skinny controlled VGs/Interfaces, enable also below debug beside the above

- Debug voip application stcapp all

Call Center Related Issues ( CVP call Flow)

- Debug voip ccapi inout
- Debug CCSIP messages
- Debug voip application vxml all
- Debug ip http client all

Network/Security  Voice related problems

- Debug ip tcp transactions

Page 11 of 13
Enabling logging on the terminal monitor of the VG will most
probably cause the VG to crash, also it will cause you to lose lots
of traces while collecting them.
Best practice for enabling traces on Cisco IOS VG is to enable logging on VG buffer then collect
them as below

conf t

service timestamps debug datetime msec

service timestamps log datetime msec
service sequence-numbers
no logging console
no logging monitor
logging buffered 10000000 7
end

clear logging

-> Enable the required debugs for ex as below

debug isdn q931

debug voip ccapi inout
debug ccsip mess

Then after you make the call and simulate the issue, stop the debugging:

#undebug all

And collect the output as below:

From the putty session choose change setting , then in the logging tab choose " all session
output" as below then browse and choose the file name and location you would like to save the
logs to (Figure 5) .

Page 12 of 13
 (Figure 5)

Then on the VG type the below to collect the logs from the buffer

#term len 0
#show log

Then restore the terminal length size back again by typing the below command

#term len 40

Page 13 of 13