Re: [MMUSIC] RFC 5576 is da answah

[Bernard Aboba <[e-mail]>]

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.

    If a range was acceptable, the answerer should have indicated that
    ([x=700:800,y=500:600]).

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