RE: [Openh323gk-developer] Per Gateway call limits

[Freddy P. <fp...@nu...>]

Great information from the both of you. This will help alot. Thanks.

Freddy

-----Original Message-----
From: ope...@li...
[mailto:ope...@li...]On Behalf Of
Zygmuntowicz Michal
Sent: Saturday, March 13, 2004 6:59 AM
To: ope...@li...
Subject: Re: [Openh323gk-developer] Per Gateway call limits


In addition, logical channels (their numbers) being opened can be stored
somewhere and closed when rerouting the call. This way (along with =
buffering
TCS and MSD) complete call rerouting can be done, including separate
H.245 tcp channel. Also empty TCS may be used to reset H.245 state when
rerouting, but H.245 negotiations already took place.

This works everything beutiful with gateways that have well designed
H.323 stacks. But in reality you can hit various problems. One that I =
encountered
is that some gateways ignore fastStart, when it is not received in =
CallProceeding.
And  this little "feature" makes all the procedures useless, unless your =
customer
like to not hear RBT. So if CallProceeding is sent without fastStart,
then sending buffered fastStart acceptance in Alerting or Progress =
message
does not take any effect.
Another problem is that many carrier gateways send Alerting message =
(along with Progress IE
#1 or #8) before ReleaseComplete, so when rerouting call buffered =
fastStart is already sent.

Instead, I found that the simplest solutions works sometimes best
and did rerouting simply by call forwarding. It may take a bit longer, =
but the difference
is not so noticeable and you don't have to worry that you missed =
something in the complicated
(an memory hungry - you need to buffer significant additional per call =
info, like fastStart, TCS,...)
rerouting implementation.

But the most important thing I've learnt that is failover (rerouting)  =
is good for dialer type applications.
If you use the failover to select another route, it always delays call =
setup which is noticeable
(and hardly accepted) by people. So it's always better to have good =
routes and use failover
only in rare, extreme cases. Not for events that happen very often, so, =
for example, 50% of your calls are rerouted.

Regards,
Michal

----- Original Message -----=20
From: "Craig Southeren" <cr...@po...>
Sent: Friday, March 12, 2004 10:17 PM


> Having implemented this feature in a previous life, the best way to
> implement call-failover is as follows:
>
> 1) The endpoint sends SETUP to the proxy
>
> 2) The proxy sends back a call proceeding immediately, and extracts =
the
> endpoint's capabilities from the SETUP for later use.
>
> 3) The proxy send a SETUP to the gateway with the correct =
capabilities.
>
> 4) When the gateway receives a PROCEEDING, the fastStart elements (if
> any) are removed and stored, and a PROGRESS or FACILITY message is =
sent
> to the endpoint. The same is done for any PROGRESS or FACILTY messages
> that are received.
>
> 5) If the proxy received a RELEASE COMPLETE from the gateway, it
> selected the next gateway in the LCR list, and goes back to step 3.
>
> 6) If a CONNECT is received, or if the proxy decides the "commit" to a
> particular gateway upon receipt of a specific PROGRESS or FACILITY
> messages, the received fastStart elements are sent to the endpoint in
> the CONNECT, PROGRESS or FACILITY.
>
>    Craig
>
> On Thu, 11 Mar 2004 18:44:47 -0500
> "Freddy Parra" <fp...@nu...> wrote:
>
> > If this is the case, then would you say that in order to implement =
non-offline endpoint retries one would have to remove the
fast start option from the call proceeding message
> > before forwarding the message to the source so that the source does =
not open h245 logical channels to the first route,
therefore, eliminating 'no audio' problem?
> >
> > Or would the second retry route call proceeding message reset the =
h245 logical channels assuming this message carries a fast
start?
> >
> > I asked this cause I am having this exact same problem on a retry =
implementation I am working on for lcr. I am able to do
retries but have one way
> > audio. From destination to source it works, but no audio from source =
to destination. I am assuming that this must be the problem
I am having.
> >
> > Freddy
> >
> > -----Original Message-----
> > From: ope...@li... =
[mailto:ope...@li...]On Behalf Of
Zygmuntowicz Michal
> > Sent: Friday, February 13, 2004 11:06 AM
> > To: ope...@li...
> > Subject: Re: [Openh323gk-developer] Per Gateway call limits
> >
> >
> > The problem with failover is that it is working only for offline
> > endpoints. If your endpoint is using fast start, remote endpoint
> > usually sends CallProceeding with fastStart accept before
> > ReleaseComplete, so connecting to a next endpoint succeeds,
> > but there is no audio then.
> > Do you also reset H.245 state/close logical channels before
> > reconnection?
> >
> > ----- Original Message -----=20
> > From: "BACTEL H323" <nu...@ba...>
> > Sent: Friday, February 13, 2004 12:23 PM
> >
> >
> > > I did a retry in 2.0.4 which is available on our website (posted =
here a while ago). I havent had time to impliment this in
2.0.7
> > as I am wrestling with libriries at the moment...
> > >
> > > The retry will try your gateways in a row, so if call fails on one =
then it try the next (sort of LCR) but not explicit call
> > limitation.
>
>
> =
-----------------------------------------------------------------------
>  Craig Southeren, cr...@po... =
http://www.postincrement.com
>  Post Increment - Software, Consulting and Services
>  Co-founder of the only open source H.323 project
>  Phone: +61 2 43654666   Fax: +61 2 43673140   Mobile: +61 417 231046
>  ICQ: #86852844          MSN: cra...@ho...
>  PGP Key:     http://www.postincrement.com/pgp.txt
>  Blog:        http://www.southeren.com/blog



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli=
ck
_______________________________________________
List: Ope...@li...
Archive: http://sourceforge.net/mailarchive/forum.php?forum_id=3D3079
Homepage: http://www.gnugk.org/