Subject: Re: [AVT] Usage of use-level-src-parameter-sets as per draft-ietf-avt-rtp-rfc3984bis-12

From: "Allison, Art" <[email-masked]>
Date: Wed, 1 Dec 2010 11:31:08 -0500

I seems to me the trade-off is delay vs. usability.  If not changed, the
rfc cannot be expected to be used by at least one organization; and the
reason given seems likely to be applicable to many business
arrangements. So an early publication may put this rfc in the hopper
with many others that are not used.

Art

Art Allison

Senior Director Advanced Engineering, Science and Technology

National Association of Broadcasters
1771 N Street NW
Washington, DC 20036
Phone  202 429 5418 
Fax  202 775 4981

www.nab.org <blocked::http://www.nab.org> 

Advocacy  Education  Innovation

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ye-Kui Wang
Sent: Tuesday, November 30, 2010 8:00 PM
To: 'Guylain Lavoie'; [email-masked]
Subject: Re: [AVT] Usage of use-level-src-parameter-sets as per
draft-ietf-avt-rtp-rfc3984bis-12

Hi,

Two points. 1) As you would like to use sprop-level-parameter-sets, the
media handling part needs anyway to assoicate parameters ets with
specific levels, then what is the essential difference between this and
associating parameter sets with specific SSRCs in terms of
implementations? 2) It is not difficult to separate the siganling if we
were to make this change early in the process, but now making such
enhancements would significantly delay the publication of the RFC, as
discussed in the max-fs discussion thread. Unless it is about something
fundamentally broken, signficantly delaying the process is not ideal. 

What do others think?

BR, YK

________________________________

	From: Guylain Lavoie [mailto:[email-masked]] 
	Sent: Tuesday, November 30, 2010 2:53 PM
	To: Ye-Kui Wang; [email-masked]
	Subject: RE: [AVT] Usage of use-level-src-parameter-sets as per
draft-ietf-avt-rtp-rfc3984bis-12

	Hi,

	Thanks a lot for answering.

	In our implementation, one of our requirement is the support of
asymmetric levels with the use of the level-asymmetry-allowed attribute.
This forces us to use the sprop-level-parameter-sets since we must be
completely sure the parameter sets are correctly sent, and we cannot
just rely on faith for their transport in-band.

	We are a provider of source code where we implement only a part
of the complete solution. We implement the SIP/SDP signalling, but the
media handling is the responsibility of our customers because different
platforms uses different media engines. We could surely support the SSRC
SDP attribute at our level but we cannot at this time push this
requirement on all of our customers. This would require important
modifications to the published interfaces that all of our customers
would need to implement. This would also mandate that their media engine
be also capable of associating parameter sets with specific ssrcs (just
because we need to support level asymmetry reliably), which we were told
might not be possible because of other third-party limitations.

	Nonetheless, I find it hard to understand that the reason why
the authors merged to the two functions (support for the
sprop-level-parameter-sets and the ssrc SDP attribute) was to save one
additional fmtp parameter. Now that we are at 23 fmtp parameters, what
is one more? There is really no need to support both or nothing, they
are not related together.

	Following my review, it seems that this is the only parameters
that causes us trouble. What can we do about this?

	Thanks,

	Guylain

	From: Ye-Kui Wang [mailto:[email-masked]] 
	Sent: 26 novembre 2010 18:25
	To: Guylain Lavoie; [email-masked]
	Subject: RE: [AVT] Usage of use-level-src-parameter-sets as per
draft-ietf-avt-rtp-rfc3984bis-12

	Hi,

	Your understanding is correct. The reason for combining the
signaling of support for both sprop-level-parameter-sets and the "fmtp"
source attribute was for simplicity (as otherwise another parameter
would be needed) and also due to that no need to separate the signaling
was identified at the time when the design was made. Could you please
clarify why it is difficult to support either both or none, and is there
any problem in this regard per the current design? If the enhancement
(by separating the signaling) is indeed needed, we then need AVT Chairs'
advice on whether the enhancement can be integrated into the draft at
this very late stage.

	BR, YK

________________________________

		From: [email-masked] [mailto:[email-masked]]
On Behalf Of Guylain Lavoie
		Sent: Wednesday, November 24, 2010 2:10 PM
		To: [email-masked] 
		Subject: [AVT] Usage of use-level-src-parameter-sets as
per draft-ietf-avt-rtp-rfc3984bis-12

		Hello,

		We are integrating the support for H.264 in our
application based on the RFC3984bis draft 12 and while reviewing the
specification we discovered that it is not possible to indicate that we
support the sprop-level-parameter-sets fmtp parameter without also
supporting the transport of the fmtp over the SDP ssrc attribute (as per
RFC5576). The problem we have is that we currently cannot implement the
support for the SDP ssrc attribute because we cannot specified the SSRC
associated with each parameter sets. How can we indicate support for
a=fmtp with the sprop-level-parameter-sets parameter without indicating
support for a=ssrc:x fmtp:sprop-level-parameter-sets=... ?

		According to our current understanding, it would seem
useful to separate the support capability for sprop-level-parameter-sets
from the support for the SDP ssrc attribute. Is there any reason for
this, please explain.

		Best Regards,

		Guylain

---

From: Guylain Lavoie <[email-masked]>
Date: Wed, 1 Dec 2010 16:16:49 -0500

Hello Ye-Kui,

The fundamental difference that I see is that the specification forces the media handling to store as many sprop-level-parameter-sets as there are ssrc and be able to dynamically perform a match to select the correct parameter sets on the fly and maybe pass this to some DSP. IMHO, this is very different than the behavior for the other parameters. Moreover, I don't think you can really expect every implementations to correctly support ssrc for some time anyway.

Best Regards,
Guylain

From: Ye-Kui Wang [mailto:[email-masked]]
Sent: 30 novembre 2010 20:00
To: Guylain Lavoie; [email-masked]
Subject: RE: [AVT] Usage of use-level-src-parameter-sets as per draft-ietf-avt-rtp-rfc3984bis-12

Hi,

Two points. 1) As you would like to use sprop-level-parameter-sets, the media handling part needs anyway to assoicate parameters ets with specific levels, then what is the essential difference between this and associating parameter sets with specific SSRCs in terms of implementations? 2) It is not difficult to separate the siganling if we were to make this change early in the process, but now making such enhancements would significantly delay the publication of the RFC, as discussed in the max-fs discussion thread. Unless it is about something fundamentally broken, signficantly delaying the process is not ideal.

What do others think?

BR, YK

Subject: RE: [AVT] Usage of use-level-src-parameter-sets as per draft-ietf-avt-rtp-rfc3984bis-12
Hi,

In our implementation, one of our requirement is the support of asymmetric levels with the use of the level-asymmetry-allowed attribute. This forces us to use the sprop-level-parameter-sets since we must be completely sure the parameter sets are correctly sent, and we cannot just rely on faith for their transport in-band.

We are a provider of source code where we implement only a part of the complete solution. We implement the SIP/SDP signalling, but the media handling is the responsibility of our customers because different platforms uses different media engines. We could surely support the SSRC SDP attribute at our level but we cannot at this time push this requirement on all of our customers. This would require important modifications to the published interfaces that all of our customers would need to implement. This would also mandate that their media engine be also capable of associating parameter sets with specific ssrcs (just because we need to support level asymmetry reliably), which we were told might not be possible because of other third-party limitations.

Nonetheless, I find it hard to understand that the reason why the authors merged to the two functions (support for the sprop-level-parameter-sets and the ssrc SDP attribute) was to save one additional fmtp parameter. Now that we are at 23 fmtp parameters, what is one more? There is really no need to support both or nothing, they are not related together.

Following my review, it seems that this is the only parameters that causes us trouble. What can we do about this?

Thanks,
Guylain

From: Ye-Kui Wang [mailto:[email-masked]]
Sent: 26 novembre 2010 18:25
To: Guylain Lavoie; [email-masked]
Subject: RE: [AVT] Usage of use-level-src-parameter-sets as per draft-ietf-avt-rtp-rfc3984bis-12

Hi,

Your understanding is correct. The reason for combining the signaling of support for both sprop-level-parameter-sets and the "fmtp" source attribute was for simplicity (as otherwise another parameter would be needed) and also due to that no need to separate the signaling was identified at the time when the design was made. Could you please clarify why it is difficult to support either both or none, and is there any problem in this regard per the current design? If the enhancement (by separating the signaling) is indeed needed, we then need AVT Chairs' advice on whether the enhancement can be integrated into the draft at this very late stage.

BR, YK

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Guylain Lavoie
Sent: Wednesday, November 24, 2010 2:10 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [AVT] Usage of use-level-src-parameter-sets as per draft-ietf-avt-rtp-rfc3984bis-12
Hello,

We are integrating the support for H.264 in our application based on the RFC3984bis draft 12 and while reviewing the specification we discovered that it is not possible to indicate that we support the sprop-level-parameter-sets fmtp parameter without also supporting the transport of the fmtp over the SDP ssrc attribute (as per RFC5576). The problem we have is that we currently cannot implement the support for the SDP ssrc attribute because we cannot specified the SSRC associated with each parameter sets. How can we indicate support for a=fmtp with the sprop-level-parameter-sets parameter without indicating support for a=ssrc:x fmtp:sprop-level-parameter-sets=... ?

According to our current understanding, it would seem useful to separate the support capability for sprop-level-parameter-sets from the support for the SDP ssrc attribute. Is there any reason for this, please explain.

Best Regards,
Guylain