Subject: RE: [Megaco] RE: Glare condition when using embedded descriptors

From: John Stock <[email-masked]>
Date: Tue, 28 Jan 2003 16:35:47 -0800

Oops, sorry for the wrong step #.
 
Can the next version of the spec (Tom?) be updated per your recommendation,
including a requirement in the spec itself stating as such?
 
Thanks,
John

-----Original Message-----
From: Terry L Anderson [mailto:[email-masked]]
Sent: Tuesday, January 28, 2003 12:15 PM
To: John Stock
Cc: 'Kevin Boyle'; [email-masked]'
Subject: Re: [Megaco] RE: Glare condition when using embedded descriptors

The note to which you refer in step 3 (not step 5) is misleading and, since
it occurs in an Appendix, is not normative.  Events matching an active event
descriptor (from a command or activated from an embedded events descriptor)
always result in a Notify (unless suspended by LockStep or deferred by being
absorbed into a current dial string).  The note should read more like:
    Note that the embedded EventsDescriptor could have been used to combine
steps 3 and 4 with 
    steps 8 and 9, so that digit collection need not wait for steps 6 and 7.

There is no way to activate an embedded events descriptor without triggering
an event which also results in a Notify, but the embedded events descriptor
allows the new events (and possibly new embedded signals) to be activated
without waiting for a Notify, Reply, Command cycle.

John Stock wrote:

The only place in the spec that I can see this addressed is in the example
call flow.  At the bottom of step 5, it says:
 
Note that the embedded EventsDescriptor could have been used to combine
steps 3 and 4 with steps 8 and 9, eliminating steps 6 and 7.
 
Since steps 6 and 7 are the offhook Notify and its corresponding Reply, this
to me means that there is not an intent to send the offhook as an observed
event.
 
Please let me know if there's somewhere else in the spec or annexes that
addresses this, I haven't been able to find anything.  Thanks.
 
John

-----Original Message-----
From: Kevin Boyle [ mailto:[email-masked]
<mailto:[email-masked]> ]
Sent: Monday, January 27, 2003 12:08 PM
To: John Stock; ' [email-masked] <mailto:[email-masked]> '
Subject: RE: [Megaco] RE: Glare condition when using embedded descriptors

Actually, the offhook IS sent.  Just because it has embedded descriptors
does not relieve the MG of its responsibility to report detected events.

Kevin 

-----Original Message----- 
From: John Stock [ mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Wednesday, January 22, 2003 5:32 PM 
To: John Stock; ' [email-masked] <mailto:[email-masked]> ' 
Subject: [Megaco] RE: Glare condition when using embedded descriptors 

Actually I just remember that an offhook event is not sent to the MG in the
case of embedded descriptors. 

However this actually exacerbates the problem - there is actually a very
large widow where this glare condition can occur.  I'm certain this must
have been discussed at some point, though couldn't find anything in looking
through past emails.  If such a discussion has taken place, can someone
point me to the email thread?

Thanks. 

>  -----Original Message----- 
> From:         John Stock  
> Sent: Wednesday, January 22, 2003 2:25 PM 
> To:   ' [email-masked] <mailto:[email-masked]> ' 
> Subject:      Glare condition when using embedded descriptors 
> 
> Hi all, 
> 
> I was wondering about handling of this situation: 
> 
> - Embedded descriptors are used, such that when a user goes offhook, 
> the MG will provide dialtone and begin digit collection without 
> waiting for additional signals from the MGC 
> - A glare condition happens, such that a ring-in on the phone from the 
> MGC side occurs at the same time as the offhook, such that the MG 
> sends the offhook notification before receiving the Add command on the 
> ring-in. 
> - Thus the MG will begin dial tone before getting the Add, and will cease 
> it when connecting the physical termination to the incoming call. 
> - The MGC will receive the offhook notification after sending the Add 
> command for the ring-in, thus sees it simply as a user answering a 
> terminating call. 
> 
> My questions are these: 
> 
> - Is it proper to handle it this way, such that the subscriber is 
> connected to the incoming call, instead of the alternative which is to 
> block the incoming call and to provide dial tone and collect digits 
> from the subscriber for a separate outgoing call?  I believe this is 
> the way it works with other protocols, such as Q.931 in GR303. 
> - The odd thing is the brief spurt of dial tone, which may be 
> exacerbated by any MGC<->MG messaging delay.  Does anyone know 
> anything that's proposed for handling this?  Though it's probably not 
> a big deal since one would expect this to happen very very seldomly.  
> An obvious solution is to not use the embedded descriptors, however 
> this then of course removes the benefits of doing such.  Another 
> solution may be to have the MG wait for the Reply to the offhook 
> before providing dial tone, but this is kind of complex because the 
> Reply handling may be in a completely different entity and level than 
> event/signal handling. 
> 
> Thanks. 
> 
> John Stock 
> Systems Engineering 
> Advanced Fibre Communications 
> [email-masked] <mailto:[email-masked]>  
> 707-792-6249 
> 
> This message (including any attachments) is intended only for the use 
> of the named addressee(s), and may contain information that is legally 
> privileged, confidential or exempt from disclosure under applicable 
> law. If you are not a named addressee, you are hereby notified that 
> any use, dissemination, distribution or copying of this message is 
> strictly prohibited. If you have received this message in error, 
> please notify the original sender immediately by telephone or by 
> return E-mail and delete this message, along with any attachments, 
> from your computer. Thank you. 
> 
> 
_______________________________________________ 
Megaco mailing list 
[email-masked] <mailto:[email-masked]>  
https://www1.ietf.org/mailman/listinfo/megaco
<https://www1.ietf.org/mailman/listinfo/megaco>  

-- 

-------------------------------------------------------

Terry L Anderson                      [email-masked]
<mailto:[email-masked]> 

Voice: +1 908.766.4463	        Mobile: +1 908.342.9595

http://www.gti.net/tla <http://www.gti.net/tla> 

-------------------------------------------------------

---

From: Terry L Anderson <[email-masked]>
Date: Tue, 28 Jan 2003 19:42:44 -0500

I agree that the note could be corrected, but I am not sure that 
anything need change in the normative text.  There is nothing that 
suggests events triggering replacement or the event descriptor by an 
embedded event descriptor should be different.  I see no reason to 
explicitly state that there is no difference.

John Stock wrote:

> Can the next version of the spec (Tom?) be updated per your 
> recommendation, including a requirement in the spec itself stating as 
> such?
>  
> Thanks,
> John
>
>     The note to which you refer in step 3 (not step 5) is misleading
>     and, since it occurs in an Appendix, is not normative.  Events
>     matching an active event descriptor (from a command or activated
>     from an embedded events descriptor) always result in a Notify
>     (unless suspended by LockStep or deferred by being absorbed into a
>     current dial string).  The note should read more like:
>         Note that the embedded EventsDescriptor could have been used
>     to combine steps 3 and 4 with
>     There is no way to activate an embedded events descriptor without
>     triggering an event which also results in a Notify, but the
>     embedded events descriptor allows the new events (and possibly new
>     embedded signals) to be activated without waiting for a Notify,
>     Reply, Command cycle.
>
>     John Stock wrote:
>
>>     The only place in the spec that I can see this addressed is in
>>     the example call flow.  At the bottom of step 5, it says:
>>      
>>     Note that the embedded EventsDescriptor could have been used to
>>     combine steps 3 and 4 with steps 8 and 9, eliminating steps 6 and 7.
>>      
>>     Since steps 6 and 7 are the offhook Notify and its corresponding
>>     Reply, this to me means that there is not an intent to send the
>>     offhook as an observed event.
>>      
>>     Please let me know if there's somewhere else in the spec or
>>     annexes that addresses this, I haven't been able to find
>>     anything.  Thanks.
>>      
>>     John
>>      
>>
>>         From: Kevin Boyle [mailto:[email-masked]]
>>         To: John Stock; [email-masked]'
>>         Actually, the offhook IS sent.  Just because it has embedded
>>         descriptors does not relieve the MG of its responsibility to
>>         report detected events.
>>
>>         Kevin
>>
>>         From: John Stock [mailto:[email-masked]]
>>         To: John Stock; [email-masked]'
>>         Actually I just remember that an offhook event is not sent to
>>         the MG in the case of embedded descriptors.
>>
>>         However this actually exacerbates the problem - there is
>>         actually a very large widow where this glare condition can
>>         occur.  I'm certain this must have been discussed at some
>>         point, though couldn't find anything in looking through past
>>         emails.  If such a discussion has taken place, can someone
>>         > To:   [email-masked]'
>>         > [email-masked]
>>         [email-masked]
>http://www.gti.net/tla

http://www.gti.net/tla

---

From: Terry L Anderson <[email-masked]>
Date: Tue, 28 Jan 2003 19:42:44 -0500