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

[Ye-Kui Wang <[e-mail]>]

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