Re: Event reporting (was audio call Thursday: Minutes)
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@eng.fore.com on 04/09/99 01:32:52 PM
To: "'Flemming Andreasen'" fandreas@telcordia.com cc: Mailing list for parties associated with ITU-T Study Group 16 ITU-SG16@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@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@eng.fore.com Subject: Re: Event reporting (was audio call Thursday: Minutes)
Consider the following example:
- 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
FlemmingBrian Rosen brosen@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@mailbag.cps.intel.com
To: ITU-SG16@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@telcordia.com] Sent: Friday, April 09, 1999 10:13 AM To: Mailing list for parties associated with ITU-T Study Group 16 Cc: brosen@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 AndreasenBrian Rosen brosen@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@mailbag.cps.intel.com>To: ITU-SG16@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@cisco.com] Sent: Thursday, April 08, 1999 5:46 PM To: ITU-SG16@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:
- 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@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.
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
FlemmingBrian Rosen brosen@eng.fore.com on 04/09/99 01:32:52 PM
To: "'Flemming Andreasen'" fandreas@telcordia.com cc: Mailing list for parties associated with ITU-T Study Group 16 ITU-SG16@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@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@eng.fore.com Subject: Re: Event reporting (was audio call Thursday: Minutes)
Consider the following example:
- 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
FlemmingBrian Rosen brosen@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@mailbag.cps.intel.com
To: ITU-SG16@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@telcordia.com] Sent: Friday, April 09, 1999 10:13 AM To: Mailing list for parties associated with ITU-T Study Group 16 Cc: brosen@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 AndreasenBrian Rosen brosen@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@mailbag.cps.intel.com>To: ITU-SG16@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@cisco.com] Sent: Thursday, April 08, 1999 5:46 PM To: ITU-SG16@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@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@lucent.com Huizen, The Netherlands internal http://hzsgp68.nl.lucent.com/
participants (2)
-
Flemming Andreasen -
Paul Sijben