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

From: Guylain Lavoie <[email-masked]>
Date: Wed, 24 Nov 2010 14:10:25 -0500

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: Ye-Kui Wang <[email-masked]>
Date: Fri, 26 Nov 2010 18:25:29 -0500

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: Tue, 30 Nov 2010 14:53:16 -0500

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]<mailto:[email-masked]>
Subject: [AVT] Usage of use-level-src-parameter-sets as per draft-ietf-avt-rtp-rfc3984bis-12
Hello,

Best Regards,
Guylain

---

From: Ye-Kui Wang <[email-masked]>
Date: Tue, 30 Nov 2010 20:00:27 -0500

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,

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

Subject: RE: [AVT] Usage of use-level-src-parameter-sets as per

Hi,

BR, YK

  _____  

Hello,

Best Regards,

Guylain