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

[Adam Roach <[e-mail]>]

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.

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.

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.

/a