Subject: [rtcweb] Use of offer / answer semantics

From: Cullen Jennings <[email-masked]>
Date: Tue, 6 Sep 2011 08:46:21 -0600

In my roll as an individual contributor, I want to propose some text that I think we can get rough consensus on around that helps specify which parts of the signaling issues we agree on and which we don't. 

At the last meeting, my read of the the room was there was a fair amount of agreement in the room that offer / answer semantics  with SDP are what we want to use. I don't think there was was broad agreement on if one should use SIP or not, or for that matter jingle. If we can nail down this decisions as the direction the WG is going, it will really help make progress. What I would like to do is propose some following principles in the text below. If we have agreement on these, then they would go into the overview document and help guide the design of other documents. I want to highlight that none of the principles below imply that we would need to use SIP in the browsers - the principals would all work fine if we there was signaling gateway in the web server that converged SIP to whatever proprietary HTML / JS  / HTTP that the applications wanted to use between the browser and the web server. 

1) The media negotiations will be done using the same SDP offer/answer semantics that are used in SIP. 

2) It will be possible to gateway between legacy SIP devices that support ICE and appropriate RTP / SDP mechanisms and codecs without using a media gateway. A signaling gateway to convert between the signaling on the web side to the SIP signaling may be needed. 

3) When a new codec is specified, and the SPD for the new codec is specified in the MMUSIC WG, no other standardization would should be required for it to be possible to use that in the web browsers. Adding a new codecs which might have new SDP parameters should not change the APIs between the browser and javascript application. As soon as the browsers support the new codec, old applications written before the codecs was specified should automatically be able to use the new codec where appropriate with no changes to the JS applications. 

People  has looked at alternatives to all these in a fair amount of detail. For example, we have considered alternatives to the SDP offer / answer such as the advertisement proposal draft (draft-peterson-sipcore-advprop-01) and discussed that several times in the WG. The primary issues identified with this was concerns over mapping this to legacy SDP. Similarly people have considered a replacement for SDP in the SDPng work which was eventually abandoned due to the difficulty of having a incentive for implementations to migrate from SDP to SDPng. 

We have also considered just sending audio and video directly over something like DTLS and not suing RTP. The WG has clearly rejected this due to a variety of reasons - the desire not to to have the operating expense of media gateway and reduction in quality of experience is obviously a high priority goal for the designs of the RTP multiplexing draft. 

The JS API is being developed by W3C but when proposing APIs that should violate the third principal, such as the the API in section 4 of draft-jennings-rtcweb-api-00, it is clear that many people that are more from the browser and web application world do not want such an API.

---

From: Colin Perkins <[email-masked]>
Date: Tue, 6 Sep 2011 16:12:30 +0100

Cullen,

One minor point inline.

> 3) When a new codec is specified, and the SPD for the new codec is specified in the MMUSIC WG, no other standardization would should be required for it to be possible to use that in the web browser…

To be clear on this last point: when RTP payload formats are defined for new codecs, they define a MIME media type and its parameters, and then a mapping of those onto SDP syntax in a standard way. If it was desirable, we could define a mapping from MIME media type names and parameters onto some non-SDP syntax without losing the investment in RTP payload formats and parameters for signalling. 

And, given that other parts of the browser rely on media types, we should be clear that codec names/parameters are drawn from the same namespace.

Colin

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

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

---

From: Matthew Kaufman <[email-masked]>
Date: Tue, 06 Sep 2011 08:20:21 -0700

> 1) The media negotiations will be done using the same SDP offer/answer semantics that are used in SIP.

I think this would be unfortunate. We have an opportunity here to not 
repeat this mistake.

And *if* we go down this road, we need additional language around things 
like exposing the capabilities via an API that doesn't start the 
offer/answer process itself. (Use case: determine if a browser has an 
appropriate camera and encoder before suggesting that they call the 
customer service rep for a live chat.)

> 2) It will be possible to gateway between legacy SIP devices that support ICE and appropriate RTP / SDP mechanisms and codecs without using a media gateway. A signaling gateway to convert between t…

Agree.

>
> 3) When a new codec is specified, and the SPD for the new codec is specified in the MMUSIC WG, no other standardization would should be required for it to be possible to use that in the web browsers.

I would be ok with reusing the SDP parameter string as specified as a 
parameter to the API, but I don't think it should be a blob of SDP that 
combines both the codec parameters *and* the connection/ICE parameters, 
*and* I think that offer/answer is the wrong model.

However, see below...

>   Adding a new codecs which might have new SDP parameters should not change the APIs between the browser and javascript application. As soon as the browsers support the new codec, old applications written before the codecs was specified should automatically be able to use the new codec where appropriate with no changes to the JS applications.

This is a good idea. But then where do all the parameters that *weren't* 
specified in the MMUSIC WG go? (Like "force Opus codec to music mode", 
or "change your motion estimation algorithm")

>
>
> People  has looked at alternatives to all these in a fair amount of detail. For example, we have considered alternatives to the SDP offer / answer such as the advertisement proposal draft (draft-peterson-sipcore-advprop-01) and discussed that several times in the WG.

This is mixing up the API and the wire protocol. If people want to use 
SDP offer/answer between the browser and the web server, that's fine, 
but that doesn't mean we need to bake SDP offer/answer into the 
Javascript API. (And it certainly doesn't mean we need to mix up the 
layers, with connection properties in the SDP *and* encoder properties 
in the same SDP... done properly, these would go to/from different 
Javascript objects anyway.)

Likewise, advprop should be able to be supported as well... with a 
different set of Javascript talking to the same APIs.

>   The primary issues identified with this was concerns over mapping this to legacy SDP.

This makes the assumption that the primary use case will have things 
that speak only SDP offer/answer on the far side. I think that's a very 
IETF + SIP + legacy point of view, which is an unfortunate way to 
approach the future of communications as enabled by web applications.

I think that as long as the browser *or* the server *can* map it to SDP 
offer/answer when needed, that is sufficient.

> Similarly people have considered a replacement for SDP in the SDPng work which was eventually abandoned due to the difficulty of having a incentive for implementations to migrate from SDP to SDPng.

Obviously can't use something that was abandoned.

>
> We have also considered just sending audio and video directly over something like DTLS and not suing RTP.

That would break point 2 above.

>   The WG has clearly rejected this due to a variety of reasons - the desire not to to have the operating expense of media gateway and reduction in quality of experience is obviously a high priority goal for the designs of the RTP multiplexing draft.

Agree.

> The JS API is being developed by W3C but when proposing APIs that should violate the third principal, such as the the API in section 4 of draft-jennings-rtcweb-api-00, it is clear that many people…

Too many negatives for me to parse.

Matthew Kaufman

---

From: Emil Ivov <[email-masked]>
Date: Tue, 06 Sep 2011 18:49:16 +0300

Hey Cullen,

На 06.09.11 17:46, Cullen Jennings написа:
> 
> In my roll as an individual contributor, I want to propose some text
> that I think we can get rough consensus on around that helps specify
> which parts of the signaling issues we agree on and which we don't.
> 
> At the last meeting, my read of the the room was there was a fair
> amount of agreement in the room that offer / answer semantics  with
> SDP are what we want to use. I don't think there was was broad
> agreement on if one should use SIP or not, or for that matter jingle.
> If we can nail down this decisions as the direction the WG is going,
> it will really help make progress. What I would like to do is propose
> some following principles in the text below. If we have agreement on
> these, then they would go into the overview document and help guide
> the design of other documents. I want to highlight that none of the
> principles below imply that we would need to use SIP in the browsers
> - the principals would all work fine if we there was signaling
> gateway in the web server that converged SIP to whatever proprietary
> HTML / JS  / HTTP that the applications wanted to use between the
> browser and the web server.
> 
> 
> 
> 1) The media negotiations will be done using the same SDP
> offer/answer semantics that are used in SIP.

Does this cover media format negotiation only or does it also cover
transport negotiation? I believe you once mentioned you were a fan of
"sending ICE candidates as they become available" and for that to happen
we'd probably need something more XMPP-like than SIP/SDP-like.

> 2) It will be possible to gateway between legacy SIP devices that
> support ICE and appropriate RTP / SDP mechanisms and codecs without
> using a media gateway. A signaling gateway to convert between the
> signaling on the web side to the SIP signaling may be needed.

+1

> 3) When a new codec is specified, and the SPD for the new codec is
> specified in the MMUSIC WG, no other standardization would should be
> required for it to be possible to use that in the web browsers.

I was about to suggest we should also mention the result from the
PAYLOAD WG here (rather than MMUSIC only) but I believe that's actually
what Colin meant.

Cheers,
Emil

> Adding a new codecs which might have new SDP parameters should not
> change the APIs between the browser and javascript application. As
> soon as the browsers support the new codec, old applications written
> before the codecs was specified should automatically be able to use
> the new codec where appropriate with no changes to the JS
> applications.
> 
> 
> People  has looked at alternatives to all these in a fair amount of
> detail. For example, we have considered alternatives to the SDP offer
> / answer such as the advertisement proposal draft
> (draft-peterson-sipcore-advprop-01) and discussed that several times
> in the WG. The primary issues identified with this was concerns over
> mapping this to legacy SDP. Similarly people have considered a
> replacement for SDP in the SDPng work which was eventually abandoned
> due to the difficulty of having a incentive for implementations to
> migrate from SDP to SDPng.
> 
> We have also considered just sending audio and video directly over
> something like DTLS and not suing RTP. The WG has clearly rejected
> this due to a variety of reasons - the desire not to to have the
> operating expense of media gateway and reduction in quality of
> experience is obviously a high priority goal for the designs of the
> RTP multiplexing draft.
> 
> The JS API is being developed by W3C but when proposing APIs that
> should violate the third principal, such as the the API in section 4
> of draft-jennings-rtcweb-api-00, it is clear that many people that
> are more from the browser and web application world do not want such
> an API.
> 
> _______________________________________________ rtcweb mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/rtcweb
> 

-- 
http://jitsi.org

---

From: Emil Ivov <[email-masked]>
Date: Tue, 06 Sep 2011 18:52:06 +0300

Hey Matthew,

На 06.09.11 18:20, Matthew Kaufman написа:
>> In my roll as an individual contributor, I want to propose some
>> text that I think we can get rough consensus on around that helps
>> specify which parts of the signaling issues we agree on and which
>> we don't.
>> 
>> agreement on if one should use SIP or not, or for that matter
>> jingle. If we can nail down this decisions as the direction the WG
>> is going, it will really help make progress. What I would like to
>> do is propose some following principles in the text below. If we
>> have agreement on these, then they would go into the overview
>> document and help guide the design of other documents. I want to
>> highlight that none of the principles below imply that we would
>> need to use SIP in the browsers - the principals would all work
>> fine if we there was signaling gateway in the web server that
>> converged SIP to whatever proprietary HTML / JS  / HTTP that the
>> applications wanted to use between the browser and the web server.
>> 
>> 
>> 

I'd be interested in hearing what mistakes you have in mind.

> And *if* we go down this road, we need additional language around
> things like exposing the capabilities via an API that doesn't start
> the offer/answer process itself. (Use case: determine if a browser
> has an appropriate camera and encoder before suggesting that they
> call the customer service rep for a live chat.)

+1

Personally I'd vote for mimicing XMPP's service discovery here. (see
XEP-0030 and XEP-0115 on http://xmpp.org/extensions )

I definitely think discovery of capabilities should not be part of the
offer/answer negotiation.

Emil

-- 
http://jitsi.org

---

From: Colin Perkins <[email-masked]>
Date: Tue, 6 Sep 2011 17:08:26 +0100

On 6 Sep 2011, at 16:49, Emil Ivov wrote:
...
> PAYLOAD WG here (rather than MMUSIC only) but I believe that's actually

The standards are done in PAYLOAD (was AVT before the split), not MMUSIC, true. My main point though was that the codec names and parameters aren't defined in terms of SDP, but rather using MIME media type names and parameters, which happen to currently get mapped to SDP. 

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

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 6 Sep 2011 18:50:42 -0600

> And, given that other parts of the browser rely on media types, we should be clear that codec names/parameters are drawn from the same namespace.

Just sloppy on my part - what I was trying to get at was that whatever happens, it is basically algorithmic to map it into the API specs we and we don't have to write any new specs for the JS API.

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 6 Sep 2011 18:59:45 -0600

> we'd probably need something more XMPP-like than SIP/SDP-like.

The SDP offer / answer cover both and in fact mix them together in a way that is a bit hard to untangle,  so yes, what I am proposing here is that it would cover both. 

In general, I am a fan of the separating the setup of the ICE transport channels from the negotiation of what goes over them but I think we are just too late at this point to really get into doing that and I don't see much support for it. The hard part of this is how to design a signaling GW that does not require a media GW but can map between this and SIP. Thought we might be able to do this, and I think it would be architecturally cleaner, it's a lot more complicated to done. I don't see the work happening to make something like this happen in a time span where it will be relevant. I think people are just looking for something much closer to existing implementations in Chrome and Firefox.

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 6 Sep 2011 19:45:25 -0600

sorry this is becoming too deep inline but, uh, inline ...

On Sep 6, 2011, at 9:20 AM, Matthew Kaufman wrote:

> I think this would be unfortunate. We have an opportunity here to not repeat this mistake.
> 
> And *if* we go down this road, we need additional language around things like exposing the capabilities via an API that doesn't start the offer/answer process itself. (Use case: determine if a browser has an appropriate camera and encoder before suggesting that they call the customer service rep for a live chat.)

So obviously I agree with that use case but two points here 1) I'm not excluding other API being needed for extra information that is efficiently local. I was only talking about the actual media negotiation so even if we do media negotiation with SDP, one could still have separate API for all kinds of things including mute my microphone that did not use SDP. 2) I think the one way to get capabilities in JS is to ask for an SDP offer, and as soon as you get it cancel the transaction and not cary on. That way you get the capabilities and then stop. 

> I would be ok with reusing the SDP parameter string as specified as a parameter to the API, but I don't think it should be a blob of SDP that combines both the codec parameters *and* the connection/ICE parameters, *and* I think that offer/answer is the wrong model.

Not sure what you mean by SDP parameter string. If you mean just the parameters for the given codec, then i view that as about 1% of SDP and would not describe that as using SDP at all. For example, if you wanted to negotiate FEC, that would not cover it. 

> This is a good idea. But then where do all the parameters that *weren't* specified in the MMUSIC WG go? (Like "force Opus codec to music mode", or "change your motion estimation algorithm")

Note that my writing of above was just wrong as Colin pointed out but to your point ... I think this type of stuff goes in other hints in the API that try and tell the browser what the application is trying to achieve. So I think it is fine for JS to tell the browser assume the audio is spoken voice, or music but I was not viewing this as something that was happening as part of the media negotiation because there is no need to communicate from one browser to the other browser. It is local not something negotiated over the signaling protocol. 

> This is mixing up the API and the wire protocol. If people want to use SDP offer/answer between the browser and the web server, that's fine, but that doesn't mean we need to bake SDP offer/answer into the Javascript API. (And it certainly doesn't mean we need to mix up the layers, with connection properties in the SDP *and* encoder properties in the same SDP... done properly, these would go to/from different Javascript objects anyway.)

I'm far less concerned about the syntax but I am discussing is the semantics of what we need to be able to represent in the various information flows. What I think when you think about this this way, I'm not mixing them up much. If the JS API supported a superset of all the semantics information flow of off/ans and adv/prop, then yes you can do both. If it does not, then you can't. But an equally important flow is what happens on the signaling GW. We have seen from the SIP SBC experience that you can't ignore this and wish it away. We need to be sure what will map, and what won't map or we don't really know we have a solution. 

> 
> Likewise, advprop should be able to be supported as well... with a different set of Javascript talking to the same APIs.
> 
> This makes the assumption that the primary use case will have things that speak only SDP offer/answer on the far side. I think that's a very IETF + SIP + legacy point of view, which is an unfortunate way to approach the future of communications as enabled by web applications.

I'm not assuming anything about this being the primary use case. I'm assuming it is an important use case. If it were not, we would do this totally differently probably starting with not using RTP, certainly not using SDP or offer/answer, and I'd argue for a p2p (in the overlay network sense of the term) form rendezvous - there would be people on the list point out if we use used HIP, everything would be done. We are not doing that because it is an import use case.  The reason it is important is because that is the way we connect this to the existing voice and video communication infrastructure that currently supports well over 4 billion users and probably over 5 billion. We already have a boat load of solutions to this problem if we don't care about legacy. That Flash stuff seems to be in lots of browsers and work fine to other browsers - but I want more than that. For the same reason IPV6 device that can't connect to anything V4 are much less interesting than devices that can connect to both, I want interoperability with the past (meaning all the existing deployments) and path for an interesting future. Either one by itself is not enough. 

> 
> I think that as long as the browser *or* the server *can* map it to SDP offer/answer when needed, that is sufficient.

Ignoring my rant in previous paragraph - I view as necessary that it be mappable, and it needs to be clear how and what parts of it are mapped. I think we are on the same page that the signaling GW should not need to be a media GW. I'm not real wrapped up about how the signaling GW is split between the browser, web server, or even some third network element. 

> Too many negatives for me to parse.

Let me try to restate with less negatives. 

I acknowledge the JS API is being developed by the W3C and not the the IETF. So I want to be careful and not imply that this IETF WG is the right WG to make decisions about the API. Given the apologies in advance, I am going to go and discuss the W3C API in this WG. 

Section 4 of draft-jennings-rtcweb-api-00 did propose an API that is along the lines of what you has been arguing for. It is adv/prop type API. Now I suspect that you would refractor this API to have pass JSON object instead of having a bunch of parameters to the function calls but it would still roughly be the type of API I think you are talking about.  I may be completely confused on the type of API you are proposing but we can sort that out. In many ways, this API is modeled after some of the design of MGCP. 

The important thing is that most the web application developers and browser developers I have talked to are not keen on this type of API. They much prefer the API in the current W3C draft.

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 07 Sep 2011 13:34:25 +0200

Getting everyone confused by not doing a deep inline answer, but 
replying to the first message on the thread......

> 1) The media negotiations will be done using the same SDP offer/answer semantics that are used in SIP.
To be precise - you're suggesting that we use RFC 3264 offer/answer 
semantics. (That RFC is 25 pages long. RFC 3261, the core SIP document, 
is 269 pages, and is NOT a normative reference from 3264. I am anxious 
to avoid having a normative dependency on 3261.)

I agree with this.
> 2) It will be possible to gateway between legacy SIP devices that support ICE and appropriate RTP / SDP mechanisms and codecs without using a media gateway. A signaling gateway to convert between t…
I agree with this - I think the "may be needed" will turn out to be 
"will be needed", but some portion of that gateway can be implemented by 
Javascript running in the browser, if desirable.
> 3) When a new codec is specified, and the SPD for the new codec is specified in the MMUSIC WG, no other standardization would should be required for it to be possible to use that in the web browser…
I agree with this (modulo spelling and WG name fixups).

I decided that the fight against SDP was not worth fighting after 
listening to the dozens of WGs doing SDP extensions for various 
purposes, many of which might make sense to incorporate in a browser 
platform, and concluding that SDP wouldn't hold still enough for us to 
specify a gateway from/to it.

                         Harald

---

From: Emil Ivov <[email-masked]>
Date: Wed, 07 Sep 2011 15:02:08 +0300

На 07.09.11 03:59, Cullen Jennings написа:
>> Does this cover media format negotiation only or does it also
>> cover transport negotiation? I believe you once mentioned you were
>> a fan of "sending ICE candidates as they become available" and for
>> that to happen we'd probably need something more XMPP-like than
>> SIP/SDP-like.
> 
> The SDP offer / answer cover both and in fact mix them together 

Yup, hence my question.

> in a way that is a bit hard to untangle,

I suppose I was (again) thinking about something along the lines of
Jingle where the separation is quite straightforward spec-wise. I do
however understand your point about how this would make it complicated
to have singnaling-only gateways with SIP ... and I do agree that this
is important, so point taken.

Thanks for explaining!

Emil
> so yes, what I am proposing here
> is that it would cover both.
> 
> In general, I am a fan of the separating the setup of the ICE
> transport channels from the negotiation of what goes over them but I
> think we are just too late at this point to really get into doing
> that and I don't see much support for it. The hard part of this is
> how to design a signaling GW that does not require a media GW but can
> map between this and SIP. Thought we might be able to do this, and I
> think it would be architecturally cleaner, it's a lot more
> complicated to done. I don't see the work happening to make something
> like this happen in a time span where it will be relevant. I think
> people are just looking for something much closer to existing
> implementations in Chrome and Firefox.
> 
> 
> 

-- 
http://jitsi.org

---

From: Henry Sinnreich <[email-masked]>
Date: Wed, 07 Sep 2011 15:16:15 -0500

Cullen makes here some important points to keep in mind as another option,
though I agree SIP to be the primary usage scenario.

People implementing HIP (avoiding ICE) and some proprietary VM such a Flash
or Silverlight (there will always be some that are years ahead of standards)
may get much higher commercial quality products in much shorter time, that
is at much lower development cost.

Why can't such an option not even be allowed here?

Thanks, Henry

On 9/6/11 8:45 PM, "Cullen Jennings" <[email-masked]> wrote:

>>> In my roll as an individual contributor, I want to propose some text that I
>>> think we can get rough consensus on around that helps specify which parts of
>>> the signaling issues we agree on and which we don't.
>>> 
>>> At the last meeting, my read of the the room was there was a fair amount of
>>> agreement in the room that offer / answer semantics  with SDP are what we
>>> want to use. I don't think there was was broad agreement on if one should
>>> use SIP or not, or for that matter jingle. If we can nail down this
>>> decisions as the direction the WG is going, it will really help make
>>> progress. What I would like to do is propose some following principles in
>>> the text below. If we have agreement on these, then they would go into the
>>> overview document and help guide the design of other documents. I want to
>>> highlight that none of the principles below imply that we would need to use
>>> SIP in the browsers - the principals would all work fine if we there was
>>> signaling gateway in the web server that converged SIP to whatever
>>> proprietary HTML / JS  / HTTP that the applications wanted to use between
>>> the browser and the web server.
>>> 
>>> 
>>> 
>> And *if* we go down this road, we need additional language around things like
>> exposing the capabilities via an API that doesn't start the offer/answer
>> process itself. (Use case: determine if a browser has an appropriate camera
>> and encoder before suggesting that they call the customer service rep for a
>> live chat.)
> 
> So obviously I agree with that use case but two points here 1) I'm not
> excluding other API being needed for extra information that is efficiently
> local. I was only talking about the actual media negotiation so even if we do
> media negotiation with SDP, one could still have separate API for all kinds of
> things including mute my microphone that did not use SDP. 2) I think the one
> way to get capabilities in JS is to ask for an SDP offer, and as soon as you
> get it cancel the transaction and not cary on. That way you get the
> capabilities and then stop.
> 
>> 
>> 
>>> 
>>> 2) It will be possible to gateway between legacy SIP devices that support
>>> ICE and appropriate RTP / SDP mechanisms and codecs without using a media
>>> gateway. A signaling gateway to convert between the signaling on the web
>>> side to the SIP signaling may be needed.
>> 
>> Agree.
>> 
>>> 
>>> 3) When a new codec is specified, and the SPD for the new codec is specified
>>> in the MMUSIC WG, no other standardization would should be required for it
>>> to be possible to use that in the web browsers.
>> 
>> combines both the codec parameters *and* the connection/ICE parameters, *and*
>> I think that offer/answer is the wrong model.
> 
> Not sure what you mean by SDP parameter string. If you mean just the
> parameters for the given codec, then i view that as about 1% of SDP and would
> not describe that as using SDP at all. For example, if you wanted to negotiate
> FEC, that would not cover it.
> 
>> 
>> However, see below...
>> 
>>>  Adding a new codecs which might have new SDP parameters should not change
>>> the APIs between the browser and javascript application. As soon as the
>>> browsers support the new codec, old applications written before the codecs
>>> was specified should automatically be able to use the new codec where
>>> appropriate with no changes to the JS applications.
>> 
>> specified in the MMUSIC WG go? (Like "force Opus codec to music mode", or
>> "change your motion estimation algorithm")
> 
> Note that my writing of above was just wrong as Colin pointed out but to your
> point ... I think this type of stuff goes in other hints in the API that try
> and tell the browser what the application is trying to achieve. So I think it
> is fine for JS to tell the browser assume the audio is spoken voice, or music
> but I was not viewing this as something that was happening as part of the
> media negotiation because there is no need to communicate from one browser to
> the other browser. It is local not something negotiated over the signaling
> protocol. 
> 
>> 
>>> 
>>> 
>>> People  has looked at alternatives to all these in a fair amount of detail.
>>> For example, we have considered alternatives to the SDP offer / answer such
>>> as the advertisement proposal draft (draft-peterson-sipcore-advprop-01) and
>>> discussed that several times in the WG.
>> 
>> This is mixing up the API and the wire protocol. If people want to use SDP
>> offer/answer between the browser and the web server, that's fine, but that
>> doesn't mean we need to bake SDP offer/answer into the Javascript API. (And
>> it certainly doesn't mean we need to mix up the layers, with connection
>> properties in the SDP *and* encoder properties in the same SDP... done
>> properly, these would go to/from different Javascript objects anyway.)
> 
> I'm far less concerned about the syntax but I am discussing is the semantics
> of what we need to be able to represent in the various information flows. What
> I think when you think about this this way, I'm not mixing them up much. If
> the JS API supported a superset of all the semantics information flow of
> off/ans and adv/prop, then yes you can do both. If it does not, then you
> can't. But an equally important flow is what happens on the signaling GW. We
> have seen from the SIP SBC experience that you can't ignore this and wish it
> away. We need to be sure what will map, and what won't map or we don't really
> know we have a solution.
> 
>> 
>> Likewise, advprop should be able to be supported as well... with a different
>> set of Javascript talking to the same APIs.
>> 
>> This makes the assumption that the primary use case will have things that
>> speak only SDP offer/answer on the far side. I think that's a very IETF + SIP
>> + legacy point of view, which is an unfortunate way to approach the future of
>> communications as enabled by web applications.
> 
> I'm not assuming anything about this being the primary use case. I'm assuming
> it is an important use case. If it were not, we would do this totally
> differently probably starting with not using RTP, certainly not using SDP or
> offer/answer, and I'd argue for a p2p (in the overlay network sense of the
> term) form rendezvous - there would be people on the list point out if we use
> used HIP, everything would be done. We are not doing that because it is an
> import use case.  The reason it is important is because that is the way we
> connect this to the existing voice and video communication infrastructure that
> currently supports well over 4 billion users and probably over 5 billion. We
> already have a boat load of solutions to this problem if we don't care about
> legacy. That Flash stuff seems to be in lots of browsers and work fine to
> other browsers - but I want more than that. For the same reason IPV6 device
> that can't connect to anything V4 are much less interesting than devices that
> c
>  an connect to both, I want interoperability with the past (meaning all the
> existing deployments) and path for an interesting future. Either one by itself
> is not enough. 
> 
>> 
> Ignoring my rant in previous paragraph - I view as necessary that it be
> mappable, and it needs to be clear how and what parts of it are mapped. I
> think we are on the same page that the signaling GW should not need to be a
> media GW. I'm not real wrapped up about how the signaling GW is split between
> the browser, web server, or even some third network element.
> 
> 
>> 
>>> Similarly people have considered a replacement for SDP in the SDPng work
>>> which was eventually abandoned due to the difficulty of having a incentive
>>> for implementations to migrate from SDP to SDPng.
>> 
>>>  The WG has clearly rejected this due to a variety of reasons - the desire
>>> not to to have the operating expense of media gateway and reduction in
>>> quality of experience is obviously a high priority goal for the designs of
>>> the RTP multiplexing draft.
>> 
>> Agree.
>> 
>>> 
>>> The JS API is being developed by W3C but when proposing APIs that should
>>> violate the third principal, such as the the API in section 4 of
>>> draft-jennings-rtcweb-api-00, it is clear that many people that are more
>>> from the browser and web application world do not want such an API.
>> 
> I acknowledge the JS API is being developed by the W3C and not the the IETF.
> So I want to be careful and not imply that this IETF WG is the right WG to
> make decisions about the API. Given the apologies in advance, I am going to go
> and discuss the W3C API in this WG.
> 
> Section 4 of draft-jennings-rtcweb-api-00 did propose an API that is along the
> lines of what you has been arguing for. It is adv/prop type API. Now I suspect
> that you would refractor this API to have pass JSON object instead of having a
> bunch of parameters to the function calls but it would still roughly be the
> type of API I think you are talking about.  I may be completely confused on
> the type of API you are proposing but we can sort that out. In many ways, this
> API is modeled after some of the design of MGCP.
> 
> The important thing is that most the web application developers and browser
> developers I have talked to are not keen on this type of API. They much prefer
> the API in the current W3C draft.
> 
> 
>> 
>> Matthew Kaufman
>> 
>> 
>

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 7 Sep 2011 21:45:27 -0700

> to avoid having a normative dependency on 3261.)

[BA] I do *not* agree that RTCWEB should have to support every aspect of SDP offer/answer.   Basic offer/answer, sure.  All potential corner cases?  Not necessarily. 

> Javascript running in the browser, if desirable.

[BA] This seems like a good principle, but I'm not clear that it will work with all use cases.  For example, what happens in the E911 use cases when an RTCWEB implementation attempts to make a call to a PSAP implementing NENA i3 Stage 3?  If you don't have a media gateway, then the browser will need to implement one of the mandated codecs on the PSAP side.  So in those use cases, eliminating the media gateway implies making G.711 and H.264 mandatory-to-implement.  

> > 3) When a new codec is specified, and the SDP for the new codec is specified in the MMUSIC WG, no other standardization would should be required for it to be possible to use that in the web browsers. Adding a new codecs which might have new SDP parameters should not change the APIs between the browser and javascript application. As soon as the browsers support the new codec, old applications written before the codecs was specified should automatically be able to use the new codec where appropriate with no changes to the JS applications.

[BA] Agree with "no new standardization".  But that doesn't mean that applications will automatically "just work", right?  That's a much harder requirement.

> specify a gateway from/to it.

[BA] Agree that it's not worth fighting, but making it clear what we do and do not support will be a "fight" of sorts.  That is, unless you're willing to require that the browser be able to *everything* enabled by RFC 3264.  Personally, I don't think that is worthwhile.

---

From: Tim Panton <[email-masked]>
Date: Thu, 8 Sep 2011 10:40:46 +0100

On 7 Sep 2011, at 02:45, Cullen Jennings wrote:
… snipped inc comment on excessive inlining ;-) …..
> 
> I'm not assuming anything about this being the primary use case. I'm assuming it is an important use case. If it were not, we would do this totally differently probably starting with not using RTP, certainly not using SDP or offer/answer, and I'd argue for a p2p (in the overlay network sense of the term) form rendezvous - there would be people on the list point out if we use used HIP, everything would be done. We are not doing that because it is an import use case.  The reason it is important is because that is the way we connect this to the existing voice and video communication infrastructure that currently supports well over 4 billion users and probably over 5 billion. 

Just to be pedantic, it is _a_ way we can connect to the 5 billion. Since a growing number of them are on GSM capable equipment, that could be seen as an argument for an Um or SS7 or IMS stack. 

My real point being that we can't expect a RTC capable web browser to be able to directly address anything but
a tiny proportion of them. A browser in an enterprise _might_ be able to connect RTP point-to-point with a SIP desk phone in the same enterprise, but only if it was on the same VLAN, which isn't common practice.

So whilst it is an important use case, it is not going to see much actual use (IMHO).

Tim (speaking for himself)

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 08 Sep 2011 12:50:35 +0200

On 09/08/11 06:45, Bernard Aboba wrote:
> [BA] I do *not* agree that RTCWEB should have to support every aspect 
> of SDP offer/answer.   Basic offer/answer, sure.  All potential corner 
> cases?  Not necessarily.
If we start off from:
- RFC 3264 assuming that we support all of it, and then list the parts 
we don't want
- RFC 3261 assuming we support none of it, and list the parts we do want
we might have a better dialogue (or at least a more precise one).
> [BA] This seems like a good principle, but I'm not clear that it will 
> work with all use cases.  For example, what happens in the E911 use 
> cases when an RTCWEB implementation attempts to make a call to a PSAP 
> implementing NENA i3 Stage 3?  If you don't have a media gateway, then 
> the browser will need to implement one of the mandated codecs on the 
> PSAP side.  So in those use cases, eliminating the media gateway 
> implies making G.711 and H.264 mandatory-to-implement.
Unless RTCWEB mandtory codecs have some overlap with the NENA i3 Stage 3 
codecs, you have given a good argument for why NENA i3 Stage 3 devices 
should not be in the list of "legacy SIP devices that support ICE and 
appropriate RTP / SDP mechanisms and codecs".

I'm still hoping that some day, someone will show up with a serial 
number and software version for a device they definitely think should be 
in the "legacy SIP devices that support ICE and appropriate RTP / SDP 
mechanisms and codecs" category.
>
> > > 3) When a new codec is specified, and the SDP for the new codec is 
> required for it to be possible to use that in the web browsers. Adding 
> a new codecs which might have new SDP parameters should not change the 
> APIs between the browser and javascript application. As soon as the 
> browsers support the new codec, old applications written before the 
> codecs was specified should automatically be able to use the new codec 
> where appropriate with no changes to the JS applications.
> [BA] Agree with "no new standardization".  But that doesn't mean that 
> applications will automatically "just work", right?  That's a much 
> harder requirement.
Nothing ever "just works"..... but simple cases should continue to work.
> [BA] Agree that it's not worth fighting, but making it clear what we 
> do and do not support will be a "fight" of sorts.  That is, unless 
> you're willing to require that the browser be able to *everything* 
> enabled by RFC 3264.  Personally, I don't think that is worthwhile.
I think we agree. Let's get down to specifics (in another thread).

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 8 Sep 2011 13:01:38 +0200

8 sep 2011 kl. 12:50 skrev Harald Alvestrand:

> I'm still hoping that some day, someone will show up with a serial number and software version for a device they definitely think should be in the "legacy SIP devices that support ICE and appropriate RTP / SDP mechanisms and codecs" category.
>> 
We all hope for that to happen ;-)

An issue here is that there's a wide gap between what the market offers in terms of SIP device functionality and the IETF's vision. At some point, I wish that the SIP forum copies  the work of the XMPP Software Foundation and tries to define standard SIP profiles for their members, so we can move the market forward in terms of implementations. SIPit events really help here as a means to educate SIP developers and put some peer pressure on them.

Sorry for being a bit off topic. Favorite topic, I guess ;-)

/O

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 08 Sep 2011 11:52:42 -0400

On 9/8/11 12:45 AM, Bernard Aboba wrote:
> [BA] I do *not* agree that RTCWEB should have to support every aspect of
> SDP offer/answer. Basic offer/answer, sure. All potential corner cases?
> Not necessarily.

I'm not sure where you are going here?
Are you suggesting that all the mandatory to implement O/A semantics of 
3264 might not be supported? Or are you saying that O/A support may not 
work for all defined SDP extensions?

I think that all mandatory O/A should be supported. If you have 
something specific in mind that is problematic, then maybe we should 
investigate why you think it needs to be excluded. My guess is that 
maybe it is something broken in the spec that ought to be fixed there.

> work with all use cases. For example, what happens in the E911 use cases
> when an RTCWEB implementation attempts to make a call to a PSAP
> PSAP side. So in those use cases, eliminating the media gateway implies
> making G.711 and H.264 mandatory-to-implement.

AFAIK, not every rtcweb application will be obligated to support E911.
(In particular, any application that doesn't identify callees by phone 
number is a good candidate to be exempt from E911.

Certainly a server without a media gateway will be limited in what it 
can call based on codec compatibility. That may or may not be a 
limitation, depending on the application. Those that find it an 
unacceptable limitation will probably find a way to incorporate a 
transcoder when needed.

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Thu, 8 Sep 2011 12:05:07 -0400

If the goal is to create something that will interop with an existing SIP
infrastructure using a signalling proxy only, we would need is to fully
support RFC 3264. I think what we will need is an ability to generate an
initial offer (as SDP), process the provisional SDP response, process final
SDP response, process an offer and generate the response, and generate a new
offer for the existing call (similar to the response to the SIP INVITE with
no body) in accordance with rules in RFC 3264. We will need to decide which
SDP related RFC would need to be supported, but I think RFC 4566, RFC 3551,
RFC 5245, and RFC 3605 are the minimum.
_____________
Roman Shpount

On Thu, Sep 8, 2011 at 11:52 AM, Paul Kyzivat <[email-masked]> wrote:

> 3264 might not be supported? Or are you saying that O/A support may not work
> for all defined SDP extensions?
>
> I think that all mandatory O/A should be supported. If you have something
> specific in mind that is problematic, then maybe we should investigate why
> you think it needs to be excluded. My guess is that maybe it is something
> broken in the spec that ought to be fixed there.
>
>
> Certainly a server without a media gateway will be limited in what it can
> call based on codec compatibility. That may or may not be a limitation,
> depending on the application. Those that find it an unacceptable limitation
> will probably find a way to incorporate a transcoder when needed.
>
>        Thanks,
>        Paul
>
> ______________________________**_________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>

---

From: Dzonatas Sol <[email-masked]>
Date: Thu, 08 Sep 2011 10:01:59 -0700

The main thing that concerns me with SIP is the stateful-ness, yet maybe 
that is not of any concern for mobile-phones. I look at this from 
evolution of RFC 2516 such that support of SIP in rtcweb allows return 
to stateless modes (in interop) where before we could assume stateless 
before specific sections on-the-wire and stateful after known points. 
Now people want that transition in the application layer and assume 
HTTPS is ok for stateful-ness. I can see why the multiplex route is 
desired, instead.

Maybe NAT64 can be in-scope if it includes some more stateful PPPoE 
alternative. That would lead to "insider" and "outsider" modes for wi-fi 
(and on-the-wire for plug-ins), so I doubt current interest exist in 
this kind of change for standard.

If, however, SIP and rtcweb work together on S/MIME and SSRC for 
stateful-ness than this could get easier (at least in half-duplex).

On 09/08/2011 09:05 AM, Roman Shpount wrote:
> If the goal is to create something that will interop with an existing 
> SIP infrastructure using a signalling proxy only, we would need is to 
> fully support RFC 3264. I think what we will need is an ability to 
> generate an initial offer (as SDP), process the provisional SDP 
> response, process final SDP response, process an offer and generate 
> the response, and generate a new offer for the existing call (similar 
> to the response to the SIP INVITE with no body) in accordance with 
> rules in RFC 3264. We will need to decide which SDP related RFC would 
> need to be supported, but I think RFC 4566, RFC 3551, RFC 5245, and 
> RFC 3605 are the minimum.
> _____________
> Roman Shpount
>
>
> On Thu, Sep 8, 2011 at 11:52 AM, Paul Kyzivat <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>         �> > 1) The media negotiations will be done using the same SDP
>         �> To be precise - you're suggesting that we use RFC 3264
>         offer/answer
>         �> semantics. (That RFC is 25 pages long. RFC 3261, the core
>         SIP document,
>         �> is 269 pages, and is NOT a normative reference from 3264. I
>         am anxious
>         �> to avoid having a normative dependency on 3261.)
>         �>
>         �> I agree with this.
>
>     Are you suggesting that all the mandatory to implement O/A
>     semantics of 3264 might not be supported? Or are you saying that
>     O/A support may not work for all defined SDP extensions?
>
>     something specific in mind that is problematic, then maybe we
>     should investigate why you think it needs to be excluded. My guess
>     is that maybe it is something broken in the spec that ought to be
>     fixed there.
>
>
>         �> > 2) It will be possible to gateway between legacy SIP
>         devices that
>         �> I agree with this - I think the "may be needed" will turn
>         out to be
>         �> "will be needed", but some portion of that gateway can be
>         implemented by
>         �> Javascript running in the browser, if desirable.
>
>     (In particular, any application that doesn't identify callees by
>     phone number is a good candidate to be exempt from E911.
>
>     Certainly a server without a media gateway will be limited in what
>     it can call based on codec compatibility. That may or may not be a
>     � � � �Thanks,
>     � � � �Paul
>     [email-masked] <mailto:[email-masked]>

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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 08 Sep 2011 13:14:12 -0400

On 9/8/11 12:05 PM, Roman Shpount wrote:
> response, process final SDP response, process an offer and generate the
> response, and generate a new offer for the existing call (similar to the
> response to the SIP INVITE with no body) in accordance with rules in RFC
> 3264. We will need to decide which SDP related RFC would need to be
> supported, but I think RFC 4566, RFC 3551, RFC 5245, and RFC 3605 are
> the minimum.

If I understand you, then I think we are in agreement.

	Thanks,
	Paul

>     Are you suggesting that all the mandatory to implement O/A semantics
>     of 3264 might not be supported? Or are you saying that O/A support
>     may not work for all defined SDP extensions?
>
>         implies
>     _________________________________________________
>     rtcweb mailing list
>     https://www.ietf.org/mailman/__listinfo/rtcweb
>     <https://www.ietf.org/mailman/listinfo/rtcweb>
>
>
>
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 11 Sep 2011 13:51:20 +0000

On Sep 6, 2011, at 9:45 PM, Cullen Jennings wrote:

> I'm not assuming anything about this being the primary use case. I'm assuming it is an important use case. If it were not, we would do this totally differently probably starting with not using RTP, certainly not using SDP or offer/answer, and I'd argue for a p2p (in the overlay network sense of the term) form rendezvous - there would be people on the list point out if we use used HIP, everything would be done. We are not doing that because it is an import use case.  The reason it is important is because that is the way we connect this to the existing voice and video communication infrastructure that currently supports well over 4 billion users and probably over 5 billion. We already have a boat load of solutions to this problem if we don't care about legacy. That Flash stuff seems to be in lots of browsers and work fine to other browsers - but I want more than that. For the same reason IPV6 device that can't connect to anything V4 are much less interesting than devices that c
> an connect to both, I want interoperability with the past (meaning all the existing deployments) and path for an interesting future. Either one by itself is not enough. 
> 

I don't see how the current rtcweb direction could really do that.  If you really want to interop with the 5 billion PSTN/IMS users without a gateway "interworking" rtcweb media to legacy SIP-based media, the rtcweb browser would have to mandate support for G.711, AVP rather than AVPF, support NOT using ICE, support not using SRTP, and not multiplexing RTP/RTCP.  If ICE remains mandatory to use, then there'll have to be some media-layer ICE terminator (or TURN server) to interop with the PSTN no matter what.  

The odds are there'll be some form of SBC at the border of the SIP-PSTN provider anyway (e.g., an IBCF), but the question is whether it'll be the PSTN providers that have to pay the additional cost to interop with rtcweb media, or whether it'll be the rtcweb service provider who also have to deploy gateways.  At the end of the day it costs money to interwork this stuff - i.e., more hardware/blades/CPUs/whatever.  So even if the PSTN providers already use SBCs and they're the ones doing the interop work, it'll cost more either in the form of more SBCs, or higher-scale hardware in them.

Generally the most expensive thing would be to make the gateway/SBC have to transcode, so if we could at least mandate rtcweb clients support G.711 and AVP, that would be good.  It would really suck if every call to/from the PSTN had to be transcoded from opus/AVPF to G.711/AVP, when G.711/AVP is royalty free (and trivial relative to opus/avpf).

-hadriel

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Mon, 12 Sep 2011 01:06:09 +0530

I agree with Hadriel for PSTN interop.

Thanks
Partha

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On
Behalf
>Of Hadriel Kaplan
>Sent: Sunday, September 11, 2011 7:21 PM
>To: Cullen Jennings
>Cc: <[email-masked]>
>Subject: [rtcweb] Supporting legacy PSTN interop (was: Use of offer /
>answer semantics)
>
>
>> I'm not assuming anything about this being the primary use case. I'm
>assuming it is an important use case. If it were not, we would do this
>totally differently probably starting with not using RTP, certainly not
>using SDP or offer/answer, and I'd argue for a p2p (in the overlay
>network sense of the term) form rendezvous - there would be people on
>the list point out if we use used HIP, everything would be done. We are
>not doing that because it is an import use case.  The reason it is
>important is because that is the way we connect this to the existing
>voice and video communication infrastructure that currently supports
>well over 4 billion users and probably over 5 billion. We already have
a
>boat load of solutions to this problem if we don't care about legacy.
>That Flash stuff seems to be in lots of browsers and work fine to other
>browsers - but I want more than that. For the same reason IPV6 device
>that can't connect to anything V4 are much less interesting than
devices
>that
>  c
>> an connect to both, I want interoperability with the past (meaning
all
>the existing deployments) and path for an interesting future. Either
one
>by itself is not enough.
>>
>
>I don't see how the current rtcweb direction could really do that.  If
>you really want to interop with the 5 billion PSTN/IMS users without a
>gateway "interworking" rtcweb media to legacy SIP-based media, the
>rtcweb browser would have to mandate support for G.711, AVP rather than
>AVPF, support NOT using ICE, support not using SRTP, and not
>multiplexing RTP/RTCP.  If ICE remains mandatory to use, then there'll
>have to be some media-layer ICE terminator (or TURN server) to interop
>with the PSTN no matter what.
>
>The odds are there'll be some form of SBC at the border of the SIP-PSTN
>provider anyway (e.g., an IBCF), but the question is whether it'll be
>the PSTN providers that have to pay the additional cost to interop with
>rtcweb media, or whether it'll be the rtcweb service provider who also
>have to deploy gateways.  At the end of the day it costs money to
>interwork this stuff - i.e., more hardware/blades/CPUs/whatever.  So
>even if the PSTN providers already use SBCs and they're the ones doing
>the interop work, it'll cost more either in the form of more SBCs, or
>higher-scale hardware in them.
>
>Generally the most expensive thing would be to make the gateway/SBC
have
>to transcode, so if we could at least mandate rtcweb clients support
>G.711 and AVP, that would be good.  It would really suck if every call
>to/from the PSTN had to be transcoded from opus/AVPF to G.711/AVP, when
>G.711/AVP is royalty free (and trivial relative to opus/avpf).
>
>-hadriel
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 12 Sep 2011 11:56:00 +0000

(sorry about the length of the email)

Well, you asked for rough consensus, so I'll give my 2 cents: 

I think building-in/requiring full SDP and in particular the offer/answer model is a big mistake.  As I said at the mic at IETF-81, by doing this you are restricting/limiting the application of Rtcweb.  You are imposing a particular model of usage into the Javascript API, which is contrary to the very notion of having a Javascript API to begin with.  

Note here I am talking about full SDP and offer/answer, not the tokens assigned for media info that we happen to encode in SDP, and which only comprise a portion of SDP - we'll need standardized tokens or enum values for those in the API itself, so those are fine as IANA-registered strings.

In particular, here're my arguments:
1) It should be recognized that for anything but the simplest case of SIP-based calling from the rtcweb server to SIP peers, the domain/scope of this SDP offer/answer will only be between the browser and its server.  In other words, the SDP state, sess-version number, media lines, etc., will only be meaningful between the browser and server, and a new set of those will exist between the server and any peer(s) it talks to using SIP.  Because if anything more complicated happens in SIP, such as forked calls, then either the browser SDP code has to understand such scenarios as well, or else the server will handle it itself - and I don't think you really want to complicate the browser to handle all possible SDP offer/answer cases.  Furthermore, while we assume the server will speak SIP to peers, it may well speak XMPP, H.323, IAX, or whatever.  And thus again this SDP exchange will only be happening (from an SDP layer perspective) between the browser and server.  I only point this out because people may think they're getting something for free here, and minimizing the complexity of the javascript or server - that's not the case.

2) One of the advantages of an rtcweb model is the clients (ie, browsers) don't need to be upgraded for new functionality - only the javascript does, unless something needs changing in the API itself.  But if the browser is generating the full SDP and handling offer/answer, as your proposal has it, then whenever we need to change SDP handling we need to upgrade the browsers.  For example, there's this lovely sdp-cap-neg mechanism.  If we don't specify the browser has to handle receiving sdp-cap-neg offers on day-1, then the extra attribute lines will be ignored and the SDP answer won't do it.  But it's possible for the javascript script to be upgraded to handle sdp-cap-neg offers itself and choose alternates from within it without upgrading the browser... except now we won't because the browser's doing SDP, and the browser needs to be updated.  Or I suppose the javascript could munge the SDP it gives to the browser, and munge back what it gets back from the browser - but that just shows how silly it is to have SDP be used in the browser to begin with.

3) The converse problem of #2: browsers upgrading with new SDP functionality that the javascript doesn't know about but needs to.  For example, suppose you've built a rtcweb app for trading floor communications.  I won't go into the details of how trading floor calls work, but one of their requirements is no time lag when they press a specific line on their phone, and they are instantly talking (no ringing/handset pickup).  So what your javascript does is actually create a voice channel to every line at the beginning, and just puts them all on "hold" until the user presses a specific line.  To avoid the delay of signaling when the user presses to talk, your javascript never tells the other side about the media being put on/off hold - it's always active bidirectional RTP media as far as that's concerned, and you don't pass the SDP back/forth unless something really changes like addressing info.  Internet Explorer v24 doesn't seem to have a problem with this, because it happens not to know/support/care-about the SDP direction attributes either.  So you deploy this thing and all seems well.  Unbeknownst to you, Internet Explorer v25 makes a small change to its SDP engine, adding support for the direction attribute such that whenever its media is on hold it sets the SDP to a=inactive, and if it receives a=inactive it doesn't send RTP.  Your Rtcweb app will now break, as the call starts out with the media being a=inactive and no SDP gets exchanged to update it back to a=sendrecv.

4) You may feel like SDP belongs in the browser because it's about "media stuff", but that's misleading - its descriptions relate to media sessions, but it includes information from the application layer as well, rather than purely from a media library.  The *browser* only knows a portion of the details.  For example, the following IANA-registered SDP attributes would be unknown to a media library in the browser and only known to the javascript: cat, keywds, tool, type, charset, lang, setup, connection, confid, userid, floorid, and probably a bunch more that I can't be bothered to look up.  And here's a use-case example: suppose I create an Rtcweb app which can make media-loopback calls for testing stuff.  It can't answer such calls, since the browser media library doesn't support loopback, but it can *generate* the calls since the generator side can simply let the user speak into the mic and hear himself/herself on the speakers to verify the media works to the loopback end. (see http://tools.ietf.org/html/draft-ietf-mmusic-media-loopback-15)  All the *browser* needs to do is support normal audio RTP, whereas the javascript or server needs to generate an SDP offer with the loopback attribute, if it uses SIP.  It won't work if the browser is the one creating SDP and handling the offer/answer.  

5) Architecturally, I don't understand why the *browser* needs to know about sessions.  I'm not talking about individual "media sessions", but rather the SIP concept of "sessions".  SDP offer/answer requires this knowledge - it needs to know when a session begins, ends, and its context/state.  Minimally it needs to know this to group media info together (ie, to know that the audio and video are tied to the same session), and to handle the origin line sess-version number, and session-level attributes.  Why should the _browser_ need to know that?  What should it care whether the audio and video being used by a javascript are tied to one call vs. two separate calls??  Why should it even know there is such a thing as a "call"?  It's a media library.  Keep it simple stupid.

6) You ask below in your email what the alternative to using SDP offer/answer would be between the browser and server.  The answer to it seems obvious to me: NOTHING.  There is no need for a standardized protocol to convey media info between the browser and server.  The only need is for a standard to convey the media/ICE/SRTP capabilities and command/setting primitives in an API between javascript and the browser.  That's it.  The javascript developer can convey that information however he/she feels it appropriate to the server, in HTTP, if it even needs conveying to the server.  That's kinda the whole POINT of using javascript!  Let the developer develop.  If they want to use an SDP offer/answer model, they can code javascript to do so.  If they want to send a binary blob instead, even to a separate server, they can.  The HTTP interface is their job, not ours.

-hadriel

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 12 Sep 2011 14:15:18 +0200

>> 2) It will be possible to gateway between legacy SIP devices that support ICE and appropriate RTP / SDP mechanisms and codecs without using a media gateway. A signaling gateway to convert between…

A media gateway (like turn) is also needed when RTP endpoints are using different address families (ipv4 / IPv6).

/O

---

From: Randell Jesup <[email-masked]>
Date: Tue, 13 Sep 2011 14:55:27 -0700

On 9/12/2011 4:56 AM, Hadriel Kaplan wrote:

Not answering the interesting arguments made earlier in his message 
right now.

> 5) Architecturally, I don't understand why the *browser* needs to know about sessions.  I'm not talking about individual "media sessions", but rather the SIP concept of "sessions".  SDP offer/answe…

The browser needs to know *somehow* that certain sets of audio and video 
streams need to be synchronized, and be given the tools and data to do 
so well.  And you may want to synchronize multiple video streams to the 
same audio stream (think the dual-camera case).

I am somewhat torn between ease-of-use for the developers (and increased 
likelihood of them getting it right) and providing a truly generic 
infrastructure that people *can* build anything on top of - but 
decreases the likelihood of getting it right, and decreases the 
likelihood of interop (federation) working or being easy.

-- 
Randell Jesup
[email-masked]

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 14 Sep 2011 12:42:26 +0000

On Sep 13, 2011, at 5:55 PM, Randell Jesup wrote:

> The browser needs to know *somehow* that certain sets of audio and video streams need to be synchronized, and be given the tools and data to do so well.  And you may want to synchronize multiple video streams to the same audio stream (think the dual-camera case).

Good point.  

> I am somewhat torn between ease-of-use for the developers (and increased likelihood of them getting it right) and providing a truly generic infrastructure that people *can* build anything on top of - but decreases the likelihood of getting it right, and decreases the likelihood of interop (federation) working or being easy.

I agree of course, but I wonder if it wouldn't cause more harm than good in the end.  I'm not a web-app developer, but I have to imagine that variances in browser functionality across browser vendors and versions must be a nightmare.  Even if it bloats my javascript, I would rather be in control and able to work across them more than rely on them all getting upgraded.  And my assumption is the less intelligence and knowledge built into the browser, the less variance and bugs there'd be in them.  I mean what are the odds we even get a browser-built-in SDP engine right the first time?  

And do we keep upgrading the browsers to get things like sdp-cap-neg, telepresence/CLUE attributes, SIPREC attributes, etc.?  

There is maybe another option: keep the API to the browser as discrete media settings not SDP, but the IETF or W3C provides an open-source javascript library/code-snippet that handles SDP.  In other words instead of building the SDP into the browser, keep it as javascript but make such a javascript available/approved by the IETF/W3C, for example have the code in an RFC.  That way if we screw it up the web-app developers can fix it (and we can publish an update); and if the web-app developer needs more complex SDP they'll have the code and can modify it; and if they don't need SDP they don't bother using the library; and the browsers don't need upgrading.

-hadriel