Re: [payload] New Version Notification for draft-nandakumar-payload-sdp-max-video-resolution-00.txt

[Harald Alvestrand <[e-mail]>]

On 02/01/2014 02:51 AM, Suhas Nandakumar wrote:
> Hello All
>
>   Following draft has been submitted to specify payload format
> parameters indicating an end-point's maximum image resolution receive
> capability in SDP. This draft aims at solving the issue with
> specifying such functionality for VP8 and is also applicable to other
> codecs in general.

Thank  you for finally posting this to the payload list! (The date of
the draft is Dec 7 - I've been waiting for the proponents to make a
public statement about it).

My biggest worry with this particular proposal is that it modifies the
way a=fmtp is specified.

As far as I understand, the syntax of a=fmtp has previously been assumed
to be specified completely by the payload specification (viz the rather
non-orthogonal stuff that is in the DTMF payload).

This specification proposes to add new parameters into a=fmtp that are
applicable to any payload. This seems like a doubtful architectural
decision.
I think it would be cleaner to add a new a= attribute that is
independent of codec (but linked to payload type) containing the
information.

I also have a nit with the way offer/answer is specified:

                          ..... When the direction is
   sendonly, these attributes have no interpretation and MUST be ignored
   by the receiving Endpoint, if present.

   ......

   An SDP Answerer MUST NOT include these parameters in the SDP Answer
   unless they are specified in the associated SDP Offer.


If taken literally, an SDP answerer wishing to state its limitations on an a=sendonly M-line would not have the option to do so. Also, it's not clear what values would be appropriate if the values were meaningless.

My suggestion would be to say that the SDP Offerer should include max-recv-widht=? and max-recv-height=? in the SDP, to indicate that it understands the parameters, but has no meaningful values to supply.

Note: I see absolutely no reason to link this functionality, if
desirable, to the RTP format for VP8. If it needs mandating, it should
be mandated for all video types going forward, including H.265, and
strongly recommended for all video types that have been standardized in
the past.

If it doesn't need mandating, it doesn't need mandating for anyone.





>
>
> URL:            
> http://www.ietf.org/internet-drafts/draft-nandakumar-payload-sdp-max-video-resolution-00.txt
> Htmlized:      
>  http://tools.ietf.org/html/draft-nandakumar-payload-sdp-max-video-resolution-00
>
>
> Looking forward for the inputs on how do we take his work ahead.
>
>
> Thanks
> Suhas Nandakumar
>
>
> _______________________________________________
> payload mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/payload


-- 
Surveillance is pervasive. Go Dark.