[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: alternate RTP profiles in SDP offer/answer
(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
draft-andreasen-mmusic-sdp-capability-negotiation-01.txt section 3.1?