MTD-107

Nicolas Tran Nicolas.Tran at ALCATEL.FR
Thu Jan 6 10:18:20 EST 2000


Robustness people,

This is something that's been being discussed on the IMTC's implementors
reflector (no doubt most of you follow that anyway).  I'd suggest that it ought
to be within your terms of reference!  I attach the earlier mail to which I'm
referring.

Raghu, Amit et al,

History regularly comes to bite us here, and I probably didn't help by not
explaining the starting points to my thinking!
So here we are:

1. Your reference to 7.2.2 of whichever standard it is.  I agree absolutely.
Where possible.  However...
If an endpoint fails to find a gatekeeper during gatekeeper discovery, it is
permitted to assume that there is no gatekeeper around, and that it may
therefore make calls without using a gatekeeper.  It might be considered
"polite", however, for an endpoint carrying on this way to periodically check
up to see if there ARE any gatekeepers around.  At least one well known H.323
stack acts in this way if asked to handle RAS for its application.  The
question is, what should it do if it should find a gatekeeper at this later
stage?

2. The obvious thing to do here is to drop any calls immediately, and remake
them when we've registered with a gatekeeper, if and only if registration is
successful.  However it is surely desirable for the user to know nothing of
what's going on (if possible - ie ONLY if registration is successful).  Delays
of a few seconds mid-call, and ringing phones spoil the user's experience.  So
either there should be some attempt to carry the call on uninterrupted or the
call should just be dropped.

3. With all the moves in the ITU towards robustness, I really think it's up to
that group to specify what heppens here.  However, given that their terms of
reference certainly DO include keeping the call up somehow or other in the
event of gatekeeper failure (which, depending on what they specify, may result
in a period in which the endpoint is in a call but not registered) calls
continue uniterrupted, I'd suggest that this should be the aim here.

4. However a gatekeeper has the right to know about any calls its endpoints are
participating in.  The only way I could see to achieve this is via ARQ for an
existing call, although again the robustness group may have some ideas!

Regards,
Chris

Amit sahai wrote:
>
> Hi Raghu,
>                 I was also thinking that this is the only viable solution . Ep
> should close all
> calls and start again .
> What do you think Chris ?
>
> regards
> Amit Sahai
> Convergence Technology Group,
> Silicon  Automation Systems.
>
> raghu.nambiath at wipro.com wrote:
>
> > Hi Amit,
> >
> > I think there are other issues involved if ARQ needs to be sent for an
> > ongoing call by the endpoint after registering with the Gatekeeper. This is
> > the case if the Gatekeeper had decide to route the call. In this case what
> > will happen to the current call status. Only way will be the endpoint close
> > the existing call and restart the same..
> >
> > Raghu
> >
> > > -----Original Message-----
> > > From: owner-h323implementors at imtc.org
> > > [mailto:owner-h323implementors at imtc.org]On Behalf Of Amit sahai
> > > Sent: Thursday, January 06, 2000 1:12 PM
> > > To: cwp at isdn-comms.co.uk; raghun at wipinfo.soft.net;
> > > h323implementors at imtc.org
> > > Subject: Re:Unregistered Calls
> > >
> > >
> > > Hi Raghu,
> > >                  I think the standard has apparently laid outlines for
> > > such a
> > > scenario.
> > > I think it  assumes that when endpoint is registered with a GK  , for
> > > all calls it
> > > will
> > > take permission from the GK . The underlying assumption is that no calls
> > > were going
> > > on
> > > beforehand .
> > > Ref. 7.2.2 Endpoint Registration
> > >   " Registration shall ocuur before any calls are attempted ......"
> > > What do you think about this line ?
> > > So this clearly is a scenario , not covered by the standard.
> > > The solution which Chris has offered seems to be a logical thing. But
> > > yet it is an
> > > improvisation. I found no mention of such a case in the standards.
> > > What I find strange is that ep is asking for ARQ for a call which is
> > > already going
> > > on !
> > > Consider this scenario:
> > > Assume  a case  where a call was going on before registering with the
> > > GK.
> > >
> > > As soon the endpoint registers with the GK ,  the ep asks GK for
> > > Admission  for
> > > this  calland GK grants it telling to route the Call Signalling through
> > > GK ( The GK
> > > has no knowledge of the call going on !)
> > > Now ep is already engaged in a call and assumes permission has been
> > > granted .
> > > It does not  follow Call Signalling procedures , since it does not need
> > > to .
> > > The GK does not know the call is going on while the endpoint thinks GK
> > > has granted
> > > permission  .
> > >
> > > Don't we  foresee problems with this situation ? Any comments ....
> > >
> > >
> > > regards
> > > Amit Sahai
> > > Convergence Technology Group,
> > > Silicon Automation Systems ,
> > > Bangalore.
> > >
> > > ------------------------------------------------------------------
> > > ---------
> > > ------------------------------
> > > Please send E-mail to contact at imtc.org <mailto:contact at imtc.org>  to
> > > subscribe or unsubscribe from this list
> > > ------------------------------
> > > ------------------------------------------------------------------
> > > ---------
> > >

--
Dr Chris Purvis -- Development Manager
ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road
Winkfield Row, Berkshire.  RG42 6LY  ENGLAND
Phone: +44 1344 899 007
Fax:   +44 1344 899 001
-------------- next part --------------
An embedded message was scrubbed...
From: raghu.nambiath at wipro.com
Subject: RE: URJ from a terminal to a GK.
Date: Thu, 6 Jan 2000 10:09:03 +0530
Size: 12681
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/20000106/1a48b2a4/attachment-0001.eml>


More information about the sg16-avd mailing list