[cisco-voip] DNA for routers

Nicholas Schilling [us] schillingn at gmail.com
Thu Jun 2 11:39:39 EDT 2011 



    http://www.cisco.com/en/US/tech/tk1077/technologies_tech_note09186a0080094045.shtml



    Verify End-to-End VoIP Signaling (VOIP Call-Leg)

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:

    *

      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.

    *

      End-to-End VoIP debugging shows a number of IOS state-machines.
      Problems with any state-machine can cause a call to fail.

    *

      End-to-End VoIP debugging can be very verbose and create a lot of
      debug output.


      debug voip ccapi inout

The primary command to debug end-to-end VoIP calls is *debug voip ccapi 
inout 
<http://www.cisco.com/en/US/docs/ios/12_3/debug/command/reference/dbg_v1g.html#wp1106585>* 
. The output from a call debug is shown in this output.

/
!--- Action: A VoIP call is originated through the
!--- Telephony SPI (pots leg) to extension 5000.
!--- Some output is omitted.
/

maui-voip-austin#*debug voip ccapi inout*
voip ccAPI function enter/exit debugging is on

/
!--- Call leg identification, source peer: Call
!--- originated from dial-peer 1 pots
!--- (extension 4000).
/

*Mar 15 22:07:11.959: cc_api_call_setup_ind
(vdbPtr=0x81B09EFC,*callInfo={called=,
calling=4000, fdest=0 peer_tag=1*}, callID=0x81B628F0)
/
!--- CCAPI invokes the session application.
/

**Mar 15 22:07:11.963: cc_process_call_setup_ind
(event=0x81B67E44) handed call to app "SESSION"*
*Mar 15 22:07:11.963: sess_appl:
ev(23=CC_EV_CALL_SETUP_IND), cid(88), disp(0)

/
!--- Allocate call leg identifiers "callid = 0x59"
/

*Mar 15 22:07:11.963: ccCallSetContext
(*callID=0x58*, context=0x81BAF154)
*Mar 15 22:07:11.963: ccCallSetupAck
(*callID=0x58*)

/
!--- Instruct VTSP to generate dialtone
/.

**Mar 15 22:07:11.963: ccGenerateTone
(callID=0x58*  tone=8)

/
!--- VTSP passes digits to CCAPI.
/

*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)
**Mar 15 22:07:20.327: cc_api_call_digit
(vdbPtr=0x81B09EFC, callID=0x58, digit=5*
, 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)
**Mar 15 22:07:22.075: cc_api_call_digit
(vdbPtr=0x81B09EFC, callID=0x58, digit=0*
, 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)
**Mar 15 22:07:23.335: cc_api_call_digit
(vdbPtr=0x81B09EFC, callID=0x58, digit=0*
, 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)
**Mar 15 22:07:25.255: cc_api_call_digit
(vdbPtr=0x81B09EFC, callID=0x58, digit=0*
, 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)

/
!--- Matched dial-peer 2 voip. Destination number
!--- 5000
/

**Mar 15 22:07:25.259: ssaSetupPeer cid(88)
peer list:tag(2) called number(5000)*
*Mar 15 22:07:25.259: ssaSetupPeer cid(88),
*destPat(5000)*, matched(4), prefix(),
peer(81C04A10)

/
!--- Continue to call an interface and start the
!--- next call leg.
/

**Mar 15 22:07:25.259: ccCallProceeding
(callID=0x58*, prog_ind=0x0)
**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*, redirectNumber=

/
!--- VoIP call setup.
/

**Mar 15 22:07:25.263: ccIFCallSetupRequest:*
(vdbPtr=0x81A75558, dest=,
*callParams={called=5000, calling=4000,
fdest=0, voice_peer_tag=2}*, mode=0x0)
**Mar 15 22:07:25.263: ccCallSetContext
(callID=0x59*, context=0x81BAF3E4)
*Mar 15 22:07:25.375: ccCallAlert
(callID=0x58, prog_ind=0x8, sig_ind=0x1)

/
!--- POTS and VoIP call legs are tied together.
/

**Mar 15 22:07:25.375: ccConferenceCreate
(confID=0x81B6DEA0, callID1=0x58, callI
D2=0x59, tag=0x0)*
**Mar 15 22:07:25.375: cc_api_bridge_done*
(confID=0x1E, srcIF=0x81B09EFC,*srcCall*
*ID=0x58, dstCallID=0x59*, disposition=0,
tag=0x0)

/
!--- Exchange capability bitmasks with remote
!--- the VoIP gateway
!--- (Codec, VAD, VoIP or FAX, FAX-rate, and so forth).
/

**Mar 15 22:07:26.127: cc_api_caps_ind*
(dstVdbPtr=0x81B09EFC,*dstCallId=0x58, src
CallId=0x59,caps={codec=0x4, fax_rate=0x2,
vad=0x2, modem=0x1 codec_bytes=20,
signal_type=0})*

/
!--- Both gateways agree on capabilities.
/
**Mar 15 22:07:26.127: cc_api_caps_ack*
(dstVdbPtr=0x81B09EFC,*dstCallId=0x58, src*
*CallId=0x59, caps={codec=0x4, fax_rate=0x2,
vad=0x2, modem=0x1 codec_bytes=20,
signal_type=0})*
**Mar 15 22:07:26.139: cc_api_caps_ack*
(dstVdbPtr=0x81A75558,*dstCallId=0x59*, src
*CallId=0x58, caps={codec=0x4, fax_rate=0x2,
vad=0x2, modem=0x1 codec_bytes=20,
signal_type=0})*
*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)
**Mar 15 22:07:35.399: cc_api_call_connected*
(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)

/
!--- VoIP call is connected.
/

**Mar 15 22:07:35.399: ccCallConnect*
(callID=0x58)

/
!--- VoIP call is disconnected. Cause = 0x10
/

**Mar 15 23:29:39.530: ccCallDisconnect
(callID=0x5B, cause=0x10 tag=0x0)*

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:

    *

      *debug ip tcp transactions
      <http://www.cisco.com/en/US/docs/ios/12_3/debug/command/reference/dbg_i3g.html#wp1018158>*
      and *debug ip tcp packet*---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.

    *

      *debug cch323 h225
      <http://www.cisco.com/en/US/docs/ios/12_3/debug/command/reference/dbg_c2g.html#wp1090785>*
      ---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.

    *

      *debug cch323 h245
      <http://www.cisco.com/en/US/docs/ios/12_3/debug/command/reference/dbg_c2g.html#wp1091236>*
      ---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.




On 6/2/2011 10:10 AM, Marcelo Zilio wrote:
>
> Is there any kind of dialed number analyzer for h323 routers?
>
> I know the "show dialplan" command, but it is not exactly what I want.
>
> I need the router tell me something like this:
> - now dial-peer 10 is matched
> - now dial-peer 10 strip off the leftmost digit
> - now voice translation XX takes place
> - now forward digits all is activated
> - now I am placing the call and the dialed digits are: 123456
>
> Thanks
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20110602/b21df2b6/attachment.html>

More information about the cisco-voip mailing list