[cisco-voip] help with debuging calls during SRST

Fri Oct 29 13:50:01 EDT 2010

Cool, thanks. 

--- 
Lelio Fulgenzi, B.A. 
Senior Analyst (CCS) * University of Guelph * Guelph, Ontario N1G 2W1 
(519) 824-4120 x56354 (519) 767-1060 FAX (JNHN) 
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
Cooking with unix is easy. You just sed it and forget it. 
- LFJ (with apologies to Mr. Popeil) 

From: "VoIP Guy" <ciscovoiper1 at gmail.com> 
To: "Lelio Fulgenzi" <lelio at uoguelph.ca> 
Cc: "Mathew Miller" <miller.mathew at gmail.com>, "voyp list" <cisco-voip at puck.nether.net> 
Sent: Friday, October 29, 2010 1:34:36 PM 
Subject: Re: [cisco-voip] help with debuging calls during SRST 

It's always the small things that throw us... :) 

If you ever want to revisit the null route setup, adjust your H.323 or SIP if you are that way inclined and set small establish/INVITE timers to minimise the time taken for a re-order tone to occur. 

Just another angle to look at if you ever want to test it again. 

On Fri, Oct 29, 2010 at 5:18 PM, Lelio Fulgenzi < lelio at uoguelph.ca > wrote: 

It turns out that I forgot to trigger SRST on the router itself so the gateways would register as H323. Once I did that, I get the output that I was used to seeing. 

The TAC had a laugh as I fixed the problem myself while they were on the line. Well, that's they're "easy button" for the day. 

I had thought about using a null route, but for some reason I couldn't get it working right. I had to deploy quickly the last time, and I'd like to keep the same format this time around. Something to think about in the future. I think the problem I had was that because it was not routeable, it didn't come back quickly with a call not progress signal, or something like that. 

*shrug* 

--- 
Lelio Fulgenzi, B.A. 
Senior Analyst (CCS) * University of Guelph * Guelph, Ontario N1G 2W1 
(519) 824-4120 x56354 (519) 767-1060 FAX (JNHN) 
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
Cooking with unix is easy. You just sed it and forget it. 
- LFJ (with apologies to Mr. Popeil) 

From: "VoIP Guy" < ciscovoiper1 at gmail.com > 

To: "Lelio Fulgenzi" < lelio at uoguelph.ca > 
Cc: "Mathew Miller" < miller.mathew at gmail.com >, "voyp list" < cisco-voip at puck.nether.net > 
Sent: Thursday, October 28, 2010 11:31:30 PM 

Subject: Re: [cisco-voip] help with debuging calls during SRST 

I may be off base as some of the debug output is internal coding calls which I am not privy to but looking at it... it looks like it tries to match the dial-peer, it has an issue, and then tries again to match an incoming dial-peer... possibly because of the cor-list... 

It would be helpful if you posted the cor list configuration, the relevant srst/cme config so we can determine how the lock & key method is setup in theory. 

If all you want to do is to blackhole a call... just create a voip dial-peer, then get a subnet segment which is not routable on your network, like 192.168.x.x/172.16.x.x/10.x.x.x... 

...create a route to null 0 for this specific route such as ip route 192.168.255.254 255.255.255.255 null0 description blackhole-voip 

... then create a voip dial-peer as the above but without the cor-list and with the destination being ipv4:192.168.255.254, then add the command hunt stop and you should see the call get blackholed. 

That is a very quick and dirty way of doing it... if you are after alternative suggestions, then I would suggest posting the requested info so we can take more of a look at it. 

Also, it would be good for you to get a "baseline" state and hence remove the cor lists and see what the behaviour is without them. 

Cheers, 

C 

Ps. Forgot to cc group so apologies Lelio for the duplicate email. 

On Thu, Oct 28, 2010 at 8:25 PM, Lelio Fulgenzi < lelio at uoguelph.ca > wrote: 

I need to block for specific users using COR lists. I don't think you can do that with after-hours. 

I'd also like to stick with dial-peers for a few other reasons. 

--- 
Lelio Fulgenzi, B.A. 
Senior Analyst (CCS) * University of Guelph * Guelph, Ontario N1G 2W1 
(519) 824-4120 x56354 (519) 767-1060 FAX (JNHN) 
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
Cooking with unix is easy. You just sed it and forget it. 
- LFJ (with apologies to Mr. Popeil) 

From: "Mathew Miller" < miller.mathew at gmail.com > 

To: "Lelio Fulgenzi" < lelio at uoguelph.ca > 
Cc: "Leslie Meade" < lmeade at signal.ca >, "voyp list" < cisco-voip at puck.nether.net > 
Sent: Thursday, October 28, 2010 1:54:37 PM 
Subject: Re: [cisco-voip] help with debuging calls during SRST 

Why not use afterhours block pattern. 

call-manager-fallback 
after-hours block pattern 1 91900 7-24 
after-hours day Sun 00:00 23:59 

On Oct 28, 2010, at 12:10 PM, Lelio Fulgenzi wrote: 

actually, i don't want it to work, that's why i'm sending the BAD# prefix and no digits. 

not the best way to prevent calls from going through, but the only one i know of right now. 

i just need to figure out which debugs to turn on to see what i'm sending. :( 

--- 
Lelio Fulgenzi, B.A. 
Senior Analyst (CCS) * University of Guelph * Guelph, Ontario N1G 2W1 
(519) 824-4120 x56354 (519) 767-1060 FAX (JNHN) 
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
Cooking with unix is easy. You just sed it and forget it. 
- LFJ (with apologies to Mr. Popeil) 

From: "Leslie Meade" < lmeade at signal.ca > 
To: "Lelio Fulgenzi" < lelio at uoguelph.ca >, "voyp list" < cisco-voip at puck.nether.net > 
Sent: Thursday, October 28, 2010 12:47:12 PM 
Subject: RE: [cisco-voip] help with debuging calls during SRST 

Add this line 

Forward-digits 3 

It will drop the 9 and send the rest.. 

From: cisco-voip-bounces at puck.nether.net [mailto: cisco-voip-bounces at puck.nether.net ] On Behalf Of Lelio Fulgenzi 
Sent: Thursday, October 28, 2010 8:14 AM 
To: voyp list 
Subject: [cisco-voip] help with debuging calls during SRST 

I'm not having any luck debugging calls during SRST mode. What I'm looking to find out is: 

    • which dial-peer is being hit 
    • all the digits that are being sent out to the PRI (including translations and prefixes) 
    • which PRI is being used 

I'm able to get which dial-peer is being hit and the translations, but I can't see the digits being sent to the PRI and which PRI is being used. I've got a crossover connected so both ports are up, but I don't think it's that, I think I'm just not using the right debug statements. 

For example, when I hit the dial-peer below. I'd like to see the "BAD#" digits being sent to pri 0/0/0. 

dial-peer voice 91811901 pots 
corlist outgoing uogdev-block-services-css 
huntstop 
preference 2 
destination-pattern 9[1-8]11 
clid network-number 5196741500 
port 0/0/0:23 
forward-digits 0 
prefix BAD# 

--- 
Lelio Fulgenzi, B.A. 
Senior Analyst (CCS) * University of Guelph * Guelph, Ontario N1G 2W1 
(519) 824-4120 x56354 (519) 767-1060 FAX (JNHN) 
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
Cooking with unix is easy. You just sed it and forget it. 
- LFJ (with apologies to Mr. Popeil) 

_______________________________________________ 
cisco-voip mailing list 
cisco-voip at puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-voip 

_______________________________________________ 
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/20101029/a2910edf/attachment.html>