RE: alternate RTP profiles in SDP offer/answer

["Dan Wing" <dwing@xxxxxxxxx>]

(removed most of the CC list, as MMUSIC's mailman configuration was
complaining about too many recipients.)

...
> However, we are discussing a slightly different SDP offer 
> where the two "m=" lines differ in RTP profiles, which is 
> clearly not in the scope if RFC3388 as such SDP offer 
> was probably not a possibility at the time of its writing. 

RTP/SAVP existed at the time RFC3388 was written.  

draft-ietf-avt-srtp-00, which defined RTP/SAVP, was a WG 
document in February 2001.  draft-ietf-mmusic-fid-06, which
is the last document prior to RFC, was published in February
2002 -- a year after SAVP was an AVT working group item.

But I doubt the problems of multiple RTP profiles signaled 
in offer/answer were well understood at the time RFC3388
was written.  Was was understood, when RFC3388 was written,
was that a non-RFC3388-aware SDP parser would have unknown
behavior if it received two "m=" lines with the same IP
address and port -- that's why RFC3388 prohibited it.

In any event, section 7.5.3 of RFC3388 doesn't provide an 
escape clause allowing grouping different RTP profiles with 
the same port number.

> RFC4585 went ahead and suggested a potential solution based
> on the grouping concept presented in RFC3388.
>
> I am not against better signaling applicable to all RTP profiles. I'd
> like to emphasize that RFC4585 has already published a suggested
> solution with (IP address, port) overloading with the help of few
> examples, which are unarguably valid when signaling a stream with both
> AVP and AVPF profiles.

I don't agree, but that's fine.

Do we agree with the disadvantages of grouping as described
in Flemming's 
draft-andreasen-mmusic-sdp-capability-negotiation-01.txt section 3.1?

-d