RE: alternate RTP profiles in SDP offer/answer

["Desineni, Harikishan" <hdesinen@xxxxxxxxxxxx>]

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

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

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

> 
> -d
> 
> 
> > --->
> >   m=video 51372 RTP/AVP 98 99
> >       c=IN IP4 224.2.1.184
> >       a=rtpmap:98 H263-1998/90000
> >       a=rtpmap:99 H261/90000
> >       m=video 51372 RTP/AVPF 98 99
> >       c=IN IP4 224.2.1.184
> >       a=rtpmap:98 H263-1998/90000
> >       a=rtpmap:99 H261/90000
> >       a=rtcp-fb:* nack
> >       a=rtcp-fb:98 nack rpsi
> > Note that these two m= lines SHOULD be grouped by some appropriate
> >    mechanism to indicate that both are alternatives actually
conveying
> >    the same contents.  A sample framework by which this can be
> >    achieved is defined in [10].
> >
> >