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

["Allison, Art" <[e-mail]>]

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  [phone] 
Fax  [phone]

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

Advocacy  Education  Innovation

 

________________________________

From: [e-mail] [mailto:[e-mail]] On Behalf Of
Ye-Kui Wang
Sent: Tuesday, November 30, 2010 8:00 PM
To: 'Guylain Lavoie'; [e-mail]
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:[e-mail]] 
	Sent: Tuesday, November 30, 2010 2:53 PM
	To: Ye-Kui Wang; [e-mail]
	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:[e-mail]] 
	Sent: 26 novembre 2010 18:25
	To: Guylain Lavoie; [e-mail]
	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: [e-mail] [mailto:[e-mail]]
On Behalf Of Guylain Lavoie
		Sent: Wednesday, November 24, 2010 2:10 PM
		To: [e-mail] 
		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