Most tones have a minimum duration before the tone is "detected".
Unless the MG is particularly slow about stripping the tone, any amount
of the tone left in the bearer should be short enough to be considered
noise.

There are no general rules for the MGC.  The determination of the MGC to
ask the MG to detect tones is an implementation choice.

Kevin 

-----Original Message-----
From: Richard Sun [mailto:xsun@lucent.com] 
Sent: Wednesday, February 15, 2006 2:07 PM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]
Cc: Maridi Raju Makaraju(Raju); Raphael Tryster; Taylor, Tom-PT
[CAR:5N00:EXCH]; megaco@ietf.org
Subject: Re: [Megaco] Duplicated in-band and out-band tones

Thanks a lot to all who replied.

Assume MG1 should strip off any tones that MGC asked to be notified.
Will there be still a chance that
MG2 also detected the tone through RTP before MG1 starts to strip the
tone?

What are the general rules for MGC to decide whether to ask MG notify
any tones (fax tones, DTMF, etc), or use alternatives?

-Richard


Kevin Boyle wrote:
> The stripping of the tone may very well apply to RFC2833 detection and

> transport, but we aren't necessarily talking about 2833 here.  That 
> being said, it may be that T.38 needs to mandate the tone be stripped 
> for these procedures, because having CNG overlap is going to cause 
> problems with detection.
> 
> Kevin
> 
> -----Original Message-----
> From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org] On 
> Behalf Of Maridi Raju Makaraju(Raju)
> Sent: Wednesday, February 15, 2006 12:11 PM
> To: Raphael Tryster; Taylor, Tom-PT [CAR:5N00:EXCH]; Richard Sun
> Cc: megaco@ietf.org
> Subject: RE: [Megaco] Duplicated in-band and out-band tones
> 
> I don't think this is an issue as... once GW detects and Notifies the 
> MGC of a requested tone MG has to "strip off" the tone from the
bearer.
> If this is not how it works on MG then we will have problems with 
> duplicate tones with DTMF or as a mater of fact with any other tones.
> 
> 
>> -----Original Message-----
>> From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org]On
> Behalf
>> Of Raphael Tryster
>> Sent: Wednesday, February 15, 2006 10:45 AM
>> To: Tom-PT Taylor; Richard Sun
>> Cc: megaco@ietf.org
>> Subject: RE: [Megaco] Duplicated in-band and out-band tones
>>
>>
>> Is it a problem that the regenerated signal will always start after 
>> the original in-band signal has already been playing for some period 
>> of time?
>>
>> Raphael Tryster
>>
>> "Things should be made as simple as possible, but not any simpler."  
>> - Albert Einstein
>>
>>
>> -----Original Message-----
>> From: megaco-bounces@ietf.org [mailto:megaco-bounces@ietf.org]On
>> Behalf Of Tom-PT Taylor
>> Sent: Wednesday, February 15, 2006 6:13 PM
>> To: Richard Sun
>> Cc: megaco@ietf.org
>> Subject: Re: [Megaco] Duplicated in-band and out-band tones
>>
>>
>> I would think the basic position would be that unless MG2 is asked to

>> detect CNG tone, it doesn't in theory understand the contents of the 
>> media stream. Hence there is no problem from the MG's point of view:
> it
>> plays out CNG as requested, and this signal displaces the audio
> received
>> from the far end while it is being played out.
>>
>> That, of course, wasn't your question, but gives us a basis for
> tackling
>> it. If the CNG tone received by the T38 fax/phone violates the
> start-up
>> protocol (e.g. by coming after V.8 CI or CM), then the appropriate 
>> protocol error procedures are applied. This may mean that the two 
>> ends
> 
>> eventually synchronize, or it may mean the call fails.
>>
>>
>>
>> Richard Sun wrote:
>>> Is there a standard on dealing with duplicate tones from in-band 
>>> (RTP) and out-band (MGC request).
>>>
>>> For example, take this scenario from T.38 (MGC directed
>>> method):
>>> 1. MGC asks MG1 to detect CNG fax tone.
>>> 2. MG1 detected CNG and notify MGC
>>> 3. MGC asks MG2 to play CNG tone
>>>
>>> The question is: how does the T38 fax/phone connected to MG2 deal 
>>> with the duplicated tones: one from in-band RTP, and one from MGC 
>>> request?
>>>
>>> Thanks for any info.
>>> -Richard
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>> ******************************************************************
>> ****************************
>> This e-mail contains confidential, privileged or proprietary 
>> information to VocalTec Communications.
>> If you received this messege by mistake, please inform us and then 
>> delete the original and all copies.
>> *** eSafe scanned this email for viruses, vandals, and malicious 
>> content. ***
>> ******************************************************************
>> ****************************
>>
>>
>> _______________________________________________
>> 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
> 
> 
> 
> _______________________________________________
> 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