Re: [rtcweb] Plan A, respun

["Roni Even" <[e-mail]>]

I think I agree with Bernard. The limitation mentioned in the second
paragraph of the introduction is not in SDP. The limitation described can be
concluded from RFC3264 but even there people are still arguing  that when
looking at the following offer

 

m=video 10000 RTP/AVP 31 32

a=rtpmap:31 H261/90000

a=rtpmap:32 MPV/90000

 

What does it mean one RTP session is offered with H.261 or MPV codecs for
the same content, or one RTP session is offered with H.261 and MPV codecs
each with different content?

This offer should really mean "arbitrarily many streams, with potentially
different content, any of which could use either H.261 or MPV, potentially
switching dynamically between them."

 

I agree that some implementations take this offer as a single RTP stream
that can be either H.261 or MPV. I think that the maxssrc proposal tries to
make it clearer.

 

Roni

 

 

From: [e-mail] [mailto:[e-mail]] On Behalf Of
Bernard Aboba
Sent: 08 May, 2013 12:45 AM
To: Adam Roach
Cc: [e-mail]
Subject: Re: [rtcweb] Plan A, respun

 

Adam Roach said:

> Specifically, we are *not* trying to allow the situation in which (1)
> the SDP has no SSRC for the m-lines in a bundle group; (2) the party who
> generated the SDP receives multiple streams (distinguished, presumably,
> by SSRC) with the same PT, and (3) the recipient then deduces that there
> should be two different rendering outputs (e.g., windows) as a result.
> That is specifically and intentionally one of the behaviors we removed
> from the Orlando proposal, since it severely dilutes the value of
> preserving existing SDP semantics.

The "existing SDP semantics" have allowed multiplexing of RTP streams from
multiple SSRCs on the 
same RTP session without explicit declaration since multicast days -- and
this behavior is implemented within a number of shipping video
implementations.  In fact, dealing with this is proposed as a MUST within
the RTP Usage document. 

If an event is triggered for a newly encountered (but undeclared) SSRC, this
can be handled by the web application which can take care of making sure
that new RTP stream is appropriately rendered.  Applications (including open
source ones, such as Jitsi) do this today.