Subject: Re: [Megaco] Duplicated in-band and out-band tones

From: [email-masked]
Date: Thu, 16 Feb 2006 11:40:31 +0100

Richard, et al.,

are you sure that your scenario is correct?

>>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

I think that such a "CNG relay" mechanism via MGC is not meaningful.
E.g., how do you handle it in case of MGC-to-MGC signalling (like SIP-I,
BICC) scenarios?
Where did you found that scenario? In T.38 (04/2004) Appendix III?

In my opinion is the CNG tone entirely transmitted end-to-end,
horizontally: either Inband/RTP or RFC2833/RTP in the IP section.
Pls have also a look into V.152 concerning hanlding of inband signalling.

Regards,
Albrecht

                      "Tom-PT Taylor"                                                                                              
                      <[email-masked]         To:      Raphael Tryster <[email-masked]>                             
                      om>                      cc:      [email-masked], Richard Sun <[email-masked]>                             
                      Sent by:                 Subject: Re: [Megaco] Duplicated in-band and out-band tones                         
                      megaco-bounces@i                                                                                             
                      etf.org                                                                                                      

                      15.02.2006 22:19                                                                                             

Not specifically for CNG -- its nominal duration is 0.5s on, 3s off,
repeated. The extra duration that might occur could mask ANSam in the
reverse direction briefly, but that's not a big problem.

Raphael Tryster wrote:

>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: [email-masked] [mailto:[email-masked]]On Behalf Of
Tom-PT Taylor
>Sent: Wednesday, February 15, 2006 6:13 PM
>To: Richard Sun
>Cc: [email-masked]
>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
>>[email-masked]
>>https://www1.ietf.org/mailman/listinfo/megaco
>>
>>
>>
>>
>
>
>_______________________________________________
>Megaco mailing list
>[email-masked]
>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
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: Richard Sun <[email-masked]>
Date: Fri, 17 Feb 2006 05:28:37 -0500

Albrecht,

Yes, the scenario is from T.38 (04/2004)
(Page76, step 8).

Is there any real implementation of
this "MGC transition method"?
Or is there any real implementation of
The autonomous method (step3 page 93)?

How does autonomous method guarentee that tones
are passed to remote if codec is not G711?

-Richard

---

From: [email-masked]
Date: Sat, 18 Feb 2006 07:55:07 +0100

Richard,

with regard to the

      MGC Transitioning Method (aka MGC strict controlled)
      = T.38 (04/2004), § III.2.1
            I'm NOT aware of any real implementations.
            See also Raphael's analysis "H.248-controlled T.38:
            Clarifications requested for T.38 (04/2004) Appendix III"
            http://www.itu.int/md/meetingdoc.asp?lang=en&parent=T05-SG16-050726-D-0091
      MG Autonomous Transitioning Method
      = T.38 (04/2004), § III.2.3
            I know implementations.

>are passed to remote if codec is not G711?

Either RFC2833 with G.729, or VBDoIP (accord. V.152 & "G.711" as VBD codec)
as interim state between G.729oIP and T.38oIP, or...

- Albrecht

                      Richard Sun                                                                                                  
                      <[email-masked]         To:      Albrecht SCHWARZ/DE/ALCATEL@ALCATEL                                        
                      >                        cc:      [email-masked], Raphael Tryster <[email-masked]>            

                      17.02.2006 11:28                                                                                             

Albrecht,

-Richard