08-18-2010 06:37 AM - edited 03-16-2019 12:19 AM
Can anyone, in a simple way detail the steps involved in
1) an outgoing call
2) an inccoming call
on a h323 gateway with a call manager setup
e.g.
first of all, looks to translation pattern
picks something in there
then from here, goes to translation rules
from translation rules, goes to dial peers
dial peers then connects the call
Im just looking for ther order of stuff as it happens, hope people know what I mean
08-18-2010 07:03 AM
The order is very logical and easy to figure out.
voice-port translation, if any.
incoming DP matching
incoming DP translation profile
outgoing DP matching
outgoing DP translation profile
08-18-2010 07:06 AM
thanks for reply
so where does trunk groups, translation profiles and e1 controllers come in to play
so are these 2 for inbound calls only :
incoming DP matching
incoming DP translation profile
and these 2 for outbound calls only :
outgoing DP matching
outgoing DP translation profile
08-18-2010 07:11 AM
Trunk group translations happens in flow sequence with voice port but for consistency, either use one or the other and not rely on processing order.
There is no translations for controllers.
Incoming and outgoing DP matching happens for every and any call no matter the flow. Review:
http://www.cisco.com/en/US/tech/tk652/tk90/technologies_tech_note09186a008010fed1.shtml
Please remember to rate useful posts clicking on the stars below.
08-18-2010 08:02 AM
A trunk group is essentially a virtual object that allows you to group several physical ports together for reference by your dial-peer(s). That way you can "point" an outbound dial-peer to your analog trunk group rather than having to create several duplicate dial-peers, each with the same destination pattern but with different preferences and different analog ports.
From what I remember though a gateway isn't "smart" enough to tell when an analog port within a trunk group is down so it may send a call to a down analog port and think it completed successfully while it never got anywhere. For that reason I usually use the preference method I briefly stated above.
Controllers contain Layer 1/2 configuration for a port and don't do any digit manipulation, but voice-ports can. Performing digit manipulation on voice-ports can get complicated so stick to the dial-peer translation method that Paolo outlined.
08-18-2010 09:07 AM
Thanks for reply Philip
I suppose im just just trying to viualize in my head the process of events
So we have :
Trunk Groups
Translation Profiles
Translation Rules
Dial Peers
Serial Interface where E1 is configured
Im just trying to viualize what exactaly happens and when to a call and in what order
e.g.
call comes in
looks at trunk group
trunk group refers to translation profile
translation profile refers to translation rules etc. etc.
I still have not got this right in my head
08-18-2010 10:23 AM
Read my post above as it is explained there.
Please remember to rate useful posts clicking on the stars below.
08-18-2010 10:57 AM
From what I remember though a gateway isn't "smart" enough to tell when an analog port within a trunk group is down so it may send a call to a down analog port and think it completed successfully while it never got anywhere. For that reason I usually use the preference method I briefly stated above.
Actually they are smart enough indeed, as there are specific tecniques to address this problem.
Also note that each member in trunk-group can have an individual preference, and various hunt schemes are available.
Another very useful property of trunk groups is that multiple can be references as targer in pots DP, each one with a separate preference again.
08-18-2010 11:02 AM
Hmm... I wonder why I had it in my head not to use analog trunk groups for FXO ports then? I know I've used them for FXS ports (RF integrations) before but never on outbound POTS dial-peers... Was there a code fix for this issue so my information is just outdated?
08-18-2010 11:10 AM
The most basic approach is to use round-robin hunt scheme in TG, so the dead port does not impact more than 1/N of call attempts and a the same time client is alerted about the unrgency of the problem. Consider that a fully transpare re-hunting scheme may hide the problem for a long time,
Then there are the certain settings with voice class cause codes to rehunt on a dead port.
In short, trunk groups are always advisable.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: