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

[Bernard Aboba <[e-mail]>]

> The M-line is problematic because it binds together multiple things:
> 
> - A set of parameters for media transmission *in all directions* (bound to payload type)

[BA] RFC 3264 Section 5.1 makes it clear that the parameters need not apply in all directions (though sendrecv is the default): 

   The list of media formats for each media stream conveys two pieces of
   information, namely the set of formats (codecs and any parameters
   associated with the codec, in the case of RTP) that the offerer is
   capable of sending and/or receiving (depending on the direction
   attributes), and, in the case of RTP, the RTP payload type numbers
   used to identify those formats.  If multiple formats are listed, it
   means that the offerer is capable of making use of any of those
   formats during the session.  In other words, the answerer MAY change
   formats in the middle of the session, making use of any of the
   formats listed, without sending a new offer.  For a sendonly stream,
   the offer SHOULD indicate those formats the offerer is willing to
   send for this stream.  For a recvonly stream, the offer SHOULD
   indicate those formats the offerer is willing to receive for this
   stream.  For a sendrecv stream, the offer SHOULD indicate those
   codecs that the offerer is willing to send and receive with.