RE: alternate RTP profiles in SDP offer/answer

["Dan Wing" <dwing@xxxxxxxxx>]

> > > RFC4585, Section 4.4, Example 3 allows grouping of media
> > > lines with the same transport address and port. I copied
> > > it below FYI.  Even though RFC 3388 prohibits such
> > > transport overloading, RFC 4585 allows such signaling for
> > > profile negotiation (between RTP/AVP and RTP/AVPF).
> > 
> > Are we going to declare RFC4585's example normative?
> 
> It is already of "SHOULD" strength, which is quite strong.

But using the same IP address/port violates two MUST NOTs in RFC3388:

   If several codecs have to be sent to the same IP address and port,
   the traditional SDP syntax of listing several codecs in the same "m"
   line MUST be used.  FID MUST NOT be used to group "m" lines with the
   same IP address/port.  Therefore, an SDP like the one below MUST NOT
   be generated.

Also, RFC4585's reference to RFC3388 is informational, not normative.  So
RFC4585 can't be trying to override RFC3388's section which prohibits this.

> > > Indeed, RFC4585 is referring to RFC 3388 for such grouping.
> > > Per RFC4585,
> > > overloading two "m=" lines isn't a violation of the standard when
> > > negotiating RTP/AVP and RTP/AVPF profiles.
> > 
> > Unfortunately, though, SDP parsers that don't implement
> > RFC4585 aren't aware of RFC4585's permission to do this.
> 
> A reasonably good SDP parser which understands grouping (RFC3388) and
> FID semantics would reject a grouped "m=" line offered with 
> unknown RTP profile. 

RFC3388 is very clear in its prohibition of m= lines with matching 
IP address/port.  It's unclear, from RFC3388, what an SDP parser
is supposed to do if receives SDP described in section 7.5.3 of 
RFC3388 -- no matter if it understands the RTP profile.

Worse, an SDP parser that doesn't understand RFC3388 is left to
its own devices as to the meaning of two m= lines with the same
IP address and port -- it's undefined.  

> > > It is an already established
> > > concept in RFC4585. Probably there are existing implementations
> > > which
> > > already support such signaling. Any new signaling 
> > > solution can only be
> > > an alternative to the solution used in the following example.
> > 
> > Is there consensus in MMUSIC with that position?
> 
> I expect that it would be the case, given that the signaling described
> in RFC4585 is of "SHOULD" strength. IMHO, new/better signaling from
> MMUSIC can only be an alternative to RFC4585 example that was pointed
> out.

I expect this will be an active discussion at the upcoming MMUSIC
session in San Diego.

-d