Re: [MMUSIC] M-line philosophy (Re: Wisdom sought: Prioritization of codecs)

[Harald Alvestrand <[e-mail]>]

On 11/19/2012 04:38 PM, Adam Roach wrote:
> On 11/18/12 23:12, Harald Alvestrand wrote:
>>
>> The M-line is problematic because it binds together multiple things:
>>
>> - A top level media type
>> - A set of parameters for media transmission *in all directions* 
>> (bound to payload type)
>> - Transport information (the "RTP session" data)
>>
>>
>> SDP M-lines are already problematic as soon as you want different 
>> parameters in the two directions. It only goes downhill from there 
>> when one does multiple flows with varying characteristics.
>>
>> As I said in Atlanta: SDP M-lines have been walking with one foot on 
>> the "I'm an RTP session" bank of the canal and with the other foot on 
>> the "I'm a media stream description" bank of the canal.
>
> I agree with your characterization of the situation. I'm a little 
> surprised that it doesn't lead you to the same conclusion as I've 
> reached.
>
> There are, at the moment, 176 attributes in the IANA registry that are 
> applicable to m= sections:
>
> 3GPP-Adaptation-Support 3GPP-Asset-Information 3GPP-QoE-Metrics
> 3GPP-SRTP-Config 3gpp-videopostdecbufsize FEC FEC-OTI-extension
> FEC-declaration SRTPAuthentication SRTPROCTxRate T38FaxFillBitRemoval
> T38FaxMaxBuffer T38FaxMaxDatagram T38FaxRateManagement
> T38FaxTranscodingJBIG T38FaxTranscodingMMR T38FaxUdpEC T38FaxVersion
> T38MaxBitRate T38VendorInfo X-decbyterate X-initpostdecbufperiod
> X-initpredecbufperiod X-predecbufsize aal2CPS aal2CPSSDUrate
> aal2sscs3661assured aal2sscs3661unassured aal2sscs3662 aal5sscop
> aalApp aalType abrParms abrSetup acap accept-types accept-wrapped-types
> acfg alt alt-default-id anycast atmQOSparms atmTrfcDesc atmmap bcob
> bearerSigIE bearerType cache candidate capability cbrRate cdsc
> cfw-id chain channel clkrec cmid codecconfig conf confid connection
> content-desc cpar cparmax cparmin cpsSDUsize creq crypto csup curr
> dccp-port dccp-service-code depend des dsel ecan ecn-capable-rtp
> eecid extmap fec fec-repair-flow fec-source-flow file-date
> file-disposition file-icon file-range file-selector file-transfer-id
> fingerprint floorctrl floorid flute-ch flute-tsi fmtp framerate
> framesize fsel g.3gpp.cat g.3gpp.crs gc h248item ice-mismatch ice-pwd
> ice-ufrag ike-setup imageattr inactive isup_usi key-mgmt label lang
> lij max-size maxprate maxptime mbms-flowid mbms-mode mbms-repair
> mid msrp-cema multicast-rtcp omr-codecs omr-m-att omr-m-bw omr-m-cksum
> omr-s-att omr-s-bw omr-s-cksum onewaySel orient path pcfg portmapping-req
> profileDesc prtfl psk-fingerprint ptime qos-mech-recv qos-mech-send
> qosClass quality rams-updates recvonly remote-candidates repair-window
> resource rtcp rtcp-fb rtcp-mux rtcp-rsize rtcp-unicast rtcp-xr
> rtpmap rtpred1 rtpred2 sbc sdplang secondary-realm sendonly sendrecv
> setup silenceSupp source-filter sqn ssrc ssrc-group stc stkmstream
> structure tcap uiLayer1_Prot upcc userid visited-realm vsel zrtp-hash
>
> Some of these are applicable to the RTP session; others only make 
> sense as applied to a single media stream.
And some make absolutely no sense at all in the RTCWEB context. Just for 
grins, let's take every single attribute defined for ATM bearer 
connection attributes and just remove them from discussion. Up to 35 
attributes down at a single blow.

I have at one point in my life dealt with T-series fax (RFC 2159 is long 
forgotten, I am happy to say). 'Nuff said.

And those were just the 2 first ones I looked at.
>
> If we choose to make each m= section represent one media stream, then 
> these attributes are applicable as-is. We get to take advantage of the 
> work put in place by the 50 to 60 documents that defined the 
> corresponding mechanisms with no changes whatsoever to this existing 
> corpus of work.
Except that, for instance, ice-pwd becomes ambiguous, and has to be 
dealt with using a bundle mechanism.

>
> If we choose to make each m= section represent one RTP session, in 
> which multiple media streams can be placed, then the use of any of 
> those 176 attributes that are to be applied on the stream level 
> becomes ambiguous. If we want to take advantage of them for RTCWEB (or 
> anything else that leverages the work of untangling this mess), then 
> we have to come up with an alternate, non-backwards-compatible syntax 
> for conveying each of those attributes (cf. 
> draft-lennox-mmusic-sdp-source-selection).
>
> And that's *just* the issues associated with attributes -- the problem 
> is even worse once you consider the more subtle (and difficult to 
> predict) damage to established mechanisms, like your codec priority 
> conundrum.
That was an easy one.