Re: [MMUSIC] RFC 5576 is da answah

[Jonathan Lennox <[e-mail]>]

On Nov 20, 2012, at 7:50 PM, Bernard Aboba wrote:

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

Hi, Bernard --

Yes, RFC 5576 wasn't a complete solution for interactive scenarios; it left some pieces open that needed additional standardization work.  Essentially, 5576 the declarative part, but not the negotiation part.

I followed it up with draft-lennox-mmusic-sdp-source-selection (still alive, though quiescent) and draft-lennox-mmusic-sdp-max-sources (expired, but more or less the same thing as draft-westerlund-mmusic-max-ssrc) which I think should cover all the issues you raise.

At the time (the IETF Stockholm meeting in 2009) these drafts didn't get much interest, because the benefits of source multiplexing weren't commonly understood yet.  I'm glad that's now changed.


>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.

Yes, you'd need a way to explain what you're prepared to receive; max-ssrc could handle this.

Generally, if you're speaking to a legacy SIP endpoint, the only safe thing to assume in the absence of ssrc or max-ssrc attributes is one source per session; but since this actively contradicts the RTP spec, that couldn't exactly be made normative.


>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.

The reason this is phrased as "no mechanism is provided" was to leave open the possibility of defining such a mechanism in the future, not to preclude the possibility of there ever being such a mechanism.  My source-selection draft would be one such mechanism; CLUE would be another.


>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.

It's perfectly reasonable to support receiving multiple sources, but not have any sources you're interested in sending at the moment.  This problem is what max-ssrc is for.

--
Jonathan Lennox
[e-mail]<mailto:[e-mail]>