Subject: [AVT] RE: [Sip] Reg draft-ietf-avt-rtp-mime-05.txt

From: Sharma Kanchinadham <[email-masked]>
Date: Tue, 27 Nov 2001 10:12:24 -0600

Hi ,

Thanks for the info on the AVT working group.

Regarding item 1 what i am trying to say is that:

There needs to be a new MIME subtype of G.711 as shown below:

MIME media type name: audio
MIME subtype name: G711
Required parameters: None
Optional parameters:

               appendix_II: indicates that appendix_II, silence suppression
                             is used.

Also there can be 2 types of Silence Suppression with G.729 i.e. G.729
annexb, or some kind of a proprietary silence suppression for example: G.729
with Cisco VAD. Hence it is suggested that there be a 'cisco_vad' or
'unspecified_vad' as another optional parameter under G.729.

The below mentioned draft is being considered as a basis for Silence
Suppression negotiation. In this connection, the second point assumes
significance. Assume a SIP client that is not conformant to this Internet
Draft. Hence it would not pass the 'annexb' parameter etc. However the draft
assumes that if 'annexb' is not passed it supports 'annexb'. Hence the far
end might start sending Silence Suppression packets and the SIP client may
not handle the SS packets properly. Thats what i mean by saying that it
causes backward compatibility problems.

Please see if you agree.

Thanks ,
Sharma Kanchinadham
Worldcom

============================================================================

-----Original Message-----
From: Colin Perkins [mailto:[email-masked]]
Sent: Tuesday, November 27, 2001 9:19 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Sip] Reg draft-ietf-avt-rtp-mime-05.txt

--> Sharma Kanchinadham writes:
>I have some comments/observations on draft-ietf-avt-rtp-mime-05.txt. Please
>provide your inputs/opinion.
>
>The link to the draft is:
>http://search.ietf.org/internet-drafts/draft-ietf-avt-rtp-mime-05.txt

You should really ask this question on the AVT group's mailing list
<[email-masked]>, since it doesn't relate to SIP.

>1. The parameter "annexb" is not always applicable. For example in G.711
the
>Silence Suppression is Appendix II. Hence there needs to be more values
such
>as "appendix_II" and "cisco_vad".

The annexb parameter is defined only for G.729. It cannot be applied to
other payload formats.

>2. The second item is currently if the "annexb" parameter is ommitted then
>it is assumed that Silence Suppression is supported (basically it is
treated
>as if it is "yes"). This would create backward compatibility problems when
>interworking with platforms that do not want to do the development. Is it
>possible to reverse this ?

There is no backwards compatibility issue, since this parameter is only
valid for G729, and was introduced at the same time as that payload format.

Colin

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
http://www1.ietf.org/mailman/listinfo/avt

---

From: Colin Perkins <[email-masked]>
Date: Tue, 27 Nov 2001 14:25:11 -0500

How would this relate to draft-ietf-avt-rtp-cn-04.txt?
Colin

---

From: Sharma Kanchinadham <[email-masked]>
Date: Tue, 27 Nov 2001 14:41:09 -0600

Hi Colin,

The draft that you have referenced provides the payload format for comfort
noise. However there could be proprietary implementations of Silence
Suppression/VAD that follow a different payload format.

Hence it becomes important to negotiate Silence Suppression so that the
nodes involved in a call are on the same page. For example, if a node does
not wish to recieve comfort noise frames there needs to be a way to
communicate that to the other node. Otherwise there could be a quality of
service issue.

Also it is important to negotiate the type of Silence Suppression so that
any possible proprietary mechanism can be handled.

Thanks ,
Sharma Kanchinadham
Worldcom

====================================================================

---

From: Stephen Casner <[email-masked]>
Date: Tue, 27 Nov 2001 15:15:48 -0800 (PST)

Sharma Kanchinadham:

Sorry for not responding earlier to your messages sent directly to me;
I was away.  I've bcc'd the cc's on that earlier message.

Yes, I have updated draft-ietf-avt-rtp-mime-05.txt, but I don't think
that the changes you have suggested are required or appropriate.
Details below.

> 1. The parameter "annexb" is not always applicable. For example in G.711 the
> Silence Suppression is Appendix II. Hence a generic Silence Suppression name
> like "silence-supp" would be more appropriate. Would it be possible to
> rename the "annexb" accordingly so that it covers a wider range of codecs?

As Colin already explained, the annexb only applies to the G729, G729D
and G729E payload formats, so there is not a requirement for that
parameter name to be more generic.

> it is assumed that Silence Suppression is supported (basically it is treated

Backwards compatibility problems between what two things exactly?  It
is true that the annexb parameter was added to the G729 payload format
subsequent to the initial appearance of G729 in the RTP profile and
rtp-mime drafts.  However, the use of Annex B VAD and CNG has been
"RECOMMENDED" since the beginning.  Hence, the assumption was that
Annex B frames may be present in the stream, so when the annexb
parameter was added, absence of the parameter needed to imply "yes" in
order to be backwards compatible.  If a new implementation that wishes
not to receive Annex B frames negotiates annexb=no with an
implementation put in concrete before the annexb parameter was added
(and hence which might send Annex B frames), the negotiation should be
rejected by the older implementation due to the unknown fmtp
parameter.  So, the current definition should be fine.  I don't know
if there are any such older implementations.

A "platform that does not want to do the development" should negotiate
annexb=no and reject responses that don't have it.  What's the problem?

I have a more basic objection to the implication of your suggestions
that we need to add a silence suppression attribute to all the payload
formats in order to allow platforms that do "not want to do the
development" to avoid receiving streams that have silence suppressed.
There is no plan to extend the existing payload formats to add a
silence suppression parameter because that would reduce
interoperability with existing implementations.  That is especially
true for PCMU (G.711) which is the most widely compatible payload
format.

Silence suppression has been a fundamental part of RTP since the
beginning.  That is why the RTP header carries both a sequence number
and a timestamp.  Suppressing silence is one of the primary reasons
for going to packet transmission of voice in the first place.
Furthermore, even if the transmitter does not suppress silence, the
receiver must be prepared to handle the situation where there is a
frame time for which no packet is present because packets may be
lost.  Any implementation that has not been sufficiently developed to
recover reasonably to such a situation should be flatly rejected.

> I have further information regarding question no 1 below. I believe
> instead of adding a generic 'silencesupp' attribute we should add
> additional values such as:
>
>       'appendix_II' to be applicable for G.711
>       'cisco_vad' for Cisco's proprietary Silence Suppression.
[snip]
> 'unspecified_vad' as another optional parameter under G.729.

I'm not convinced that a generic problem exists, but it sounds like
you may be concerned with a specific problem related to G.711 and
G.729 interoperation between Cisco products and others.  Can you
please describe the specific problem?  In particular, what is Cisco
VAD and how does it compare to G.711 Appendix II or G.729 Annex B?

> causes backward compatibility problems.

The payload formats have always assumed silence suppression.  If the
old SIP client assumed it could operate without silence suppression
and without some means to signal that requirement, then is sounds
broken to me.

[Colin asked: How would this relate to draft-ietf-avt-rtp-cn-04.txt?]
> any possible proprietary mechanism can be handled.

I think we want to encourage the use of standardized methods and
discourage the use of proprietary methods, don't we?  That suggests
that putting in negotiation of lots of different methods might not be
a good idea.

> communicate that to the other node. Otherwise there could be a quality of

There is a way to negotiate annexb=no for G.729.  There is a way to
negotiate no use of the generic CN payload format (e.g., with G.711)
through the acceptance or rejection of that payload format in the
list on the m= line.

There is not a way to force the other end to send a data frame in
every frame time.  As I said above, wanting to build a receiver that
requires receiving a frame for every period sounds pretty unwise to
me.
							-- Steve

---

From: Sharma Kanchinadham <[email-masked]>
Date: Thu, 29 Nov 2001 12:32:09 -0600

[Sharma wrote]

> communicate that to the other node. Otherwise there could be a quality of

[Stephen Casner wrote]

(Sharma)

Can you please illustrate how G.711 Appendix II can be negotiated with an
example. I believe the appraoch you are suggesting above might conflict with
the following para in SDP RFC2327.

"Additional parameters may be defined in the future, but
 Codecspecific parameters should not be added.  Parameters added to
 an rtpmap attribute should only be those required for a session
 directory to make the choice of appropriate media too to
 participate in a session.  Codec-specific parameters should be
 added in other attributes. "

---

From: Stephen Casner <[email-masked]>
Date: Fri, 30 Nov 2001 19:06:15 -0800 (PST)

On Thu, 29 Nov 2001, Sharma Kanchinadham wrote:
> example.

As far as I know, I do not have access to ITU Recommendations,
therefore I can't say anything definite about G.711 Appendix II.  That
is why in my previous message I asked you to give a brief description:

However, the CN payload format (draft-ietf-avt-rtp-cn-04.txt) claims
to be based on G.711 Appendix II:

   The payload format is based on Appendix II of ITU-T
   Recommendation G.711 [9] which defines a comfort noise payload
   format (or bit-stream) for ITU-T G.711 use in packet-based
   multimedia communication systems.

Therefore, I assume that the way to negotiate G.711 Appendix II is to
negotiate the use of the CN payload format in combination with the
PCMU (G.711) payload format.  This may be done with an SDP media line
like the following:

    m=audio 49230 RTP/AVP 0 13

An implementation that did not want to receive CN frames would have to
restrict the media specification to:

    m=audio 49230 RTP/AVP 0

As I said, there isn't any way to insist that audio packets be
transmitted continously, but I am not convinced that the need to
signal such a requirement is justified.

> I believe the appraoch you are suggesting above might conflict with

No.  I am not proposing that any parameters be added either to the
rtpmap or the fmtp attribute.
							-- Steve