Subject: Re: [Megaco] conflict between embedded descriptors

From: Christian Groves <[email-masked]>
Date: Thu, 12 Apr 2007 12:05:01 +1000

Hello Raphael,

I've had this in my inbox a little while to think about this and the 
question comes to mind, is this really a simultaneous detection? Also 
exactly what did you have in mind with regards to the embedded 
descriptors in the example?

Is the sequence: the off-hook detected first, then based on the 
detection of the off-hook whatever signal is playing is stopped. As the 
signal is stopped then the q/sc event is detected. There seems to be a 
sequence here (I agree it will only be separated in time by a very short 
period).

Now if we add embedding to the equasion then we have to consider how the 
following will effect the picture:
H.248.1 section 7.1.9 Events Descriptor
... In the case of an embedded Events Descriptor being activated, the MG 
continues event processing
based on the newly activated Events Descriptor.
NOTE 1 − For purposes of EventBuffer handling, activation of an embedded 
Events Descriptor is equivalent
to receipt of a new Events Descriptor.

If the off-hook now has an embedded event descriptor do with consider 
there's three possible interpretations given that you can't have two of 
the same descriptors active at one time:
a) the new embedded event descriptor will take effect, thus the g/sc 
event from the original descriptor will not be triggered, or
b) the original g/sc will be detected, MG processes all the events from 
the original events descriptor (g/sc will be triggered) before replacing 
with the new embedded descriptors from the off-hook event.
c) b) the original g/sc will be detected, MG processes all the events 
from the original events descriptor (g/sc will be triggered) before 
replacing with the new embedded descriptors from the g/sc event.

I'm favouring a) because it seems in the spirit on the 7.1.9 text.

Your thoughts?

Regards, Christian

Stephen Mell (CV/ETL) wrote:
> And to answer your question ... (apologies for not reading to the end) 
>
> I think once the g/sc is matched its embedded descriptor is activated,
> even if the g/sc event is in the ReqEventDescripor as the Original
> Offhook, because control of the event handler may still be with the
> original ReqEvents Descriptor, even though control of the signal handler
> may have moved into an embedded descriptor.
>
> If the Off_hook event did have an embedded events descriptor though (not
> just embedded signals), it's a different. there is a new priming to be
> applied after the Off-hook which will dictate what happens to the g/sc.
>
> Steve.
>
> -----Original Message-----
> From: Raphael Tryster [mailto:[email-masked]] 
> Sent: Wednesday, March 28, 2007 11:43
> To: [email-masked]
> Subject: [Megaco] conflict between embedded descriptors
>
> When an events descriptor requests more than one event containing an
> embedded events or signals descriptor, the first event that occurs will
> cause the replacement of the original events descriptor by the embedded
> descriptor for that event.  This is well defined as long as two events
> cannot occur simultaneously.
>
> Now what happens if the events descriptor contains a signal completion
> event and another event, say off-hook, and both have embedded
> descriptors?  When off-hook occurs, any signal playing will stop and
> trigger the signal completion event.  Whose embedded descriptor is now
> activated, that of the off-hook or that of the signal completion?
>
> Raphael Tryster
>
> _______________________________________________
> Megaco mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/megaco
>
> _______________________________________________
> Megaco mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/megaco
>
>
>
>
>   

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: "Raphael Tryster" <[email-masked]>
Date: Wed, 18 Apr 2007 12:35:08 +0200

Hello Christian, 

I think I also prefer your option a), not because I understand the spirit of 7.1.9 - you and the other authors are better judges of that, but it seems to me that the text allows either interpretation.  The reason I prefer option a) is that it removes the ambiguity regarding which events descriptor is in effect at each instant.  I believe Steven Mell's reply is also consistent with this interpretation.

Is c) b) a typo? 
 
Regards, 
 
Raphael Tryster

-----Original Message-----
From: Christian Groves [mailto:[email-masked]] 
Sent: Thursday, April 12, 2007 4:05 AM
To: Raphael Tryster
Cc: Kevin Boyle; [email-masked]
Subject: Re: [Megaco] conflict between embedded descriptors

Hello Raphael,

I've had this in my inbox a little while to think about this and the question comes to mind, is this really a simultaneous detection? Also exactly what did you have in mind with regards to the embedded descriptors in the example?

Is the sequence: the off-hook detected first, then based on the detection of the off-hook whatever signal is playing is stopped. As the signal is stopped then the q/sc event is detected. There seems to be a sequence here (I agree it will only be separated in time by a very short period).

Now if we add embedding to the equasion then we have to consider how the following will effect the picture:
H.248.1 section 7.1.9 Events Descriptor
... In the case of an embedded Events Descriptor being activated, the MG continues event processing based on the newly activated Events Descriptor.
NOTE 1 − For purposes of EventBuffer handling, activation of an embedded Events Descriptor is equivalent to receipt of a new Events Descriptor.

If the off-hook now has an embedded event descriptor do with consider there's three possible interpretations given that you can't have two of the same descriptors active at one time:
a) the new embedded event descriptor will take effect, thus the g/sc event from the original descriptor will not be triggered, or
b) the original g/sc will be detected, MG processes all the events from the original events descriptor (g/sc will be triggered) before replacing with the new embedded descriptors from the off-hook event.
c) b) the original g/sc will be detected, MG processes all the events from the original events descriptor (g/sc will be triggered) before replacing with the new embedded descriptors from the g/sc event.

Your thoughts?

Regards, Christian

Stephen Mell (CV/ETL) wrote:
> original ReqEvents Descriptor, even though control of the signal 
> handler may have moved into an embedded descriptor.
>
> If the Off_hook event did have an embedded events descriptor though 
> (not just embedded signals), it's a different. there is a new priming 
> to be applied after the Off-hook which will dictate what happens to the g/sc.
>
> Steve.
>
> embedded events or signals descriptor, the first event that occurs 
> will cause the replacement of the original events descriptor by the 
> embedded descriptor for that event.  This is well defined as long as 
> two events cannot occur simultaneously.
>

---

From: "Dave Stephens" <[email-masked]>
Date: Wed, 18 Apr 2007 14:59:48 -0700

If there is no Event Descriptor defined in the Embedded Event/Signal which Event Descriptor is in effect.  Section 7.1.9 states that: "An event can include an Embedded Signals descriptor and/or an Embedded Events descriptor which, if present, replaces the current Signals/Event descriptor when the event is recognized." If no Event descriptor is defined in the embedded signal what event descriptor is in effect.
Consider the script"

events = 23 { 
   aasb/audfail { 
    stream = 1,
     embed { 
      signals { 
        aasb/play { 
          stream = 1,
          an = "sid=FileGenerateError2",
          notifycompletion =  { Timeout, IntByEvent, IntBySigDescr, OtherReason }
 }}}}},
 signals { 
   aasb/play { 
     stream = 1,
     an = "sid=FileGenerateError1",
     notifycompletion =  { Timeout, IntByEvent, IntBySigDescr, OtherReason } 
 }}
 
The script plays the first signal, FileGenerateError1, resulting in an error. The aasb/audfail event is thrown. This triggers the embedded signal which attempts to play FileGenerateError2 which throwns aasb/audfail. 
If the aasb/audfail as part of events = 23 is still in effect we have an infinite loop of notifications and failures. This essentially results in a Denial of Service attack on the MGC as the speed at which Notifys are sent could overwhelm a MGC before it is able to transmit another Event Descriptor to disable this one.
So the question is does the embedded signal have an active Events Descriptor in this case and should the audfail event continue to be thrown.

Thanks,

Dave

-------------------------------------------------------------------
Dave Stephens
Team Leader VXML Team
RadiSys Canada Inc.
Ph:  604 918 6381
Fax: 604 918 6400

-----Original Message-----
From: Raphael Tryster [mailto:[email-masked]] 
Sent: Wednesday, April 18, 2007 3:35 AM
To: Christian Groves
Cc: [email-masked]
Subject: RE: [Megaco] conflict between embedded descriptors

Hello Christian, 

Is c) b) a typo? 
 
Regards, 
 
Raphael Tryster

-----Original Message-----
From: Christian Groves [mailto:[email-masked]]
Sent: Thursday, April 12, 2007 4:05 AM
To: Raphael Tryster
Cc: Kevin Boyle; [email-masked]
Subject: Re: [Megaco] conflict between embedded descriptors

Hello Raphael,

Your thoughts?

Regards, Christian

---

From: "Kevin Boyle" <[email-masked]>
Date: Wed, 18 Apr 2007 18:04:07 -0400

The existing Events Descriptor remains in effect until replaced.  In
this case, it would probably be wise of the implementor to account for
this possible loop and build in defense against it.  Such possibilities
are embedding a new Events Descriptor on the existing one, such that the
loop cannot occur.  Another possibility is to handle this without
embedding.

Kevin 

-----Original Message-----
From: Dave Stephens [mailto:[email-masked]] 
Sent: Wednesday, April 18, 2007 6:00 PM
To: 'Raphael Tryster'; 'Christian Groves'
Cc: [email-masked]
Subject: RE: [Megaco] conflict between embedded descriptors

If there is no Event Descriptor defined in the Embedded Event/Signal
which Event Descriptor is in effect.  Section 7.1.9 states that: "An
event can include an Embedded Signals descriptor and/or an Embedded
Events descriptor which, if present, replaces the current Signals/Event
descriptor when the event is recognized." If no Event descriptor is
defined in the embedded signal what event descriptor is in effect.
Consider the script"

events = 23 { 
   aasb/audfail { 
    stream = 1,
     embed { 
      signals { 
        aasb/play { 
          stream = 1,
          an = "sid=FileGenerateError2",
          notifycompletion =  { Timeout, IntByEvent, IntBySigDescr,
OtherReason }  }}}}},  signals { 
   aasb/play { 
     stream = 1,
     an = "sid=FileGenerateError1",
     notifycompletion =  { Timeout, IntByEvent, IntBySigDescr,
OtherReason }  }}
 
The script plays the first signal, FileGenerateError1, resulting in an
error. The aasb/audfail event is thrown. This triggers the embedded
signal which attempts to play FileGenerateError2 which throwns
aasb/audfail. 
If the aasb/audfail as part of events = 23 is still in effect we have an
infinite loop of notifications and failures. This essentially results in
a Denial of Service attack on the MGC as the speed at which Notifys are
sent could overwhelm a MGC before it is able to transmit another Event
Descriptor to disable this one.
So the question is does the embedded signal have an active Events
Descriptor in this case and should the audfail event continue to be
thrown.

Thanks,

Dave

-----Original Message-----
From: Raphael Tryster [mailto:[email-masked]]
Sent: Wednesday, April 18, 2007 3:35 AM
To: Christian Groves
Cc: [email-masked]
Subject: RE: [Megaco] conflict between embedded descriptors

Hello Christian, 

I think I also prefer your option a), not because I understand the
spirit of 7.1.9 - you and the other authors are better judges of that,
but it seems to me that the text allows either interpretation.  The
reason I prefer option a) is that it removes the ambiguity regarding
which events descriptor is in effect at each instant.  I believe Steven
Mell's reply is also consistent with this interpretation.

Is c) b) a typo? 
 
Regards, 
 
Raphael Tryster

-----Original Message-----
From: Christian Groves [mailto:[email-masked]]
Sent: Thursday, April 12, 2007 4:05 AM
To: Raphael Tryster
Cc: Kevin Boyle; [email-masked]
Subject: Re: [Megaco] conflict between embedded descriptors

Hello Raphael,

Now if we add embedding to the equasion then we have to consider how the
following will effect the picture:
H.248.1 section 7.1.9 Events Descriptor
... In the case of an embedded Events Descriptor being activated, the MG
continues event processing based on the newly activated Events
Descriptor.
NOTE 1 − For purposes of EventBuffer handling, activation of an embedded
Events Descriptor is equivalent to receipt of a new Events Descriptor.

Your thoughts?

Regards, Christian

---

From: "Dave Stephens" <[email-masked]>
Date: Wed, 18 Apr 2007 15:10:17 -0700

Kevin,

Thanks for the clarification.

Dave 

-----Original Message-----
From: Kevin Boyle [mailto:[email-masked]] 
Sent: Wednesday, April 18, 2007 3:04 PM
To: [email-masked]; Raphael Tryster; Christian Groves
Cc: [email-masked]
Subject: RE: [Megaco] conflict between embedded descriptors

The existing Events Descriptor remains in effect until replaced.  In this case, it would probably be wise of the implementor to account for this possible loop and build in defense against it.  Such possibilities are embedding a new Events Descriptor on the existing one, such that the loop cannot occur.  Another possibility is to handle this without embedding.

Kevin 

-----Original Message-----
From: Dave Stephens [mailto:[email-masked]]
Sent: Wednesday, April 18, 2007 6:00 PM
To: 'Raphael Tryster'; 'Christian Groves'
Cc: [email-masked]
Subject: RE: [Megaco] conflict between embedded descriptors

events = 23 { 
   aasb/audfail { 
    stream = 1,
     embed { 
      signals { 
        aasb/play { 
          stream = 1,
          an = "sid=FileGenerateError2",
          notifycompletion =  { Timeout, IntByEvent, IntBySigDescr, OtherReason }  }}}}},  signals { 
   aasb/play { 
     stream = 1,
     an = "sid=FileGenerateError1",
     notifycompletion =  { Timeout, IntByEvent, IntBySigDescr, OtherReason }  }}

Thanks,

Dave

-----Original Message-----
From: Raphael Tryster [mailto:[email-masked]]
Sent: Wednesday, April 18, 2007 3:35 AM
To: Christian Groves
Cc: [email-masked]
Subject: RE: [Megaco] conflict between embedded descriptors

Hello Christian, 

Is c) b) a typo? 
 
Regards, 
 
Raphael Tryster

-----Original Message-----
From: Christian Groves [mailto:[email-masked]]
Sent: Thursday, April 12, 2007 4:05 AM
To: Raphael Tryster
Cc: Kevin Boyle; [email-masked]
Subject: Re: [Megaco] conflict between embedded descriptors

Hello Raphael,

Your thoughts?

Regards, Christian