How calls work on a h323 Gateway

Unanswered Question
Aug 18th, 2010
User Badges:

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

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
paolo bevilacqua Wed, 08/18/2010 - 07:03
User Badges:
  • Super Gold, 25000 points or more
  • Hall of Fame,

    Founding Member

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

from_atozinc Wed, 08/18/2010 - 07:06
User Badges:

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

paolo bevilacqua Wed, 08/18/2010 - 07:11
User Badges:
  • Super Gold, 25000 points or more
  • Hall of Fame,

    Founding Member

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.

philip.e.denton Wed, 08/18/2010 - 08:02
User Badges:
  • Silver, 250 points or more

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.

from_atozinc Wed, 08/18/2010 - 09:07
User Badges:

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

paolo bevilacqua Wed, 08/18/2010 - 10:23
User Badges:
  • Super Gold, 25000 points or more
  • Hall of Fame,

    Founding Member

Read my post above as it is explained there.


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

paolo bevilacqua Wed, 08/18/2010 - 10:57
User Badges:
  • Super Gold, 25000 points or more
  • Hall of Fame,

    Founding Member

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.

philip.e.denton Wed, 08/18/2010 - 11:02
User Badges:
  • Silver, 250 points or more

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?

paolo bevilacqua Wed, 08/18/2010 - 11:10
User Badges:
  • Super Gold, 25000 points or more
  • Hall of Fame,

    Founding Member

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.

Actions

This Discussion

Related Content