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

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

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

Interpretation: In the absence of grouping, transport overloading does
not signal implicit grouping and the semantics are undefined. Explicit
grouping is allowed however semantics need to be expressed.

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

RFC 3388 is based on an obsoleted (very old)SDP RFC 2327. Its semantics
on transport overloading contradict with the latest SDP RFC 4566 (SDP
new), which allows transport overloading.

>From RFC4585 (RTPAVPF profile)

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

[10] is RFC3388. Based on the RFC4566 (SDP new) non-normative citing
which allows transport overloading with explicit grouping, RFC4585
suggested such usage with clear semantics "to indicate that both are
alternatives actually conveying the same contents". Hence, RFC4585 is
properly following RFC4566 by defining the semantics for explicit
grouping. It makes sense why explicit grouping is of "SHOULD" strength
here.

RFC3388 has defined its own grouping semantics (disallowing transport
overloading) when multiple codecs are targeted to one port. Of course,
it also denied transport overloading in general(probably unwantedly, as
it does not know about RFC4566-SDP new). RFC3388 and its explcit
grouping semantics are not correct with respect to latest SDP RFC 4566.
RFC3388 is correct only with respect to obsolted SDP RFC2327.

To conclude, 

RFC4585 is not the culprit as it is compliant with what was stated in
SDP new (RFC4566).

The root cause for this confusion is RFC3388, which is based on an
obsolted SDP RFC 2327. 

RFC3388 is contradicting with RFC4566 (SDP new). This is due to
advancement of SDP after the publication of RFC3388.

Also, RFC3388 is correct with respect to its normative and informative
references.

Given the above, any argument based on RFC3388 does not hold strong
here.

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