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

[Guylain Lavoie <[e-mail]>]

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