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

["Kevin Boyle" <kboyle@nortelnetworks.com>]

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
_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco