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

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:raphael.trystervocaltec.com] 
> Sent: Wednesday, March 28, 2007 11:43
> To: megacoietf.org
> 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
> Megacoietf.org
> https:/
/www1.ietf.org/mailman/listinfo/megaco
>
> _______________________________________________
> Megaco mailing list
> Megacoietf.org
> https:/
/www1.ietf.org/mailman/listinfo/megaco
>
>
>
>
>   


_______________________________________________
Megaco mailing list
Megacoietf.org
https:/
/www1.ietf.org/mailman/listinfo/megaco

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:Christian.Grovesnteczone.com] 
Sent: Thursday, April 12, 2007 4:05 AM
To: Raphael Tryster
Cc: Kevin Boyle; megacoietf.org
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.

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:raphael.trystervocaltec.com]
> Sent: Wednesday, March 28, 2007 11:43
> To: megacoietf.org
> 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
> Megacoietf.org
> https:/
/www1.ietf.org/mailman/listinfo/megaco
>
> _______________________________________________
> Megaco mailing list
> Megacoietf.org
> https:/
/www1.ietf.org/mailman/listinfo/megaco
>
>
>
>
>   

_______________________________________________
Megaco mailing list
Megacoietf.org
https:/
/www1.ietf.org/mailman/listinfo/megaco