Event reporting (was audio call Thursday: Minutes)

Paul Sijben sijben at LUCENT.COM
Mon Apr 12 05:09:05 EDT 1999


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/



More information about the sg16-avd mailing list