Re: [Megaco] Local/Remote descriptors and Permanent terminations

Terry L Anderson <tla@lucent.com> Wed, 03 April 2002 15:05 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05167 for <megaco-archive@odin.ietf.org>; Wed, 3 Apr 2002 10:05:12 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA28064; Wed, 3 Apr 2002 09:39:09 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA28035 for <megaco@ns.ietf.org>; Wed, 3 Apr 2002 09:39:04 -0500 (EST)
Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04444 for <megaco@ietf.org>; Wed, 3 Apr 2002 09:38:59 -0500 (EST)
Received: from teton.ho.lucent.com (h135-112-32-10.lucent.com [135.112.32.10]) by auemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g33EbvD13899; Wed, 3 Apr 2002 09:37:58 -0500 (EST)
Received: from lucent.com (tla.lra.lucent.com [192.11.62.65]) by teton.ho.lucent.com (8.8.8+Sun/8.8.8) with ESMTP id JAA21882; Wed, 3 Apr 2002 09:38:40 -0500 (EST)
Message-ID: <3CAB13B0.5B7B5284@lucent.com>
Date: Wed, 03 Apr 2002 09:37:36 -0500
From: Terry L Anderson <tla@lucent.com>
Organization: Lucent Technologies
X-Mailer: Mozilla 4.79 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom-PT Taylor <taylor@nortelnetworks.com>
CC: 'Pauls Markus' <Markus.Pauls@icn.siemens.de>, megaco@ietf.org, 'Carl Rutter' <crutter@telica.com>, "'Chuong N. Nguyen'" <Chuong.Nguyen@alcatel.com>, 'Stephen Casner' <casner@acm.org>
Subject: Re: [Megaco] Local/Remote descriptors and Permanent terminations
References: <4D79C746863DD51197690002A52CDA0001E8A23F@zcard0kc.ca.nortel.com>
Content-Type: multipart/mixed; boundary="------------AE44D80F31F7B735404D2940"
Sender: megaco-admin@ietf.org
Errors-To: megaco-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Media Gateway Control <megaco.ietf.org>
X-BeenThere: megaco@ietf.org

just to be clear about the options, I do not believe that the comfort noise
draft alone provides a solution.  The payload provides a way to specify the
nature of the comfort noise to be used when silence suppression is in use, but
its absence is not intended to imply that silence suppression should not occur
(just that no comfort noise is played).  We would still need one of the other
ways to indicate that silence suppression should be turned off.

Tom-PT Taylor wrote:

> [Stephen Casner copied because this potentially affects AVT WG work in
> progress.]
>
> To summarize: we are trying to define how to indicate that silence
> suppression is desired for a given audio flow.  We could do it through an
> a=silenceSupp attribute, through codec-specific a=fmtp: parameters, or
> implicitly by specifying the Comfort Noise codec as an alternative.  Markus
> shows the sort of contradictions we could arrive at if we are not careful.
>
> I think it's quite clear that we do NOT want to tie silence suppression to
> the TDM package.
>
> The cleanest way would be to ensure that every codec where silence
> suppression might apply has a silence suppression parameter.  For RTP, this
> requires revisiting draft-ietf-avt-rtp-mime-06.txt, which is currently in
> IETF Last Call.  Not sure what we do about ATM: RFC 3108 defines a profile
> that just picks up the RTP mappings, so maybe it would also pick up the
> parameters defined in the MIME type registrations and payload format
> descriptions.  I find this whole area murky because theoretically there
> should be new MIME type registrations for each transport in order to reuse
> the profiles in SDP.
>
> A second possibility is to define the a=silenceSupp attribute for all
> transports, but specify that it takes second priority to a=fmtp parameters
> where these are defined.  This is probably the most practical route.
>
> Stephen, any comments?
>
> -----Original Message-----
> From: Pauls Markus [mailto:Markus.Pauls@icn.siemens.de]
> Sent: Wednesday, April 03, 2002 2:49 AM
> To: megaco@ietf.org
> Cc: 'Carl Rutter'
> Subject: RE: [Megaco] Local/Remote descriptors and Permanent
> terminations
>
> Suppose you have the following SDP:
>
> m=audio 4444 RTP/AVP 0 18
> a=fmtp:18 annexb=no         // G.729, Silence Suppression off (see
> draft-ietf-avt-rtp-mime-05)
> a=silenceSupp: on - - - -
>
> (that means the GW may either use G.711 µ-law or G.729)
>
> The silenceSupp attribute is not specific for a payload type, the fmtp
> attribute is. So which one has precedence in this case?
>
> In my opinion you should have the ability to switch on silence suppression
> depending on the payload type. If you want to use it with G.711, it does not
> mean that you want it with G.729.
>
> Beyond that I believe generally it is more suited to an ephemeral
> termination. Therefore it should be expressed by means of SDP.
>
> However, if you want to transport the comfort noise payload (according to
> draft-ietf-avt-rtp-cn-05), you should add the payload type 13 to the SDP
> media line as well (IMO).
>
> From my point of view the SDP should therefore look something like this:
>
> m=audio 4444 RTP/AVP 0 18 13
> a=fmtp:18 annexb=no
> a=fmtp:0 silSup=yes
>
> where this PCMU specific parameter silSup must still be defined (for PCMA as
> well).
>
> Any comment is appreciated.
>
>         Kind regards
>
>                 Markus Pauls
>
> ________________________________________________________
> Markus Pauls
>
> SIEMENS
> Information and Communication Networks
>
> ICN WN CC NA B13        Tel.:   +49 89 722 62937
> Hofmannstr. 51          Fax:    +49 89 722 44176
> 81359 Munich            Email:  markus.pauls@icn.siemens.de
> Germany
>
> -----Original Message-----
> From: Carl Rutter [mailto:crutter@telica.com]
> Sent: Wednesday, April 03, 2002 3:36 AM
> To: Chuong N. Nguyen
> Cc: megaco@ietf.org
> Subject: RE: [Megaco] Local/Remote descriptors and Permanent terminations
>
> You bring up a good point,
> Is/Should Silient Suppression be tied to the TDM package or
> SDP TDM, if in fact its really more applicable to the Ephemral side.
> If no can think of a good reason then your right it would make more sense to
> be in the SDP.
> For now we could use 0 13 for G711 and long-term use the ATM approach for
> SDP.
> Trying to drive towards closure as we have a need to implement this.
> Yea, the hairpinning would be in the MG Switch.
> Comments?
>
> Carl
> -----Original Message-----
> From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org]On Behalf Of
> Chuong N. Nguyen
> Sent: Tuesday, April 02, 2002 8:05 PM
> Cc: megaco@ietf.org
> Subject: Re: [Megaco] Local/Remote descriptors and Permanent terminations
>
>
> That is what  I initially thought silence suppression was about.
> But then I was told differently.
> It could be applied to TDM.
> If not, then why are we discussing adding silence suppresion to the TDM
> package?
>
> By the way,  I thought TDM-TDM calls are being made at the Gwy too.
> Aren't you guys doing that now?
>
>
> Carl Rutter wrote:
> I can't think of an application where you'd want to do that. Silence
> suppression really wouldn't make sense for a TDM-TDMwhich is hairpined at
> the CO. The DS0 is dedicated. The advantage of Silent suppression it to
> limit the RTP traffic on the IP side, which you wouldn't have in that
> case.Maybe if you wanted to inject Comfort Noise instead of backgroundnoice
> in the TDM-TDM call??Carl
> -----Original Message-----
> From: megaco-admin@ietf.org [mailto:megaco-admin@ietf.org]On Behalf Of
> Chuong N. Nguyen
> Sent: Tuesday, April 02, 2002 7:16 PM
> To: megaco@ietf.org
> Subject: Re: [Megaco] Local/Remote descriptors and Permanent terminations
> Tom-PT Taylor wrote:
> I've had a message pointing out the existence of
> draft-ietf-avt-rtp-cn-05.txt.  Specifying this payload type as well as G.711
>
> would indicate the use of silence suppression implicitly.  That covers RTP
> transport.  For ATM we have the a=silenceSupp attribute defined in RFC 3108.
>
> Do we need anything for TDM?
>
> What if someone wanted to make a TDM-TDM, hairpin call?
> Would silenceSupp be used for such a call?
> If yes, then what?
>
>
> --
>   Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
>   1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
>   **** The opinions expressed are not those of Alcatel USA, Inc ****
> --
>   Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
>   1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
>   **** The opinions expressed are not those of Alcatel USA, Inc ****
>
> _______________________________________________
> 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

--
-------------------------------------------------------
Terry L Anderson, DMTS                   tla@lucent.com
Lucent Technologies /INS/ Voice over IP Access Networks
Rm 2B-121,   600 Mountain Ave, Murray Hill, NJ 07974
Voice:908 582-7013  FAX:908 582-6226   Org:18E75000000
http://its.lucent.com/~tla  (Lucent internal)
http://www.gti.net/tla
-------------------------------------------------------