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

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

> >
> > 1) the same transport address being indicated in otherwise
explicitly
> >     grouped media session (grouped using some fid + whathaveyou
> >     attribute)
> >
> > 2) the same port number being used to infer grouping.
> >
> > One reason for confusion appears to be one example in RFC 4585
> > from which I would not want to try and infer 1) but some people
might
> > be able to even though it states that you should do explicit
grouping
> > (but cannot list it in the example as the respective attribute does
> > not yet exist).
> >
    RFC4585 did list 1) as a sample option. 
     "A sample framework by which this can be achieved is defined in
[10]."

> > And we have RFC 4566 which states that two m= lines with the same
> > transport address do not imply grouping and that their semantics is
> > undefined -- obviously until you define something meaningful.

RFC 4566 did list 1) as an option (Of course, not normative)

"an explicit grouping framework (for example, [18]) should instead
 be used to express the intended semantics."

> But unless the endpoint understands the grouping syntax and
> semantics, the new syntax and semantics are invisible to such
> an endpoint.  I mean, that is the problem with RFC3388 -- if
> you send RFC3388 SDP to an endpoint that doesn't understand
> RFC3388 it will parse the SDP following normal SDP rules
> which say each m= line is a separate RTP session.
> 

This is a fundamental problem with FID semantics defined in RFC3388 and
sec 8.4.2 describes how to address this issue.

Sec 8.4.2 of RFC3388 suggests that the offer re-try without "group".
That may not look good, but is not too bad either. Those end points
which crash when they look at transport overloaded "m=" lines are
anyways faulty s/w implementations and it is unlikely that majority of
deployed s/w is unstable to such an extent. And with the (majority of
good) end points that do not crash, it is possible to continue the
session.
 
In any case, not supporting the fallback approach suggested by RFC3388
is risky.

> -d
>