<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<small><small><small><span class="content">
<h2><br>
</h2>
<h2><br>
</h2>
<h2><a class="moz-txt-link-freetext" href="http://www.cisco.com/en/US/tech/tk1077/technologies_tech_note09186a0080094045.shtml">http://www.cisco.com/en/US/tech/tk1077/technologies_tech_note09186a0080094045.shtml</a></h2>
<h2><a name="endtoend"></a></h2>
<h2><br>
</h2>
<h2><a name="endtoend">Verify End-to-End VoIP Signaling
(VOIP Call-Leg)</a></h2>
<p>After you verify that voice-port signaling works properly
and the correct digits are received, move to the VoIP call
control troubleshooting and debugging. These factors
explain why call control debugging can become a complex
job:</p>
<ul>
<li>
<p>Cisco VoIP gateways use H.323 signaling to complete
calls. H.323 is made up of three layers of
call-negotiation and call-establishment: H.225, H.245,
and H.323. These protocols use a combination of TCP
and UDP to set up and establish a call.</p>
</li>
<li>
<p>End-to-End VoIP debugging shows a number of IOS
state-machines. Problems with any state-machine can
cause a call to fail.</p>
</li>
<li>
<p>End-to-End VoIP debugging can be very verbose and
create a lot of debug output.</p>
</li>
</ul>
<h3><a name="voipccapi">debug voip ccapi inout</a></h3>
<p>The primary command to debug end-to-end VoIP calls is <b><a
href="http://www.cisco.com/en/US/docs/ios/12_3/debug/command/reference/dbg_v1g.html#wp1106585">debug
voip ccapi inout</a></b> . The output from a call
debug is shown in this output.</p>
<table bgcolor="#ffffff" border="1" cellpadding="3"
cellspacing="1" width="60%">
<tbody>
<tr>
<td colspan="1" rowspan="1" bgcolor="#ffffff" width=""
height="">
<pre><i>
<font color="#0000ff">!--- Action: A VoIP call is originated through the
!--- Telephony SPI (pots leg) to extension 5000.
!--- Some output is omitted.</font>
</i>
maui-voip-austin#<b>debug voip ccapi inout</b>
voip ccAPI function enter/exit debugging is on
<i>
<font color="#0000ff">!--- Call leg identification, source peer: Call
!--- originated from dial-peer 1 pots
!--- (extension 4000).</font>
</i>
*Mar 15 22:07:11.959: cc_api_call_setup_ind
(vdbPtr=0x81B09EFC, <b>callInfo={called=,
calling=4000, fdest=0 peer_tag=1</b>}, callID=0x81B628F0)
<i>
<font color="#0000ff">!--- CCAPI invokes the session application.</font>
</i>
<b>*Mar 15 22:07:11.963: cc_process_call_setup_ind
(event=0x81B67E44) handed call to app "SESSION"</b>
*Mar 15 22:07:11.963: sess_appl:
ev(23=CC_EV_CALL_SETUP_IND), cid(88), disp(0)
<i>
<font color="#0000ff">!--- Allocate call leg identifiers "callid = 0x59"</font>
</i>
*Mar 15 22:07:11.963: ccCallSetContext
(<b>callID=0x58</b>, context=0x81BAF154)
*Mar 15 22:07:11.963: ccCallSetupAck
(<b>callID=0x58</b>)
<i>
<font color="#0000ff">!--- Instruct VTSP to generate dialtone</font>
</i>.
<b>*Mar 15 22:07:11.963: ccGenerateTone
(callID=0x58</b> tone=8)
<i>
<font color="#0000ff">!--- VTSP passes digits to CCAPI.</font>
</i>
*Mar 15 22:07:20.275:cc_api_call_digit_begin
(vdbPtr=0x81B09EFC,callID=0x58,digit=5, flags=0x1, timestamp=0xC2E63BB7, expiration=0x0)
*Mar 15 22:07:20.279: sess_appl:
ev(10=CC_EV_CALL_DIGIT_BEGIN), cid(88), disp(0)
*Mar 15 22:07:20.279: ssaTraceSct:
cid(88)st(0)oldst(0)cfid(-1)csize(0)in(1)fDest(0)
*Mar 15 22:07:20.279: ssaIgnore cid(88),
st(0),oldst(0), ev(10)
<b>*Mar 15 22:07:20.327: cc_api_call_digit
(vdbPtr=0x81B09EFC, callID=0x58, digit=5</b>
, duration=100)
*Mar 15 22:07:20.327: sess_appl:
ev(9=CC_EV_CALL_DIGIT), cid(88), disp(0)
*Mar 15 22:07:20.327: ssaTraceSct:
cid(88)st(0)oldst(0)cfid(-1)csize(0)in(1)fDes
t(0)
*Mar 15 22:07:21.975:cc_api_call_digit_begin
(vdbPtr=0x81B09EFC,callID=0x58,digit=0,
flags=0x1, timestamp=0xC2E63BB7, expiration=0x0)
*Mar 15 22:07:21.979: sess_appl:
ev(10=CC_EV_CALL_DIGIT_BEGIN), cid(88), disp(0)
*Mar 15 22:07:21.979: ssaTraceSct:
cid(88)st(0)oldst(0)cfid(-1)csize(0)in(1)fDes
t(0)
*Mar 15 22:07:21.979: ssaIgnore cid(88),
st(0),oldst(0), ev(10)
<b>*Mar 15 22:07:22.075: cc_api_call_digit
(vdbPtr=0x81B09EFC, callID=0x58, digit=0</b>
, duration=150)
*Mar 15 22:07:22.079: sess_appl:
ev(9=CC_EV_CALL_DIGIT), cid(88), disp(0)
*Mar 15 22:07:22.079: ssaTraceSct:
cid(88)st(0)oldst(0)cfid(-1)csize(0)in(1)fDest(0)
*Mar 15 22:07:23.235: cc_api_call_digit_begin
(vdbPtr=0x81B09EFC, callID=0x58, dgit=0,
flags=0x1, timestamp=0xC2E63BB7, expiration=0x0)
*Mar 15 22:07:23.239: sess_appl:
ev(10=CC_EV_CALL_DIGIT_BEGIN), cid(88), disp(0)
*Mar 15 22:07:23.239: ssaTraceSct:
cid(88)st(0)oldst(0)cfid(-1)csize(0)in(1)fDest(0)
*Mar 15 22:07:23.239: ssaIgnore cid(88),
st(0),oldst(0), ev(10)
<b>*Mar 15 22:07:23.335: cc_api_call_digit
(vdbPtr=0x81B09EFC, callID=0x58, digit=0</b>
, duration=150)
*Mar 15 22:07:23.339: sess_appl:
ev(9=CC_EV_CALL_DIGIT), cid(88), disp(0)
*Mar 15 22:07:23.339: ssaTraceSct:
cid(88)st(0)oldst(0)cfid(-1)csize(0)in(1)fDes
t(0)
*Mar 15 22:07:25.147: cc_api_call_digit_begin
(vdbPtr=0x81B09EFC, callID=0x58, d
igit=0, flags=0x1, timestamp=0xC2E63BB7,
expiration=0x0)
*Mar 15 22:07:25.147: sess_appl:
ev(10=CC_EV_CALL_DIGIT_BEGIN), cid(88), disp(0)
*Mar 15 22:07:25.147: ssaTraceSct:
cid(88)st(0)oldst(0)cfid(-1)csize(0)in(1)fDest(0)
*Mar 15 22:07:25.147: ssaIgnore cid(88),
st(0),oldst(0), ev(10)
<b>*Mar 15 22:07:25.255: cc_api_call_digit
(vdbPtr=0x81B09EFC, callID=0x58, digit=0</b>
, duration=160)
*Mar 15 22:07:25.259: sess_appl:
ev(9=CC_EV_CALL_DIGIT), cid(88), disp(0)
*Mar 15 22:07:25.259: ssaTraceSct:
cid(88)st(0)oldst(0)cfid(-1)csize(0)in(1)fDest(0)
<i>
<font color="#0000ff">!--- Matched dial-peer 2 voip. Destination number
!--- 5000</font>
</i>
<b>*Mar 15 22:07:25.259: ssaSetupPeer cid(88)
peer list:tag(2) called number(5000)</b>
*Mar 15 22:07:25.259: ssaSetupPeer cid(88),
<b>destPat(5000)</b>, matched(4), prefix(),
peer(81C04A10)
<i>
<font color="#0000ff">!--- Continue to call an interface and start the
!--- next call leg.</font>
</i>
<b>*Mar 15 22:07:25.259: ccCallProceeding
(callID=0x58</b>, prog_ind=0x0)
<b>*Mar 15 22:07:25.259: ccCallSetupRequest
(Inbound call = 0x58, outbound peer =2,
dest=, params=0x81BAF168 mode=0,
*callID=0x81B6DE58)
*Mar 15 22:07:25.259: callingNumber=4000,
calledNumber=5000</b>, redirectNumber=
<i>
<font color="#0000ff">!--- VoIP call setup.</font>
</i>
<b>*Mar 15 22:07:25.263: ccIFCallSetupRequest:</b>
(vdbPtr=0x81A75558, dest=,
<b>callParams={called=5000, calling=4000,
fdest=0, voice_peer_tag=2}</b>, mode=0x0)
<b>*Mar 15 22:07:25.263: ccCallSetContext
(callID=0x59</b>, context=0x81BAF3E4)
*Mar 15 22:07:25.375: ccCallAlert
(callID=0x58, prog_ind=0x8, sig_ind=0x1)
<i>
<font color="#0000ff">!--- POTS and VoIP call legs are tied together.</font>
</i>
<b>*Mar 15 22:07:25.375: ccConferenceCreate
(confID=0x81B6DEA0, callID1=0x58, callI
D2=0x59, tag=0x0)</b>
<b>*Mar 15 22:07:25.375: cc_api_bridge_done</b>
(confID=0x1E, srcIF=0x81B09EFC, <b>srcCall</b>
<b>ID=0x58, dstCallID=0x59</b>, disposition=0,
tag=0x0)
<i>
<font color="#0000ff">!--- Exchange capability bitmasks with remote
!--- the VoIP gateway
!--- (Codec, VAD, VoIP or FAX, FAX-rate, and so forth).</font>
</i>
<b>*Mar 15 22:07:26.127: cc_api_caps_ind </b>
(dstVdbPtr=0x81B09EFC, <b>dstCallId=0x58, src
CallId=0x59,caps={codec=0x4, fax_rate=0x2,
vad=0x2, modem=0x1 codec_bytes=20,
signal_type=0})</b>
<i>
<font color="#0000ff">!--- Both gateways agree on capabilities.</font>
</i>
<b>*Mar 15 22:07:26.127: cc_api_caps_ack </b>
(dstVdbPtr=0x81B09EFC, <b>dstCallId=0x58, src</b>
<b>CallId=0x59, caps={codec=0x4, fax_rate=0x2,
vad=0x2, modem=0x1 codec_bytes=20,
signal_type=0})</b>
<b>*Mar 15 22:07:26.139: cc_api_caps_ack</b>
(dstVdbPtr=0x81A75558, <b>dstCallId=0x59</b>, src
<b>CallId=0x58, caps={codec=0x4, fax_rate=0x2,
vad=0x2, modem=0x1 codec_bytes=20,
signal_type=0})</b>
*Mar 15 22:07:35.259: cc_api_call_digit
(vdbPtr=0x81B09EFC, callID=0x58, digit=T
, duration=0)
*Mar 15 22:07:35.259: sess_appl:
ev(9=CC_EV_CALL_DIGIT), cid(88), disp(0)
*Mar 15 22:07:35.259: ssaTraceSct:
cid(88)st(4)oldst(3)cfid(30)csize(0)in(1)
fDest(0)-cid2(89)st2(4)oldst2(1)
<b>*Mar 15 22:07:35.399: cc_api_call_connected</b>
(vdbPtr=0x81A75558, callID=0x59)
*Mar 15 22:07:35.399: sess_appl:
ev(8=CC_EV_CALL_CONNECTED), cid(89), disp(0)
*Mar 15 22:07:35.399: ssaTraceSct:
cid(89)st(4)oldst(1)cfid(30)csize(0)in(0)
fDest(0)-cid2(88)st2(4)oldst2(4)
<i>
<font color="#0000ff">!--- VoIP call is connected.</font>
</i>
<b>*Mar 15 22:07:35.399: ccCallConnect</b>
(callID=0x58)
<i>
<font color="#0000ff">!--- VoIP call is disconnected. Cause = 0x10</font>
</i>
<b>*Mar 15 23:29:39.530: ccCallDisconnect
(callID=0x5B, cause=0x10 tag=0x0)</b>
</pre>
</td>
</tr>
</tbody>
</table>
<p>
</p>
<p>If the call fails and the cause appears to be in the VoIP
portion of the call setup, you might possibly need to look
at the H.225 or H.245 TCP part of the call setup, as
opposed to just the UDP portion of the H.323 setup. The
commands that can be used to debug the H.225 or H.245 call
setup are:</p>
<ul>
<li>
<p><b><a
href="http://www.cisco.com/en/US/docs/ios/12_3/debug/command/reference/dbg_i3g.html#wp1018158">debug
ip tcp transactions</a></b> and <b>debug ip tcp
packet</b>—These commands examine the TCP portion of
the H.225 and H.245 negotiation. They return the IP
addresses, TCP ports, and states of the TCP
connections.</p>
</li>
<li>
<p><b><a
href="http://www.cisco.com/en/US/docs/ios/12_3/debug/command/reference/dbg_c2g.html#wp1090785">debug
cch323 h225</a></b> —This command examines the
H.225 portion of the call negotiation and traces the
state transition of the H.225 state machine based on
the processed event. Think of this as the Layer 1 part
of the three part H.323 call setup.</p>
</li>
<li>
<p><b><a
href="http://www.cisco.com/en/US/docs/ios/12_3/debug/command/reference/dbg_c2g.html#wp1091236">debug
cch323 h245</a></b> —This command examines the
H.245 portion of the call negotiation and traces the
state transition of the H.245 state machine based on
the processed events. Think of this as the Layer 2
part of the three part H.323 call setup.</p>
</li>
</ul>
</span></small><br>
<br>
<br>
On 6/2/2011 10:10 AM, Marcelo Zilio wrote:</small></small>
<blockquote
cite="mid:BANLkTik_87xhSCKFiVbFLLWO2FX5xuv7AQ@mail.gmail.com"
type="cite"><small><small><br>
Is there any kind of dialed number analyzer for h323 routers?<br>
<br>
I know the "show dialplan" command, but it is not exactly what
I want.<br>
<br>
I need the router tell me something like this:<br>
- now dial-peer 10 is matched<br>
- now dial-peer 10 strip off the leftmost digit<br>
- now voice translation XX takes place<br>
- now forward digits all is activated<br>
- now I am placing the call and the dialed digits are: 123456<br>
<br>
Thanks<br>
</small></small>
<pre wrap=""><small><small>
</small></small><fieldset class="mimeAttachmentHeader"></fieldset><small><small>
_______________________________________________
cisco-voip mailing list
<a class="moz-txt-link-abbreviated" href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a>
<a class="moz-txt-link-freetext" href="https://puck.nether.net/mailman/listinfo/cisco-voip">https://puck.nether.net/mailman/listinfo/cisco-voip</a>
</small></small></pre>
</blockquote>
<small><small><br>
</small></small>
</body>
</html>