Subject: [rtcweb] Quick comments on draft-roach-rtcweb-glareless-add-00

From: Ted Hardie <[email-masked]>
Date: Tue, 7 May 2013 14:17:37 -0700

Hi Adam,

Taking the first look at this, there were two quick issues I wanted to
mention.  The first is this text:

"In the offer-answer model used by RTCWEB, "glare" arises when
offer messages "cross on the wire" (that is, both parties in a session
attempt to change the session at the same time)."

While RTCWEB is being built to support offer/answer, there is no
requirement that an application use that model for the interaction
between two clients.  So, this wording might need to get a tweak.

Second, it seems like the avoidance of glare by having a single
offer/answerer at a time would work in most cases, but I'm wondering
why the initial exchange isn't simply a request to change roles?   If
the initial offer role is determined by time, one of the options seems to
be to accede to a request by the other client to become the offerer.  Is
this because you're concerned that it would add a round trip?  If so,
would including the "potential offer" with the request to change role
solve that problem?

regards,

Ted

---

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

On 5/7/13 16:17, Ted Hardie wrote:
> between two clients.

I'm not sure that's right. When calling setRemoteDescription / 
setLocalDescription, the RTCSessionDescription objects contain a 
mandatory "type" field that must be "offer", "answer", or "pranswer." 
This really makes the 3264 offer/answer model pretty thoroughly baked 
into the system.

>   So, this wording might need to get a tweak.

If I'm wrong above, I'm happy to take text that explains this fact. I 
can't craft any right now, since I don't know how you would set up a 
WebRTC session (I say WebRTC since we're really talking about the API 
side of things here) without use of offer/answer.

> be to accede to a request by the other client to become the offerer.

That's an interesting approach that certainly works just fine. It's 
probably worth documenting as an alternative. One thing to note is that 
the technique described in my draft is something applications can apply 
unilaterally without any standardization work; whether they choose to 
perform a solicitation/offer/answer or role-switch/offer/answer is 
something implementors can decide to do as they see fit. Implementations 
can even do both, with the decision about which approach to use at any 
given moment dictated by which works best for the current application 
behavior.

The only real twist this introduces is for the work described in section 
3. If we think this role switching behavior is useful, then it's 
probably something that we would want to include in any equivalent SIP 
mechanisms.

> Is this because you're concerned that it would add a round trip?

I think it's more like half a round trip, but it's not worth splitting 
hairs over. In any case, I'm not terribly concerned about an extra 
(half-)round-trip delay for mid-session media changes.

/a

---

From: Ted Hardie <[email-masked]>
Date: Tue, 7 May 2013 15:29:49 -0700

On Tue, May 7, 2013 at 3:07 PM, Adam Roach <[email-masked]> wrote:

> setLocalDescription, the RTCSessionDescription objects contain a mandatory
> "type" field that must be "offer", "answer", or "pranswer." This really
> makes the 3264 offer/answer model pretty thoroughly baked into the system.
>
> Well, the overview document is pretty careful in its terminology:

"

      The RTCWEB media negotiations will be capable of representing the
       same SDP offer/answer semantics that are used in SIP [RFC3264
<http://tools.ietf.org/html/rfc3264>],
       in such a way that it is possible to build a signaling gateway
       between SIP and the RTCWEB media negotiation.

"

> can't craft any right now, since I don't know how you would set up a WebRTC
> session (I say WebRTC since we're really talking about the API side of
> things here) without use of offer/answer.
>
>
I think the tweak I'm thinking of here is a shift from "used by RTCWEB" to
"supported by RTCWEB".
It's not critical, since it is motivation text rather than specification,
but it did strike me.

> probably worth documenting as an alternative. One thing to note is that the
> technique described in my draft is something applications can apply
> 3. If we think this role switching behavior is useful, then it's probably
> something that we would want to include in any equivalent SIP mechanisms.
>
>
It seems like this would require a similar Supported header to that
described in the draft and an Info package for changing roles.  Is there a
more efficient way to do that?  Or am I missing something else?

regards,

Ted Hardie

---

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

On 5/7/13 17:29, Ted Hardie wrote:
>
>     The only real twist this introduces is for the work described in
>     section 3. If we think this role switching behavior is useful,
>     then it's probably something that we would want to include in any
>     equivalent SIP mechanisms.
>
>
> described in the draft and an Info package for changing roles.  Is 
> there a more efficient way to do that?  Or am I missing something else?

This is getting a little far from the topic at hand, and is something 
I'm comfortable we can work out in SIP when we take the work on in earnest.

/a

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 8 May 2013 12:17:46 -0400 (EDT)

I see that draft-roach-rtcweb-glareless-add-00 eliminates glare a the
SDP offer/answer level, but it seems to do so by having glare at the
higher "solicitation" level -- the designated answer can discover that
it has received an offer that is not correspondent with the
solicitation that it has sent.  The result is that the proposal
includes a bunch of logic which has the structure of glare-resolution
logic.

The benefit of the proposal is that it avoids "When [glare] happens
mid-session, user experience can be negatively impacted."  But I don't
fully understand what the negative user experience impact is or how
this proposal eliminates it -- given that glare can still happen.

As far as I can tell so far, the core advantage is that this proposal
resolves glare faster than the RFC 3261 (section 14) procedure because
the designated answerer is required to process the updated offer it
receives even if that is not the updated offer it has solicited.
After that, its solicitation is expected to be acted upon by the
designated offerer.

I haven't thought through the details, but it seems to me that the
same effect could probably be achieved by negotiating an amendment to
the RFC 3261 glare-recovery procedure with similar properties, e.g.,
(1) designating one endpoint as the being required to process a
received re-INVITE even if it has a re-INVITE outstanding, and (2)
allowing the other endpoint to immediately send a new re-INVITE after
processing a received re-INVITE.

There's also the question how this gets negotiated across a gateway to
SIP.

Dale

---

From: Adam Roach <[email-masked]>
Date: Wed, 08 May 2013 13:24:50 -0500

On 5/8/13 11:17, Dale R. Worley wrote:
> I see that  draft-roach-rtcweb-glareless-add-00 eliminates glare a
 > the SDP offer/answer level, but it seems to do so by having glare at
 > the higher "solicitation" level -- the designated answer can discover
 > that it has received an offer that is not correspondent with the
 > includes a bunch of logic which has the structure of
 > glare-resolution logic.

The logic is actually much, much simpler in that it only requires 
queuing of an outstanding operation rather than the relatively messy 
(and time consuming) business of backing off and running timers.

I will also emphasize that the condition you're describing arises far, 
far less frequently than general glare. In the vast majority of the 
cases (where the number of m= sections is not changing), the queuing 
isn't even necessary. The only cases requiring queuing are those in 
which the offerer isn't trying to add streams but the answerer is.

 > mid-session, user experience can be negatively impacted." But I
 > don't fully understand what the negative user experience impact is or
 > how this proposal eliminates it -- given that glare can still
 > happen.

I don't think it's really fair to characterize the situation you're 
describing as glare. It's more of a system-wide enforcement of event 
ordering according to the order in which they occur at a cannonical 
observer. We've just arbitrarily chosen that observer to be whichever 
party offers first.

> As far as I can tell so far,  the core advantage is that this
 > proposal resolves glare faster than the RFC 3261 (section 14)
 > procedure because the designated answerer is required to process the
 > updated offer it receives even if that is not the updated offer it
 > has solicited.

I think the core advantage is that the situation in which any 
exceptional behavior arises is several orders of magnitude more rare 
than the situation in which generalized glare can arise.

 > same effect could probably be achieved by negotiating an amendment
 > to the RFC 3261 glare-recovery procedure with similar properties...

Fixing 3261 does nothing for RTCWEB. We'd need to change 3264. :)

> There's also the question how  this gets negotiated across a gateway
 > to SIP.

Section 3.

/a

---

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

> probably something that we would want to include in any equivalent SIP

If find the approach in the draft very unappealing. The persistent 
answerer must send a solicitation that describes the offer it wants the 
persistent offerer to make on its behalf. You don't explain how this 
would be encoded, but in general it must be like a delta on the last 
offer it received. So it will be at least as complex as SDP itself, but 
different. I expect that defining that will be difficult. But its 
further complicated because there is no defined signaling to carry it. 
At least with what we have so far the signaling *can* carry SDP offers 
and answers. (Though something else can be used.)

Switching to the scheme Ted suggests makes it much simpler, since the 
only new thing required is a signal to request the role change.

Note that the "change roles" request is just a variation on token 
passing. The relationship between single-offerer+change-roles and normal 
O/A is like that between token ring and ethernet. We know how that 
battle turned out.

I remain dubious that this glare situation is a problem that needs to be 
fixed. How often will it occur in practice? Is it really worth totally 
changing the model, and debugging the new one, to fix? And what happens 
when you interoperate with a traditional O/A app?

	Thanks,
	Paul

---

From: Adam Roach <[email-masked]>
Date: Wed, 08 May 2013 16:18:59 -0500

On 5/8/13 15:07, Paul Kyzivat wrote:
> The persistent answerer must send a solicitation that describes the 
> offer it wants the persistent offerer to make on its behalf. You don't 
> explain how this would be encoded, but in general it must be like a 
> delta on the last offer it received.

Sorry, I thought I'd spelled this out relatively clearly:

    So, for example, if the
    "persistent answerer" wishes to add a new audio-visual element, it
    sends a solicitation to the "persistent offerer" indicating that it
    requires one new audio m-line section and one new video m-line
    section.

What I was trying to say above is that the only information you would 
need to convey is literally one, two, or three <mediatype,ordinality> 
pairs. You don't say what you're planning to do with them, just that you 
need them.

I intentionally left syntax out of the document because giving a 
non-normative exemplary syntax seems to encourage infinite bikeshedding 
rather than the high-level discussion that is necessary to form consensus.

So, at the risk of encouraging bikeshedders to complain about dictionary 
key names or XML attributes versus cdata, I'm envisioning something that 
looks roughly like this (using JSON format):

{
   'newAudioStreams': 1,
   'newVideoStreams': 1,
   'newDataChannels': 0
}

...or like this (in XML):

<solicitation>
   <newAudio count="1"/>
   <newVideo count="1"/>
   <newData count="0"/>
</solicitiation>

(Given that this isn't necessarily subject to standardization -- at 
least for the WebRTC-only cases --  implementations could really send 
something as minimal as "[1,1,0]" to get the same point across.)

> I remain dubious that this glare situation is a problem that needs to 
> be fixed.

So am I, but Justin seems to be obsessed with it. That's why I'm 
proposing a non-normative recipe that allows people who are 
unnecessarily preoccupied with the issue to indulge their peccadillos. 
The rest of us are free to ignore it.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 09 May 2013 11:18:02 -0400

> pairs. You don't say what you're planning to do with them, just that you

How is that possibly enough? What codecs and codec parameters/optons? 
What bandwidth? What bundling options? The list goes on.

> The rest of us are free to ignore it.

Well, I agree that if somebody wants to do this on their own, then that 
is their business. If applied in a sufficiently constrained environment 
the amount of info that needs to be conveyed can be reduced, as you 
suggest. And of course the token passing approach requires very little 
to be passed.

But I don't want to standardize any of this.

	Thanks,
	Paul

---

From: Adam Roach <[email-masked]>
Date: Thu, 09 May 2013 10:39:49 -0500

> What bandwidth? What bundling options? The list goes on.

I apologize. I must have done a really poor job in the prose in my 
draft, since I clearly didn't communicate the fundamental mechanism that 
I had in mind at all.

Let me try with a ladder diagram to see whether that helps illuminate 
what I'm proposing.

Offerer                             Answerer
    |                                    |
    |<----------Solicitation-------------|
    |  (I need 1 new audio 1 new video)  |
    |                                    |
    |                                    |
    |-------------SDP Offer------------->|
    | (Contains two more m-line sections |
    | than the current session; one      |
    | audio, one video. Both recvonly.)  |
    |                                    |
    |                                    |
    |<------------SDP Answer-------------|
    | (Makes use of the two new m-line   |
    | sections by populating them with   |
    | codec parameters, options, ssrc    |
    | bandwidth, bundling, etc, etc.)    |

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 09 May 2013 22:21:41 -0400

>     | bandwidth, bundling, etc, etc.)    |

Yeah, I figured that from the last message. But the answer is 
constrained by the offer. So the answer may only have codecs that are 
listed in the offer.

I guess the offerer can just include everything it is capable of 
supporting. But that would be especially unpleasant if the goal is to 
use payload type demux, because it will use up a bunch of PT numbers.

Also, I guess you presume that the answerer wants to send, not receive. 
But if this were to be used for CLUE, it could well be that the answerer 
wants to receive, and will be using the clue channel to indicate what it 
wants to receive over that m-line.

The bandwidth in the offer is what the offerer wants to receive, but it 
doesn't know the intent of the stream yet, so it doesn't really know 
this. So presumably it would need to put the maximum it can handle. With 
more than one m-line, it could be difficult to apportion bw if there is 
concern about the total. The bandwidth in the answer applies to media 
from offerer to answerer, which is irrelevant if media is assumed to 
only flow the other way.

You also mention bundling. But as currently proposed bundling must be 
proposed in the offer and accepted or rejected in the answer. But the 
offerer won't know what to propose. If there is already a single bundle 
I suppose it could propose that the new m-lines be in that one, and the 
answerer could agree or not. But if there is more than one bundle that 
won't work.

This just goes on and on. To make this work in general is going to 
require sending the moral equivalent of a delta to the last offer.

Token passing to negotiate who is offerer would not have these problems. 
For something to offer up that doesn't require any standardization, that 
would make more sense.

	Thanks,
	Paul

---

From: Stefan Håkansson LK <[email-masked]>
Date: Fri, 10 May 2013 06:37:21 +0000

> The rest of us are free to ignore it.

I think that glare coming from simultaneous add or remove of media may 
not be that common.

But I can easily think of other situations that would lead to glare for 
Plan A.

Just as an example, think about a conference scenario with a centralized 
node. Now, one of the participants wants to mute her/his audio, and as a 
result the audio m-line would go from sendrecv to recvonly. At roughly 
the same time the server wants to disable the high res video and enable 
the low res video (because this user will be moved, based e.g. on the 
recent audio activity, from being displayed in the main video window to 
be in a thumbnail on the screen of the other participants in the 
conference), so it wants to manipulate the direction attribute of other 
m-lines.

So there would be two offers sent at roughly the same time, which means 
we would have glare.

I think the result would be similar if the server would instead ask for 
another resolution using the imageattr.

You could argue that all control should be left to one end-point, but it 
is sort of clumsy.

Plan B, with the individual control of sources, seems better fitted to 
handle this kind of situations.

---

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

On May 9, 2013, at 8:21 PM, Paul Kyzivat <[email-masked]> wrote:

> Yeah, I figured that from the last message. But the answer is constrained by the offer. So the answer may only have codecs that are listed in the offer.
> 
> I guess the offerer can just include everything it is capable of supporting. But that would be especially unpleasant

it seem to me that we all the same problems in the initial offer. The whole idea of an Offer/Answer is the offer has more or less has everything you support or are willing to do so I don't really see that being a big problem here.

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 10 May 2013 16:14:33 -0400 (EDT)

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

It seems unlikely that the situation is that simple.  I see a number
of issues.

If the follower (= designated answerer) wants an additional, say,
audio m= line, it asks for that.  But how is it to know when it has
been given them?  The next re-INVITE to arrive from the leader (=
designated offerer) may have been spontaneously sent, and it may have
an additional audio m= line that the leader added, for entirely
different purposes.  The follower may misinterpret the use of the new
m= line as the one that it ordered, and it will get confused when a
further m= line shows up when the solicited re-INVITE arrives.  (I've
written a set of messy railroad diagrams below that show how the
follower can lose track of what the leader is doing.)

In any case, the logic in the draft assumes that the follower can
determine when the leader has sent the solicited INVITE.  (Among other
things, the follower is then allowed to send another solicitation.)

You can probably clean that up by having each solicitation contain a
sequence number or identifier, and the leader copies the identifier
into the INVITE it generates because of the solicitation.  Then the
follower can always tell what the state of the conversation is.

If the solicited INVITE fails, the leader has to send it again,
because the solicitation is still outstanding.  This could lead to bad
failure situations.

There are situations where simply having "an additional audio m= line"
is not sufficient.  I'd expect that the leader, once it sees the
follower's configuration of the m= line, might want to update its
configuration of the m= line.  (Because we are logically (though not
in protocol) *offering* the m= line in the *answer*.)  So the leader
may want to do a re-INVITE cycle to get its end of the media stream
configured.  (This isn't an error, though, and can't cause a delay;
it's just an implementation warning.)

Another complex situation is where the follower wants to split a
bundle.  If the leader is willing to bundle all m= lines, but the
follower wants to bundle 1 with 2 and 3 with 4, it's difficult for the
follower to prompt the leader to offer that bundle configuration.

Three situations that look much alike to the follower:

               Leader         Follower

                  |               |
                  |          sol  |-- send
                  |<--------------|   solicit
                  |               |
        respond --| INV           |
       w/INVITE   |-------------->|
                  |               |
                  |           200 |
                  |<--------------|
                  |               |
    spontaneous --| INV           |
         INVITE   |-------------->|
                  |               |
                  |           200 |
                  |<--------------|
                  |               |
                  |               |-- What's
                  |               |   happening?
                  |               |

                  |               |
                  |          sol  |-- send
                  |       +-------|   solicit
                  |       |       |
    spontaneous --| INV   |       |
         INVITE   |-------|------>|
                  |       |       |
                  |       |   200 |
                  |<------|-------|
                  |       |       |
                  |<------+       |
                  |               |
        respond --| INV           |
       w/INVITE   |-------------->|
                  |               |
                  |           200 |
                  |<--------------|
                  |               |
                  |               |-- What's
                  |               |   happening?
                  |               |

                  |               |
                  |          sol  |-- send
                  |       +-------|   solicit
                  |       |       |
    spontaneous --| INV   |       |
         INVITE   |-------|------>|
                  |       |       |
                  |       |   200 |
                  |<------|-------|
                  |       |       |
    spontaneous --| INV   |       |
         INVITE   |-------|------>|
                  |       |       |
                  |       |   200 |
                  |<------|-------|
                  |       |       |
                  |<------+       |-- What's	
                  |               |   happening?
        respond --| INV           |
       w/INVITE   |------>        |
        to come   |               |
                  |               |

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 10 May 2013 16:15:10 -0400 (EDT)

Two possible solutions for glare problems come to mind:

One is to require the designated "follower" to accept and give a 200
response to an incoming re-INVITE even if it has an outstanding
re-INVITE.  The difficulty that follows is that the follower doesn't
know whether the "leader" has accepted or rejected its re-INVITE until
the response arrives, so there is an interval (between sending the 200
to the leader's re-INVITE and receiving the leaders response to its
re-INVITE) during which the follower doesn't know its outgoing media
configuration.  We could probably fix that by annotating the leader's
offers with the o= value of the follower's SDP that the leader
currently is using.

A second one would be to simply drastically shorten the glare backoff
timer.  Given that we're talking about video systems, the RFC 3261
timer ranges of 0 to 2 secs and 2.1 to 4 secs are very slow.  If we
cut those times by a factor of 10, wouldn't the user-visible problems
nearly vanish?

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 10 May 2013 17:20:02 -0400

On 5/10/13 2:37 AM, Stefan Håkansson LK wrote:
...
> So there would be two offers sent at roughly the same time, which means

What do you mean by "roughly"?

How long does it take to do an O/A exchange that doesn't require human 
input? Presumably less than a second, maybe considerably less. (Or will 
it be more with RTCWEB and web servers in the path?)

What is the probability that the other side, for independent reasons, 
decides to make a change within that interval? (And it isn't really the 
whole interval - it is only the first part of it.)

There may indeed be realistic cases for glare, but they will probably be 
because both changes are keyed to a common event.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 10 May 2013 17:24:00 -0400

> it seem to me that we all the same problems in the initial offer. The whole idea of an Offer/Answer is the offer has more or less has everything you support or are willing to do so I don't really s…

The existing O/A only works reasonably when variations from the norm are 
small. As long as it was just codecs on a single audio m-line it wasn't 
a big deal. Add one video m-line and it still has a reasonable chance of 
working.

But in a case like CLUE, where each side has a mass of things available 
to send it doesn't work well at all. And some of the rtcweb cases have a 
lot of similarity to that.

But this particular discussion is a little silly, because passing an 
"offer token" around doesn't have any of these problems.

	Thanks,
	Paul

---

From: Stefan Håkansson LK <[email-masked]>
Date: Sat, 11 May 2013 11:50:03 +0000

> it be more with RTCWEB and web servers in the path?)

That sounds right to me.

> whole interval - it is only the first part of it.)

Given that in multiparty services the "main" video changes quite often, 
I'd not say this is extremely low. It will happen.

But, given that there is a way to roll-back in a predictable way I think 
glare resolution could be quick - nothing stops the web application from 
including a random number in every offer, and resolve glare based on 
that (one of the offers "win").

So I think glare will happen in practice (that is what I wanted to point 
out), but it is not a show-stopper provided there is a way to roll back.

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 11 May 2013 12:24:09 -0400

> I'd not say this is extremely low. It will happen.

Are you thinking that there will be an SDP change every time the speaker 
changes???

Or do you mean changes when participants join and leave a conference?

I would hope there will normally not be SDP changes for either of those 
events.

> out), but it is not a show-stopper provided there is a way to roll back.

I'm sure it will happen. The question is whether it happens often enough 
to do more than count on the normal glare recovery procedures.

	Thanks,
	Paul

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 11 May 2013 20:17:35 -0700

>> So there would be two offers sent at roughly the same time, which means

There are implementations where no signalling is required for the mixer to go from high res to lower res. For example, if the receiver declares what it can receive and the mixer selects the simulcast stream for that receiver based on capabilities and conditions, with the stream properties declared in band.

---

From: Stefan Håkansson LK <[email-masked]>
Date: Sun, 12 May 2013 17:18:23 +0000

> Or do you mean changes when participants join and leave a conference?

I meant the former (at speaker change).

I guess that different designs can be chosen for media from central node 
to end-user clients, and some of them (as Bernard pointed out) would not 
require any signaling. Still, there might be cases where signaling is 
needed.

But leaving that aside, we still have the case of the media end-user 
client -> central node. If you're serious about not wasting bandwidth 
(and with my radio/mobile background I am sort of obsessed :-) ) all 
end-user clients which do not end up as main video anywhere should only 
transmit a low resolution video. So at every speaker change there would 
be at least one client that is asked to stop sending high resolution and 
only transmit low resolution, and one client that is asked to start 
transmitting high resolution video.

I think that this would best be done using some RTCP signaling scheme, 
but I also think there was an agreement a long time ago that SDP O/A 
should be used. In this case either to transmit a new imageattr value 
requesting another resolution, or to pause/resume - using recv on/off in 
Plan B or the direction attribute in Plan A - the low and high 
resolution simulcast streams accordingly (or I assume to pause/resume 
the enhancement layers if a scalable codec is used).

> I would hope there will normally not be SDP changes for either of those

I would like to avoid them too, but I'm not sure how.

---

From: Emil Ivov <[email-masked]>
Date: Sun, 12 May 2013 21:28:50 +0300

> require any signaling. Still, there might be cases where signaling is

Right, however in cases where signalling is indeed needed, should it
really be defined by RTCWEB rather than the application developer?

> I think that this would best be done using some RTCP signaling scheme,

RTCP is just one of the possibilities. This could also be implemented
in a number of other ways that would all be more efficient for the
specific application and all out-of-scope for rtcweb.

> should be used.

Well the way I remember it SDP O/A was chosen for session negotiation
and that other forms of signalling were explicitly left out of the
charter.

> In this case either to transmit a new imageattr value

imageattr is great as a declarative parameter indicating capabilities:
"I can't show more than 720p so there's no point to send me more than
that". Using it as a way to switch between thumbnail and HQ videos is
not entire impossible but is not particularly efficient either.

> I would like to avoid them too, but I'm not sure how.

Well we can either figure that out (and it seems that we can't quite
agree on a solution) or make sure APIs have all it takes for the
matter to be resolved by app-to-app signalling.

Emil

--
https://jitsi.org

---

From: Stefan Håkansson LK <[email-masked]>
Date: Mon, 13 May 2013 09:21:46 +0200

> and that other forms of signalling were explicitly left out of the

I took the result of the discussion and poll at the IETF-84 
(http://tools.ietf.org/wg/rtcweb/minutes?item=minutes-84-rtcweb.html) as 
an indication of that SDP O/A should be used for this kind of in-session 
changes as well.

> not entire impossible but is not particularly efficient either.

To me it looks like a solution that people might feel inclined towards 
using.

But there are others that want to use simulcast, and then pause/resume 
sending of high and low resolution streams, and that problem is more or 
less the same when it comes to signaling.

And even if we omitted the possibility for a receiver to indicate to the 
sender (via standardized signaling) that it should pause or resume 
sending, and instead left that up to an API (at sender side) and 
proprietary signaling, we still have to have some kind of signaling IMO: 
the sender can not just stop sending RTP packets, there need to be a 
signal to the receiver so it understands this (and does not think there 
are extreme packet losses or some other errors) and can indicate to the 
application at the receiving end (in WebRTC it should result in a "mute" 
event being fired on the PC-track in question).

I think the current assumption is SDP O/A for that kind of signaling.

---

From: Emil Ivov <[email-masked]>
Date: Mon, 13 May 2013 17:33:10 +0300

Hey Stefan,

> an indication of that SDP O/A should be used for this kind of in-session 

True, I am not sure we all realized the number of use cases this would
end up encompassing and how we would end up implementing signalling
features into SDP.

> signal to the receiver so it understands this 

I never implied there should be no signalling. Just that implementing it
all over SDP O/A leads to unforeseen complexities.

RTCP BYE and/or SSRC expiration would be one option here. Custom
signalling another.

Cheers,
Emil

-- 
https://jitsi.org

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 13 May 2013 10:58:49 -0700

> I would like to avoid them too, but I'm not sure how.

[BA] It is probably not possible to avoid them in all cases, but we can define RTCP functionality which along with some set of functionality (e.g. Simulcast, layered coding) will minimize them. This is worth doing (and soon).

---

From: Stefan Håkansson LK <[email-masked]>
Date: Tue, 14 May 2013 10:24:24 +0200

On 2013-05-13 19:58, Bernard Aboba wrote:
>
>
> On May 12, 2013, at 10:18, "Stefan Håkansson LK"
>>> I would hope there will normally not be SDP changes for either of
>>> those events.
>>
> [BA] It is probably not possible to avoid them in all cases, but we
> can define RTCP functionality which along with some set of
> functionality (e.g. Simulcast, layered coding) will minimize them.
> This is worth doing (and soon).

I agree to this!

---

From: Emil Ivov <[email-masked]>
Date: Tue, 14 May 2013 12:17:14 +0300

>> This is worth doing (and soon).

RTCP `certainly sounds a lot better than SDP O/A

Emil

-- 
https://jitsi.org

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 22 May 2013 13:55:40 +0200

> RTCP `certainly sounds a lot better than SDP O/A
If something's doable doing app-level signalling, it can be deployed at 
the speed of app updates - but each app has to do it on its own.

If something's doable using RTCP, it can be deployed at the speed of 
browser updates - but you have to convince the browser people to do it 
first.

SDP O/A extensions are in an uncomfortable place between these extremes, 
I think. But it's not obvious to me that one of the three always "sounds 
better" than the other ones.

---

From: Stefan Håkansson LK <[email-masked]>
Date: Wed, 22 May 2013 13:24:21 +0000

> better" than the other ones.

I think that having things like pause/resume signaling (and perhaps 
resolution and the like) in RTCP would be better than SDP, not least 
because you escape the session related state model for this kind of 
signaling (which I can see can be frequent in scenarios when you want to 
save transmission). And I think that standardized signaling it preferred 
since the functionality enabled would then be easily available also to 
more naive developers.

But, I think what you prefer to a large extent depends on your 
viewpoint, and also what scenarios you consider, so I could agree that 
it is not obvious that one way would always be better than the other ones.

There was a discussion on RTCP vs SDP signaling at an earlier IETF 
meeting, and the group at that time preferred SDP signaling. But I don't 
think a concrete proposal on how to do pause request/indication, resume 
request/indication etc. was ever put together (there are hints in the 
draft-juberti-plan-00). Perhaps that should be the first thing to do?

>
>
>
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>