Subject: Re: [MMUSIC] RFC 5576 is da answah

From: Bernard Aboba <[email-masked]>
Date: Tue, 20 Nov 2012 16:50:36 -0800

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.

---

From: Jonathan Lennox <[email-masked]>
Date: Wed, 21 Nov 2012 11:50:15 -0500

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

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.

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.

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.

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
[email-masked]<mailto:[email-masked]>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 21 Nov 2012 12:13:47 -0500

On 11/21/12 11:50 AM, Jonathan Lennox wrote:

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

It doesn't help me very much to know you are "prepared to receive" a 
bunch of media streams unless there is also a way to negotiate what they 
are for. You may be prepared to receive streams for purposes 
incompatible with the streams I am prepared to transmit.

Using a=ssrc it is possible to negotiate things about each stream. For 
those that aren't negotiated that way, ISTM that there must be some 
other mechanism for negotiating semantics. This could be SDP signaling 
that indicated "all otherwise unspecified streams are ...", or the 
semantics could be conveyed via some other protocol (e.g. CLUE) or by 
prior agreement.

	Thanks,
	Paul

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 21 Nov 2012 19:30:03 -0800

> semantics could be conveyed via some other protocol (e.g. CLUE) or by 

[BA] If I read draft-lennox-mmusic-sdp-source-selection correctly, it is possible to describe aspects of what the answerer is "prepared to receive" but not details of what the Offerer is capable of sending.  For example, Section 4, includes the following offer/answer:
       Offer
   m=video 49168 RTP/AVP 96
   a=rtpmap:96 H264/90000
   a=ssrc:12345 cname:[email-masked]
   a=ssrc:67890 cname:[email-masked]

   Answer
   m=video 49170 RTP/AVP 96
   a=rtpmap:96 H264/90000
   a=remote-ssrc:12345 recv:on
   a=remote-ssrc:12345 imageattr:* [x=720,y=576]
   a=remote-ssrc:12345 framerate:15

While the above exchange might work for a very basic scenario, it doesn't seem capable of handling more complex cases. In the above Offer/Answer exchange, the Answerer doesn't know what resolutions or framerates are supported by the Offerer.  For example, the Offerer might be capable of encoding 16:9 or 9:16 aspect ratios at 15, 30 or 64 frames/second:
16:9:  1280x720, 960x540, 848x480,  640x360,  480x270, 424x240, 320x180	  9:16: 720x1280,  540x960, 480x848,  360x640, 270x480, 240x424, 180x320
Yet in the above exchange, the Answerer asks for 720 by 576, leaving the Offer to guess what supported resolution is "closest". 
Also, in the Offer, there is no indication of what the purpose of ssrc 67890 is.  For example, this could be for slides, and by rejecting it, the Answerer will not be able to usefully participate in the conference.  So a content: attribute could come in handy.  
IMHO, it became clear to me at IETF 85 that we are indeed straddling a steadily widening canyon as Harald has said, though I see the two cliffs being CLUE on one side and RFC 5576 on the other. If RFC 5576 is to be "the answah", then MMUSIC needs to fill in the details of how the SDP negotiation works. Alternatively, if the negotiation is to occur outside SDP (as advocated in CLUE), then we need an explicit statement of where the boundaries lie.  The middle path (pursuing neither with conviction) doesn't seem viable to me.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 22 Nov 2012 09:31:31 +0000

Hi,

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

In CLUE we have a requirement to be able to communicate with "non-CLUE" and "single stream" devices, so also there we may have to deal with the case where an endpoint doesn't support CLUE and/or RFC 5576.

Also keep in mind that, eventhough max-ssrc allows you to specify the number of streams, it is currently not a mechanism to indicate WHICH streams are accepted/rejected.

Regards,

Christer

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 22 Nov 2012 13:41:25 +0100

On 11/22/2012 04:30 AM, Bernard Aboba wrote:
> [BA] If I read draft-lennox-mmusic-sdp-source-selection correctly, it 
> is possible to describe aspects of what the answerer is "prepared to 
> receive" but not details of what the Offerer is capable of sending. 
>  For example, Section 4, includes the following offer/answer:
>
>      Offer
>
>     m=video 49168 RTP/AVP 96
>     a=rtpmap:96 H264/90000
> While the above exchange might work for a very basic scenario, it 
> doesn't seem capable of handling more complex cases. In the above 
> Offer/Answer exchange, the Answerer doesn't know what resolutions or 
> framerates are supported by the Offerer.  For example, the Offerer 
> might be capable of encoding 16:9 or 9:16 aspect ratios at 15, 30 or 
> 64 frames/second:
>
> 16:9:  1280x720, 960x540, 848x480,  640x360,  480x270, 424x240, 320x180
> 9:16: 720x1280,  540x960, 480x848,  360x640, 270x480, 240x424, 180x320
>
> Yet in the above exchange, the Answerer asks for 720 by 576, leaving 
> the Offer to guess what supported resolution is "closest".
That's a misreading of RRC 6236. The answer asks for *exactly* 720 by 
576. The offerer has to either send in that resolution or renegotiate.
If a range was acceptable, the answerer should have indicated that 
([x=700:800,y=500:600]).
>
> Also, in the Offer, there is no indication of what the purpose of ssrc 
> 67890 is.  For example, this could be for slides, and by rejecting it, 
> the Answerer will not be able to usefully participate in the 
> conference.  So a content: attribute could come in handy.
>
> IMHO, it became clear to me at IETF 85 that we are indeed straddling a 
> steadily widening canyon as Harald has said, though I see the two 
> cliffs being CLUE on one side and RFC 5576 on the other.
Are you seeing the canyon as being in-SDP signalling vs out-of-SDP 
signalling?
If CLUE goes with multiple streams per m-line, and in-SDP signalling, it 
needs RFC 5576.
If out-of-band signalling needs to refer to SSRCs, we need unique 
identifiers (SRCNAME or MSID) that out-of-band signalling can use to 
refer to the flows. Those will likely use RFC 5576 too.

> If RFC 5576 is to be "the answah", then MMUSIC needs to fill in the 
> details of how the SDP negotiation works. Alternatively, if the 
> negotiation is to occur outside SDP (as advocated in CLUE), then we 
> need an explicit statement of where the boundaries lie.  The middle 
> path (pursuing neither with conviction) doesn't seem viable to me.
Our ability to converge on a boundary definition with conviction seems 
limited. So since we're presently implementing, it seems that our 
options are limited to what can be achieved without such convergence.
>
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 22 Nov 2012 19:49:51 +0000

Hi,

> Are you seeing the canyon as being in-SDP signalling vs out-of-SDP signalling?
> If CLUE goes with multiple streams per m-line, and in-SDP signalling, it needs RFC 5576.
> If out-of-band signalling needs to refer to SSRCs, we need unique identifiers (SRCNAME or MSID) that out-of-band 
> signalling can use to refer to the flows. Those will likely use RFC 5576 too.
>
> If RFC 5576 is to be "the answah", then MMUSIC needs to fill in the details of how the SDP negotiation works. 

Agree. The same issues apply for both CLUE and RTCWEB, so it needs to be described on a general level.

> Alternatively, if the negotiation is to occur outside SDP (as advocated in CLUE), then we need an explicit statement of where 
> the boundaries lie.  The middle path (pursuing neither with conviction) doesn't seem viable to me. 

CLUE has not yet decided what goes in SDP, and what goes into the CLUE channel.

My suggestion has been that "CLUE application specific data" (e.g. spatial relationship information) goes into the CLUE channel, while "transport data" (especially data which might be needed by intermediaries etc) goes into SDP. 

Now, there ARE some gray areas, where it can be discussed whether specific data is "CLUE app" or "transport". BUT, I would be concerned about CLUE putting data in the CLUE channel as a workaround, simply because it doesn't "fit" into SDP - even if the data as such would belong SDP.

Regards,

Christer

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 22 Nov 2012 14:17:18 -0800

Christer said:

"My suggestion has been that "CLUE application specific data" (e.g. spatial relationship information) goes into the CLUE channel, while "transport data" (especially data which might be needed by intermediaries etc) goes into SDP. "

[BA]  That seems like a reasonable guideline to me.  Looking at draft-ietf-clue-framework Section 6.1.1, many of the attributes other than the "spatial relationship" ones (such as Point of Capture, Line of Capture and Area of Capture) do seem like they can be handled in SDP.  For example,  the max-send-ssrc:  and max-recv-ssrc: parameters defined in draft-westerlund-mmusic-max-ssrc seem to communicate similar information to Max Capture Encodings, and Encoding Group might be taken care of via the a=ssrc-group construct in RFC 5576.   Height, Width and Framerate also can be handled in SDP (though IMHO the negotiation mechanism in draft-lennox-mmusic-sdp-source-selection needs work). 

    [Harald]  The answer asks for *exactly* 720
    by 576. The offerer has to either send in that resolution or
    renegotiate.

[BA] Yes, but it seems clumsy for the receiver to indicate its preferences without information on what the sender supports.  In draft-lennox-mmusic-sdp-source-selection, imageattr information only seems to be supported in the answer, whereas in RFC 6236, the Offer may include both send and receive information as described in Section 6.1:
a=imageattr:PT send attr-list recv attr-listIncluding both send and receive information in the Offer seems more likely to enable the negotiation to conclude in a single Offer/Answer exchange.
For example, the Offer can describe what can be sent by including an a=max-send-ssrc: line as well as information on the individual a=ssrc: lines (e.g.,  imageattr:, framerate:, content:).  In addition, the Offer can communicate about what can be received via an a=max-recv-ssrc: line (and perhaps a=remote-ssrc: lines with some imageattr: and framerate: suggestions).  Then the Answer can include a=remote-ssrc lines corresponding to  the sources described in the Offer, as well as a=ssrc: lines describing what the Offer can send (which should be compatible with the receive information in the Offer).  This may allow the negotiation to be concluded in a single Offer/Answer exchange.  

[Harald]  If CLUE goes with multiple streams per m-line, and in-SDP
    signalling, it needs RFC 5576. If out-of-band signalling needs to refer to SSRCs, we need unique
    identifiers (SRCNAME or MSID) that out-of-band signalling can use to
    refer to the flows. Those will likely use RFC 5576 too.

[BA] Christer has suggested that CLUE out-of-band signalling should only be required to communicate parameters (such as spatial relationships) that are unique to CLUE.   This seems reasonable to me, but today there is considerable overlap in the parameters described in 
draft-ietf-clue-framework and SDP documents such as RFC 5576, 6236, 
draft-lennox-mmusic-sdp-source-selection and 
draft-westerlund-mmusic-max-ssrc.  

      
         If RFC 5576 is to be "the answah", then MMUSIC needs
            to fill in the details of how the SDP negotiation works.
            Alternatively, if the negotiation is to occur outside SDP
            (as advocated in CLUE), then we need an explicit statement
            of where the boundaries lie.  The middle path (pursuing
            neither with conviction) doesn't seem viable to me. 

    [Harald] Our ability to converge on a boundary definition with conviction
    seems limited. So since we're presently implementing, it seems that
    our options are limited to what can be achieved without such
    convergence.

[BA] We can at least describe how the source negotiation is supposed to work in the absence of CLUE.  That exercise would help in understand the limits of what can be accomplished in a single O/A exchange.

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 26 Nov 2012 08:44:21 +0100

On 11/22/2012 11:17 PM, Bernard Aboba wrote:
> Christer said:
>
> "My suggestion has been that "CLUE application specific data" (e.g. 
> spatial relationship information) goes into the CLUE channel, while 
> "transport data" (especially data which might be needed by 
> intermediaries etc) goes into SDP. "
>
> [BA]  That seems like a reasonable guideline to me.  Looking at 
> draft-ietf-clue-framework Section 6.1.1, many of the attributes other 
> than the "spatial relationship" ones (such as Point of Capture, Line 
> of Capture and Area of Capture) do seem like they can be handled in 
> SDP.  For example,  the max-send-ssrc:  and max-recv-ssrc: parameters 
> defined in draft-westerlund-mmusic-max-ssrc seem to communicate 
> similar information to Max Capture Encodings, and Encoding Group might 
> be taken care of via the a=ssrc-group construct in RFC 5576. Height, 
> Width and Framerate also can be handled in SDP (though IMHO the 
> negotiation mechanism in draft-lennox-mmusic-sdp-source-selection 
> needs work).
>
> [Harald]  The answer asks for *exactly* 720 by 576. The offerer has to 
> either send in that resolution or renegotiate.
> [BA] Yes, but it seems clumsy for the receiver to indicate its 
> preferences without information on what the sender supports. In 
> draft-lennox-mmusic-sdp-source-selection, imageattr information only 
> seems to be supported in the answer, whereas in RFC 6236, the Offer 
> may include both send and receive information as described in Section 6.1:
> a=imageattr:PT send attr-list recv attr-list
> Including both send and receive information in the Offer seems more 
> likely to enable the negotiation to conclude in a single Offer/Answer 
> exchange.

So are you arguing that draft-lennox should specify "imageattr" with the 
"a=ssrc" construct as well as with the "a=remote-ssrc" construct? I 
could support that.

Sender's generic support can be indicated using 6236, but the sender 
might want to specify it per stream too.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 26 Nov 2012 00:02:50 -0800

Harald said:

    "So are you arguing that draft-lennox should specify "imageattr" with
    the "a=ssrc" construct as well as with the "a=remote-ssrc"
    construct? I could support that.

    Sender's generic support can be indicated using 6236, but the sender
    might want to specify it per stream too."

[BA] Yes.  There are situations in which per-stream information would be useful (e.g. if the cameras do not have the same capabilities).  Including a=ssrc and a=remote-ssrc in both the Offer and the Answer, along with parameters from RFC 6236, it seems to me that it would be possible to negotiate per-stream parameters in a single O/A exchange in many situations.