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

[Guylain Lavoie <[e-mail]>]

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:[e-mail]]
Sent: 30 novembre 2010 20:00
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]<mailto:[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