Subject: Re: [rtcweb] Additional requirement - audio-only communication

From: Randell Jesup <[email-masked]>
Date: Thu, 25 Aug 2011 12:24:23 -0400

On 8/25/2011 11:55 AM, Matthew Kaufman wrote:

> On 8/24/2011 4:36 AM, Harald Alvestrand wrote:

Re: negotiate offer/answer separately in each direction

>>
>> I think that:
>> a) this doesn't make sense - it's a completely new SDP/RTP practice,
>> and we should not depart from established practice without a good
>> reason; it also flies against the "keep the number of RTP sessions as
>> low as we can" conclusion that came out of all the discussions about ICE.
>> b) it's not consistent with section 4.1.2 step 7.
>>
>> I think step 16 of section 4:
>> "If connection's ICE started flag is still false, start the
>> PeerConnection ICE Agent and send the initial offer. The initial offer
>> must include a media description for the PeerConnection data UDP media
>> stream, marked as "sendrecv", and for all the streams in localStreams
>> (marked as "sendonly")."
>>
>> is neither correct nor complete.
>
> I agree that "this doesn't make sense" and it is just yet another reason
> that I think SDP offer-answer is entirely inappropriate for WEBRTC.
>
> The web user agent should do what the web site's HTML and cooperating
> Javascript tell it to do. It should not be engaged in direct negotiation
> with the far end such that the outcome is either indeterminate or even
> unexpected, except where direct negotiation is explicitly required to
> meet a security requirement (the initial ICE handshake to determine that
> it is permitted to send data to that endpoint).
>
> Note that any perceived gains by doing this negotiation (like "what if
> my browser is on a slow connection and only wants to receive audio") are
> immediately negated the moment the site changes the SDP enroute to add
> "wants HD-resolution video" for you.

Ok, so that's a bad web-app - don't use it.

Are you really suggesting "send video to someone who doesn't want it anyways"?

"perceived gains" - sending me video at (say) 500K or more plus audio at<50K,
when I'm on a 128K link will kill my connection until I can somehow get the
other side to back off.  Horrid user experience.  Remember people without
broadband or with limited broadband will be using this.  What if I have 768
down, 128 up - but Johnny in the his bedroom is watching youtube videos or
downloading torrents, etc?

> In addition, because the spec is currently written with offer-answer, a
> wide array of use cases that would be possible if capabilities were
> instead exposed via Javascript become impossible. As an example, it
> should be possible for me as a web site developer to create a page that
> can determine, without prompting you to use your camera, whether or not
> a camera is available and if so what codecs it supports. That way I can
> put "I see you have a high-resolution camera and can encode H.264
> video... click here to call a live agent who can help you find the exact
> replacement part" for users who have that, and not if they don't have a
> codec that works with my call center or a camera with sufficient
> resolution to examine the parts I sell.

In what way is that use-case blocked by offer-answer?  Access to the video
needs user confirmation; access to capabilities info shouldn't.  And so the
page can generate an offer with audio and video, or just audio if they have
no camera.  A user declining to send video doesn't necessarily mean you
don't negotiate it - they advertise receive-only for video (if the web app
wants to).

You state above there are major possibilities blocked by offer-answer (I can
think of some minor issues that with O-A require a second O-A pass) - can you
detail some use-cases so we can see the benefit and not just the assertion?
Then we could balance that against the advantage of O-A being well-speced and
known and implemented.  (And the issues surrounding how well and how
interoperably web-app developers can implement their own capability
negotiations/etc)

-- 
Randell Jesup
[email-masked]

---

From: Matthew Kaufman <[email-masked]>
Date: Thu, 25 Aug 2011 10:04:48 -0700

> Are you really suggesting "send video to someone who doesn't want it 

No, I don't think that's a good idea. But one of the arguments I've 
heard *for* doing O-A between the two ends is that it somehow ensures 
that the sender won't send things that the receiver isn't prepared to 
receive.

I was simply pointing out that this isn't true at all. Because the O-A 
can easily be modified in-transit, either end can be trivially convinced 
to do things it otherwise shouldn't be doing.

> other side to back off.  Horrid user experience.

Yes. And it will be possible for a "bad web site" to do this whether we 
use O-A or something else.

> Remember people without

In theory the sender will back off once they get reports of massive 
loss, assuming we do congestion control for the media. If not, they 
you're both out of luck. No different really than anything else 
though... I can easily build a web site that lets you connect over HTTP 
and then runs a modified TCP that doesn't slow down when there's loss.

> needs user confirmation; access to capabilities info shouldn't.

I'm reading http://dev.w3.org/2011/webrtc/editor/webrtc.html

I cannot see how to get it to generate an SDP offer before I try to open 
a media connection.

I also cannot see how one could possibly know *what* SDP to offer until 
you call "getUserMedia", which prompts the user. (As an example, I have 
two cameras attached to this computer over USB. One of them has an 
on-board H.264 encoder. The other does not. If my browser can do 
pass-through of the encoded H.264 but doesn't have its own H.264 
encoder, what offer do I generate before the camera is selected? SDP 
doesn't have a good way to encode "maybe".)

What we need are a set of Javascript APIs that let us enumerate the 
available audio input devices and encoders, video input devices and 
encoders, audio output devices and decoders, video output devices and 
decoders. I hate to say it but even H.245 is probably a better model for 
how to collect the capabilities than SDP O-A.

> And so the

I don't understand what you mean by "(if the web app wants to)"... the 
current proposed specification doesn't have a way for the web app to 
control whether the SDP offer is receive-only for video or not.

> detail some use-cases so we can see the benefit and not just the 

It is certainly possible that a repeated set of fake offer-answer 
exchanges can be used by either Javascript or the server to determine 
what the capabilities are, and that a set of rich Javascript-exposed 
capabilities may be used to generate SDP offers and answers, so in that 
sense they are mappable from one to another.

But I would argue that turning capabilities into SDP is easier than the 
reverse. This is really a question of whether we are trying to turn the 
browser into a *platform for building applications* (in which case we 
should be exposing, as an operating system does, APIs for determining 
what is possible and APIs for control) or turning the browser into *a 
phone*, in which case sure, SIP and SDP are both fine choices.

I think there's a whole lot of potential applications beyond what we're 
currently thinking of if we provide a platform and not just a phone.

I've already outlined one case (offering the user the ability to place a 
video call *if* there is an acceptable camera and encoder on the system).

Another obvious one is where there's a dozen people already in a video 
call and one more wishes to join... if the server knows what 
capabilities exist, the server can tell the new joiner "your browser 
can't support video in a format that the other users need" or can tell 
the existing user browsers to switch to a different codec that is now 
compatible with everyone or whatever, rather than having to re-run 
offer-answer with every party.

> known and implemented.

But it *isn't* well-speced for use cases other than one-to-one calling, 
really. It works poorly for recording, it works poorly for large 
multi-party conferences, etc.

And on top of that, it is missing important attributes that we'll want 
to control (like whether the Opus codec is being forced to "music" mode 
or not).

> (And the issues surrounding how well and how

For interoperability, the browser (in Javascript) or the server (in any 
language you wish) can generate SDP, if that's how they wish to 
interoperate.

Turning capability and control APIs into SDP is exactly the same problem 
as turning operating system APIs into SDP... the browser should be the 
new operating system, not just a hardcoded phone.

Matthew Kaufman

---

From: Dzonatas Sol <[email-masked]>
Date: Thu, 25 Aug 2011 10:20:25 -0700

> Are you really suggesting "send video to someone who doesn't want it 

"Streaming ads" already exist, so there is this more common usage.

> downloading torrents, etc?

If we redirect the discussion back to web-browsers (and not composition 
over the network) then we can merely point out the activity of multiple 
tabs, or why should each tab have equal bandwidth, and why should tabs 
not actively-viewed have more bandwidth than those actively viewed.

Magic solution would be uPNP negotiates frame rate.

-- 
--- http://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering
Ag-Biotech, Virtual Reality, Consultant

---

From: Justin Uberti <[email-masked]>
Date: Thu, 25 Aug 2011 18:33:30 -0400

On Thu, Aug 25, 2011 at 1:04 PM, Matthew Kaufman
<[email-masked]>wrote:

> No, I don't think that's a good idea. But one of the arguments I've heard
> *for* doing O-A between the two ends is that it somehow ensures that the
> sender won't send things that the receiver isn't prepared to receive.
>
> I was simply pointing out that this isn't true at all. Because the O-A can
> easily be modified in-transit, either end can be trivially convinced to do
> things it otherwise shouldn't be doing.
>
>
>
>>
> Yes. And it will be possible for a "bad web site" to do this whether we use
> O-A or something else.
>
>
>  Remember people without
> In theory the sender will back off once they get reports of massive loss,
> assuming we do congestion control for the media. If not, they you're both
> out of luck. No different really than anything else though... I can easily
> build a web site that lets you connect over HTTP and then runs a modified
> TCP that doesn't slow down when there's loss.
>
>
>
>
>>
> I'm reading http://dev.w3.org/2011/webrtc/**editor/webrtc.html<http://dev.w3.org/2011/webrtc/editor/webrtc.html>
>
> I cannot see how to get it to generate an SDP offer before I try to open a
> media connection.
>
> I also cannot see how one could possibly know *what* SDP to offer until you
> call "getUserMedia", which prompts the user. (As an example, I have two
> cameras attached to this computer over USB. One of them has an on-board
> H.264 encoder. The other does not. If my browser can do pass-through of the
> encoded H.264 but doesn't have its own H.264 encoder, what offer do I
> generate before the camera is selected? SDP doesn't have a good way to
> encode "maybe".)
>
> decoders. I hate to say it but even H.245 is probably a better model for how
> to collect the capabilities than SDP O-A.
>
>
>  And so the
> current proposed specification doesn't have a way for the web app to control
> whether the SDP offer is receive-only for video or not.
>
>
>
> It is certainly possible that a repeated set of fake offer-answer exchanges
> can be used by either Javascript or the server to determine what the
> capabilities are, and that a set of rich Javascript-exposed capabilities may
> be used to generate SDP offers and answers, so in that sense they are
> mappable from one to another.
>
> browser into a *platform for building applications* (in which case we should
> be exposing, as an operating system does, APIs for determining what is
> possible and APIs for control) or turning the browser into *a phone*, in
> which case sure, SIP and SDP are both fine choices.
>

I think it makes sense for the browser to emit capabilities, which could
then be used by the web app to generate a SDP offer or answer. This provides
the web app with more control over the functionality; the browser just
reacts to what the web app asks it to do, rather than trying to make
decisions (such as how the answer should be generated from the offer) that
may not be possible without context.

The original problem that started this email is one specific example - if
the callee application wants to only receive audio, the application can
generate an audio-only SDP based on the offer, the browser capabilities, and
the desired app behavior - without any new APIs in the browser.

> Another obvious one is where there's a dozen people already in a video call
> and one more wishes to join... if the server knows what capabilities exist,
> the server can tell the new joiner "your browser can't support video in a
> format that the other users need" or can tell the existing user browsers to
> switch to a different codec that is now compatible with everyone or
> whatever, rather than having to re-run offer-answer with every party.

> really. It works poorly for recording, it works poorly for large multi-party
> conferences, etc.
>
> And on top of that, it is missing important attributes that we'll want to
> control (like whether the Opus codec is being forced to "music" mode or
> not).
>
>
> Turning capability and control APIs into SDP is exactly the same problem as
> turning operating system APIs into SDP... the browser should be the new
> operating system, not just a hardcoded phone.
>
> Matthew Kaufman
>
>
> ______________________________**_________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Thu, 25 Aug 2011 17:01:40 -0700

> I think it makes sense for the browser to emit capabilities, which could

I agree there's clearly some gaps here that need to be filled.

> then be used by the web app to generate a SDP offer or answer. This

> The original problem that started this email is one specific example -
> if the callee application wants to only receive audio, the application
> can generate an audio-only SDP based on the offer, the browser

I think the Harald's original problem was the other way around: the 
_caller_ wants to only receive audio, and needs to generate an SDP 
_offer_ that says that, even if the browser is capable of receiving 
video. I don't think that invalidates your point, though.

> capabilities, and the desired app behavior - without any new APIs in the
> browser.

But I'm not sure what you mean by "without any new APIs"... in your 
approach, something has to be able to enumerate the capabilities in 
sufficient detail for the webapp to generate SDP by itself. I don't 
think there are any existing APIs that go that far.

You also need an API to tell the browser what to actually do. The 
current PeerConnection approach is passing in the offer or the answer. 
If you're generating the answer, you need some way to tell your browser 
what you answered. For the "please don't send me video" case this is not 
an issue... it'll simply never arrive. If you want to change what the 
local browser is sending out, however, then it is.

I do agree it eliminates the need for an API to tell the browser what 
kind of SDP to generate, but it also seems like it imposes a pretty big 
burden on application developers: even if you keep the 
currently-proposed PeerConnection ability to generate SDP as the "simple 
API", the moment you want to do something slightly more complex, you 
have to add code to generate the appropriate SDP, which necessarily 
involves figuring out all the capabilities of the various browsers on 
various platforms. Maybe I'm naive in thinking that seems like an awful 
lot of work just to say, "Please don't send me video."

---

From: Justin Uberti <[email-masked]>
Date: Fri, 26 Aug 2011 00:48:08 -0400

On Thu, Aug 25, 2011 at 8:01 PM, Timothy B. Terriberry <
[email-masked]> wrote:

> _caller_ wants to only receive audio, and needs to generate an SDP _offer_
> that says that, even if the browser is capable of receiving video. I don't
> think that invalidates your point, though.
>
>
> sufficient detail for the webapp to generate SDP by itself. I don't think
> there are any existing APIs that go that far.
>

I meant, without specific APIs for that specific use case (i.e. "create an
audio-only offer"). We would need some sort of GetCapabilities API that
returned a blob of all the session description options the browser
supported, which probably could be formatted as a uber SDP offer if that
made parsing simplest.

>
> You also need an API to tell the browser what to actually do. The current
> PeerConnection approach is passing in the offer or the answer. If you're
> generating the answer, you need some way to tell your browser what you
> answered. For the "please don't send me video" case this is not an issue...
> it'll simply never arrive. If you want to change what the local browser is
> sending out, however, then it is.
>

Yes, you need a "HandleLocalDescription" and "HandleRemoteDescription" API,
instead of just a single OnSignalingMessage API. The deviation from the
current flow is fairly minor, you just have 2 additional states in the state
machine.

>
> I do agree it eliminates the need for an API to tell the browser what kind
> of SDP to generate, but it also seems like it imposes a pretty big burden on
> application developers: even if you keep the currently-proposed
> PeerConnection ability to generate SDP as the "simple API", the moment you
> want to do something slightly more complex, you have to add code to generate
> the appropriate SDP, which necessarily involves figuring out all the
> capabilities of the various browsers on various platforms. Maybe I'm naive
> in thinking that seems like an awful lot of work just to say, "Please don't
> send me video."

It's a fair point, there is more complexity involved in generating the
offer, but in our experience it is manageable. I suppose it depends on how
many APIs we decide we need to control the generation of SDP  (i.e. use
cases other than no-video). If we decide we need to control crypto,
resolution preference, codec preference, we may find this approach simpler.

---

From: Stefan Håkansson LK <[email-masked]>
Date: Fri, 26 Aug 2011 09:14:47 +0200

FWIW,

this is how I would do the case of the caller (initiator) wanting to 
receive only audio, but willing to send audio and video with the current 
API proposal:

1. Generate an audiovisual mediastream (getUserMedia)
2. create PeerConnection, add the above mediastream (addStream)
3. combine the SDP received from PeerConnection with the following 
fields "This is an invitation to a communication", "sending audio and 
video", "want to receive only audio" into a message sent to the peer.
4. the app in the peer (same app!) receives the message, reads the 
fields, (given user agreement to start the communication) creates a 
PeerConnection, feeds the received SDP into the PC, generates an *audio 
only* stream (getUserMedia) and adds it to the PC
5. A couple of SDP exchanges later the application is working as 
intended. (there will be onaddstream's, you will attach those streams to 
video/audio elements etc.)

Quite simple! And no need to have the application read, understand, or 
modify, the SDPs - they are opaque. (Then, of course, the mediastreams 
must be mapped to RTP sessions and such stuff, but I'm sure that is 
solvable and should not be visible in the API IMHO.)

Stefan

on 2011-08-26 06:48, Justin Uberti wrote:
>
>
> On Thu, Aug 25, 2011 at 8:01 PM, Timothy B. Terriberry
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Justin Uberti wrote:
>
> I meant, without specific APIs for that specific use case (i.e. "create
> an audio-only offer"). We would need some sort of GetCapabilities API
> that returned a blob of all the session description options the browser
>     current PeerConnection approach is passing in the offer or the
>     answer. If you're generating the answer, you need some way to tell
>     your browser what you answered. For the "please don't send me video"
>     case this is not an issue... it'll simply never arrive. If you want
>     to change what the local browser is sending out, however, then it is.
>
>
> Yes, you need a "HandleLocalDescription" and "HandleRemoteDescription"
> API, instead of just a single OnSignalingMessage API. The deviation from
> the current flow is fairly minor, you just have 2 additional states in
> the state machine.
>
>
>     I do agree it eliminates the need for an API to tell the browser
>     what kind of SDP to generate, but it also seems like it imposes a
>     pretty big burden on application developers: even if you keep the
>     currently-proposed PeerConnection ability to generate SDP as the
>     "simple API", the moment you want to do something slightly more
>     complex, you have to add code to generate the appropriate SDP, which
>     necessarily involves figuring out all the capabilities of the
>     various browsers on various platforms. Maybe I'm naive in thinking
>     that seems like an awful lot of work just to say, "Please don't send
>     me video."
>
>
> offer, but in our experience it is manageable. I suppose it depends on
> how many APIs we decide we need to control the generation of SDP  (i.e.
> use cases other than no-video). If we decide we need to control crypto,
>     _________________________________________________
>     rtcweb mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/__listinfo/rtcweb
>     <https://www.ietf.org/mailman/listinfo/rtcweb>
>
>

---

From: Justin Uberti <[email-masked]>
Date: Fri, 26 Aug 2011 10:11:31 -0400

On Fri, Aug 26, 2011 at 3:14 AM, Stefan Håkansson LK <
[email-masked]> wrote:

> receive only audio, but willing to send audio and video with the current API
> proposal:
>
> 3. combine the SDP received from PeerConnection with the following fields
> "This is an invitation to a communication", "sending audio and video", "want
> to receive only audio" into a message sent to the peer.
> 4. the app in the peer (same app!) receives the message, reads the fields,
> (given user agreement to start the communication) creates a PeerConnection,
> feeds the received SDP into the PC, generates an *audio only* stream
> (getUserMedia) and adds it to the PC
> 5. A couple of SDP exchanges later the application is working as intended.
> (there will be onaddstream's, you will attach those streams to video/audio
> elements etc.)
>
> modify, the SDPs - they are opaque. (Then, of course, the mediastreams must
> be mapped to RTP sessions and such stuff, but I'm sure that is solvable and
> should not be visible in the API IMHO.)
>

Maybe I misunderstand, but it sounds like with these fields you are defining
a new signaling protocol, which I think we want to avoid.

Going back to your step 3 - here the initiator can of course munge the
generated SDP and discard the m=video section, which should work, but in
other cases this munging may cause things to get out of sync since the
initiator browser's understanding of the offer now differs from reality.
What we really want is some way to either a) an API to tell the initiator
browser to produce an offer with no m=video, or b) a way for the application
to customize or generate the offer and feed it back to the browser. b) is
definitely more complex, but a) could end up causing us to add a lot of
knobs to the API.

>> <[email-masked] <mailto:tterriberry@mozilla.**com<[email-masked]>>>
>> wrote:
>>
>>    Justin Uberti wrote:
>>
>>    ______________________________**___________________
>>    rtcweb mailing list
>>    https://www.ietf.org/mailman/_**_listinfo/rtcweb<https://www.ietf.org/mailman/__listinfo/rtcweb>
>>    <https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>> >
>>
>>
>>

---

From: Stefan Håkansson LK <[email-masked]>
Date: Fri, 26 Aug 2011 16:23:24 +0200

On 2011-08-26 16:11, Justin Uberti wrote:
>
>
> On Fri, Aug 26, 2011 at 3:14 AM, Stefan Håkansson LK
> <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     FWIW,
>
>     receive only audio, but willing to send audio and video with the
>     current API proposal:
>
>     fields "This is an invitation to a communication", "sending audio
>     and video", "want to receive only audio" into a message sent to the
>     peer.
>     PeerConnection, feeds the received SDP into the PC, generates an
>     *audio only* stream (getUserMedia) and adds it to the PC
>     intended. (there will be onaddstream's, you will attach those
>     streams to video/audio elements etc.)
>
>     Quite simple! And no need to have the application read, understand,
>     or modify, the SDPs - they are opaque. (Then, of course, the
>     mediastreams must be mapped to RTP sessions and such stuff, but I'm
>     sure that is solvable and should not be visible in the API IMHO.)
>
>
> Maybe I misunderstand, but it sounds like with these fields you are
> defining a new signaling protocol, which I think we want to avoid.

That's not how I see it. It is the same web app in both peers, and they 
can communicate inbetween them in any way the app developer see fit 
(using e.g. XHR via the web server). There is already a need for a 
mechanism to pass the SDPs between the browsers, and that mechanism 
could be used to pass other data.

So no new protocol needed!

> initiator browser's understanding of the offer now differs from reality.

I would really like to avoid that the web app has to read and modify the 
SDP except for in exceptional cases.

In the current API there is also no need (at least in this case) since 
all streams are set up unidirectional - all that is needed is that the 
application in the browser of the callee gets to know it should add an 
audio-only stream (and it can be told that as I outlined above).

> What we really want is some way to either a) an API to tell the
> initiator browser to produce an offer with no m=video, or b) a way for
> the application to customize or generate the offer and feed it back to
> the browser. b) is definitely more complex, but a) could end up causing
> us to add a lot of knobs to the API.
>
>
>     Stefan
>
>
>
>
>
>
>         <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>> wrote:
>
>             Justin Uberti wrote:
>
>             ___________________________________________________
>             rtcweb mailing list
>         [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>
>
>         https://www.ietf.org/mailman/____listinfo/rtcweb
>         <https://www.ietf.org/mailman/__listinfo/rtcweb>
>         <https://www.ietf.org/mailman/__listinfo/rtcweb
>         <https://www.ietf.org/mailman/listinfo/rtcweb>>
>
>
>

---

From: Justin Uberti <[email-masked]>
Date: Fri, 26 Aug 2011 10:56:26 -0400

On Fri, Aug 26, 2011 at 10:23 AM, Stefan Håkansson LK <
[email-masked]> wrote:

>> <stefan.lk.hakansson@ericsson.**com <[email-masked]>
>> <mailto:stefan.lk.hakansson@**ericsson.com<[email-masked]>>>
>> wrote:
>>
>>    FWIW,
>>
> That's not how I see it. It is the same web app in both peers, and they can
> communicate inbetween them in any way the app developer see fit (using e.g.
> XHR via the web server). There is already a need for a mechanism to pass the
> SDPs between the browsers, and that mechanism could be used to pass other
> data.
>

How will this work if it is not the same web app in both peers, i.e. an
interop scenario? Clearly if it is the same app we can pass along whatever
meta-info we want to instruct the remote side on what to do.

> In the current API there is also no need (at least in this case) since all
> streams are set up unidirectional - all that is needed is that the
>>        <[email-masked] <mailto:tterriberry@mozilla.**com<[email-masked]>
>> >
>>        <mailto:[email-masked]**com
>>
>>        <mailto:tterriberry@mozilla.**com <[email-masked]>>>>
>> wrote:
>>
>>            Justin Uberti wrote:
>>
>>                I think it makes sense for the browser to emit
>> capabilities,
>>                which could
>>
>>
>>                The original problem that started this email is one
>> specific
>>                example -
>>                capabilities, and the desired app behavior - without any
>> new
>>                APIs in the
>>                browser.
>>
>>
>>            ______________________________**_____________________
>>            rtcweb mailing list
>>        https://www.ietf.org/mailman/_**___listinfo/rtcweb<https://www.ietf.org/mailman/____listinfo/rtcweb>
>>        <https://www.ietf.org/mailman/**__listinfo/rtcweb<https://www.ietf.org/mailman/__listinfo/rtcweb>
>> >
>>        <https://www.ietf.org/mailman/**__listinfo/rtcweb<https://www.ietf.org/mailman/__listinfo/rtcweb>

---

From: Stefan Håkansson LK <[email-masked]>
Date: Fri, 26 Aug 2011 17:05:11 +0200

On 2011-08-26, Justin Uberti wrote:

>How will this work if it is not the same web app in both peers, i.e. an interop scenario? Clearly if it is the same app we can pass along whatever meta-info we want to instruct the remote side on what to do.
I agree that this specific case would not work without defining some kind protocol. Then, on the other hand, do all 'advanced' features have to be supported also in interop? Perhaps "you get what you send" or "you get audio and video (unless the user at the sending side opts out of one component)" is OK in interop cases. I guess we need to discuss this.

Br,
Stefan

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 26 Aug 2011 10:06:22 -0700

[BA] Why can't the initiating application delete the m=video line from the SDP blobthat the signaling callback receives, before sending it to the callee?   Are we assumingthat the SDP blob is opaque and can't be edited?  
  Stefan said: "What we really want is some way to either a) an API to tell the
initiator browser to produce an offer with no m=video, or b) a way for
the application to customize or generate the offer and feed it back to
the browser. b) is definitely more complex, but a) could end up causing
us to add a lot of knobs to the API.

   Stefan
"

---

From: Dzonatas Sol <[email-masked]>
Date: Fri, 26 Aug 2011 11:27:36 -0700

One less complex path forward is the question "is this audio meant for 
this geolocation" rather than "is this audio meant for this user". In 
the ubiquitous environment is the implication of user recognition by 
gestures and the assumption of relative vehicle location (that carries 
the audio out) to specific geolocation.

Instead of 'the phone' in the browser, tabs with geolocation data may 
clarify "mobile tabs". For example, two different web-browsers, user 
drags tab from one browser to the other, and it "just works". If the 
web-browsers works like an O/S, then this should be simple based on 
"offers" that originate at the paravirtual level. If each web-browser 
virtualizes such ability then you already know (a) and tabs as the 
semantic vehicle.

On another note, I wonder why the concept is so hard to open tab X and 
tab Y and connect the two related sites together through those tabs if I 
set X as server and Y as client for each other. Of course, some keep the 
motto that the web-browser does not enter web-server mode because 
corporate firewalls are more acceptable for them.

Based on capabilities available ("tethering included"), which endpoint 
is client and which endpoint is server SHOULD BE negotiated in the 
connection phase. The example above taken one step further, the users 
drags the mobile X tab already in server mode (for Y client-tab) to 
another web-browser... still complex? I think that clearly reveals 
legacy systems.

On 08/26/2011 10:06 AM, Bernard Aboba wrote:
> [BA] Why can't the initiating application delete the m=video line from 
> the SDP blob
> that the signaling callback receives, before sending it to the 
> callee?   Are we assuming
> that the SDP blob is opaque and can't be edited?
>
>
>  Stefan said:
>
> "What we really want is some way to either a) an API to tell the
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>    

--

---

From: Randell Jesup <[email-masked]>
Date: Fri, 26 Aug 2011 15:43:05 -0400

On 8/26/2011 10:23 AM, Stefan Håkansson LK wrote:
> That's not how I see it. It is the same web app in both peers, and 
> they can communicate inbetween them in any way the app developer see 
> fit (using e.g. XHR via the web server). There is already a need for a 

This is a new (application-specific) protocol.  It may be a simple one, 
but it is one, overlaid on top of the SDP saying "ignore this part of 
the SDP" effectively.  As mentioned, you then have more problems when 
two different domains/apps want to talk to each other.  We've left the 
protocol between the domains unspecified here, but it will likely need 
to be translated to some external standard such as SIP, H.323 (ugh) or 
Jingle/XMPP.

-- 
Randell Jesup
[email-masked]

---

From: Justin Uberti <[email-masked]>
Date: Fri, 26 Aug 2011 16:07:52 -0400

It can, and in this case it would probably work fine. The browser will still
instantiate the machinery needs to receive video, since it doesn't know the
m=video line was removed, but assuming the remote side functions correctly,
this should not result in a noticeable problem.

However, other adjustments to the SDP will not be so benign, such as
changing the a=crypto lines, or payload ids, although they could be if the
offerer was informed of the updated description.

On Fri, Aug 26, 2011 at 1:06 PM, Bernard Aboba <[email-masked]>wrote:

>  [BA] Why can't the initiating application delete the m=video line from the
> SDP blob
> that the signaling callback receives, before sending it to the callee?
> Are we assuming

---

From: Stefan Håkansson LK <[email-masked]>
Date: Sat, 27 Aug 2011 06:50:36 +0200

Randell wrote:
>Stefan wrote
>>Justing wrote
>This is a new (application-specific) protocol. 

At least it is an application specific way to exchange information.

> It may be a simple one,
>the SDP" effectively.  

I don't think it says anything along those lines. What the extra info says is what A expects B to set up. The SDP o/a initiated by A (caller) deals _only_ with the stream(s) flowing from A to B, it contains no info about what B should send to A (and then there is no need to say anything like "ignore part of SDP").

>As mentioned, you then have more problems when
>two different domains/apps want to talk to each other.  

Yes, that is right. Another problem Harald pointed out in another thread was the mapping to RTP sessions.

For the record, I'm not trying to say that the current API proposal is the final one that should not be changed. I think discussions will show that there will be a need to make adjustments and enhancements to it. I'm just trying to show how you could/would solve things with the current API proposal (as there seem to be some misconceptions).

Stefan

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 27 Aug 2011 08:55:06 -0700

[BA] Agreed that there seems to be some misconceptions about what the current API proposal can do. 

To clear this up, would it make sense to have a (brief) presentation on the API at the interim?

---

From: Stephan Wenger <[email-masked]>
Date: Sat, 27 Aug 2011 09:19:09 -0400

Or perhaps pointers on this list to the newest version every now and then
(whenever a major update has happened)?
Specifically, is Harald's draft from March 24 still the one to look at?
(The companion lists have quite a bit of traffic, and there are only so many
cycles per day to monitor those, especially if API design is not in your
core interest or competency).
Thanks,
Stephan

From:  Bernard Aboba <[email-masked]>
Date:  Sat, 27 Aug 2011 08:55:06 -0700
To:  <[email-masked]>, <[email-masked]>
Subject:  Re: [rtcweb] Additional requirement - audio-only communication

[BA] Agreed that there seems to be some misconceptions about what the
current API proposal can do.

To clear this up, would it make sense to have a (brief) presentation on the
API at the interim?

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

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 27 Aug 2011 10:47:12 -0700

The W3C WEBRTC wiki (which includes links to archives, tracker, editor's draft, etc.) is available here: http://www.w3.org/2011/04/webrtc/wiki/Main_Page

Currently a link points to a W3C editor's draft dated 23 August 2011: http://dev.w3.org/2011/webrtc/editor/webrtc.html
Date: Sat, 27 Aug 2011 09:19:09 -0400
From: [email-masked]
To: [email-masked]
Subject: Re: [rtcweb] Additional requirement - audio-only communication

Or perhaps pointers on this list to the newest version every now and then (whenever a major update has happened)?Specifically, is Harald's draft from March 24 still the one to look at?(The companion lists have quite a bit of traffic, and there are only so many cycles per day to monitor those, especially if API design is not in your core interest or competency).Thanks,Stephan