Event reporting (was audio call Thursday: Minutes)

Flemming Andreasen fandreas at TELCORDIA.COM
Fri Apr 9 12:58:03 EDT 1999

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

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.



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

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.


> -----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.
> > --------------------------------------------------
> >

More information about the sg16-avd mailing list