RE: [MMUSIC] RE: alternate RTP profiles in SDP offer/answer

["Dan Wing" <dwing@xxxxxxxxx>]

> > What I am worried about is RFCs allowing port overloading, 
> > and others saying it's illegal.
> 
> Please distinguish between:
> 
> 1) the same transport address being indicated in otherwise explicitly
>     grouped media session (grouped using some fid + whathaveyou
>     attribute)
> 
> 2) the same port number being used to infer grouping.
> 
> These two things are fundamentally different.  What I am 
> saying is that
> there are legitimate use cases for 1) while all of us agree that we do
> not want 2).
> 
> One reason for confusion appears to be one example in RFC 4585
> from which I would not want to try and infer 1) but some people might
> be able to even though it states that you should do explicit grouping
> (but cannot list it in the example as the respective attribute does
> not yet exist).
> 
> The other reason for confusion is RFC 3388 which wants to 
> prevent people
> from using multiple m= lines to specify alternate codecs but phrases
> this in a way that you could construe as "do not use the same 
> transport
> address for two m= lines".
> 
> And we have RFC 4566 which states that two m= lines with the same
> transport address do not imply grouping and that their semantics is
> undefined -- obviously until you define something meaningful.
> 
> This is where I think we are.  All we need to do is to define a
> proper grouping.

I agree that would be the cleanest, architecturally.

But unless the endpoint understands the grouping syntax and 
semantics, the new syntax and semantics are invisible to such
an endpoint.  I mean, that is the problem with RFC3388 -- if
you send RFC3388 SDP to an endpoint that doesn't understand
RFC3388 it will parse the SDP following normal SDP rules
which say each m= line is a separate RTP session.

-d