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

[Flemming Andreasen <[e-mail]>]

On 11/19/12 10:38 AM, 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.
>
> If we choose to make each m= section represent one media stream, then 
> these attributes are applicable as-is.
Unfortunately not; some of them are, some of them are not (typically 
because they are attributes related to the "stream" part more than the 
"media format" part). SDES and ICE are examples that require some form 
of selection.

There was an off-line discussion between a few folks in Atlanta about 
taking a look at every single SDP attribute defined today (and the other 
SDP parameters) and determine for each if it would work "as-is" in a 
bundle scenario or whether it would require some sort of special 
treatment and what that would be (e.g "aggregation" or "pick-one"). I'm 
not sure that work has been started yet, but it's probably a good way of 
making progress on this part of the discussion.

Thanks

-- Flemming