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

[Harald Alvestrand <[e-mail]>]

On 11/20/2012 08:12 PM, Bernard Aboba wrote:
> > 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):

agreed. What I find more problematic / irritating is that with 
parameters that apply to both directions of a sendrecv stream, there's 
no way to specify one set that applies A->B and another set that 
applies  B->A.
With sendonly / recvonly streams, this is not an issue; with parameters 
that apply only in one direction (such as crypto keys), it is also not 
an issue. But for some parameters, it is an issue.

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