Re: [MMUSIC] RFC 5576 is da answah

[Bernard Aboba <[e-mail]>]

Christer said:

"RFC 5576 is da answah :)

http://tools.ietf.org/rfc/rfc5576.txt

Or, do you have specific examples/use-cases where it wouldn't work?
"

[BA] In the WebRTC context, IMHO there are a lot of unanswered questions in RFC 5576. 

>From Section 5:

   Endpoints MUST NOT assume that only the sources mentioned in SDP will
   be present in an RTP session; additional sources, with previously
   unmentioned SSRC IDs, can be added at any time, and endpoints MUST be
   prepared to receive packets from these sources.  (How endpoints
   handle such packets is not specified here; they SHOULD be handled in
   the same manner as packets from additional sources would be handled
   had the endpoint not received any a=ssrc: attributes at all.)

[BA] While the advice above seems generally sensible, the meaning of "prepared to receive" isn't very clear.  Implementations may differ in how they respond if they don't receive any a=ssrc attributes.   For example, an implementation might only be able to deal with a single undeclared source or perhaps not at all.  So being "prepared to receive" isn't enough to be able to deal with an RTP translator, for example. 

>From Section 8:

   When used with the SDP Offer/Answer Model [RFC3264], SDP source-
   specific attributes describe only the sources that each party is
   willing to send (whether it is sending RTP data or RTCP report
   blocks).  No mechanism is provided by which an answer can accept or
   reject individual sources within a media stream; if the set of
   sources in a media stream is unacceptable, the answerer's only option
   is to reject the media stream or the entire multimedia session.

[BA] The advice above appears to only apply to an answerer that supports RFC 5576.  If it doesn't support RFC 5576, then it will presumably ignore the a=ssrc lines, but may not reject the media stream (by setting the port to zero) or the entire session.   In this case, it may not be clear to the Offerer whether in fact it can send all the declared ssrc's or not.  Contrast this with the CLUE approach in which receiver gets to indicate what media captures it would like to receive. 

>From Section 9:

   Source descriptions are specified in this document such that RTP
   endpoints that are compliant with the RTP specification [RFC3550]
   will be able to decode the media streams they describe whether or not
   they support explicit source descriptions.  However, some deployed
   RTP implementations may not actually support multiple media sources
   in a media stream.  Media senders MAY wish to restrict themselves to
   a single source at a time unless they have some means of concluding
   that the receivers of the media stream support source multiplexing.

[BA]  The obvious way for an answerer to indicate support for RFC 5576 would be to include a=ssrc lines in the answer.   If the Answer doesn't include a=ssrc lines, should the Offerer conclude that only one source can be sent?   The above paragraph indicates this is optional.