H.226 Usage

[Chip Sharp]

Flemming is right.  Even if we assumed reliable transport or had a sequence
numbering scheme built into the protocol's lower layer we would have this
problem.  It's a race condition and we have to deal with it.  On the surface
I can't think of a better way of doing it than the RequestID for events.

Rex

Flemming Andreasen wrote:

> There is actually a good reason for the RequestID. It basically enables you
> to determine whether a notification was issued before or after the
> reception of a given request for the notification. As an example where this
> is important, consider what we refer to as "lockstep mode". It essentially
> states that a given request can at most generate one Notify, which implies
> that after receiving a Notify you must send down a new request. Without a
> RequestID you cannot determine whether that request has already been
> received or not. This is not only protocol-wise important but semantically
> as well, as your new request may contain instructions to look for a new set
> of events that all of a sudden either became important to know about, or
> you no longer want to hear about. Thus we should keep the RequestID.
>
> Regards
>
>           Flemming Andreasen
>
> Brian Rosen <brosen at ENG.FORE.COM> on 04/09/99 08:18:46 AM
>
> Please respond to Mailing list for parties associated with ITU-T Study
>       Group 16 <ITU-SG16 at mailbag.cps.intel.com>
>
> To:   ITU-SG16 at mailbag.cps.intel.com
> cc:    (bcc: Flemming Andreasen/Bellcore)
> Subject:  Re: Event reporting (was audio call Thursday: Minutes)
>
> As the protocol is currently defined, there is
> thus thing we called a RequestID.  You supply
> a RequestID with the EventDescriptor, and it is
> returned by the Notify.  A RequestID is a 32 bit
> integer.  The syntax defines the requestID, and
> uses it in the Notify, but does not show it in
> the EventDescriptor.  That should be fixed, but...
>
> As I noted, TerminationID + EventName is logically
> equivalent to an MGC assigned RequestID if you
> can only have one instance of an event on a
> termination.  Implementation seems to be simple
> in either case at both ends.  At the MG, storing
> the requestID is easy, but not storing is easier.
> At the MGC, the RequestID would be a separate table,
> but it would have to have TerminationID and
> EventName at least implicitly, and probably
> explicitly in it.  Searching a structure by
> TerminationID and then EventName (or the other way
> around) is also easy.Thinking about it overnight, if it
> really is the same, then it would be best to
> eliminate the RequestID artifice and use Termination
> ID + EventName.
>
> At the time, I believed we thought that there were
> circumstances where there was not uniqueness.  Right
> now, I can't see how that can occur.
>
> Brian
>
> > -----Original Message-----
> > From: Chip Sharp [mailto:chsharp at cisco.com]
> > Sent: Thursday, April 08, 1999 5:46 PM
> > To: ITU-SG16 at mailbag.cps.intel.com
> > Subject: Re: Event reporting (was audio call Thursday: Minutes)
> >
> >
> > Yes that was my understanding as well.  The TerminationID
> > would be used to
> > associate the event to the termination.  Thus the event report would
> > contain the Termination ID and the event ID.
> >
> > Chip
> >
> > At 02:21 PM 4/8/99 -0700, Rex Coldren wrote:
> > >Actually I believe this item was not correctly written.  I
> > believe the
> > >discussion was about how you associate a reported event to a given
> > >Termination.  There was talk that notifications come back with a
> > >RequestID, which must be somehow associated to a Termination.
> > >Paul suggested using TerminationID directly.
> > >
> > >Christian Huitema wrote:
> > >
> > >> > 5) event handling
> > >> > - currently an event is identified to the MGC with an
> > eventId - Paul
> > >> > Sijben suggested that it would be better to use a terminationId
> > >>
> > >> Sorry for missing the call, but let's comment on that
> > specific point.  We
> > >> discussed the event reporting model at length during the
> > IETF meetings and
> > >> in the following week, and I don't beleive that there is
> > any advantage in
> > >> opening the debate again.
> > >>
> > >> Termination Id and event names just do not belong to the
> > same space.
> > >>  Terminations are defined on a per MG basis; events are defined
> > >> independently of the MG, and in many cases independently of the
> > >> termination class.
> > >>
> > >> The current notifications identify both the termination on
> > which the event
> > >> was observed and the name of the event.  There is a lot of
> > experience to
> > >> show that this is a very efficient decomposition, and I
> > don't see any
> > >> reason whatsoever for ditching the experience in favor of
> > an unproven
> > >> theoretical design.
> > >>
> > >> --
> > >> Christian Huitema
> > >> ------------------------------
> > >> Please note my new address: huitema at research.telcordia.com
> > >> http://www.telcordia.com/
> > >
> > >
> > --------------------------------------------------
> > Chip Sharp                 voice: +1 (919) 851-2085
> > Cisco Systems              Consulting Eng. - Telco
> > Reality - Love it or Leave it.
> > --------------------------------------------------
> >
-------------- next part --------------
A non-text attachment was scrubbed...
Name: coldrenr.vcf
Type: text/x-vcard
Size: 199 bytes
Desc: Card for Rex Coldren
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/19990409/384fbbde/attachment-0006.vcf>