Subject: [rtcweb] Plan A, respun

From: Adam Roach <[email-masked]>
Date: Tue, 07 May 2013 13:30:30 -0500

In order to facilitate discussion between the two SDP format 
alternatives we're considering, I've put together a document that more 
clearly spells out the Plan A approach as we originally envisioned it. 
Note that this is a slightly different approach than Cullen outlined in 
Orlando. I fear the Orlando approach may have suffered from its attempts 
to incorporate some elements of Plan B in an attempt to appease 
proponents of that approach; and, in doing so, lost some of its clean 
architecture.

The cleaned up, new-and-improved description of the Plan A approach is 
available here:

http://www.ietf.org/id/draft-roach-rtcweb-plan-a-00.txt

Note that we've omitted discussion of glare reduction from that 
document, as I believe that mid-session glare can be completely avoided 
by applications implementing a set of non-normative behaviors. These 
behaviors are described in the a separate companion document:

http://www.ietf.org/id/draft-roach-rtcweb-glareless-add-00.txt

Thanks.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 07 May 2013 15:29:02 -0400

Adam,

I want to check on something:

If I bundle an m-line without a=ssrc, and with unique PTs, do you 
consider it ok if there are multiple "anonymous" flows each complying to 
the attributes of the m-line? Or do you assume that all packets with 
that PT are treated as one flow, switching from one SSRC to another as 
they are received?

	Thanks,
	Paul

On 5/7/13 2:30 PM, Adam Roach wrote:
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Adam Roach <[email-masked]>
Date: Tue, 07 May 2013 15:00:49 -0500

On 5/7/13 14:29, Paul Kyzivat wrote:
> consider it ok if there are multiple "anonymous" flows each complying 
> to the attributes of the m-line?

I presume, by "multiple anonymous flows," you mean multiple series of 
packets with the same PT, but with different SSRC values.

> Or do you assume that all packets with that PT are treated as one 
> flow, switching from one SSRC to another as they are received?

In the example you gave, all of those packets are defined to be 
associated with the same media line. Looking at basic principles, the 
intention here is that the semantics would be identical to non-webrtc, 
non-bundle clients receiving multiple SSRCs on the same port. 
Admittedly, those semantics have never been crystal clear, but my 
experience is that most systems would use this approach to send multiple 
streams that are semantically the same "thing" and should be rendered as 
one "thing" (e.g., window, speaker, etc).

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.

Does that answer the question you're answering?

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 07 May 2013 17:09:37 -0400

> Does that answer the question you're answering?

Yes, that exactly answers the question I was asking.

It fits a clue case, of a "dynamic switched capture", where a single 
logical flow (capture) may be conveyed via unknown SSRCs.

But it doesn't cope well with a case where there a several of those, 
because each will require distinct PTs, and that may not work.

To adequately cover that, I think we need the potential to signal a 
*different* demux algorithm, instead of PT or SSRC. (We are assuming a 
new RTP header extension).

Bottom line, instead of saying the demux is by ssrc if present, and 
otherwise by PT, I suggest that we explicitly signal the demux 
mechanism, with options being at least those, plus another one once we 
get it defined.

Otherwise I think what you are proposing can work for CLUE.

	Thanks,
	Paul

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 7 May 2013 14:12:47 -0700

On Tue, May 7, 2013 at 2:09 PM, Paul Kyzivat <[email-masked]> wrote:
> *different* demux algorithm, instead of PT or SSRC. (We are assuming a new
> RTP header extension).
>

So your thinking is that the offerer would say something like

m=audio
a=demux-token:ABC

m=video
a=demux-token:DEF

And then at that point he would need to be prepared to demux
RTP packets with header extension [demux=ABC], etc.?

-Ekr

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 7 May 2013 14:44:55 -0700

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

---

From: "Roni Even" <[email-masked]>
Date: Wed, 8 May 2013 01:16:57 +0300

Hi Paul,
The problem in the CLUE case in the example you gave is that the receiver
will get an RTP stream with a new SSRC not in the SDP  to the same port and
will need to know how to map it to one of the media capture replacing the
previous one.
I think that this mode can work in plan B as an additional case, multiple
RTP streams in an m-line but the SSRC or mapping to media capture is done
via RTP header extension. For plan A it works only if it will allow multiple
RTP streams based on the same m-line.  The assumption in both cases is that
both sides identify that they understand this specific usage, for example,
by support of the specific header extension

Roni 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Paul Kyzivat
Sent: 08 May, 2013 12:10 AM
To: Adam Roach
Cc: [email-masked]
Subject: Re: [rtcweb] Plan A, respun

On 5/7/13 4:00 PM, Adam Roach wrote:
> experience is that most systems would use this approach to send 
> multiple streams that are semantically the same "thing" and should be 
> rendered as one "thing" (e.g., window, speaker, etc).
>
> 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.

It fits a clue case, of a "dynamic switched capture", where a single logical
flow (capture) may be conveyed via unknown SSRCs.

But it doesn't cope well with a case where there a several of those, because
each will require distinct PTs, and that may not work.

Bottom line, instead of saying the demux is by ssrc if present, and
otherwise by PT, I suggest that we explicitly signal the demux mechanism,
with options being at least those, plus another one once we get it defined.

	Thanks,
	Paul

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 7 May 2013 15:33:40 -0700

Roni said: 

> via RTP header extension. 

[BA] Support for RTP extensions is supposed to be optional.  So if the RTP extension is there to help the receiver deal with the anonymous SSRC until an SDP Answer or RTP SDES packet shows up to clarify things, I can live with it.  But if supporting the RTP extension is necessary to process every RTP packet I would not be favorably inclined toward this approach.

---

From: "Roni Even" <[email-masked]>
Date: Wed, 8 May 2013 01:32:52 +0300

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: [email-masked] [mailto:[email-masked]] On Behalf Of
Bernard Aboba
Sent: 08 May, 2013 12:45 AM
To: Adam Roach
Cc: [email-masked]
Subject: Re: [rtcweb] Plan A, respun

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

---

From: Adam Roach <[email-masked]>
Date: Tue, 07 May 2013 17:55:15 -0500

On 5/7/13 17:16, Roni Even wrote:
> For plan A it works only if it will allow multiple RTP streams based on the same m-line.

I want to re-iterate the most important part of my answer to Paul, since 
it allows anyone who can apply apply critical thinking skills to arrive 
at the correct conclusion about what we are proposing. Here is the crux 
of my answer again, from which the remainder of my answer was derived:

    Looking at basic principles, the intention here is that the
    semantics would be identical to non-webrtc, non-bundle clients
    receiving multiple SSRCs on the same port.

So if you're going to define an extension that makes it explicit that 
multiple SSRCs in non-bundled media is intended to represent multiple 
independent streams, then you've defined that extension and it works 
just fine with Plan A.

/a

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 08 May 2013 13:00:26 +0200

The paragraph that worries me most is this one:

    Offerers conformant to this specification MUST do one of the
    following:

    o  Use non-overlapping PT values for each m-line in any given bundle
       group.

    o  Provide distinct a=ssrc attributes for each m-line which uses
       overlapping PT values with any other m-line.  [Technically, this
       is a general case of the previous point.]

To put a blunt point on it: Either send less than ~32 streams, or give 
a=ssrc attributes.

To me, that measn we're mandating one mechanism (PT values) for small 
numbers of flows, and another mechanism (a=ssrc) for large numbers of 
flows - such mechanism changes usually have "interesting" properties in 
what happens at the changeover point.

It would seem to me to be architecturally cleaner to insist that a=ssrc 
be used always.
But in that case, I have a very large difficulty seeing the important 
advantage this has over Plan B.

On 05/07/2013 08:30 PM, Adam Roach wrote:
> Note that this is a slightly different approach than Cullen outlined 
> in Orlando. I fear the Orlando approach may have suffered from its 
> attempts to incorporate some elements of Plan B in an attempt to 
> appease proponents of that approach; and, in doing so, lost some of 
> its clean architecture.
>
> document, as I believe that mid-session glare can be completely 
> avoided by applications implementing a set of non-normative behaviors. 
> These behaviors are described in the a separate companion document:
>

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 08 May 2013 13:03:34 +0200

On 05/07/2013 11:44 PM, Bernard Aboba wrote:
> 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.
>
There's a paragraph in draft-ietf-mmusic-msid about this:

4.1.  Handling of non-signalled tracks

    Pre-WebRTC entities will not send msid.  This means that there will
    be some incoming RTP packets with SSRCs where the recipient does not
    know about a corresponding MediaStream id.

    Handling will depend on whether or not any SSRCs are signaled in the
    relevant m-line(s).  There are two cases:

    o  No SSRC is signaled with an msid attribute.  The SDP session is
       assumed to be a backwards-compatible session.  All incoming SSRCs,
       on all m-lines that are part of the SDP session, are assumed to
       belong to independent media streams, each with one track.  The
       identifier of this media stream and of the media stream track is a
       randomly generated string; the label of this media stream will be
       set to "Non-WMS stream".

So for the non-msid case, we already have this signal in the WebRTC API 
- it's called "onaddstream".

---

From: Colin Perkins <[email-masked]>
Date: Wed, 8 May 2013 12:33:05 +0100

On 8 May 2013, at 12:00, Harald Alvestrand wrote:
> To put a blunt point on it: Either send less than ~32 streams, or give a=ssrc attributes.
> 
> To me, that measn we're mandating one mechanism (PT values) for small numbers of flows, and another mechanism (a=ssrc) for large numbers of flows - such mechanism changes usually have "interesting" properties in what happens at the changeover point.
> 
> It would seem to me to be architecturally cleaner to insist that a=ssrc be used always.

I agree: the PT was never intended to be used as a demultiplexing point for different flows in RTP, that's the role of the SSRC. An a=ssrc: line, or an RTCP SDES item, can then be used to bind the SSRC to an m= line, or some other higher-layer identifier. 

-- 
Colin Perkins
http://csperkins.org/

---

From: Colin Perkins <[email-masked]>
Date: Wed, 8 May 2013 12:37:20 +0100

On 7 May 2013, at 23:33, Bernard Aboba wrote:
> Roni said: 
> 
>> I think that this mode can work in plan B as an additional case, multiple RTP streams in an m-line but the SSRC or mapping to media capture is done via RTP header extension. 
>> 

Agree: if we define an RTP header extension for this, it should only be used to speed-up acquisition of the relevant information that's sent in an RTCP SDES item (much like we did with RFC 6051). 

-- 
Colin Perkins
http://csperkins.org/

---

From: Stefan Håkansson LK <[email-masked]>
Date: Wed, 8 May 2013 14:38:36 +0200

A couple of questions (and sorry for the rtcweb/webrtc centric 
perspective) for clarification:

* How would the info about PC-track and PC-stream id's be conveyed (I 
assume the msid draft)?

* What is your thinking regarding mapping between PC-tracks and m-lines? 
For example, if Alice's app initiates a session with two video 
PC-track's flowing to Bob's app, that would presumable create a session 
with two sendonly m-lines. If, at a later stage, Bob's app upgrades the 
session by sending three video PC-tracks to Alice's app. How would the 
Bob -> Alice video PC-tracks be allocated to the existing m-lines 
(becoming sendrecv), and how would pick which one to use a new m-line? 
E.g., would it be random, or should the app decide, and based on what in 
that case?

Stefan

---

From: Stefan Håkansson LK <[email-masked]>
Date: Wed, 8 May 2013 15:06:40 +0200

One more question (and I think this one is applicable to Plan B as 
well). It has to do with devices with HW encoders.

If I have a system that supports video encoding and decoding of format X 
and Y it is pretty obvious what the offer should look like.

But if I add a camera that can also encode in format Z, what should the 
offer look like?

The camera would not decode, so for sendrecv m-lines format Z could not 
be included in an offer.

Does this mean that to utilize camera encoders (if the corresponding 
decoders are not available in the system), we'd be limited to sendonly 
m-lines?

Stefan

---

From: Jonathan Lennox <[email-masked]>
Date: Wed, 8 May 2013 11:03:31 -0400

On May 7, 2013, at 6:55 PM, Adam Roach wrote:

I want to re-iterate the most important part of my answer to Paul, since it allows anyone who can apply apply critical thinking skills to arrive at the correct conclusion about what we are proposing. Here is the crux of my answer again, from which the remainder of my answer was derived:
Looking at basic principles, the intention here is that the semantics would be identical to non-webrtc, non-bundle clients receiving multiple SSRCs on the same port.
Which would be great, if the community actually had a common understanding of what those semantics are.

--
Jonathan Lennox
[email-masked]<mailto:[email-masked]>

---

From: Martin Thomson <[email-masked]>
Date: Wed, 8 May 2013 08:38:00 -0700

> To put a blunt point on it: Either send less than ~32 streams, or give

This doesn't worry me in the slightest.  Legacy endpoints and those
that have trouble accessing SSRC information wont be able to use lots
of streams.  But it's interoperation with those endpoints that is why
this provision exists.

Requiring a=ssrc is as bad as my suggestion to move to v=1.  (Which I
still stand by, if you were wondering.)

---

From: Martin Thomson <[email-masked]>
Date: Wed, 8 May 2013 08:43:20 -0700

On 8 May 2013 05:38, Stefan Håkansson LK
<[email-masked]> wrote:
> A couple of questions (and sorry for the rtcweb/webrtc centric perspective)
> for clarification:
>
> * How would the info about PC-track and PC-stream id's be conveyed (I assume
> the msid draft)?

Yes, that's a solved problem. No sense reiterating it in the draft
(it's orthogonal to what the draft actually addresses).

> * What is your thinking regarding mapping between PC-tracks and m-lines? For
> example, if Alice's app initiates a session with two video PC-track's
> flowing to Bob's app, that would presumable create a session with two
> sendonly m-lines. If, at a later stage, Bob's app upgrades the session by
> sending three video PC-tracks to Alice's app. How would the Bob -> Alice
> video PC-tracks be allocated to the existing m-lines (becoming sendrecv),
> and how would pick which one to use a new m-line? E.g., would it be random,
> or should the app decide, and based on what in that case?

Alice's offer would contain at least two m-lines.  Those would not
necessarily be sendonly.  If she was capable of receiving more than 2
inbound, the offer could contain recvonly lines too (I believe that
this fits with the OfferToReceiveVideo=n constraint).  Of course, if
those lines were not compatible with what Bob wanted to send (too
much, different codecs, different constraints, etc...), then Bob is
required to send another offer to get his media out.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 8 May 2013 08:47:32 -0700

This is a pretty complicated example, but I agree that it is quite relevant.

If the camera that can produce Z is attached (to the
RTCPeerConnection), then an offer would include X, Y and Z, but it
would probably have to be marked sendonly.  Other m-lines could be
used to offer to receive X and Y.

I don't see this being solved very well by SDP at all.  Regardless of
the option chosen.

On 8 May 2013 06:06, Stefan Håkansson LK
<[email-masked]> wrote:
> One more question (and I think this one is applicable to Plan B as well). It
> has to do with devices with HW encoders.
>
> If I have a system that supports video encoding and decoding of format X and
> Y it is pretty obvious what the offer should look like.
>
> The camera would not decode, so for sendrecv m-lines format Z could not be
> included in an offer.
>

---

From: Stefan Håkansson LK <[email-masked]>
Date: Wed, 8 May 2013 15:49:09 +0000

>I don't see this being solved very well by SDP at all.  Regardless of

That's in line with my conclusion.

>>be
>>>>in
>>>>avoided

---

From: Adam Roach <[email-masked]>
Date: Wed, 08 May 2013 10:51:21 -0500

> To put a blunt point on it: Either send less than ~32 streams, or give 

Let's call it 96, just to keep reality involved in the conversation (cf. 
RFC 3551, section 3, para 7; as updated by RFC 5761, section 4, para 10).

I'll also point out that you can always have more than one bundle; so, 
if you're willing to burn two ports rather than just one, you can double 
this to 192. Repeat as necessary.

> numbers of flows...

Uh... no? Small numbers of flows can use a=ssrc. They just lose some 
flexibility by doing so.

> ...and another mechanism (a=ssrc) for large numbers of flows - such 
> mechanism changes usually have "interesting" properties in what 
> happens at the changeover point.

Given the actual limit here is 96 *per* *port*, I'd be more inclined to 
characterize it as:

  * One very flexible mechanism for small, medium, and moderately large
    numbers of streams, and
  * Another less flexible mechanism for sessions of arbitrary size,
    including small numbers of streams

/a

---

From: Emil Ivov <[email-masked]>
Date: Wed, 08 May 2013 18:51:41 +0300

> To put a blunt point on it: Either send less than ~32 streams, or give

I might be missing something ... probably even a lot, but why do we need
the above limitation? Why is it not an option to just let the
application provide the relationship with the MediaStream?

Requiring that all SSRCs be known in advance or imposing re-offer/answer
exchanges seems like waaay too heavy a requirement that can add severe
restrictions on the way applications and topologies are designed.

Emil

-- 
https://jitsi.org

---

From: Emil Ivov <[email-masked]>
Date: Wed, 08 May 2013 18:55:52 +0300

On 08.05.13, 18:38, Martin Thomson wrote:
> of streams. 

I don't agree with this. Unavailable SSRC information could mean a bunch
of things and not only "I am a legacy application and I don't know how
to talk to my media stack".

There's also the case of de-coupled applications for example. I may want
to invite you into a conference that's hosted on an RTP translator. I
don't necessarily know who else will be connecting to that translator
and requiring that I learn this is 1) unnecessary 2) potentially
extremely complicated in many cases.

Emil

-- 
https://jitsi.org

---

From: Martin Thomson <[email-masked]>
Date: Wed, 8 May 2013 08:56:40 -0700

On 8 May 2013 04:03, Harald Alvestrand <[email-masked]> wrote:
> So for the non-msid case, we already have this signal in the WebRTC API -
> it's called "onaddstream".

This always confused me, so I ignored it.  Why is the IETF making
proscriptive statements about API behavior?  I'm pretty sure that when
rtcweb did that it was wrong, but now mmusic has done it.

I don't think that this specific behavior is correct on a couple of
levels.  For the ones that we are expected to discuss in the IETF,
this relates to the point Adam raised about how multiple SSRCs are
rendered.  The ramifications for the API are something I'd rather
discuss in the W3C, preferably after the first issue is resolved.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 8 May 2013 09:08:01 -0700

> extremely complicated in many cases.

I separated the two classes.  There are legacy apps that don't produce
SSRC.  And there are apps that find it difficult to get SSRC info.  In
both cases, PT demux is not going to be an option beyond a certain
scale.

---

From: Emil Ivov <[email-masked]>
Date: Wed, 08 May 2013 19:13:08 +0300

> both cases, PT demux is not going to be an option beyond a certain

Well in that case the "won't be able to use lots of streams" part
doesn't necessarily apply. In the RTP translator case described above
one could easily have hundreds of SSRCs and hundreds of streams.

This would actually be all the more reason not to mandate SSRCs during O/A.

-- 
https://jitsi.org

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 8 May 2013 09:25:18 -0700

On Wed, May 8, 2013 at 4:00 AM, Harald Alvestrand <[email-masked]>wrote:

> numbers of flows, and another mechanism (a=ssrc) for large numbers of flows
> - such mechanism changes usually have "interesting" properties in what

That doesn't sound *quite* right to me.

As I read the document, implementations are free to:

(a) offer entirely disjoint PTs for all the m-lines in a given bundle, in
      which case they must consume in total less than about 96 PTs
(b) offer a=ssrc in which case they must only guarantee that each
      m-line doesn't internally repeat PTs (i.e., the current guarantee
      that you don't say that 102 is both VP8 and H.264 on the same
      m-line.)

I would think that a smart implementation would try to use disjoint
PTs to the extent possible (thus allowing early demuxing) but
also offer a=ssrc, so that if they ran out of PTs, the transition was
smooth. Obviously there is potential for bugs here, but this seems
like code that would get fairly well tested in the field, no?

> advantage this has over Plan B.

Isn't the argument that Plan A preserves all the existing SDP negotiation
mechanisms but allows them to be used with a high level of muxing,
rather than reinventing some subset of them at the SDP level?

-Ekr

---

From: Martin Thomson <[email-masked]>
Date: Wed, 8 May 2013 09:26:28 -0700

> one could easily have hundreds of SSRCs and hundreds of streams.

Yeah, I wouldn't recommend the use of SDP for signaling that sort of session.

> This would actually be all the more reason not to mandate SSRCs during O/A.

If you plan to a) add lots and lots of streams to the same RTP session
and b) can't know ahead of time what the SSRCs are going to be.  Then
no current SDP proposal is going to work for you.

---

From: Emil Ivov <[email-masked]>
Date: Wed, 8 May 2013 19:36:55 +0300

> Yeah, I wouldn't recommend the use of SDP for signaling that sort of
session.

Wouldn't be my first choice either ... or last. Fortunately SDP is only
necessary to signal the m-line. SSRCs could be handled out of band if only
browsers would allow for it.

> no current SDP proposal is going to work for you.

Why not? To me this issue is orthogonal to SDP. If the browser would only
let the application provide the m-line to SSRC relation in cases where it
isn't in the SDP, then we should be fine.

--sent from my mobile

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 08 May 2013 20:55:39 +0200

> rtcweb did that it was wrong, but now mmusic has done it.

Well .... the statement needs to be made.

The API document says that MediaStreams that get added to a 
PeerConnection get signalled with an onaddstream() - you will notice 
that the quoted text doesn't mention that detail.

The decision that when a certain event happens in the protocol, a 
certain API function happens ... needs to be documented somewhere. 
Whether that's a protocol document or an API document depends on how far 
down you consider the coupling to be API, and how far up it's protocol.

> discuss in the W3C, preferably after the first issue is resolved.
I'm confused.
How can we "discuss how multiple SSRCs are rendered" without discussing 
what the API events that are caused by the protocol events are?

This seems wrong to me. We need to have the discussion. The text I 
quoted is in a document. Let's discuss.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 08 May 2013 15:23:21 -0400

> I don't see this being solved very well by SDP at all.  Regardless of

There are multiple ways to skin this cat:

- there could be separate m-lines for sendonly and recvonly (and
   flipped at the peer). To be safe, you could make everything that
   way - no sendrecv m-lines. Each stream would be assigned to an
   m-line with the appropriate directionality. (But this doesn't
   work well if you want to change the directionality to reflect
   hold.)

- we could make the extension to support a=ssrc:nnn sendonly, etc.
   That way you can signal the directionality of each individual stream.
   Presumably in that case an a=sendonly/recvonly/... for the same
   m-line would apply to any ssrc's that didn't have their own.

	Thanks,
	Paul

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 8 May 2013 15:37:04 -0400 (EDT)

> From: Adam Roach <[email-masked]>
> 

Echoing Jonathan, I don't think that there is a consistent rule for
those semantics now.  Some devices consider multiple SSRCs to be data
from multiple captures, and others consider multiple SSRCs to be
alternative representations of the same capture (either simultaneous
in time or alternating in time).

Or perhaps there is a consistent rule, but there are inconsistent
implementations.  In which case we should document the correct
behavior -- and worry about interoperability.

Or perhaps we should define an SDP extension (or tighten the semantics
of an existing syntax) to remove the ambiguities.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 08 May 2013 16:14:45 -0400

> will need to know how to map it to one of the media capture replacing the

My assumption was that each m-line would correspond to a capture, and 
according to what Adam specified, it would have to be demuxed by payload 
type.

And also, according to Adam's assumptions, whatever SSRCs are received 
would all be assumed to be part of the same capture.

So it works in a limited way, without a header extension, used PT demux. 
But its limited by the number of PTs.

> by support of the specific header extension

Either scheme can be *made* to work for the clue dynamic capture case 
using a header extension. But we have to work out the details of how.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 08 May 2013 16:22:09 -0400

On 5/7/13 5:12 PM, Eric Rescorla wrote:
>
>
> On Tue, May 7, 2013 at 2:09 PM, Paul Kyzivat <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     *different* demux algorithm, instead of PT or SSRC. (We are assuming
>     a new RTP header extension).
>
>

I haven't thought about the specific syntax, but it would require *some* 
new marking associated with each m-line.

In principle, a different demux algorithm can be selected for each 
m-line. But each algorithm imposes some constraints on usage within the 
bundle. For instance, demux by PT implies that the PTs of the m-line 
that selects this must be disjoint from those of all other m-lines in 
the bundle. Demux for a DTLS/SCTP m-line only works for one of those, 
unless we provide a way to specify specify SCTP port for a DTLS/SCTP m-line.

	Thanks,
	Paul

---

From: Martin Thomson <[email-masked]>
Date: Wed, 8 May 2013 14:53:50 -0700

On 8 May 2013 11:55, Harald Alvestrand <[email-masked]> wrote:
> This seems wrong to me. We need to have the discussion. The text I quoted is
> in a document. Let's discuss.

How about we start that discussion in mmusic.

---

From: Stefan Håkansson LK <[email-masked]>
Date: Thu, 9 May 2013 13:41:46 +0200

> (it's orthogonal to what the draft actually addresses).

Right, just wanted it clarified.

> this fits with the OfferToReceiveVideo=n constraint).

OK. So if Alice's app used OfferToReceiveVideo=0, then both m-lines 
would be sendonly, 1 would give one sendrecv and one sendonly and so on.

So, if OfferToReceiveVideo=0 was used (or was even the default), we 
would in the case of a symmetric service (Alices's and Bob's apps 
intending to send the same amount of audio and video tracks, and doing 
it from the start of the session) actually end up with the same 3-way 
handshake as in Plan B (since sendonly/recvonly can't be upgraded to 
sendrecv without a new offer)?

(I have no problem with that behavior, I just want to understand)

> Of course, if

...because new m-lines are required.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 9 May 2013 08:45:47 -0700

On 9 May 2013 04:41, Stefan Håkansson LK
<[email-masked]> wrote:
> OK. So if Alice's app used OfferToReceiveVideo=0, then both m-lines would be
> sendonly, 1 would give one sendrecv and one sendonly and so on.
>
> So, if OfferToReceiveVideo=0 was used (or was even the default), we would in
> the case of a symmetric service (Alices's and Bob's apps intending to send
> the same amount of audio and video tracks, and doing it from the start of
> the session) actually end up with the same 3-way handshake as in Plan B
> (since sendonly/recvonly can't be upgraded to sendrecv without a new offer)?
>

I think that you have it understood.

> ...because new m-lines are required.

Yep.

---

From: Jonathan Lennox <[email-masked]>
Date: Thu, 9 May 2013 14:20:05 -0400

>   m-line would apply to any ssrc's that didn't have their own.

a=ssrc attributes are inherently unidirectional -- they talk about what you can send.  In draft-lennox-mmusic-source-selection, I defined an additional a=remote-ssrc attribute to talk about what you want to receive.

That draft defines a=ssrc:send and a=remote-ssrc:recv source attributes, which allow on/off control for individual source hold.

--
Jonathan Lennox
[email-masked]

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 10 May 2013 13:12:42 +0200

On 05/08/2013 06:25 PM, Eric Rescorla wrote:
>
>
> On Wed, May 8, 2013 at 4:00 AM, Harald Alvestrand 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     To me, that measn we're mandating one mechanism (PT values) for
>     small numbers of flows, and another mechanism (a=ssrc) for large
>     numbers of flows - such mechanism changes usually have
>     "interesting" properties in what happens at the changeover point.
>
>

Well.... you WOULD think the Java spec that says that Integer(127) is a 
globally unique object while Integer(128) isn't (so that, when testing 
for object equality instead of value equality, Integer(127) == 
Integer(127), while Integer(128) != Integer(128)), wouldn't you? (note - 
I think the limit may be JVM-implementation defined, but don't quote me 
on that).

This still bites implementors fairly far out in the deployment cycle, I 
hear. Obscure limits that you hit only after significant installed base 
is deployed is not really things that make me happy.

And of course Unicode's "we'll never need more than 65.535 characters" 
is another fun one.

>     But in that case, I have a very large difficulty seeing the
>     important advantage this has over Plan B.
>
>

That's the argument, but a) I'm not convinced that the argument holds, 
and b) I'm worried about the cost in terms of model complexity and 
richness of edge cases like this one.

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 10 May 2013 08:51:10 -0700

Some folks asked me if I plan to resubmit my plan-a document and I am not going to submit it. I think Adam's version is simpler and managed to split the difference between what I was proposing and plan b so I think it is a better choice for the WG than the initial draft I had worked on. 

On May 7, 2013, at 11:30 AM, Adam Roach <[email-masked]> wrote:

> In order to facilitate discussion between the two SDP format alternatives we're considering, I've put together a document that more clearly spells out the Plan A approach as we originally envisioned it. Note that this is a slightly different approach than Cullen outlined in Orlando. I fear the Orlando approach may have suffered from its attempts to incorporate some elements of Plan B in an attempt to appease proponents of that approach; and, in doing so, lost some of its clean architecture.
> 
> The cleaned up, new-and-improved description of the Plan A approach is available here:
> 
> Note that we've omitted discussion of glare reduction from that document, as I believe that mid-session glare can be completely avoided by applications implementing a set of non-normative behaviors. These behaviors are described in the a separate companion document:
>

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 10 May 2013 10:34:47 -0600

> of an existing syntax) to remove the ambiguities.

I realize that opinions differ on this topic, but for the O/A SDP cases (not the declarative SDP in RTSP), the meaning seemed to be clear and long ago it was put in some RFC, lots of products where build. Later it was suggested it could mean something different.  

But let's get to the high level point, regardless of what people think the existing RFCs say, it is a confusing topic and it needs to have  clear signaling with clear semantics or there will be interop problems.  I think that devices that want to multiple SRC on same m-line to represent different captures need to define new SDP signaling that clearly indicates this is the case.

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 10 May 2013 10:37:41 -0600

> To put a blunt point on it: Either send less than ~32 streams, or give a=ssrc attributes.

As a slide note, as I imagine you are aware,  it is not 32 but in the roughly 100 range 

> To me, that measn we're mandating one mechanism (PT values) for small numbers of flows, and another mechanism (a=ssrc) for large numbers of flows - such mechanism changes usually have "interesting"…

The problem is that SSRC are not a stable demux point due to collision and early media issues so, for applications that care about theses, they can use PT. For things that need the properties of the larger code space, they can use SSRC or other future extension to RTP.  The code is very simple to deal with demux on both PT and SSRC . If someone wants to later add a RTP header extensions with another tag that can be used for demux, that is fine too. The idea is that the device will use what it currently knows (both PT and SSRC) to do the best demux it can do given the information at hand. This gives us the best of SSRC demux and PT demux and actually allows a combination of the two that scales to much larger numbers than either alone. And it's trivial to implement.

> It would seem to me to be architecturally cleaner to insist that a=ssrc be used always.

There rare two major disadvantages to doing this 

1) The side receiving the media can't tell the other side what SSRC to use in the offer. That means you can not demux until after the answer is received in the best case. This adds latency and cause media clipping. It does not work with early media in some cases. 

It may not matter to the use case you have in mind but it does matter to use cases other have in mind. Note there is no problem for the use case you are interested in just using the SSRC and not caring what happens with the PT. For applications that want to do that, the mechanism in this draft works just fine.  

2) the other problem is that SSRC collide and it takes a long time to get the the updated information about how the collision was resolved and in that time the data may actually go the wrong place.  Just sort of curios if chrome has implemented dealing with collisions yet?

I will note that using PT + SSRC in the way Adam's draft has them actually allows for a theoretical maximum of more like 3 million RTP flows per port. 

> But in that case, I have a very large difficulty seeing the important advantage this has over Plan B.
> 
> 
>

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 10 May 2013 10:38:19 -0600

On May 7, 2013, at 2:44 PM, Bernard Aboba <[email-masked]> wrote:

> same RTP session without explicit declaration since multicast days -

Right, but what it has meant to do that in Offer / Answer cases has been that these are alternative encoding of same capture and not different captures. I think we need to have the signaling be explicit about the meaning if it is supposed to mean something different than that. Note, I'm not against an extension that indicates specific semantics that are different that the current O/A ones, but just it would need to be defined and signaled. The plan A seem to avoid needing to argue about this and at the same time make it easy to define theses semantics and signal them if CLUE or someone other user of RTP needs that.

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 10 May 2013 10:39:11 -0600

On May 8, 2013, at 4:33 AM, Colin Perkins <[email-masked]> wrote:

> I agree: the PT was never intended to be used as a demultiplexing point for different flows in RT

I'm not sure I really agree on this point. Lots of implications use the PT along with the port received on to decide which codec to pass to the RTP packet on to. I think, in practice, the PT has been a very key demux pony for a  long time in RTP.

---

From: Colin Perkins <[email-masked]>
Date: Fri, 10 May 2013 19:59:25 +0100

> I'm not sure I really agree on this point. Lots of implications use the PT along with the port received on to decide which codec to pass to the RTP packet on to. I think, in practice, the PT has be…

To identify the codec, sure, that's what the PT is designed to do. That's logically separate to identifying the source, which is the role of the SSRC.

-- 
Colin Perkins
http://csperkins.org/

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 10 May 2013 12:55:58 -0700

On Fri, May 10, 2013 at 11:59 AM, Colin Perkins <[email-masked]> wrote:

> > I'm not sure I really agree on this point. Lots of implications use the
> PT along with the port received on to decide which codec to pass to the RTP
> packet on to. I think, in practice, the PT has been a very key demux pony
> for a  long time in RTP.
>
>
> To identify the codec, sure, that's what the PT is designed to do. That's
> logically separate to identifying the source, which is the role of the SSRC.
>
>
I note that Bundle currently requires a totally disjoint PTs:
"- The dynamic payload type values used in the "m=" lines MUST NOT overlap"'
[
http://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-03#section-7.2
]

I had assumed this was done to allow demux.

It seems to me that plan A relaxes this requirement in:
http://tools.ietf.org/html/draft-roach-rtcweb-plan-a-00#section-6.2

-Ekr

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 10 May 2013 14:03:28 -0600

> To identify the codec, sure, that's what the PT is designed to do. That's logically separate to identifying the source, which is the role of the SSRC.

But I am not trying to identify the source, if I wanted to do that I agree CSRC would be one of things to use. I am trying to figure out which codec to pass the incoming packet to. I don't mind using SSRC when they are around but when they are not, PT seems perfectly reasonable to use if uniquely identifiers which codec to pass the packet to. I realize that you prefer the shim approach but when there is not a shim, I'm not seeing the problem with using PT. Adam's draft also allows use of SSRC for folks that want to overlap the PT from different m lines. 

Consider a normal SIP call with only single speaker of G.711 audio with early media where two sources are both sending to the same port and PT on that phone. That's normal. It does not need to figure out the sources to render the audio. Sure the codec probably might want to note that a SSRC changed and retrain the jitter buffer but the phone does not care about who the sources are in this case to play them. In more complicated conferring cases the phone could use SSRC/CSRC info to map to roster information received over some other protocol than SDP to display a name for the active speaker or something. But thats a case where who the sources are matters - this is just about getting the media to the right codec on the right m line.

---

From: Colin Perkins <[email-masked]>
Date: Fri, 10 May 2013 21:50:40 +0100

> But I am not trying to identify the source, if I wanted to do that I agree CSRC would be one of things to use. I am trying to figure out which codec to pass the incoming packet to. I don't mind usi…

I wasn't thinking about the shim at all; this is independent of that.

> Consider a normal SIP call with only single speaker of G.711 audio with early media where two sources are both sending to the same port and PT on that phone. That's normal. It does not need to figure out the sources to render the audio. Sure the codec probably might want to note that a SSRC changed and retrain the jitter buffer but the phone does not care about who the sources are in this case to play them.

Except that it does care about the source, as you say, to retrain the jitter buffer. Or, if you're using something other than G.711 to reset the codec state when you change source. Or to link to the appropriate FEC or retransmission stream, comfort noise packets, RTCP reports, codec control messages, etc. None of which works properly if you ignore the SSRCs. WebRTC isn't building a dumb SIP phone that only does G.711. The kind of features people are talking about for WebRTC need to use the SSRC as the first demultiplexing point to work properly, then use the payload type to select the codec. 

> In more complicated conferring cases the phone could use SSRC/CSRC info to map to roster information received over some other protocol than SDP to display a name for the active speaker or something. But thats a case where who the sources are matters - this is just about getting the media to the right codec on the right m line. 

-- 
Colin Perkins
http://csperkins.org/

---

From: Emil Ivov <[email-masked]>
Date: Sun, 12 May 2013 12:39:04 +0300

Coming back to this for a sec:

> To put a blunt point on it: Either send less than ~32 streams, or give

Wouldn't it make more sense to either send ~32 streams or you don't use
bundle? If you run out of PTs for a single m-line then you may also
reconsider use of rtcp-mux.

It seems to me that the consequences of not using bundle in some
specific scenarios, especially in cases where trickle ICE is also
supported, are far lesser than requiring everyone to support
pre-announcement of SSRCs.

Emil

-- 
https://jitsi.org

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 12 May 2013 13:58:29 +0200

> reconsider use of rtcp-mux.
So you're saying that when using 1-31 streams, we use a single port 
pair, but when we use 32 streams, we use 32 port pairs?

I hadn't even considered the possibility of driving off that particular 
cliff at that boundary.
> pre-announcement of SSRCs.

Why?

Remember: In Plan B, the only applications who have to support 
pre-announcement of SSRCs are those that want to send more than one 
media stream in a single RTP session.

Any application that is satisfied with having mulitple RTP sessions 
corresponding to multiple M-lines can just signal as they're used to, 
without BUNDLE or SSRC signalling (although it will work a lot better if 
they use a=content consistently).

Plan B is even compatible with folks that want to use BUNDLE, but are 
happy to let the recipient handle incoming SSRCs without knowing which 
one is  which.

That's not "everyone".

---

From: Emil Ivov <[email-masked]>
Date: Sun, 12 May 2013 16:00:48 +0300

> pair, but when we use 32 streams, we use 32 port pairs?

Most certainly not! I am suggesting that if you fill up your PT space
you could stop using bundle for your (presumably two, audio and video)
m= lines. So rather than using a single port for RTP, you'll fall back
to using two ports for audio and video.

If you start lacking numbers again, you could consider turning off
rtcp-mux which would again almost double your choices (presuming that
you limited yourself to using the 96-127 range because you wanted to
make rtcp demuxing easier).

Just to clarify, I consider Plan B's use of m= lines (i.e. 1 m=line for
many SSRCs) very natural and in-line with RTP design. I am not arguing
against this. (I would actually strongly argue against the alternative).

> I hadn't even considered the possibility of driving off that particular 

Fortunately I don't think anyone is.

> media stream in a single RTP session.

And it is exactly those applications that I am worried about. Imagine I
am a conference focus that remotely controls an RTP translator. I would
hence invite you with a single m= line for audio and a single m=line for
video.

On either of these you would end up getting a bunch of SSRCs for all the
other participants. Or maybe you would just get one if the translator
decides to mix rather than translate for some reason.

Either way I can't send you all SSRCs in advance because there's know
way for me to learn those of the other participants unless I use some
unnecessary, unnecessarily complicated and unnecessarily time-consuming,
signalling.

> they use a=content consistently).

Again, that's not the kind of alternative that I was arguing for.

Emil

-- 
https://jitsi.org

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 12 May 2013 16:54:11 +0200

> to using two ports for audio and video.
Hmmm... how would you do that? Since you're using one M-line per video 
source (remember, this is plan A, not plan B), you're using the PT 
number for getting back to your M-line, which means that you're now 
creating more than one bundle, each bundle being limited to 32 PTs (and 
therefore 32 M-lines).

Plan A is certainly creating an use case for more than one bundle, but 
it's still implying code that swings into action at the 32 track 
boundary, and is unused before that.

> against this. (I would actually strongly argue against the alternative).

Thanks for the clarification!

> unnecessary, unnecessarily complicated and unnecessarily time-consuming,

Or you could signal none of them and depend on the fallback case in 
draft-ietf-mmusic-msid to handle them in a consistent manner, and use 
other methods to figure out how to handle them...

---

From: Emil Ivov <[email-masked]>
Date: Sun, 12 May 2013 19:03:56 +0300

On May 12, 2013 5:54 PM, "Harald Alvestrand" <[email-masked]> wrote:
> Hmmm... how would you do that? Since you're using one M-line per
> video source

No, I am not. I am using one m= line for many video sources.

> (remember, this is plan A, not plan B),

Correct, and again I am not talking about plan A.

> you're using the PT
> creating more than one bundle, each bundle being limited to 32 PTs
> (and therefore 32 M-lines).

My point was NOT to use bundle in case PTs are insufficient. So in most
cases you'd have one m= line for video (with as many sources as you wish)
and one for audio.

> draft-ietf-mmusic-msid to handle them in a consistent manner, and
> use other methods to figure out how to handle them...

If you are referring to section 4.1 that you also pasted earlier in this
thread, it only talks about one track, per stream, per m= line. This
doesn't cover the conferencing case I described in my previous mail (quoted
above).

Cheers,
Emil

--sent from my mobile

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 12 May 2013 21:55:26 +0200

On 05/12/2013 06:03 PM, Emil Ivov wrote:
> If you are referring to section 4.1 that you also pasted earlier in 
> this thread, it only talks about one track, per stream, per m= line. 
> This doesn't cover the conferencing case I described in my previous 
> mail (quoted above).
>
Changing subject as I'm replying to a subtopic, and because I was 
misunderstanding what Emil was arguing in favour of.....

when I wrote that text, I didn't intend it to cover only one SSRC per 
stream.
What I intended to say was that when, in an RTP session, a browser gets 
several SSRCs that were not mentioned in signalling, it will send 
several onaddstream signals to the application, each indicating a new 
stream being added, which has exactly one track. If the language doesn't 
say that, I need to change it.

(One reason why I changed this from the version with just a single 
stream with one track per unknown SSRC was that there's no way to know 
the desired synchronization properties of the stream before one sees the 
CNAME of the stream - which may be at an arbitrary time after the first 
packet.)

---

From: Colin Perkins <[email-masked]>
Date: Mon, 13 May 2013 11:32:57 +0100

> The problem is that SSRC are not a stable demux point due to collision and early media issues so, for applications that care about theses, they can use PT. For things that need the properties of th…

I'm confused about what you mean by using a combination of SSRC and PT demux. You can't have two distinct SSRCs using the same PT values in a single RTP session, because you can't distinguish the RTCP packets for the two SSRCs, and we mandated the use of RTCP. 

The RTP demultiplexing process, as I always understood it, was to look at the SSRC first, and based on that find your SRTP context, jitter buffer, RTCP state, etc., which are all indexed by SSRC. Then, look at the PT to determine what codec to use for the stream (noting that SSRCs can switch between PT values, and multiple SSRCs can use the same PT). Using the PT as the de-mux point for streams doesn't let you find the appropriate RTCP state or SRTP context, since those are indexed by SSRC, and requires you to use unique PT values for each stream, which is a much more limited space than the SSRC space (and, unlike the SSRC space, has no collision resolution built-in). 

> 1) The side receiving the media can't tell the other side what SSRC to use in the offer. That means you can not demux until after the answer is received in the best case. This adds latency and caus…

You can always use the SSRC to demux based on source, then use the PT to direct to the appropriate codec, irrespective of whether you've received signalling of the SSRC in advance. I don't see how using the PT as the primary demultiplexing point helps here.

> 2) the other problem is that SSRC collide and it takes a long time to get the the updated information about how the collision was resolved and in that time the data may actually go the wrong place.…

If the colliding sources send the required RTCP packets immediately, as RFC 3550 allows in unicast scenarios, you should be able to determine how collision was resolved straight away. 

And, if you're signalling SSRCs, an SSRC collision is no more likely than a PT collision, and gives you a bigger space to work with to identify streams.

> I will note that using PT + SSRC in the way Adam's draft has them actually allows for a theoretical maximum of more like 3 million RTP flows per port. 

Using the SSRC to distinguish sources allows this anyway, and as I noted above, you can't run multiple sources with the same SSRC and different PT values without breaking RTCP.

-- 
Colin Perkins
http://csperkins.org/

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 13 May 2013 09:20:16 -0700

Colin said: 

The RTP demultiplexing process, as I always understood it, was to look at the SSRC first, and based on that find your SRTP context, jitter buffer, RTCP state, etc., which are all indexed by SSRC. Then, look at the PT to determine what codec to use for the stream (noting that SSRCs can switch between PT values, and multiple SSRCs can use the same PT). Using the PT as the de-mux point for streams doesn't let you find the appropriate RTCP state or SRTP context, since those are indexed by SSRC, and requires you to use unique PT values for each stream, which is a much more limited space than the SSRC space (and, unlike the SSRC space, has no collision resolution built-in). 
[BA]  That is typically how I've seen it done, yes.  
Colin also said: 
I'm confused about what you mean by using a combination of SSRC and PT demux. You can't have two distinct SSRCs using the same PT values in a single RTP session, because you can't distinguish the RTCP packets for the two SSRCs, and we mandated the use of RTCP. 
[BA]  The statement above seems inconsistent with the earlier statement that "multiple SSRCs can use the same PT".  Or did you mean having multiple SSRCs, each using multiple PT values?  
Since the RTCP packets include the SSRC (but not the PT), distinguishing the RTCP packets by SSRC isn't a problem. I have seen multiple SSRCs use the same PT within an RTP session to enable several scenarios.  This includes RTP stream demux (e.g. the objective of "Plan B"), as well as simulcast and layered coding.  In the simulcast/layered coding case there are issues with understanding which RTP streams go together purely at the RTP level (e.g. adding this info to an SDES packet would be helpful), but it doesn't seem to cause problems for de-muxing.

---

From: Colin Perkins <[email-masked]>
Date: Mon, 13 May 2013 17:25:08 +0100

> [BA]  The statement above seems inconsistent with the earlier statement that "multiple SSRCs can use the same PT".  Or did you mean having multiple SSRCs, each using multiple PT values?  

Sorry, what I meant to say was that you can't do this while demuxing based on the PT, because you can't distinguish RTCP packets. You need to use the SSRC for demuxing. 

> Since the RTCP packets include the SSRC (but not the PT), distinguishing the RTCP packets by SSRC isn't a problem. I have seen multiple SSRCs use the same PT within an RTP session to enable several…

Agree.

-- 
Colin Perkins
http://csperkins.org/

---

From: Emil Ivov <[email-masked]>
Date: Tue, 14 May 2013 09:16:35 +0300

Hey Harald,

On 12.05.13, 22:55, Harald Alvestrand wrote:
> stream being added, which has exactly one track.

Aha! OK, I understand and it sounds better now that I do.

That's only half of it though. We would also need ways in the API to
control these streams if we weren't using SDP O/A.

Incidentally, when people have tried this with Chrome it didn't work as
described above and the unannounced SSRCs were handled in unpredictable
ways. I suppose this is just a matter of time and that the
implementation would eventually get there?

> If the language doesn't 

Well obviously I hadn't understood but that might be just me.

Incidentally, we might want to replace Pre-WebRTC with Non-WebRTC or
something similar. Applications that don't aggressively rely on SDP O/A
for stream control are not necessarily a thing of the past.

Emil

-- 
https://jitsi.org

---

From: Emil Ivov <[email-masked]>
Date: Tue, 14 May 2013 11:59:39 +0300

> Aha! OK, I understand and it sounds better now that I do.

Oh, just thought of something else while reading Stefan's mail: is it
really necessary that this should only happen in case no SSRCs have been
defined? Why not apply that to any unknown SSRC regardless of whether or
not others exist in SDP?

The second bullet there talks about a possible race condition but I am
not sure I see how this could occur with valid use of O/A.

Emil

-- 
https://jitsi.org

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 14 May 2013 13:41:09 +0200

> implementation would eventually get there?

Yes - please file a bug; that helps prioritize what gets done first!

> for stream control are not necessarily a thing of the past.

Non-WebRTC sounds good. Or even "applications that don't use MSID for 
SSRC indications".

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 14 May 2013 14:08:57 +0200

> not sure I see how this could occur with valid use of O/A.

The worrying case is:

A sends offer
B sends answer (either with or without MSID)
B starts sending data on some SSRCs
A receives the data, but has not yet seen the answer

The two cases are:

- B sends with MSID. In this case, he expects those specific IDs to be 
signalled in onaddstream.
- B sends without MSID. In this case, he expects that A will announce a 
locally generated ID in onaddstream.

A can't know the difference between those two before he sees the answer 
from B.
In this spec, I've "solved" it by saying that we don't signal 
onaddstream before we see the answer.

After the first answer has been seen, either party knows that new SSRCs 
always will be signalled, so any data on an unknown SSRC can be held 
until the negotiation announcing it is complete - or discarded as "bad 
data" if signalling doesn't happen in a reasonable time.

If we were to permit unknown SSRCs when there are some MSIDs, the 
decision to announce as "Unsignalled MediaStream" or wait for the 
offer/answer announcing the MSID it should be announced with has to 
depend on some other resolution mechanism. I don't like timers, and 
haven't found a better way to do it.

Note: If we follow "plan B"'s idea of having B send an offer with its 
own streams immedately after sending the answer to A, and only announce 
its streams in the counter-offer, not in the answer, and not sending 
data until it gets the answer, this problem goes away; there cannot be a 
case where A gets an SSRC that was intended to be signalled before he 
gets the signalling message that announces it.

I'm sure there's a cost to this solution (the extra half RTT is one 
obvious cost. Are there others?)

---

From: Emil Ivov <[email-masked]>
Date: Wed, 15 May 2013 08:36:51 +0300

> haven't found a better way to do it.

I didn't get this part. While I see the race condition that occurs
during offer/answer, I am not sure I understand why a new SSRC received
mid-session by either side is ambiguous. If the application had any
intent to announce it, then presumably it would be on the verge of
initiating a new offer/answer. If that were the case, sending the new
stream/track could have been held off until completion of that
offer/answer.

This way one would be able to only announce SSRCs for things such as FEC
and simulcasting (where available) while simple streams could be
delivered immediately.

Emil

-- 
https://jitsi.org

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 15 May 2013 08:24:43 +0200

> stream/track could have been held off until completion of that
Exactly - IF the party sending the SSRC is able to see when the 
offer/answer completes.
The offerer is the only party that can actually know if the offer/answer 
exchange is complete.

So the ambiguity only applies if the answerer is able to announce new 
SSRCs in an answer.
Is it reasonable to remove this functionality (and thereby mandating 
Plan B's double offer/answer) in order to achieve this functionality?

> and simulcasting (where available) while simple streams could be

As long as you don't need any information not carried in the RTP packet 
in order to announce the stream correctly, this would work.

---

From: Emil Ivov <[email-masked]>
Date: Wed, 15 May 2013 19:06:29 +0300

> The offerer is the only party that can actually know if the offer/answer 

OK, got it.

Then, going back to your second bullet, we could apply the same
buffering as the one you currently describe there. Only this time, once
we are done with the offer/answer things could go either way: we could
end up either signalling a new track or determining that packets
actually belong to some specific stream.

If this makes sense, I'd be happy to propose text if it helps.

> in order to announce the stream correctly, this would work.

I suppose we'll get there eventually. RTCP is one option here but what I
am personally hoping is that we'll agree that the APIs can also start
providing that information so that web apps can exchange it any way they
wish. Before, with, or after the SDP O/A has taken place.

Cheers,
Emil

-- 
https://jitsi.org

---

From: Adam Roach <[email-masked]>
Date: Thu, 16 May 2013 12:39:39 -0500

> pair, but when we use 32 streams, we use 32 port pairs? 

Harald:

Your insistence of using "32" rather than "96" is somewhat reminiscent 
of the statements made Muhammad Saeed al-Sahhaf (the Iraqi Information 
Minister at the end of Saddam Hussein's tenure). During the 2003 
invasion of Iraq, he made several proclamations that were so factually 
incorrect, so out of touch with reality, and so easy to disprove, that 
they became an hilarious Internet meme. His antics earned him the 
nickname "Comical Ali" in the popular press.

I've tried correcting you on this point, even going so far as to cite 
document, section, and paragraph; it doesn't seem to have made any 
difference.

I would strongly encourage you to stick to documented reality in this 
discussion rather than stating facts from an alternate universe that 
would, if true, bolster your position. Otherwise, you risk becoming the 
same kind of laughingstock that Comical Ali did.

/a

---

From: Emil Ivov <[email-masked]>
Date: Thu, 16 May 2013 20:43:58 +0300

> Your insistence of using "32" rather than "96" is somewhat reminiscent

96? Do you assume no use of rtcp-mux?

Emil

---

From: Emil Ivov <[email-masked]>
Date: Thu, 16 May 2013 21:16:52 +0300

> 96? Do you assume no use of rtcp-mux?

I suppose you must be referring to [5761#4]:

   Values below 64
   MAY be used if that is insufficient, in which case it is RECOMMENDED
   that payload type numbers that are not statically assigned by be
   used first.

While this works on paper, most media libraries are likely to have many
of those statically bound to the formats from 3551. This would bring us
down to 61. Even then going below 96 is still likely to be problematic
for many such libraries.

This actually reminds me how recently (I believe it was in Boston)
someone advised that in trickle ICE, even though 3264 allowed it, we
shouldn't be using 0.0.0.0 in descriptions with no candidates. This was
because (from the notes) "otherwise, you have to add special purpose
code to existing SDP libraries".

Emil

-- 
https://jitsi.org

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 16 May 2013 20:26:50 +0200

Adam, this is the first time I've been compared to the Iraqi Information 
Minister... another achievement unlocked!

There are just 2 issues with your correction:

1) I don't believe your comment (or the RFCs you cite) reflect currently 
deployed reality.
I've seen the lines of code - they allocate from 32 dynamic types, not 192.
So the solution you propose is going to be incompatible with deployed 
code bases.

2) If the true limit at which one has to change allocation strategy were 
to become 96, not 32, it actually strengthens my "falling off a cliff" 
argument (unless you don't believe in applications with more than 96 
streams): This won't be a problem except in rare cases - ensuring even 
more code will be deployed that works until stressed.

I also have a confession to make: On some days, I respond to mail 
addressed to me without checking that I'm caught up on the mailing list 
that the conversation is copied to.

In this case, I responded to the mail sent directly to me on May 12 (a 
Sunday) without checking that I had also read your posting to the list 
on May 8 (Wednesday on the week before).

I suppose that's enough of a lapse in courtesy to be deserving of some 
censure.

           Harald

---

From: Adam Roach <[email-masked]>
Date: Thu, 16 May 2013 13:41:36 -0500

On 5/16/13 13:26, Harald Alvestrand wrote:

> I don't believe your comment (or the RFCs you cite) reflect currently 
> deployed reality. 

I'm not sure how much design we need to do to accommodate out-of-spec 
implementations. I would be interested in knowing how pervasive this 
behavior actually is in deployments, since the proper handling of 
dynamic PTs has been well documented for nearly a decade.

> If the true limit at which one has to change allocation strategy were 
> argument

And, to be clear, it's not a cliff. For any given session (without 
a=ssrc:), you have to allocate ceiling(streams/96) ports. It's not like 
you go from using one port to using 97 ports when you add the 97th 
stream. You go from one port to two, which will handle 192 streams.

And that's okay. As you approach 100 streams, I seriously doubt that 
port utilization is going to be the constraining factor in what your 
network can support.

/a

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 16 May 2013 21:15:23 +0200

> dynamic PTs has been well documented for nearly a decade.

Since an argument that has been made in favour of Plan A is that it is 
(supposedly) more compatible with deployed code, this interests me greatly.

Has dynamic allocation of sub-96 payload numbers ever been tested at a 
SIPit, for instance?

>> to become 96, not 32, it actually strengthens my "falling off a 
>> cliff" argument
>
> a=ssrc:), you have to allocate ceiling(streams/96) ports. It's not 
> like you go from using one port to using 97 ports when you add the 
> 97th stream. You go from one port to two, which will handle 192 streams.

Going from one port to two ports is a cliff.
We may have differing opinions on how tall it is.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 16 May 2013 16:28:20 -0700

On Thu, May 16, 2013 at 12:15 PM, Harald Alvestrand <[email-masked]>wrote:
>
>  If the true limit at which one has to change allocation strategy were to
>>> become 96, not 32, it actually strengthens my "falling off a cliff" argument
>>>
>>
>> a=ssrc:), you have to allocate ceiling(streams/96) ports. It's not like you
>> go from using one port to using 97 ports when you add the 97th stream. You
>> go from one port to two, which will handle 192 streams.
>>
>

Harald,

I am not following how this is a discriminating factor between Plan A and
Plan B.

In both Plan A and Plan B, any media stream which is intended to be
independently processable by a legacy endpoint must appear on its
own m-line. That means it must also have its own independent ports,
even if you are hoping to eventually be able to mux it via BUNDLE.

In both Plan A and Plan B, it is possible to indicate additional media
streams that are not processable by a legacy endpoint but that
will be processable by a new endpoint:

- In Plan A, this is done by marking them bundle-only
- In Plan B, this is done by having them be additional SSRCs on one
  of the extant m-lines.

Regardless of Plan A versus Plan B, bundle contemplates having
multiple media flows on the same media 5-tuple. Thus, it must
be possible to demux the flows somehow. As I read Plan A,
it proposes using both PT and SSRC to demux whereas plan B
only wants to use SSRC? So, the implication is that a Plan A
endpoint must:

1. Demux on both PT and SSRC (this is trivial, I think you will agree)
2. When acting as offerer, either always offer SSRC or conditionally
offer SSRC when the # of PTs is excessive.

I don't understand why you think that plan A means more ports than
plan B. Presumably we can simply specify that bundle requires
SSRC muxing, in which case plan A and plan B behave identically.

What am I missing?

-Ekr

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 17 May 2013 08:31:59 +0200

On 05/17/2013 01:28 AM, Eric Rescorla wrote:
>
>
> On Thu, May 16, 2013 at 12:15 PM, Harald Alvestrand 
>             If the true limit at which one has to change allocation
>             strategy were to become 96, not 32, it actually
>             strengthens my "falling off a cliff" argument
>
>
>         And, to be clear, it's not a cliff. For any given session
>         (without a=ssrc:), you have to allocate ceiling(streams/96)
>         ports. It's not like you go from using one port to using 97
>         ports when you add the 97th stream. You go from one port to
>         two, which will handle 192 streams.
>
>

I agree with this characterization - the two proposals have the same 
number of ports in the initial offer.

I quibble about the characterization "any media stream which is intended 
to be
independently processable by a legacy endpoint must appear on its
own m-line." As Bernard has said, the field of deployed applications is 
diverse enough to make this question confusing - both "independently 
processable" and "legacy endpoint" may need further qualification in 
order to make that statement unequivocally true.

> 1. Demux on both PT and SSRC (this is trivial, I think you will agree)

The demuxing is trivial. In fact, I don't think it's even necessary to 
describe it as "demux on PT"; you can't allow SSRC collision between two 
tracks with different PT anyway.

> SSRC muxing, in which case plan A and plan B behave identically.

This particular issue is about what happens when you run out of payload 
types to multiplex on.

In Plan A as I currently understand Adam, any application that needs 
less than 96 M-lines (Adam's number) can use a single port, and use the 
payload type to indicate the M-line.

If there are 97 M-lines, if I've understood Adam correctly, one could 
use two ports and two bundles, with some subset of the M-lines being 
allocated to one bundle and another subset of the M-lines allocated to 
the other bundle.

In Plan B, there is no difference in the mechanism used to multiplex 96 
SSRCs from the mechanism used to multiplex 97 SSRCs, and it does not 
matter for the multiplexing how many M-lines they are distributed over.

---

From: Kevin Dempsey <[email-masked]>
Date: Fri, 17 May 2013 11:55:23 +0100

I think part of the problem is that the receiver doesn't know which media
flow a given SSRC belongs to until it is told about it by the sender. The
PT, on the other hand, is chosen by the receiver and so if that is unique
across all media flows it could be used to determine which media flow a
packet belongs to.

As others have said, signalling SSRCs is problematic as sometimes the SSRCs
are not known or can change. It also may cause clipping in cases where
media can arrive before the answer.

If RTP packets included an identifier chosen by the receiver (e.g. in a RTP
extension header) then we would not need to rely on SSRC signalling.

On 17 May 2013 07:31, Harald Alvestrand <[email-masked]> wrote:

> processable" and "legacy endpoint" may need further qualification in order
> to make that statement unequivocally true.
>
>
>
> In Plan A as I currently understand Adam, any application that needs less
> than 96 M-lines (Adam's number) can use a single port, and use the payload
> type to indicate the M-line.
>
> If there are 97 M-lines, if I've understood Adam correctly, one could use
> two ports and two bundles, with some subset of the M-lines being allocated
> to one bundle and another subset of the M-lines allocated to the other
> bundle.
>
> SSRCs from the mechanism used to multiplex 97 SSRCs, and it does not matter
> for the multiplexing how many M-lines they are distributed over.
>
>
>

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 17 May 2013 06:07:00 -0700

> to make that statement unequivocally true.

Well, to the extent to which there are many legacy endpoints which assume
that
each renderable entity must be on its own m-line, then presumably you
need to follow this rule to ensure interop, no?

> tracks with different PT anyway.

This seems to me to be true only in the trivial sense.  I.e., demuxing is
not
just a matter of separation but also of assignment. So, as Cullen has
observed, if the two m-lines use distinct PTs, the offerer can properly
demux and display the streams even before receiving the answer.

> to one bundle and another subset of the M-lines allocated to the other

Yes, one could. But one could also use one port, one bundle, and demux on
SSRC.

> for the multiplexing how many M-lines they are distributed over.

I would say rather that plan B *only* allows SSRC multiplexing whereas plan
A allows you to use other forms of multiplexing beside SSRC, but only under
limited circumstances.

However, I'm not sure why this is a big issue. The requirement for distinct
PTs isn't new to plan A. In fact, it's in Section 7.2 of BUNDLE:
http://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-03#section-7.2
This seems to me to be a question the working group needs to resolve
for BUNDLE and then it can just be inherited by either Plan A or Plan B.

-Ekr

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 17 May 2013 06:12:15 -0700

The Iraqi Information minister did not correctly communicate "facts on the ground", whereas I do think Harald correctly characterizes how some existing implementations behave. 

Given the discussion on this topic I would suggest that it would be useful to include a recommendation for WebRTC implementations (in the RTP usage document?).

On May 16, 2013, at 11:27, "Harald Alvestrand" <[email-masked]> wrote:

> Adam, this is the first time I've been compared to the Iraqi Information Minister... another achievement unlocked!
> 
> 1) I don't believe your comment (or the RFCs you cite) reflect currently deployed reality.
> So the solution you propose is going to be incompatible with deployed code bases.
> 
> 2) If the true limit at which one has to change allocation strategy were to become 96, not 32, it actually strengthens my "falling off a cliff" argument (unless you don't believe in applications with more than 96 streams): This won't be a problem except in rare cases - ensuring even more code will be deployed that works until stressed.
> 
> I also have a confession to make: On some days, I respond to mail addressed to me without checking that I'm caught up on the mailing list that the conversation is copied to.
> 
> In this case, I responded to the mail sent directly to me on May 12 (a Sunday) without checking that I had also read your posting to the list on May 8 (Wednesday on the week before).
> 
> I suppose that's enough of a lapse in courtesy to be deserving of some censure.
> 
>          Harald

---

From: Emil Ivov <[email-masked]>
Date: Fri, 17 May 2013 18:00:27 +0300

On 17.05.13, 16:07, Eric Rescorla wrote:
> 
> On Thu, May 16, 2013 at 11:31 PM, Harald Alvestrand
>     I quibble about the characterization "any media stream which is
>     intended to be
>     own m-line." As Bernard has said, the field of deployed applications
>     is diverse enough to make this question confusing - both
>     "independently processable" and "legacy endpoint" may need further
>     qualification in order to make that statement unequivocally true.
> 
> 
> Well, to the extent to which there are many legacy endpoints which
> assume that
> each renderable entity must be on its own m-line,

There are tons of legacy endpoints that know what to do with one audio
m= line. There are some legacy endpoints that which know what to do with
one audio and one video m=line.

There might be endpoints that are capable of handling multiple audio
video endpoints but I am not sure how they could possibly be quantified
as many.

> then presumably you need to follow this rule to ensure interop, no?

Therefore, the interop part with the "many" endpoints seems to be
covered already. One still needs to find ways of handling and
potentially gatewaying ICE and SRTP for many of them but that's a
different matter. O/A-wise we seem to have consensus on how to do the
case with the two m= lines that each carry one track.

It seems to me that we have now moved beyond that.

Emil

-- 
https://jitsi.org

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 17 May 2013 08:08:12 -0700

On Fri, May 17, 2013 at 8:00 AM, Emil Ivov <[email-masked]> wrote:

>
> On 17.05.13, 16:07, Eric Rescorla wrote:=line.
>

> It seems to me that we have now moved beyond that.

The question is how an endpoint which wishes fo offer more than one
audio and one video does so in a way that doesn't cause older
endpoints to choke.

-Ekr

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 17 May 2013 11:51:18 -0400

ISTM we may be mixing up two things when discussing demuxing:

* getting packets to the correct instance of the correct decoder.

Any of these proposals can handle the first. The only constraint is that 
a particular PT must be consistently mapped to the same codec and 
parameters in each bundled m-line where it appears. Its not necessary to 
restrict a PT to a particular m-line to achieve this.

* associating those packets with a particular m-line in the bundle.

There must be some combination of fields within each RTP packet that are 
unique to a particular bundled media section (m-line and friends) in the 
bundle to achieve this. That could be:

- SSRC
- PT
- the value of some RTP header extension that matches some
   new SDP attribute
- some combination of the above

This is important because it then binds that instance of the decoder to 
all the properties of the SDP media section.

I don't think it is necessary to make a single choice from the above 
list. In some cases it may be possible to infer this, by analyzing the 
SDP and identifying what combination of properties uniquely identifies 
each m-line. But in some cases it may be ambiguous. If so, then I think 
we should signal what should be used.

For instance, demux by SSRC and demux by clue capture id may yield 
conflicting results. (A  single SSRC may move from one capture to another.)

So, rather than argue about which is the right way, can't we just 
discuss how to signal which one to use?

	Thanks,
	Paul

---

From: Emil Ivov <[email-masked]>
Date: Fri, 17 May 2013 19:02:45 +0300

On 17.05.13, 18:08, Eric Rescorla wrote:
> On Fri, May 17, 2013 at 8:00 AM, Emil Ivov <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> 

I might be misunderstanding or missing something, but isn't it clear
that, if you are trying not to choke anyone, the first thing to do would
be to stick to a single m= line for audio and a single m= line for video?

Emil

-- 
https://jitsi.org

---

From: Martin Thomson <[email-masked]>
Date: Fri, 17 May 2013 09:10:04 -0700

> tracks with different PT anyway.

Let's be very, very precise about this.

Demultiplexing is *always* performed based on SSRC.  It's just that
correlation with signaling components (the m-line in this case) might
use of PT in the absence of prior knowledge of SSRC.

We didn't get this quite right in Plan A.

---

From: Adam Roach <[email-masked]>
Date: Mon, 20 May 2013 17:43:14 +0800

> (supposedly) more compatible with deployed code, this interests me 

The other, probably more important factor when we're talking about 
legacy interop is that it will be hard (impossible?) to find *legacy* 
implementations that use more than 32 streams -- making this pretty much 
a non-issue from a legacy perspective.

However, I think we do need to be explicit that RTCWEB implementations 
need to actually implement the AVT profile as specified, including the 
ability to use 96 PTs.

/a

---

From: Adam Roach <[email-masked]>
Date: Mon, 20 May 2013 17:45:04 +0800

> We didn't get this quite right in Plan A.

Yeah, that's a valid point. It's not really being proposed as a demux 
point as much as a correlation token. Thanks for clearing that up -- we 
should definitely clear that up in the next version of the document.

/a

---

From: Adam Roach <[email-masked]>
Date: Mon, 20 May 2013 17:46:51 +0800

> be to stick to a single m= line for audio and a single m= line for video?

Not if you're talking to a device that expects three media streams -- 
such things have historically used three m=video sections (one for each 
stream). Which is kind of the reason we're specifying Plan A the way we are.

/a

---

From: Emil Ivov <[email-masked]>
Date: Mon, 20 May 2013 13:08:20 +0300

> Not if you're talking to a device that expects three media streams -- 

This gets back to my original point: I don't see how such a device would
qualify as one of the "many legacy endpoints that have already been
deployed".

> stream). Which is kind of the reason we're specifying Plan A the way we are.

I get that, but I don't believe it is an effort to guarantee interop
with legacy. It's an effort to talk to specific applications that use
such signalling.

Note that if you really need to interoperate with such applications you
would still be able to do this if WebRTC gave you the necessary API.
You would then have the choice of modifying the browser's SDP in the
javascript or handling it all in a signalling gateway.

Emil

-- 
https://jitsi.org

---

From: Colin Perkins <[email-masked]>
Date: Mon, 20 May 2013 12:17:36 +0100

On 20 May 2013, at 10:45, Adam Roach wrote:
> Yeah, that's a valid point. It's not really being proposed as a demux point as much as a correlation token. Thanks for clearing that up -- we should definitely clear that up in the next version of the document.

Rather than try to overload the PT, I would suggest we define an explicit correlation token that can be sent. Put something in RTCP SDES and/or RTP header extensions, and in the SDP, to signal what RTP flow corresponds to what m-line.

-- 
Colin Perkins
http://csperkins.org/

---

From: Colin Perkins <[email-masked]>
Date: Mon, 20 May 2013 12:22:24 +0100

On 20 May 2013, at 10:43, Adam Roach wrote:
>> Since an argument that has been made in favour of Plan A is that it is (supposedly) more compatible with deployed code, this interests me greatly. 
> 
> The other, probably more important factor when we're talking about legacy interop is that it will be hard (impossible?) to find *legacy* implementations that use more than 32 streams -- making this pretty much a non-issue from a legacy perspective.
> 
> However, I think we do need to be explicit that RTCWEB implementations need to actually implement the AVT profile as specified, including the ability to use 96 PTs.

Do you want to propose some text for the rtp-usage draft that clarifies this? If there's agreement, we can then include it. 

-- 
Colin Perkins
http://csperkins.org/

---

From: Adam Roach <[email-masked]>
Date: Mon, 20 May 2013 20:19:18 +0800

> Rather than try to overload the PT, I would suggest we define an explicit correlation token that can be sent. Put something in RTCP SDES and/or RTP header extensions, and in the SDP, to signal what…

That kind of defeats some of the purpose here, which includes working 
with existing deployed implementations.

/a

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 20 May 2013 13:32:05 +0000

Hi,

>>>> correlation with signaling components (the m-line in this case) 
>>>> might use of PT in the absence of prior knowledge of SSRC.
>>>>
>> Rather than try to overload the PT, I would suggest we define an explicit correlation token that can be sent. Put something in RTCP SDES 
>> and/or RTP header extensions, and in the SDP, to signal what RTP flow corresponds to what m-line.
>
> That kind of defeats some of the purpose here, which includes working with existing deployed implementations.

Existing deployments will use different port numbers, so you would be able to separate media belonging to different m- lines (as different 5-tuples will be used), so you would not need to use the extension.

Regards,

Christer

---

From: "Roni Even" <[email-masked]>
Date: Mon, 20 May 2013 16:44:41 +0300

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Adam Roach
Sent: 20 May, 2013 12:47 PM
To: Emil Ivov
Cc: [email-masked]
Subject: Re: [rtcweb] Plan A, respun

On 5/18/13 00:02, Emil Ivov wrote:
> that, if you are trying not to choke anyone, the first thing to do 
> would be to stick to a single m= line for audio and a single m= line for
video?

>Not if you're talking to a device that expects three media streams -- such
things have historically used three m=video sections (one for each stream).
Which >is kind of the reason we're specifying Plan A the way we are.

When a device offers three video m-lines and the other EP can receive only
one there is no interoperability specified and this will be a more common
case.

/a

---

From: "Roni Even" <[email-masked]>
Date: Mon, 20 May 2013 16:48:57 +0300

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Adam Roach
Sent: 20 May, 2013 3:19 PM
To: Colin Perkins
Cc: [email-masked]
Subject: Re: [rtcweb] Plan A, respun

>
> Rather than try to overload the PT, I would suggest we define an explicit
correlation token that can be sent. Put something in RTCP SDES and/or RTP
header extensions, and in the SDP, to signal what RTP flow corresponds to
what m-line.

>That kind of defeats some of the purpose here, which includes working with
existing deployed implementations.

I do not understand why it breaks. When existing implementation receive
three m-lines it is not specified what behavior they will take if they
support different number of RTP streams and there is no specification about
how they will render the three m-lines (no mapping)

/a

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 23 May 2013 13:47:52 +0200

Apologies for being late in the response....

> On 15.05.13, 09:24, Harald Alvestrand wrote:

<snip>
> actually belong to some specific stream.
Hm. Declaring a moratorium on "onaddstream" events while a negotiation 
is in progress actually solves the problem - I think!

In the case where signalling takes a while to complete (response got 
lost, signalling relay server is overloaded, or something else weird 
happens) we do have a problem with buffering - we have to be able to 
throw away some data at some point, or we require infinite buffers. But 
throwing away RTP data is something we have to deal with anyway - 
recovery should not be much worse than after a temporary transmission 
glitch.

> wish. Before, with, or after the SDP O/A has taken place.

If we're depending on RTCP, we have to wait until the first RTCP packet 
arrives, of course.

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 24 May 2013 12:58:19 -0700

On May 23, 2013, at 4:48, "Harald Alvestrand" <[email-masked]> wrote:

> If we're depending on RTCP, we have to wait until the first RTCP packet arrives, of course.

[BA] Yes. The same is also true of parameters transmitted in RTP - they should be sent first, but may not necessarily arrive in order or at all. That is why there is no substitute for reliable signaling at call setup, and why RTP/RTCP control is more for changes in "mid stream", where speed is a consideration, and loss can be tolerated. For example, if the potential simulcast/layered streams are defined in SDP up front, they can be rapidly switched on and off without requiring signaling. This is one potential use of RTCP pause/resume.

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Thu, 30 May 2013 19:40:56 +0000

On May 16, 2013, at 1:15 PM, Harald Alvestrand <[email-masked]> wrote:

> Has dynamic allocation of sub-96 payload numbers ever been tested at a SIPit, for instance?

Yes