[cisco-voip] Assistance with call routing question...

Tim Reimers treimers at ashevillenc.gov
Wed Apr 11 18:44:57 EDT 2012


Thanks Peter! 
 
Saved in my cisco-voip-notes folder.... 
 
I realised the forward digits probably wasn't necessary, but was including it to ensure it worked and the 72 didn't get sent out.
 
I'll finish my testing of the PRI, but probably then will play with this some more.
So far, no echo.
 
Don't know if I mentioned it, but my original reason for asking this was to test echo on a new PRI before rolling it out to a callcenter.
We have outboard echo cancellers on our other PRIs, but I know the router can do echo cancelling on it's own, so I was 
attempting to figure out whether or not we really had needed them. They pre-date my involvement with this system by several years.
 
So far (knock on wood, cross fingers) I don't seem to hear echo, and I'm hoping to roll onwards in a few days here, after doing a bunch more test calls.
 
Thanks, Tim

________________________________

From: Peter Slow [mailto:peter.slow at gmail.com]
Sent: Wed 4/11/2012 4:54 PM
To: Tim Reimers; cisco voip; Nick Matthews
Subject: Re: [cisco-voip] Assistance with call routing question...


haha, yes i did but im glad you sent me this one, so i can show you the right-er way to do this. I'm including the list again cause there's some really good info here and i want people to see it. hope you don't mind =) This was written in a not-for-public-consumption-tone of voice but i think the list can handle it. things said here are my $2 ;) anyway...

you made it more complicated than necessary, and i dislike the "forward digits" command because it effects the new number at an awkward point in processing and my experiences have been that it messes up your ability to (easily) use translation profiles (which are much more flexible IMHO) (please weigh in on that nick, interested in your opinion!)  ...because the number is not what you were expecting it to be when you wrote the rule. ...personal preference. I DO usually find that people who use that command are using it unnecessarily. back to what I was saying abou this being too complicated:

my dial-peer 57 will do the SAME thing as your two dial peers, transparently from your user's perspective. while I usually consider it poor form to use the "T" for things other than dial-peers for long distance, here im just trying to make a point. that first point is that your additionof the forward digits command is doign nothign in this case. 


 

dial-peer voice 72099 pots

destination-pattern 72......... 

port 0/1/0:23

forward-digits 7

...Is going to behave exactly the same as



dial-peer voice 72099 pots

destination-pattern 72......... 

port 0/1/0:23


...furthermore, the second dial-peer, lacking a $ at the end of the string, will still match an 11 digit number should it not match any other dial peers. if i _wanted_ that to happen, i'd simply say



dial-peer voice 72099 pots

destination-pattern 72T 

port 0/1/0:23


This works and you wont get inter-digit because CUCM sends the number enbloc. ...now people know that this dial peer is matching anything that starts with a 72, and since the 72 is matched explicitly, it gets stripped (in the absence of the no digit-strip command.) and this dp behaves just like your other two (below) would. 

Original:


 

dial-peer voice 72099 pots

description TestPRI-LD

destination-pattern 72...........

progress_ind setup enable 3

progress_ind alert enable 8

fax rate disable

port 0/1/0:23

forward-digits 11



dial-peer voice 729999999 pots

description TestPRI

destination-pattern 72........

progress_ind setup enable 3

progress_ind alert enable 8

fax rate disable

port 0/1/0:23

forward-digits 7

 

dial-peer voice 72099 pots

description TestPRI-LD

destination-pattern 72...........

progress_ind setup enable 3

progress_ind alert enable 8

fax rate disable

port 0/1/0:23

forward-digits 11



....Hope that's helpful,
   -Peter Slow


On Wed, Apr 11, 2012 at 10:31 AM, Tim Reimers <treimers at ashevillenc.gov> wrote:


	 

	(Heh .. just noticed this never went --- I think you probably got my other 'thanks' email first! )

	 

	Hey Peter-

	 

	Getting back to this finally, after the holiday and some fires we had-

	 

	So, if I do a route pattern of 72.XXXXXXX and 72.XXXXXXXXXX in UCM and tell that to use only this GW, then at that point, I'd need to do a dial-peer like this:

	 

	dial-peer voice 729999999 pots

	description TestPRI

	destination-pattern 72........

	progress_ind setup enable 3

	progress_ind alert enable 8

	fax rate disable

	port 0/1/0:23

	forward-digits 7

	 

	dial-peer voice 72099 pots

	description TestPRI-LD

	destination-pattern 72...........

	progress_ind setup enable 3

	progress_ind alert enable 8

	fax rate disable

	port 0/1/0:23

	forward-digits 11

	 

	 

	Does that sound correct?

	 

	That way, if I dial any seven digit number and prefix it with 72 (which I think isn't anything we use internally)

	the UCM would send to that GW router, and then the router would select only that port based on matching that specific dialpeer??

	 

	Anything I'm not thinking of??

	 

	thanks, Tim

	 

	 

	 

	From: Peter Slow [mailto:peter.slow at gmail.com] 
	Sent: Wednesday, April 04, 2012 4:38 PM
	To: Tim Reimers
	Cc: cisco-voip at puck.nether.net
	Subject: Re: [cisco-voip] Assistance with call routing question...

	 

	an h323 GW is all one entitiy from CUCMs perspective. If everything is in a single gateway, you'd have to use CUCM to prefic particular digits that the GW could then use to send to a particular interface.



	How many PRIs are on this gateway, or are the other PRIs on _different_ gateways?
	
	sounds like you're about to want to prefix somethign on the front of the called number, based on the callING number, which this document will show you how to do with translation profiles, directly in IOS:

	


	Mapping Outbound Calls to Unique FXS/FXO Ports on Analog Gateways


	http://www.cisco.com/en/US/tech/tk652/tk90/technologies_configuration_example09186a00801bc341.shtml
	
	
	-Peter Slow
	
	
	

	On Wed, Apr 4, 2012 at 3:23 PM, Tim Reimers <treimers at ashevillenc.gov> wrote:

	hi all-

	 

	I should be able to do this myself, but I am experiencing a BSOB (Blue screen of Brain) on this simple one-

	 

	I have a new PRI I want to test for echo and other issues-

	For inbound calling, I already have a DID configured on the PRI and built on a couple of phones-

	 

	I've set up a couple of route patterns for specific numbers, and those calls do go out this PRI

	 

	 

	For outbound calling, I'd like to simply set up a couple of phones in such a way that the only outside gateway they have access to is this PRI.

	 

	The gateway router is running this PRI in H.323 mode-  

	 

	I think I need to configure a new CSS in such a way that the only PSTN access for it would go through this one PRI?

	but I'm stuck on that - 

	 

	For just one number, I can make the system use that PRI by doing this- 

	 

	dial-peer voice <myhomephone> pots

	description Local call test on new PRI

	destination-pattern 9<myhomephone>

	progress_ind setup enable 3

	progress_ind alert enable 8

	fax rate disable

	port 0/1/0:23

	forward-digits 7

	 

	If I expand that dial-peer out to wildcards, it's going to affect everyone on the voice network, not just my test phones...

	 

	But I'm not certain how to set things up so that -all- calls to and from a couple of test phones will always use that one H.323 PRI.

	 

	There's another PRI on that same gateway that's in production, so I can't just switch the config on the entire gateway at large-

	 

	When I try building a route list, all I can do is select that router and "all ports" - unlike MGCP, I don't have  the granular selection of just ports belonging to one Serial interface...

	 

	Clues, anyone? 

	
	_______________________________________________
	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/20120411/701e2515/attachment.html>


More information about the cisco-voip mailing list