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

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

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