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

[Pauls Markus <[e-mail]>]

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.:  	[phone]
Hofmannstr. 51     	Fax:   	[phone]
81359 Munich        	Email: 	[e-mail]
Germany




-----Original Message-----
From: Carl Rutter [mailto:[e-mail]]
Sent: Wednesday, April 03, 2002 3:36 AM
To: Chuong N. Nguyen
Cc: [e-mail]
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: [e-mail] [mailto:[e-mail]]On Behalf Of Chuong N. Nguyen
Sent: Tuesday, April 02, 2002 8:05 PM
Cc: [e-mail]
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: [e-mail] [mailto:[e-mail]]On Behalf Of Chuong N. Nguyen 
Sent: Tuesday, April 02, 2002 7:16 PM 
To: [e-mail] 
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: [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 ****  


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