Subject: [rtcweb] RTP multiplexing - my understanding of status

From: Harald Alvestrand <[email-masked]>
Date: Mon, 13 Jun 2011 14:14:11 +0200

I thought I'd try to capture my understanding of the state of play wrt 
RTP multiplexing as of the end of Wednesday's meeting.

As I understand it, we have two possibilities for guidelines, and the 
difference between them can be decided on whether it's technically 
feasible or not to put audio and video into the same RTP session.

(for the sake of clarity of argument, I'm claiming that only two types 
of media exist: audio and video, and I'm ignoring the question of 
additional sessions for FEC. It's simpler to see what we come out with 
that way.)

-------------------------------------------------

1) draft-perkins-rtcweb-rtp-usage, as clarified in discussion:

Each RTCWEB user has two RTP sessions active. All outgoing and incoming 
audio channels go on one RTP session; all outgoing and incoming RTP 
sessions go on the other RTP session.

Audio and video from a single user is correlated based on the CNAME; the 
SSRC for streams with the same CNAME can be different in the two RTP 
sessions.

Each RTP session, together with its RTCP data, is carried over a single 
pair of ports (5-tuple, for those who prefer that terminology) between 
each pair of participants. The RTP sessions are bidirectional.

(Note: in draft-holmberg's scenario 4.3, multiparty without central 
server, there are multiple participants; I don't know if this would have 
only one pair of RTP sessions or one per pair.)

2) A not-yet-written-up alternative:

Each RTCWEB user has one RTP session active. Audio and video both use 
the same RTP session. Streams from the same user all have the same 
CNAME; the audio and video stream [must have different SSRCs|can have 
the same SSRC|must have the same SSRC]. <not sure what to write here - 
last alternative doesn't make sense if a single user sends multiple 
streams of the same PT>

All data between two participants is carried over a single 5-tuple.

-------------------------------------------
I recognize that this is a gross simplification that glosses over 
significant detail, but ... can we agree that this is a roughly correct 
description of the alternatives we were talking about?

                 Harald

---

From: Colin Perkins <[email-masked]>
Date: Mon, 13 Jun 2011 13:27:32 +0100

On 13 Jun 2011, at 13:14, Harald Alvestrand wrote:
> I thought I'd try to capture my understanding of the state of play wrt RTP multiplexing as of the end of Wednesday's meeting.
> 
> As I understand it, we have two possibilities for guidelines, and the difference between them can be decided on whether it's technically feasible or not to put audio and video into the same RTP session.
> 
> (for the sake of clarity of argument, I'm claiming that only two types of media exist: audio and video, and I'm ignoring the question of additional sessions for FEC. It's simpler to see what we come out with that way.)
> 
> Each RTCWEB user has two RTP sessions active. All outgoing and incoming audio channels go on one RTP session; all outgoing and incoming RTP sessions go on the other RTP session.
> 
> Audio and video from a single user is correlated based on the CNAME; the SSRC for streams with the same CNAME can be different in the two RTP sessions.
> 
> Each RTP session, together with its RTCP data, is carried over a single pair of ports (5-tuple, for those who prefer that terminology) between each pair of participants. The RTP sessions are bidirectional.
> 
> (Note: in draft-holmberg's scenario 4.3, multiparty without central server, there are multiple participants; I don't know if this would have only one pair of RTP sessions or one per pair.)
> 
> Each RTCWEB user has one RTP session active. Audio and video both use the same RTP session. Streams from the same user all have the same CNAME; the audio and video stream [must have different SSRCs|can have the same SSRC|must have the same SSRC]. <not sure what to write here - last alternative doesn't make sense if a single user sends multiple streams of the same PT>
> 
> I recognize that this is a gross simplification that glosses over significant detail, but ... can we agree that this is a roughly correct description of the alternatives we were talking about?

RTP requires some lower-layer demultiplexing point to identify sessions. A third alternative is to introduce some shim-layer between RTP and UDP that can provide this demultiplexing point. This has the advantage that it also only uses a single 5-tuple, but unlike option 2, doesn't break the RTP protocol.

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

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 13 Jun 2011 14:34:23 +0200

On 06/13/11 14:27, Colin Perkins wrote:
>> Each RTCWEB user has one RTP session active. Audio and video both use the same RTP session. Streams from the same user all have the same CNAME; the audio and video stream [must have different SSRCs|can have the same SSRC|must have the same SSRC].<not sure what to write here - last alternative doesn't make sense if a single user sends multiple streams of the same PT>
>>
Yes - the disadvantage is of course that it kills all hope of 
interoperability with any other RTP implementation; people may or may 
not think of that as "breaking the RTP protocol".

An interesting property of RTP is that if a third party monitors two 
packet streams on different ports, I don't think he can tell whether 
they belong to the same RTP session or not - the tying of transport 
5-tuples to RTP sessions is n-to-n, and must be done using singalling.

              Harald

---

From: Colin Perkins <[email-masked]>
Date: Mon, 13 Jun 2011 13:37:41 +0100

On 13 Jun 2011, at 13:34, Harald Alvestrand wrote:
> Yes - the disadvantage is of course that it kills all hope of interoperability with any other RTP implementation; people may or may not think of that as "breaking the RTP protocol".

Option 2 cannot directly interoperate with standard RTP either. They both need some form of gateway to separate the sessions. 

Colin

> An interesting property of RTP is that if a third party monitors two packet streams on different ports, I don't think he can tell whether they belong to the same RTP session or not - the tying of transport 5-tuples to RTP sessions is n-to-n, and must be done using singalling.
> 
>             Harald
> 
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

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

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Mon, 13 Jun 2011 08:28:43 -0700

>>>> sessions go on the other RTP session.

s/sessions go/video goes/, I assume?

>>>> Each RTCWEB user has one RTP session active. Audio and video both use the

Allow me to make a suggestion for how this might work below...

>>> RTP requires some lower-layer demultiplexing point to identify sessions. A
>>> third alternative is to introduce some shim-layer between RTP and UDP that
>>> can provide this demultiplexing point. This has the advantage that it also
>>> only uses a single 5-tuple, but unlike option 2, doesn't break the RTP
>>> protocol.

So, I looked at some of RFCs mentioned in the rtp-usage-01 draft.

RFC 2733 (FEC) says, "For unicast, different ports or different SSRC may 
be used. Each of these approaches has drawbacks and benefits which 
depend on the application." This flexibility was apparently removed 8 
years later in RFC 5109, though I suspect there are a number of people 
in this WG who still believe the second sentence from RFC 2733 is true.

RFC 4588 (retransmission) also says, "These two streams may be 
multiplexed either by sending them in two different sessions, i.e., 
session-multiplexing, or in the same session using different SSRC 
values, i.e., SSRC-multiplexing."

>> Yes - the disadvantage is of course that it kills all hope of interoperability
>> with any other RTP implementation; people may or may not think of that as
>> "breaking the RTP protocol".

The problem, as I see it, is that ports are rare and expensive, and SSRC 
values are plentiful and cheap. With NATs, many endpoints (and 
potentially pairs of hosts) must share the same port namespace, and 
firewalls/routers/etc. consume resources for each one. In contrast, 
there are 32-bits of available SSRC space per CNAME, but the number of 
actual streams needed is usually quite small and self-limiting (since 
there are normally significant processing requirements at the endpoints 
associated with each one).

I propose taking the most significant, say, 8 bits of the SSRC value and 
using them as a "pseudo-session" identifier. Then the association of 
mutliple streams for purposes of scalability, retransmission, and FEC 
can be done simply by clearing the top 8 bits, with no signaling required.

This can be thought of as a variation of the "shim-layer" approach (what 
has been meant by that has never been clear to me, but my assumption has 
always been that it would encapsulate the RTP packets with yet another 
header), but it has some advantages:

1) No additional bytes must be transmitted. IP+UDP+RTP is already 40 
bytes, or 16 kbps when sending 50 packets per second (typical for audio, 
where this is a significant fraction of the total bandwidth).

2) Interoperability with existing RTP implementations works for the 
cases where only a single session is needed (e.g., simple audio, or even 
audio with some amount of FEC, as the packet sizes are typically much 
smaller than an MTU).

3) As the change and semantics are relatively simple, eventually 
upgrading existing RTP deployments should not be hard.

For interoperability in more complex cases, you can add the same 
translation tool a shim-layer would normally need, and it can be just as 
simple and generic.

So, what does this break?

RFC 3550 Section 5.2 lists 5 points. The first 3 are eliminated by using 
different SSRCs. Point 4 is, "An RTP mixer would not be able to combine 
interleaved streams of incompatible media into one stream," which is 
still true, but it would be able to combine them into a small number of 
streams, the same as if they had been transmitted in different sessions, 
based on media type (which it would have to know to be able recombine 
them at all), so I'm not sure what the actual drawback is here. Point 5 
says SSRC-multiplexing precludes 3 things:

A) "...the use of different network paths or network resource 
allocations if appropriate..." Resource allocation already requires deep 
packet inspection for many parts of the internet, and the inspection 
required here is not particularly onerous (masking off a fixed-size 
field at a fixed offset that is always transmitted in the clear, even 
for SRTP).

B) "...reception of a subset of the media, if desired, for example just 
audio if video would exceed the available bandwidth..." This is true, 
but I expect rtcweb to be mostly point-to-point, and that these 
decisions should be made during call setup, so this doesn't really apply 
(I assume it was meant for multicast environments where one might wish 
to subscribe to a subset of the available streams).

C) "...receiver implementations that use separate processes for the 
different media..." It would not be hard to write packet-filter rules to 
distribute the separate session data to multiple processes if this was 
really desired, but at least at the endpoints, is there really much 
expectation that audio and video data which must be synchronized to a 
single, common clock can be processed in separate processes?

What else am I missing?

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 13 Jun 2011 17:41:17 +0200

> s/sessions go/video goes/, I assume?
Yes, sorry about that. Silly of me, since it's the whole point.

I'll hold off on commenting on the rest of the message.

---

From: Randell Jesup <[email-masked]>
Date: Mon, 13 Jun 2011 11:49:34 -0400

>>> RTP requires some lower-layer demultiplexing point to identify sessions. A third alternative is to introduce some shim-layer between RTP and UDP that can provide this demultiplexing point. This h…

I assume the Matthew Kaufman here is the same one who presented the 
paper on RTMFP for Adobe at IETF 77.  :-)  From the email address, I 
take it you work for Skype now.

While that protocol per se may be out-of-bounds (proprietary, patents), 
some of the problems they were trying to solve aren't entirely different 
than what we're looking at here.  In particular, there may be advantages 
in setup time and complexity to reducing the number of "5-tuples" 
required and multiplexing data.  For example, if you need to poke holes 
in a firewall using UPnP it can be painful and slow (to the point where 
we at WorldGate pre-poked holes to use if a call came in, and we had to 
keep 2 or 3 sets of holes open to handle call-waiting cases, etc).  Even 
ignoring that and just considering ICE, the number of messages to open N 
ports is a lot higher than 1 or a pair of ports, and it may also 
increase the chance of a single-packet loss interfering and slowing down 
convergence (or pushing ICE to select a sub-optimal connection method).  
Also, what are the odds of ICE selecting different methods for the 
different streams?

As mentioned, if this is done as a shim/multiplex layer it simplifies 
interop with existing voice gateways.  Side note: there is a draft for 
(just) multiplexing RTP and RTCP which I had weighed in on and 
supported; I forget where it stands currently.

Another goal from RTMFP that is worth considering is consolidated 
congestion control - doing congestion control and bandwidth 
measurement/adaptation across all the streams exchanged with another 
endpoint together.  This is simplified by using a single or smaller 
number of "5-tuples", though it isn't gated on that.

Thought should be given to some of the other goals of RTMFP and if 
they're in-scope or not.  (IP addr changes, etc).

---

From: Randell Jesup <[email-masked]>
Date: Mon, 13 Jun 2011 13:07:15 -0400

On 6/13/2011 11:28 AM, Timothy B. Terriberry wrote:
> RFC 2733 (FEC) says, "For unicast, different ports or different SSRC 
> may be used. Each of these approaches has drawbacks and benefits which 
>>> interoperability
> The problem, as I see it, is that ports are rare and expensive, and 
> SSRC values are plentiful and cheap. With NATs, many endpoints (and 
> there are normally significant processing requirements at the 
> endpoints associated with each one).
>
> I propose taking the most significant, say, 8 bits of the SSRC value 
> and using them as a "pseudo-session" identifier. Then the association 
> of mutliple streams for purposes of scalability, retransmission, and 
> FEC can be done simply by clearing the top 8 bits, with no signaling 
> required.

I can understand the temptation to re-purpose the SSRC in this manner.

> This can be thought of as a variation of the "shim-layer" approach 
> (what has been meant by that has never been clear to me, but my 
> assumption has always been that it would encapsulate the RTP packets 
> with yet another header), but it has some advantages:

I would assume the "shim layer" suggested is a multiplexor byte or more 
between RTP/RTCP and UDP.

> bytes, or 16 kbps when sending 50 packets per second (typical for 
> audio, where this is a significant fraction of the total bandwidth).

Agreed.

> cases where only a single session is needed (e.g., simple audio, or 
> even audio with some amount of FEC, as the packet sizes are typically 
> much smaller than an MTU).

In my experience, most video implementations (which can fill packets) 
avoid using every possible byte in an ethernet MTU because this can 
cause problems with things like PPPOE/etc (which is a form of shim layer 
itself).  It does mean you don't need to strip the shim layer outgoing, 
and you don't need to fragment (in the rare case of full-MTU incoming).  
Note however this may cause issues with interop requiring SSRC 
translation, since the interop device may change SSRCs to any value at 
will, and SSRC translation gets fun when you have to deal with RTCP and 
all the variants like XR report blocks.  Perhaps I'm overplaying the 
issues here; Magnus & Colin are probably more familiar with the issues.

> upgrading existing RTP deployments should not be hard.

You mean "RTP v3"?  Perhaps I mis-understand your comment.  Technically 
it wouldn't be hard, but in practice I think you'd have to wait a long 
time even if there was agreement that this was the "next step" for RTP - 
you'd need pretty much for all existing equipment to be end-of-lifed and 
retired.  There's little or no incentive for them to switch, let alone 
upgrade existing devices and servers.

> translation tool a shim-layer would normally need, and it can be just 
> as simple and generic.
>
> RFC 3550 Section 5.2 lists 5 points. The first 3 are eliminated by 
> using different SSRCs. Point 4 is, "An RTP mixer would not be able to 
> combine interleaved streams of incompatible media into one stream," 
> which is still true, but it would be able to combine them into a small 
> number of streams, the same as if they had been transmitted in 
> different sessions, based on media type (which it would have to know 
> to be able recombine them at all), so I'm not sure what the actual 
> drawback is here. Point 5 says SSRC-multiplexing precludes 3 things:
>
> allocations if appropriate..." Resource allocation already requires 
> deep packet inspection for many parts of the internet, and the 
> inspection required here is not particularly onerous (masking off a 
> fixed-size field at a fixed offset that is always transmitted in the 
> clear, even for SRTP).

An example of this is resource-reservations (in particular upstream 
bandwidth) done on HFC cable access networks.  I know such things used 
to be done circa 4-5 years ago, or at least were being played with by 
the cable companies.  In theory different media (audio vs video) could 
be treated differently by a resource-reservation if they're on separate 
ports; I'm not sure that's ever actually done however.

> B) "...reception of a subset of the media, if desired, for example 
> just audio if video would exceed the available bandwidth..." This is 
> true, but I expect rtcweb to be mostly point-to-point, and that these 
> decisions should be made during call setup, so this doesn't really 
> apply (I assume it was meant for multicast environments where one 
> might wish to subscribe to a subset of the available streams).

This is a fairly bogus issue at least for the rtcweb use-cases I know 
of, in that you need the sender to throttle if you want to save 
available bandwidth, though in theory a midbox or conference server 
could do so for you.  These decisions may be made in-call instead of at 
setup, but they still require coordination with the sender.

> different media..." It would not be hard to write packet-filter rules 
> to distribute the separate session data to multiple processes if this 
> was really desired, but at least at the endpoints, is there really 
> much expectation that audio and video data which must be synchronized 
> to a single, common clock can be processed in separate processes?

Well, RTP is designed to not only allow separate processes to handle 
different media types (streams) but also to allow different devices (IP 
addresses) for each stream in a session.  And yes, such devices really 
do exist.  In the context of rtcweb, however, I can't think of a 
use-case for this ability.  (Magnus, Colin?)

-- 
Randell Jesup
[email-masked]

---

From: Colin Perkins <[email-masked]>
Date: Mon, 13 Jun 2011 18:14:37 +0100

On 13 Jun 2011, at 16:28, Timothy B. Terriberry wrote:
>>>> RTP requires some lower-layer demultiplexing point to identify sessions. A third alternative is to introduce some shim-layer between RTP and UDP that can provide this demultiplexing point. This has the advantage that it also only uses a single 5-tuple, but unlike option 2, doesn't break the RTPprotocol.
> 
> RFC 2733 (FEC) says, "For unicast, different ports or different SSRC may be used. Each of these approaches has drawbacks and benefits which depend on the application." This flexibility was apparently removed 8 years later in RFC 5109, though I suspect there are a number of people in this WG who still believe the second sentence from RFC 2733 is true.

I'm sure there are. Unfortunately, the SSRC multiplexing mechanism used in RFC 2733 breaks when a participant tries to send several streams in the session, which is why RFC 5109 mandates a separate RTP session for the FEC. 

> RFC 4588 (retransmission) also says, "These two streams may be multiplexed either by sending them in two different sessions, i.e., session-multiplexing, or in the same session using different SSRC values, i.e., SSRC-multiplexing."

Again, as Section 5.3 of RFC 4588 explains, there are difficulties when using SSRC multiplexing when a participant tries to send several streams in a session.

In both cases, SSRC multiplexing appears to work, until you consider the more complex scenarios in which RTP is used.

> The problem, as I see it, is that ports are rare and expensive, and SSRC values are plentiful and cheap. With NATs, many endpoints (and potentially pairs of hosts) must share the same port namespace, and firewalls/routers/etc. consume resources for each one.

So add a shim layer to demultiplex, sitting between the UDP header and the RTP header. Don't break RTP.

> In contrast, there are 32-bits of available SSRC space per CNAME, but the number of actual streams needed is usually quite small and self-limiting (since there are normally significant processing requirements at the endpoints associated with each one).
> 
> I propose taking the most significant, say, 8 bits of the SSRC value and using them as a "pseudo-session" identifier. Then the association of mutliple streams for purposes of scalability, retransmission, and FEC can be done simply by clearing the top 8 bits, with no signaling required.
> 
> This can be thought of as a variation of the "shim-layer" approach (what has been meant by that has never been clear to me, but my assumption has always been that it would encapsulate the RTP packets with yet another header), but it has some advantages:

The shim could be a simple as a single byte to identify the RTP session prepended onto the packets (there might be advantages in using something more complex like RTP in DCCP in UDP encapsulation, but this also has some significant costs).

> 1) No additional bytes must be transmitted. IP+UDP+RTP is already 40 bytes, or 16 kbps when sending 50 packets per second (typical for audio, where this is a significant fraction of the total bandwidth).
> 
> 2) Interoperability with existing RTP implementations works for the cases where only a single session is needed (e.g., simple audio, or even audio with some amount of FEC, as the packet sizes are typically much smaller than an MTU).

It's not clear that this interoperates, since the other endpoint might pick one of the reserved SSRC values. You'd need to translate the SSRC at the gateway, which is non-trival once you start including RTCP packets in the translation.

> 3) As the change and semantics are relatively simple, eventually upgrading existing RTP deployments should not be hard.

The semantics are complex, especially once you start to think about the interactions with the RTCP timing rules. It would be much simpler to add a demultiplexing shim.

> For interoperability in more complex cases, you can add the same translation tool a shim-layer would normally need, and it can be just as simple and generic.

It's much more complex, since you may need to rewrite SSRC values in RTCP and deal with the differences in RTCP timing and participant timeout.

> RFC 3550 Section 5.2 lists 5 points. The first 3 are eliminated by using different SSRCs. Point 4 is, "An RTP mixer would not be able to combine interleaved streams of incompatible media into one stream," which is still true, but it would be able to combine them into a small number of streams, the same as if they had been transmitted in different sessions, based on media type (which it would have to know to be able recombine them at all), so I'm not sure what the actual drawback is here. Point 5 says SSRC-multiplexing precludes 3 things:
> 
> A) "...the use of different network paths or network resource allocations if appropriate..." Resource allocation already requires deep packet inspection for many parts of the internet, and the inspection required here is not particularly onerous (masking off a fixed-size field at a fixed offset that is always transmitted in the clear, even for SRTP).

Demultiplexing based on a shim is also no more onerous.

> B) "...reception of a subset of the media, if desired, for example just audio if video would exceed the available bandwidth..." This is true, but I expect rtcweb to be mostly point-to-point, and that these decisions should be made during call setup, so this doesn't really apply (I assume it was meant for multicast environments where one might wish to subscribe to a subset of the available streams).

It's also useful in unicast environments. 

> C) "...receiver implementations that use separate processes for the different media..." It would not be hard to write packet-filter rules to distribute the separate session data to multiple processes if this was really desired, but at least at the endpoints, is there really much expectation that audio and video data which must be synchronized to a single, common clock can be processed in separate processes?

There have been implementations that work that way, but a more common issue might be where audio and video are rendered by different devices.

> What else am I missing?

You also break the RTCP timing rules and participant timeouts, the SSRC allocation, and the SSRC collision detection and resolution algorithm. All of these make it incompatible with other RTP implementations. 

And all to avoid a one byte shim layer...

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

---

From: Colin Perkins <[email-masked]>
Date: Mon, 13 Jun 2011 18:27:34 +0100

On 13 Jun 2011, at 18:07, Randell Jesup wrote:
>> The problem, as I see it, is that ports are rare and expensive, and SSRC values are plentiful and cheap. With NATs, many endpoints (and potentially pairs of hosts) must share the same port namespace, and firewalls/routers/etc. consume resources for each one. In contrast, there are 32-bits of available SSRC space per CNAME, but the number of actual streams needed is usually quite small and self-limiting (since there are normally significant processing requirements at the endpoints associated with each one).
>> 
> I would assume the "shim layer" suggested is a multiplexor byte or more between RTP/RTCP and UDP.
> 
>> 
> In my experience, most video implementations (which can fill packets) avoid using every possible byte in an ethernet MTU because this can cause problems with things like PPPOE/etc (which is a form of shim layer itself).  It does mean you don't need to strip the shim layer outgoing, and you don't need to fragment (in the rare case of full-MTU incoming).  Note however this may cause issues with interop requiring SSRC translation, since the interop device may change SSRCs to any value at will, and SSRC translation gets fun when you have to deal with RTCP and all the variants like XR report blocks.  Perhaps I'm overplaying the issues here; Magnus & Colin are probably more familiar with the issues.

No, the translation will get very difficult once you consider all the RTCP packet types. The trivial case can be made to work, but the complexity rapidly spirals up as you consider all the other ways in which RTP is used.

> You mean "RTP v3"?  Perhaps I mis-understand your comment.  Technically it wouldn't be hard, but in practice I think you'd have to wait a long time even if there was agreement that this was the "next step" for RTP - you'd need pretty much for all existing equipment to be end-of-lifed and retired.  There's little or no incentive for them to switch, let alone upgrade existing devices and servers.
> 
> An example of this is resource-reservations (in particular upstream bandwidth) done on HFC cable access networks.  I know such things used to be done circa 4-5 years ago, or at least were being played with by the cable companies.  In theory different media (audio vs video) could be treated differently by a resource-reservation if they're on separate ports; I'm not sure that's ever actually done however.
> 
> This is a fairly bogus issue at least for the rtcweb use-cases I know of, in that you need the sender to throttle if you want to save available bandwidth, though in theory a midbox or conference server could do so for you.  These decisions may be made in-call instead of at setup, but they still require coordination with the sender.
> 
> Well, RTP is designed to not only allow separate processes to handle different media types (streams) but also to allow different devices (IP addresses) for each stream in a session.  And yes, such devices really do exist.  In the context of rtcweb, however, I can't think of a use-case for this ability.  (Magnus, Colin?)

We don't have a use case, or we don't have a use case _yet_? While we may not want to support more advanced scenarios today, we don't want to make decisions which preclude them if we can avoid it (and, in this case, we can easily avoid it by either using separate UDP ports, or by adding a shim layer between UDP and RTP, and leaving the SSRC semantics alone).

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

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 13 Jun 2011 11:53:32 -0600

> We don't have a use case, or we don't have a use case _yet_? While we may not want to support more advanced scenarios today, we don't want to make decisions which preclude them if we can avoid it (…

One possible use case is I want the video displayed in my browser but the audio going to a high quality speaker phone on my desk. People often do this with soft phones today so it is easy to imagine them wanting to do with a browser and phone. So I can impinge a use case, however... I'm not seeing that this use case changes much. Assuming that SSRC multiplex is signaled and both ends negotiate using it, I'm not understanding Colin's & Magnus draft well enough to see what breaks that people care about. 

Cullen <in my individual contributor role>

---

From: Colin Perkins <[email-masked]>
Date: Mon, 13 Jun 2011 19:40:43 +0100

> One possible use case is I want the video displayed in my browser but the audio going to a high quality speaker phone on my desk. People often do this with soft phones today so it is easy to imagin…

The problem is in signalling the SSRC multiplexing, partitioning the SSRC space between the different RTP sessions, and updating the RTP end-points and middleboxes to cope with the changed SSRC semantics and RTCP timing rules. All of this is possible, but the result isn't compatible with RTP as it stands now, and is not easy to gateway into a standard RTP session. 

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

---

From: Dzonatas Sol <[email-masked]>
Date: Mon, 13 Jun 2011 11:50:41 -0700

On 06/13/2011 10:07 AM, Randell Jesup wrote:
> different media types (streams) but also to allow different devices 
> (IP addresses) for each stream in a session.  And yes, such devices 
> really do exist.  In the context of rtcweb, however, I can't think of 
> a use-case for this ability.  (Magnus, Colin?)
>

The basic common clock is most available in kernel mode, so of course 
use-cases are harder to delineate that way unless there are ties into 
that mode (into user mode). Exploitation of that clock can lead to 
over-usage of resources, which then lead to known depletion of energy or 
cause resource imbalances.

That's why my previous message hinted about the colosseum, yet think 
where every seat has their own clock however set (i.e. for now, 
cellphone-cams or D8 media). Start with one solution as if the Olympics 
would setup some kind of heartbeat server for all media that stems 
(ports) from such an event. It's not an odd use-case unless the idea of 
software development doesn't belong in any kind of Olympic theme (which 
seems anti-Olympian and only supports privatization in such idea). I 
have distributed processes in mind that go over collections of assets or 
posted content and render the scene. The harder part is how-to layout 
the words for specific use-case that does not favor any particular 
development or group other than to say "on the Olympic scale."

The Olympics prove how resourceful people are in reality, and the rings 
represent such elementary thinking.

-- 
--- https://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant