Re: [MMUSIC] RFC 5576 is da answah

[Bernard Aboba <[e-mail]>]

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