From: Terry L Anderson [mailto:tlatla@verizon.net]
Sent: Tuesday, January 28, 2003 12:15 PM
To: John Stock
Cc: 'Kevin Boyle'; 'megaco@ietf.org'
Subject: Re: [Megaco] RE: Glare condition when using embedded descriptors
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:kboyle@nortelnetworks.com]
Sent: Monday, January 27, 2003 12:08 PM
To: John Stock; 'megaco@ietf.org'
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:John.Stock@afc.com]
Sent: Wednesday, January 22, 2003 5:32 PM
To: John Stock; 'megaco@ietf.org'
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: 'megaco@ietf.org'
> 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
> john.stock@afc.com
> 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
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco
-- ------------------------------------------------------- Terry L Anderson tlatla@verizon.net Voice: +1 908.766.4463 Mobile: +1 908.342.9595 http://www.gti.net/tla -------------------------------------------------------
-- ------------------------------------------------------- Terry L Anderson tlatla@verizon.net Voice: +1 908.766.4463 Mobile: +1 908.342.9595 http://www.gti.net/tla -------------------------------------------------------