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

["Chuong N. Nguyen" <[e-mail]>]

Doesn't the following cover this already?

5.6.3.2 The 'silenceSupp' attribute

   When present, the 'silenceSupp' attribute is used to indicate the use

   or non-use of silence suppression.  The format of the 'silenceSupp'
   media attribute line is as follows:

   a=silenceSupp: <silenceSuppEnable> <silenceTimer> <suppPref> <sidUse>

                   <fxnslevel>





Carl Rutter wrote:

> All good questions another I would add is:If we use SDP for TDM going
> forward how is silence suppression implemented?
> Carl
>
>      -----Original Message-----
>      From: Chuong N. Nguyen [mailto:[e-mail]]
>      Sent: Tuesday, April 02, 2002 3:41 PM
>      To: [e-mail]
>      Subject: Re: [Megaco] Local/Remote descriptors and Permanent
>      terminations
>
>
>      I thought the reason that we decided to have SDP TDM is to
>      get away from TDM package
>      to be more inline w/how we specify RTP termination
>      characteristics.
>      Also to reuse the good stuffs from RTP/ATM SDP.
>
>      I guess we can start by asking the questions
>
>      1) Can we live w/o the TDM package?
>      2) Can we just use SDP for TDM going forward?
>      3) For backward compatibility, just leave TDM package as is
>      and don't extend it anymore.
>
>      For the TDM package, echo control is understood but the Gain
>      control is not quite right.
>      I have discussed the Gain control before and gotten nowhere.
>
>      Gain control is also defined in the SDP for ATM which seems
>      more correct.
>
>
>
>      Carl Rutter wrote:
>
>     > Chuong,There was several ideas bouncing around but I don't
>     > believethere was any closure.  There is a hole for G711
>     > since we can't use annexa or annexb.Lifting the support in
>     > RFC 3108, section 5.6.3.2 and putting it intothe TDM
>     > Circuit Package would give us a lot of flexibility.Here
>     > are the ideas I know of:1)
>     >
>     > Another option is to extend the TDM Circuit Package (which
>     > has been
>     >
>     > previously discussed on the list). The TDM Cicruit Package
>     >
>     > currently has Gain and Echo Control as its properties. So,
>     > it's logical
>     >
>     > (IMO) for Silence Suppression to be part of the package as
>     >
>     > well. In fact, it looks like an oversight that it was
>     > missed off in the
>     >
>     > first place.
>     >
>     > Regards,
>     >
>     > Wayne Cutler
>     >
>     > 2)
>     >
>     > Another possibility is to use payload 13 as defined in
>     > draft-ietf-avt-rtp-cn-05.  E.g.:
>     >
>     > Media={Stream=1{ Local {
>     > v=0
>     > c=IN IP4 $
>     > m=audio $ RTP/AVP 0 13
>     > }}}
>     >
>     > David Barr
>     >
>     > 3)
>     >
>     > I'm starting to think that the answer may be to use the
>     > a=silenceSupp
>     > attribute defined in RFC 3108, section 5.6.3.2.
>     >
>     > Tom Taylor
>     >
>     >
>     >
>     > Carl
>     >
>     >      -----Original Message-----
>     >      From: Chuong N. Nguyen
>     >      [mailto:[e-mail]]
>     >      Sent: Tuesday, April 02, 2002 2:59 PM
>     >      Cc: [e-mail]
>     >      Subject: Re: [Megaco] Local/Remote descriptors
>     >      and Permanent terminations
>     >
>     >
>     >      So what was that discussion about adding silence
>     >      suppression to TDM package?
>     >
>     >      Do we use SDP TDM or TDM package or both?
>     >      Or even worse combination of both within 1
>     >      command w/some parameters defined by TDM package
>     >      and
>     >      some parameters defined by SDP TDM.
>     >
>     >
>     >
>     >      Tom-PT Taylor wrote:
>     >
>     >      > As I noted earlier, you do need to specify the
>     >      > properties in the NAS case.
>     >      > The SDP TDM draft has certainly had time to
>     >      > ripen, and I will reissue it and
>     >      > the NAS packages within the next week.
>     >      >
>     >      > -----Original Message-----
>     >      > From: Chuong N. Nguyen
>     >      > [mailto:[e-mail]]
>     >      > Sent: Tuesday, April 02, 2002 2:48 PM
>     >      > To: [e-mail]
>     >      > Subject: Re: [Megaco] Local/Remote descriptors
>     >      > and Permanent terminations
>     >      >
>     >      >
>     >      > I don't know about the sendrecv issue here.
>     >      > I don't know what you mean by SDP parameters
>     >      > are of no significance in case
>     >      > of phy. term.
>     >      > Tom wrote the SDP TDM draft which I wonder what
>     >      > is the status of this draft.
>     >      >
>     >      > But I can't remember now whether it was
>     >      > intended to be used in local or
>     >      > localControl Descriptor.
>     >      >
>     >      >
>     >      > Madhu Babu Brahmanapally wrote:
>     >      > HI Rajesh/All,
>     >      > Not all parameters might be useful for the
>     >      > MG/MGC in case of physical
>     >      > terminations. The SDP parameters are of no
>     >      > significance in case of physical
>     >      > terminations (in normal scenario). Hence the
>     >      > mode was set to "sendrecv"
>     >      > without specifying the local/remote descriptor
>     >      > information.
>     >      > Regards
>     >      > Madhubabu
>     >      > -----Original Message-----
>     >      > From: [e-mail]
>     >      > [mailto:[e-mail]]On Behalf Of
>     >      > Rajesh N
>     >      > Sent: Tuesday, April 02, 2002 11:32 AM
>     >      > To: [e-mail]
>     >      > Subject: [Megaco] Local/Remote descriptors and
>     >      > Permanent terminations
>     >      > Hi,
>     >      > Sometime back there was a thread regarding
>     >      > usage of SendRecv mode for an
>     >      > ephemeral termination, when Remote Descriptor
>     >      > values are yet to be defined.
>     >      > And one of the choices for the MG in such a
>     >      > situation is to reply back with
>     >      > error 411, "missing remote or local
>     >      > descriptor".
>     >      > I would like to know, what is the significance
>     >      > of this problem w.r.to
>     >      > permanent terminations. The example call flow
>     >      > in the draft shows a Modify
>     >      > request for a permanent termination, from MGC
>     >      > to MG1, in which mode is set
>     >      > as SendRecv and  the Local descriptor values
>     >      > alone are being provided.
>     >      > Are local and remote descriptors relevant for
>     >      > physical terminations? If
>     >      > yes, where should I get the values from?
>     >      > Thanks
>     >      > Regards,
>     >      > Rajesh N
>     >      > _______________________________________________
>     >      >
>     >      > Megaco mailing list
>     >      > [e-mail]
>     >      > https://www1.ietf.org/mailman/listinfo/megaco
>     >      > ---
>     >      > [This E-mail was scanned for viruses and is
>     >      > clean.]
>     >      > _______________________________________________
>     >      >
>     >      > Megaco mailing list
>     >      > [e-mail]
>     >      > https://www1.ietf.org/mailman/listinfo/megaco
>     >      > --
>     >      >   Alcatel USA, Inc             Internet:
>     >      > [e-mail]
>     >      >   1000 Coit Road Plano, Texas 75075
>     >      > Phone:    [phone]
>     >      >   **** The opinions expressed are not those of
>     >      > Alcatel USA, Inc ****
>     >      >
>     >
>     >      --
>     >        Alcatel USA, Inc             Internet: [e-mail]
>     >        1000 Coit Road Plano, Texas 75075           Phone:    [phone]
>     >        **** The opinions expressed are not those of Alcatel USA, Inc ****
>     >
>     >
>     >
>      --
>        Alcatel USA, Inc             Internet: [e-mail]
>        1000 Coit Road Plano, Texas 75075           Phone:    [phone]
>        **** The opinions expressed are not those of Alcatel USA, Inc ****
>
>
>
--
  Alcatel USA, Inc             Internet: [e-mail]
  1000 Coit Road Plano, Texas 75075           Phone:    [phone]
  **** The opinions expressed are not those of Alcatel USA, Inc ****