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

["Dan Wing" <dwing@xxxxxxxxx>]

> > However, let's assume, for a minute, that HERFP is solved.  If my
> > endpoint supports supports RTP, SRTP, feedback, and running RTP over
> > DCCP or over UDP, I would need to send an SDP that contains 
> > 8 m-lines (RTP/AVP, RTP/AVPF, RTP/SAVP, RTP/SAVPF, DCCP/RTP/AVP, 
> > DCCP/RTP/SAVP, DCCP/RTP/AVPF, DCCP/RTP/SAVPF), and each m-line 
> > would have duplicated ICE attributes for all of the UDP 
> > transports and all of the m-lines would have duplicated 
> > codec attributes.  This makes for a _very_ long SDP, and 
> > requires anyone receiving it to understand port overloading.
> 
> Agreed
> 
> From standards perspective, we have to keep the port 
> overloading a valid concept when an end point supports 
> only AVP and AVPF (due to RFCs 4585 and 4566). 

But the standards contradict each other, and do not support port overloading
as a valid concept.  

Specifically, RFC4566 (SDPnew) says:

  The semantics of multiple "m=" lines using the same transport
  address are undefined.  This implies that, unlike limited past
  practice, there is no implicit grouping defined by such means and
  an explicit grouping framework (for example, [18]) should instead
  be used to express the intended semantics.

[18] is RFC3388 (grouping).  As we have discussed, RFC3388 explicitly
disallows using the same port on multiple media lines, and RFC3388 does not
contain an exception to that rule for different RTP profiles.

It may have been the intent of RFC4566 to allow port overloading with
grouping by non-normatively citing grouping, but there is no mistaking
section 7.5.3 of RFC3388 which clearly says this is illegal.

> This does not mean that alternate signaling (Flemming's draft)
> cannot be used for the same purpose.  IMO, Felmming's draft should
> put more details on port overloading when an end point supports only
> AVP and AVPF. It might be acceptable if the draft recommends that
> grouping be not used when the proposed (compact) signaling is
> available.  This would result in less (or NO) confusion from a set
> of existing standard documents (RFCs:3388,4566,4585 and RFC No for
> Flemming's draft).

-d