cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1696
Views
0
Helpful
9
Replies

How calls work on a h323 Gateway

from_atozinc
Level 1
Level 1

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

9 Replies 9

paolo bevilacqua
Hall of Fame
Hall of Fame

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

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

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.

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.

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

Read my post above as it is explained there.

Please remember to rate useful posts clicking on the stars below.

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.

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?

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.

Getting Started

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: