Event reporting (was audio call Thursday: Minutes)

Rex Coldren coldrenr at agcs.com
Mon Apr 12 11:22:45 EDT 1999 

I think this is a winner.

Flemming Andreasen wrote:

> Sounds good to me assuming the structure is something like
>
>      <terminationID, requestID, event_1, event_2, ..., event_n>
>
> since there is no reason to repeat the terminationID (or requestID for that
> matter) for every event reported in a Notify message.
>
> Basically, you simply want to know
> - which termination generated the event(s), hence the terminationID
> - which request triggered the detection of the event., hence the requestID
> - what the event(s) generated are, hence the eventIDs
>
> Regards
>
>           Flemming
>
> Paul Sijben <sijben at LUCENT.COM> on 04/12/99 05:09:05 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)
>
> What I am going to say may sound like a political compromise but in fact
> isn't.
>
> Having read the disucssion i see a good reason to do both:
>
> 1) eventID+terminationID : it is straightforward and relies on the minimum
> of state to be kept and it allows multiple events to be set in one request.
> 2) requestID: it may help you in timing sensitive cases (although I am not
> completely convinced yet).
>
> Yet, is there any problem in allowing both in a notify message. The
> overhead would only be a few bytes in transport and the keeping of the
> requestID in the MGW as long as the MGC is interested in an event. I have
> seen no rule against having the best of both worlds. :-)
>
> Paul
>
> Flemming Andreasen wrote:
> >
> > Well, such is the nature of glare - glare resolution is a different story
> > and the MGC may implement whatever policy it wants. However, if it cannot
> > determine the order of events, it becomes rather hard for it to achieve
> any
> > kind of policy besides randomness. Having the ability to determine order
> > would seem a solid design principle to me.
> >
> > Going back to lockstep again, it should be noted that without the
> > RequestId, you will *always* have to issue a new request in response to
> it,
> > since you don't know whether the Notify was generated before or after
> some
> > request had been received - that's hardly a good solution since you are
> now
> > forced to send more messages than needed and if signals are not
> idempotent,
> > you may in fact not achieve what you desired.
> >
> > I still say there are lots of good reasons for a RequestID - is anybody
> > opposed to including this ?
> >
> > Regards
> >
> >           Flemming
> >
> > Brian Rosen <brosen at eng.fore.com> on 04/09/99 01:32:52 PM
> >
> > To:   "'Flemming Andreasen'" <fandreas at telcordia.com>
> > cc:   Mailing list for parties associated with ITU-T Study Group 16
> >       <ITU-SG16 at mailbag.cps.intel.com> (bcc: Flemming Andreasen/Bellcore)
> > Subject:  RE: Event reporting (was audio call Thursday: Minutes)
> >
> > Suppose the flash hook came .5 ms after the call waiting
> > happened.  Clearly the intention is to initiate a new call,
> > but your email suggests it should connect to the waiting caller.
> >
> > It seems to me that whichever action the MGC takes on the
> > event it can do the same thing with or without the RequestID.
> > This is true because all the events we are discussing have
> > long response times relative to MG/MGC communication.
> > With timestamps (also a suggestion), it could do something
> > approximating the right thing all the time with or without
> > RequestIDs.
> >
> > Please note, I liked RequestIDs when they were suggested.
> > I still like them, but I can't currently seem to defend them
> > very well.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Flemming Andreasen [mailto:fandreas at telcordia.com]
> > > Sent: Friday, April 09, 1999 12:58 PM
> > > To: Mailing list for parties associated with ITU-T Study Group 16
> > > Cc: Flemming Andreasen; brosen at eng.fore.com
> > > Subject: Re: Event reporting (was audio call Thursday: Minutes)
> > >
> > >
> > >
> > >
> > > Consider the following example:
> > >
> > > 1. Party A is currently involved in a call with Party B. The
> > > active request
> > > for A is RA-1
> > > 2. Another call now arrives to A, who happens to subscribe to
> > > call-waiting
> > > as well as three-way calling.
> > > 3a. The MGC decides that since A subscribes to call-waiting,
> > > A should hear
> > > call-waiting tones so the MGC sends a new request RA-2 to A
> > > 3b. At the same time, party A could have decided to put B on
> > > hold and place
> > > another call. Party A would then generate a flash-hook which
> > > results in a
> > > Notify (N-x) message being sent to the MGC.
> > >
> > > Now, if RA-2 arrived at A prior to A generating the flash-hook, the
> > > call-waiting tone would have been played prior to the
> > > flash-hook, and the
> > > correct glare resolution would probably be for the incoming call to be
> > > connected.
> > >
> > > On the other hand, if RA-2 arrived at A after A generated the
> > > flash-hook,
> > > we should probably consider A to attempt to initiate a new
> > > call, and the
> > > correct glare resolution would probably be for the incoming
> > > call to get
> > > called-party-busy treatment, and for A to continue with the
> > > call attempt.
> > > (In this case, the call-waiting tone would actually be played
> > > after the
> > > flash-hook, so you may even have a need to specify that "the following
> > > request is only to be applied if there is currently no outstanding
> > > Notify"). Also note, that if the RA-2 message had been lost,
> > > there would no
> > > longer be a need for retransmitting it.
> > >
> > > The only way you can determine the order of events is by including the
> > > request id (I would not favor a transaction-id based
> > > approach), and I do
> > > believe that order matters in some cases, so you might as
> > > well include a
> > > solution, especially when it's this simple. We can probably
> > > come up with
> > > more examples if needed.
> > >
> > >
> > > Regards
> > >
> > >           Flemming
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Brian Rosen <brosen at ENG.FORE.COM> on 04/09/99 11:48:08 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)
> > >
> > >
> > >
> > >
> > > You might be right, but I am confused.
> > >
> > > The simple case of lockstep works.  The EventDescriptor is
> > > set up with the event, it happens, you get notified, and you
> > > send a modify to rearm it.  If the event happens again before
> > > the rearm, you ignore it.  If it happens after, you get
> > > another Notify.
> > >
> > > The only way I see a problem is when you have time order
> > > of a Modify; you have a lockstep event "armed", you send down
> > > a Modify with a new EventDescriptor, and the event either
> > > happens before or after the Modify command is executed.
> > > Perhaps you think it's important to know if the event
> > > happened before or after the Modify, but I can't come up with
> > > a scenario where it matters.  If it does, then I agree, you
> > > need a tag that is unique to the setting of the
> > > EventDescriptor.
> > >
> > > I do note that you could (theoretically) report the
> > > transactionID of the command that set the event.  That would
> > > make you sent TerminationID, Event Name and TransactionID on
> > > the Notify.  It would solve the problem.  It might be better
> > > to use RequestID rather than that.
> > >
> > > Brian
> > >
> > > > -----Original Message-----
> > > > From: Flemming Andreasen [mailto:fandreas at telcordia.com]
> > > > Sent: Friday, April 09, 1999 10:13 AM
> > > > To: Mailing list for parties associated with ITU-T Study Group 16
> > > > Cc: brosen at eng.fore.com; Flemming Andreasen
> > > > Subject: Re: Event reporting (was audio call Thursday: Minutes)
> > > >
> > > >
> > > >
> > > >
> > > > 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.
> > > > > --------------------------------------------------
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> > >
>
> --
> Paul Sijben              Telno:+ 31 35 687 4774 Fax:+31 35 687 5954
> Lucent Technologies      Home telno: +31 33 4557522
> Forward Looking Work     e-mail: sijben at lucent.com
> Huizen, The Netherlands  internal http://hzsgp68.nl.lucent.com/
-------------- 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/19990412/6e84ccf1/attachment-0006.vcf>

More information about the sg16-avd mailing list