Re: [MMUSIC] RFC 5576 is da answah

[Harald Alvestrand <[e-mail]>]

On 11/22/2012 04:30 AM, Bernard Aboba wrote:
> Paul Kyzivat said:
>
> > 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.
>
> [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:[e-mail]
>     a=ssrc:67890 cname:[e-mail]
>
>     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".
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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic