Debug the calls on the voice gateway has more than E1

Answered Question
Mar 31st, 2010

Hi All;

How can I debug (to see if the call coming) to the voice gateway at its E1, but it has 5 E1s? Actually what I need to do is to know if an incoming call to the number 23451518 (DID is 1518) was reached or not?

When we try to call from any PSTN or Mobile to the number 23451518 (which is an extension of the DID 1518), we do not receive the call on that extension, and we need to do debug if it reached to the voice gateway E1s (the total of E1s are 5), so the call might come for any of those E1, how can we debug? Special if each E1 was in a separated trunk?

Any advise?

Regards

Bilal

I have this problem too.
0 votes
Correct Answer by Aaron Harrison about 6 years 8 months ago

Hi

You may be able to filter it as in this doc:

http://docwiki.cisco.com/wiki/Cisco_IOS_Voice_Troubleshooting_and_Monito...

Typically if you connect over telnet/ssh using putty, issue 'no logging console' to reduce CPU and log to a text file in Putty you'll be OK unless you know from experience that this is a particularly busy router (as in lots of start/end calls or other mid call signaling being generated rather than just high channel usage).

Regards

Aaron

Correct Answer by Aaron Harrison about 6 years 8 months ago

Hi

Just do a 'debug isdn q931', and log the output to a text file from putty if the GW is busy.

If you try to filter the output too much you may just miss the call you are looking for as it might arrive on an unexpected E1.

Search the output text file for your calling number as well as for the DID number you are expecting...

Regards

Aaron

Please rate helpful posts...

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Loading.
Correct Answer
Aaron Harrison Wed, 03/31/2010 - 03:33

Hi

Just do a 'debug isdn q931', and log the output to a text file from putty if the GW is busy.

If you try to filter the output too much you may just miss the call you are looking for as it might arrive on an unexpected E1.

Search the output text file for your calling number as well as for the DID number you are expecting...

Regards

Aaron

Please rate helpful posts...

bilalghayad Wed, 03/31/2010 - 07:02

Thanks a lot.

If alot of traffic is coming to the voice gateway, is there an effecient method to direct the output of the debug for a text file (or any good idea to collect the debug)?

From the other side: is there any kind of filtering I can do based on DID or Calling number and so on, so I can control better the output of the debug command instead of having all what I need?

As I understand that debug isdn q931 will involve all traffic coming to the E1s (to any E1), correct? If I need to debug only traffic coming to the first E1, how it will be?

Thanks in advance for your kindly help.

Regards

Bilal

Correct Answer
Aaron Harrison Wed, 03/31/2010 - 07:10

Hi

You may be able to filter it as in this doc:

http://docwiki.cisco.com/wiki/Cisco_IOS_Voice_Troubleshooting_and_Monito...

Typically if you connect over telnet/ssh using putty, issue 'no logging console' to reduce CPU and log to a text file in Putty you'll be OK unless you know from experience that this is a particularly busy router (as in lots of start/end calls or other mid call signaling being generated rather than just high channel usage).

Regards

Aaron

bilalghayad Thu, 04/01/2010 - 05:56

Big thanks for your kindly help and replying.

As I am worry about the processor utlization because there is a big traffic, just if u can advise me for the following:

What is the difference between the logging and the debugging? (in other words, when to use logging and when to use debug commands)?

How to view the debug results that have been placed in the text file?

If I used term mon, then debug will be displayed on the screen instead of the text file?

Your kindly help is high appreciated.

Regards

Bilal

Aaron Harrison Thu, 04/01/2010 - 06:29

Hi

Debugging = turning on specific diagnostic processes that output information in accordance with the logging settings.

Logging = output of information to a location - either screen, console, syslog server etc. Different locations have different impact on CPU; for example, busy debugs output to console cause a bigger CPU load than to terminal lines (telnet) or syslog.

Term Mon = a command to turn on debug output to the current telnet session

So - as I suggested earlier, I would:

Conf t

No logging console

End

Term mon

Debug isdn q931

The text file I referred to is configured from within Putty or whatever client you use. Term mon outputs the debug info to the telnet or SSH session you are in, and the telnet/SSH client then logs this to text. You then read it from the telnet client initially, and if it scrolls too quickly you take a look at the text log via notepad or whatever you like.

Regards

Aaron

Actions

This Discussion