Subject: [MMUSIC] UP: Meaning of "scope is WEBRTC"

From: Christer Holmberg <[email-masked]>
Date: Mon, 5 Aug 2013 16:59:15 +0000

Hi,

While cleaning up my MMUSIC notes today, I was listening to the audio recording, in order to get a clarification regarding what "scope is WEBRTC" really means.  However, unless I missed something, I didn't get a clear answer.

Does it only cover the browser API (JSEP) or does it also cover something that can be sent out on the wire (as long as it is not SIP) by a browser?

Feel free to tell me that it is a stupid question, and that the answer is very clear :)

Regards,

Christer

Sent from Windows using TouchDown (www.nitrodesk.com)

---

From: Matthew Kaufman <[email-masked]>
Date: Mon, 05 Aug 2013 12:42:02 -0700

On 8/5/2013 9:59 AM, Christer Holmberg wrote:
> Hi,
> While cleaning up my MMUSIC notes today, I was listening to the audio 
> recording, in order to get a clarification regarding what "scope is 
> WEBRTC" really means. However, unless I missed something, I didn't get 
> a clear answer.
> Does it only cover the browser API (JSEP) or does it also cover 
> something that can be sent out on the wire (as long as it is not SIP) 
> by a browser?
>

And what if it passes through a gateway that doesn't inspect the SDP and 
blindly passes it to a SIP device. What happens then?

RTCWEB used SDP so it would be compatible with SIP legacy devices, so 
certainly this will work... or something about all this has gone off the 
rails.

Matthew Kaufman

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 6 Aug 2013 16:50:20 -0700

Christer said: 

"While cleaning up my MMUSIC notes today, I was listening to the audio recording, in order to get a clarification regarding what "scope is WEBRTC" really means.  However, unless I missed something, I didn't get a clear answer.

Feel free to tell me that it is a stupid question, and that the answer is very clear :)" [BA]  I actually think it is a good question :) One interpretation of "scope is WebRTC"  is that the  SDP in "Unified Plan" applies to use within  the JSEP API.    As a result, one might expect the SDP used in createOffer, setLocalDescription and setRemoteDescription to resemble that in the "Unified Plan" document.   Since signaling is out of scope for WebRTC, applications that use the JSEP API might or might not use the "Unified Plan" SDP in signaling on the wire.   However, "Unified Plan" includes normative references to published SDP specifications that were developed for general use, and the adoption of "Unified Plan" (or even an applicability statement within the "Unified Plan" document) doesn't change the applicability of those documents.  Also, there may be some specifications that are part of the "Unified Plan" workload that may have applicability beyond WebRTC (e.g. a=group: SIMULCAST)  Ultimately, I am expecting the work involved in "Unified Plan" to span multiple documents, and to clarify the applicability,  those individual documents will need to explain what they apply to (just WebRTC use or more general use).

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 7 Aug 2013 12:04:12 +0000

As one of those that used the term, my intention was that the initial decision was to agree to define what RTCWEB needed.

As each dependent working group looks at the extensions they need to do, then they need to make the decision as to whether a wider scope of possible, desirable, or dangerous.

So the BUNDLE status at the moment is that any changes for the unified plan should work for RTCWEB usage, but not for general. It would probably make sense to make it more generally applicable, but that is the next step in the decision process, and may need some other technical decisions before it happens.

Keith

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bernard Aboba
Sent: 07 August 2013 00:50
To: Christer Holmberg; mmusic
Subject: Re: [MMUSIC] UP: Meaning of "scope is WEBRTC"

Christer said:

Feel free to tell me that it is a stupid question, and that the answer is very clear :)"

[BA]  I actually think it is a good question :)

One interpretation of "scope is WebRTC"  is that the  SDP in "Unified Plan" applies to use within  the JSEP API.    As a result, one might expect the SDP used in createOffer, setLocalDescription and setRemoteDescription to resemble that in the "Unified Plan" document.   Since signaling is out of scope for WebRTC, applications that use the JSEP API might or might not use the "Unified Plan" SDP in signaling on the wire.

However, "Unified Plan" includes normative references to published SDP specifications that were developed for general use, and the adoption of "Unified Plan" (or even an applicability statement within the "Unified Plan" document) doesn't change the applicability of those documents.

Also, there may be some specifications that are part of the "Unified Plan" workload that may have applicability beyond WebRTC (e.g. a=group: SIMULCAST)

Ultimately, I am expecting the work involved in "Unified Plan" to span multiple documents, and to clarify the applicability,  those individual documents will need to explain what they apply to (just WebRTC use or more general use).

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 07 Aug 2013 15:40:39 +0200

On 8/7/13 2:04 PM, DRAGE, Keith (Keith) wrote:
> As one of those that used the term, my intention was that the initial
> decision was to agree to define what RTCWEB needed.
>
> As each dependent working group looks at the extensions they need to do,
> then they need to make the decision as to whether a wider scope of
> possible, desirable, or dangerous.
>
> So the BUNDLE status at the moment is that any changes for the unified
> plan should work for RTCWEB usage, but not for general. It would
> probably make sense to make it more generally applicable, but that is
> the next step in the decision process, and may need some other technical
> decisions before it happens.

I don't know how you intend the above to be parsed. Specifically, when 
you say:
   "any changes for the unified plan should work for RTCWEB usage"

Do you mean:

1) that the changes should be designed solely with RTCWEB usage in mind? 
(But are still applicable in other environments that find them useful 
and choose to adopt them.)

Or do you mean:

2) that those changes should not be used in any environment other than 
RTCWEB?

I might be able to accept (1), but not (2).

	Thanks,
	Paul

> Keith
>
> ------------------------------------------------------------------------
>
> *From:[email-masked] [mailto:[email-masked]] *On
> Behalf Of *Bernard Aboba
> *Sent:* 07 August 2013 00:50
> *To:* Christer Holmberg; mmusic
> *Subject:* Re: [MMUSIC] UP: Meaning of "scope is WEBRTC"
>
> Christer said:
>
> "While cleaning up my MMUSIC notes today, I was listening to the audio
> something that can be sent out on the wire (as long as it is not SIP) by
> a browser?
>
> One interpretation of "scope is WebRTC"  is that the  SDP in "Unified
> Plan" applies to use within  the JSEP API.    As a result, one
> might expect the SDP used in createOffer, setLocalDescription and
> setRemoteDescription to resemble that in the "Unified Plan" document.
> Since signaling is out of scope for WebRTC, applications that use the
> JSEP API might or might not use the "Unified Plan" SDP in signaling on
> the wire.
>
> However, "Unified Plan" includes normative references to published SDP
> specifications that were developed for general use, and the adoption of
> "Unified Plan" (or even an applicability statement within the "Unified
> Plan" document) doesn't change the applicability of those documents.
>
> Also, there may be some specifications that are part of the "Unified
> Plan" workload that may have applicability beyond WebRTC (e.g. a=group:
> SIMULCAST)
>
> Ultimately, I am expecting the work involved in "Unified Plan" to span
> multiple documents, and to clarify the applicability,  those individual
> documents will need to explain what they apply to (just WebRTC use or
> more general use).
>
>
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Mary Barnes <[email-masked]>
Date: Wed, 7 Aug 2013 09:56:03 -0500

On Wed, Aug 7, 2013 at 8:40 AM, Paul Kyzivat <[email-masked]> wrote:

> I don't know how you intend the above to be parsed. Specifically, when you
> say:
>
> (But are still applicable in other environments that find them useful and
> choose to adopt them.)
>
> Or do you mean:
>
[MB] I would agree with your (1), however, not with the parenthetical part.
 I would suggest that be "But MAY still be applicable in other
environments... "   My concern is that at this point in time, you can't say
that the changes ARE applicable to other environments ....  [/MB]

>
>         Thanks,
>         Paul
>
>
>  Keith
>>
>> ------------------------------**------------------------------**
>> ------------
>>
>> *From:[email-masked] [mailto:mmusic-bounces@ietf.**org<[email-masked]>]
>> *On
>> Behalf Of *Bernard Aboba
>> ______________________________**_________________
>> mmusic mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/mmusic<https://www.ietf.org/mailman/listinfo/mmusic>
>>
>>
> ______________________________**_________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/mmusic<https://www.ietf.org/mailman/listinfo/mmusic>
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 7 Aug 2013 15:21:26 +0000

Hi,

Ok, so what is "RTCWEB usage" then? :)

For example, if I implement a JavaScript SIP app, and want to use the UP with SIP on the wire, would that be a "RTCWEB usage"? My understanding is that it would NOT be.

My personal understanding of the scope is:

1)      JSEP; and

2)      Browser-to-browser cases where we KNOW there are no intermediaries etc in between.

Regards,

Christer

Lähettäjä: [email-masked] [mailto:[email-masked]] Puolesta Mary Barnes
Lähetetty: 7. elokuuta 2013 17:56
Vastaanottaja: Paul Kyzivat
Kopio: [email-masked]
Aihe: Re: [MMUSIC] UP: Meaning of "scope is WEBRTC"

On Wed, Aug 7, 2013 at 8:40 AM, Paul Kyzivat <[email-masked]<mailto:[email-masked]>> wrote:
On 8/7/13 2:04 PM, DRAGE, Keith (Keith) wrote:
As one of those that used the term, my intention was that the initial
decision was to agree to define what RTCWEB needed.

I don't know how you intend the above to be parsed. Specifically, when you say:

1) that the changes should be designed solely with RTCWEB usage in mind? (But are still applicable in other environments that find them useful and choose to adopt them.)

Or do you mean:

2) that those changes should not be used in any environment other than RTCWEB?

I might be able to accept (1), but not (2).
[MB] I would agree with your (1), however, not with the parenthetical part.  I would suggest that be "But MAY still be applicable in other environments... "   My concern is that at this point in time, you can't say that the changes ARE applicable to other environments ....  [/MB]

        Thanks,
        Paul

Keith

*From:[email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] *On
Behalf Of *Bernard Aboba
*Sent:* 07 August 2013 00:50
*To:* Christer Holmberg; mmusic
*Subject:* Re: [MMUSIC] UP: Meaning of "scope is WEBRTC"

Christer said:

Feel free to tell me that it is a stupid question, and that the answer
is very clear :)"

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

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

---

From: Mary Barnes <[email-masked]>
Date: Wed, 7 Aug 2013 10:25:14 -0500

On Wed, Aug 7, 2013 at 10:21 AM, Christer Holmberg <
[email-masked]> wrote:

>  Hi,****
>
> ** **
>
> Ok, so what is ”RTCWEB usage” then? :)****
>
> ** **
>
> For example, if I implement a JavaScript SIP app, and want to use the UP
> with SIP on the wire, would that be a “RTCWEB usage”? My understanding is
> that it would NOT be.****
>
> ** **
>
[MB] That is also my understanding. [/MB]

> ****
>
> ** **
>
> **1)      **JSEP; and****
>
> **2)      **Browser-to-browser cases where we KNOW there are no
> intermediaries etc in between.****
>
> ** **
>
> Regards,****
>
> ** **
>
> Christer****
>
> ** **
>
> *Lähettäjä:* [email-masked] [mailto:[email-masked]] *Puolesta
> *Mary Barnes
> *Lähetetty:* 7. elokuuta 2013 17:56
> *Vastaanottaja:* Paul Kyzivat
> *Kopio:* [email-masked]
> *Aihe:* Re: [MMUSIC] UP: Meaning of "scope is WEBRTC"****
>
> ** **
>
> On Wed, Aug 7, 2013 at 8:40 AM, Paul Kyzivat <[email-masked]>
> wrote:****
>
>  On 8/7/13 2:04 PM, DRAGE, Keith (Keith) wrote:****
>
> decisions before it happens.****
>
> ** **
>
> say:****
>   "any changes for the unified plan should work for RTCWEB usage"****
>
> Do you mean:
>
> I might be able to accept (1), but not (2).****
>
>  [MB] I would agree with your (1), however, not with the parenthetical
> part.  I would suggest that be "But MAY still be applicable in other
> that the changes ARE applicable to other environments ....  [/MB]****
>
>  ****
>
>
>         Thanks,
>         Paul
>
> ****
>
> Keith
>
> *Subject:* Re: [MMUSIC] UP: Meaning of "scope is WEBRTC"****
>
>
>
> Christer said:
>
> ****
> https://www.ietf.org/mailman/listinfo/mmusic****
>
>
> https://www.ietf.org/mailman/listinfo/mmusic****
>
>  ** **
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 7 Aug 2013 15:27:35 +0000

If everyone has the same understanding, I would ask the chairs to make it very clear in the final minutes ;)

Regards,

Christer

Lähettäjä: Mary Barnes [mailto:[email-masked]]
Lähetetty: 7. elokuuta 2013 18:25
Vastaanottaja: Christer Holmberg
Kopio: Paul Kyzivat; [email-masked]
Aihe: Re: [MMUSIC] UP: Meaning of "scope is WEBRTC"

On Wed, Aug 7, 2013 at 10:21 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

1)      JSEP; and

Regards,

Christer

Lähettäjä: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] Puolesta Mary Barnes
Lähetetty: 7. elokuuta 2013 17:56
Vastaanottaja: Paul Kyzivat
Kopio: [email-masked]<mailto:[email-masked]>
Aihe: Re: [MMUSIC] UP: Meaning of "scope is WEBRTC"

Or do you mean:

        Thanks,
        Paul
Keith

Christer said:

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 7 Aug 2013 17:26:15 +0000

I said that all the involved groups need to make a second step with all their deliverables, which is to decide whether what they are doing is used generally, or solely in the context of WEBRTC.

Deciding whether it is 1) or 2) has not been defined in my understanding, and would really come under the scope of the second decision.

I for one am hoping as much of this as possible comes out as being generally applicable, and obviously designed as such as a result, but the MMUSIC WG did not appear to be ready to say that last week. So some steps to get there.

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Paul Kyzivat 
> Sent: 07 August 2013 14:41
> To: [email-masked]

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 7 Aug 2013 13:26:07 -0400

On Aug 7, 2013, at 11:21 AM, Christer Holmberg <[email-masked]> wrote:

> Ok, so what is ”RTCWEB usage” then? :)
> For example, if I implement a JavaScript SIP app, and want to use the UP with SIP on the wire, would that be a “RTCWEB usage”? My understanding is that it would NOT be.

No it wouldn't be, imo, but perhaps in a different way than you mean it.  If you implement "SIP", by definition you follow the SIP RFCs.  If you don't follow SIP RFCs, you're not really implementing SIP.  It's no different than if you wrote it in C++ or Java or whatever, as a native application.  The fact that you're running inside a browser and using javascript as a language doesn't change the SIP protocol or what it needs to do/not-do to interoperate with other SIP devices.  

If you don't want to interoperate with other SIP devices and the deployed SIP domains, then do whatever you like and add whatever extensions you wish.  There's no protocol police, nor need for one, when two hosts want to do whatever they want to do with each other.  So long as they are running the same code (e.g., javascript), or privately agree on how things work between each other, things work in an interoperable fashion.

I think people want to think of WebRTC as SIPv3, but it isn't - there's no actual signaling protocol defined, nor does it make sense to define one.  Even the JSEP draft makes the point that the application can do whatever it likes on-the-wire. (right?)  The fact that WebRTC uses SDP for the "API" is an (unfortunate) coincidence - I don't mean it was done by accident, since clearly it wasn't - but I mean its usage in a WebRTC context is not defined as the on-the-wire encoding for host-to-host media session exchange/negotiation protocol.  We might use it that way in our javascript app, and draw it that way in powerpoint, but it's not one.  It's silly to constrain WebRTC applications to semantics/behaviors SIP or RTSP or MGCP support, even when using SDP for the Javascript API.  If JSEP, for example, wants to go do all kinds of new things for itself, it should be able to - without impacting anything else.

> 2)      Browser-to-browser cases where we KNOW there are no intermediaries etc in between.

My understanding of the "scope" is that it's applicable to the actual Javascript API as well as (1) JSEP.  Saying (2) is a bit weird, both because it can be between a browser and a native application or server or gateway or whatever, but also because there are in fact intermediaries (HTTP Proxies, for example).

-hadriel

---

From: Matthew Kaufman <[email-masked]>
Date: Thu, 08 Aug 2013 15:08:39 -0700

On 8/5/2013 12:42 PM, Matthew Kaufman wrote:
>> WEBRTC" really means.  However, unless I missed something, I didn't 
>> get a clear answer.
> And what if it passes through a gateway that doesn't inspect the SDP 
> and blindly passes it to a SIP device. What happens then?
>
> certainly this will work... or something about all this has gone off 
> the rails.
>
> Matthew Kaufman

There's been some great discussion in this thread, but nobody has 
answered my question or provided feedback on my interpretation of what 
might has happened. Anyone?

Matthew Kaufman

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 9 Aug 2013 10:24:14 -0400

On Aug 8, 2013, at 6:08 PM, Matthew Kaufman <[email-masked]> wrote:

>> And what if it passes through a gateway that doesn't inspect the SDP and blindly passes it to a SIP device. What happens then?
>> 
>> RTCWEB used SDP so it would be compatible with SIP legacy devices, so certainly this will work... or something about all this has gone off the rails.

Are we talking about theory, or reality?

I've been told that one vendor thinks they'll be able to pass the SDP from WebRTC-land to SIP-land unchanged.  My belief is that this would require all the SIP devices in their SIP-land to be manufactured by them, or at least known to support their particular features.  But for their general/common customer environment, that's likely to be the case so it's not an issue for them. (unless of course the requests get forwarded outside their domain, but for that they sell SBCs to normalize it all)

For most vendors and deployment scenarios, however, I think blindly passing SDP between WebRTC and SIP is a pipe dream.  At the very least, there'll be a lot of media-plane interworking for some WbeRTC-SIP interworking gateway to perform, so it can't be SDP agnostic/blind.  Things like ICE termination, SRTP interworking or termination, audio transcoding, and perhaps data-channel interworking for certain applications.  It might also want to do BUNDLE rtp-mux termination, although the complexities of that in the media-plane likely outweigh the benefits.

As far as I can recall, however, the main benefit of WebRTC using SDP was NOT the ability to interwork to SIP easily.  That was more of a frosting-on-the-cake type thing.  The main benefit its proponents espoused was that it would let simple WebRTC use-cases be done easily, with few lines of JS code.  Advanced use-cases would be possible, but not easy.  I.e., they would require SDP munging in JS, or worse.

Or at least that is my impression of what the main argument for SDP was.  Of course this was like two years ago, so my memory could be faulty.  Maybe it was not the main argument, but just the one that I personally felt was actually valid and laudable. :)

-hadriel

---

From: Justin Uberti <[email-masked]>
Date: Fri, 9 Aug 2013 15:35:00 -0700

That is not my understanding. If we don't care about intermediaries, we
could have made BUNDLE and UP a lot simpler.

I think the expectation should be that Matthew's proposed case will work,
modulo any implementation bugs on the remote device.

On Wed, Aug 7, 2013 at 8:27 AM, Christer Holmberg <
[email-masked]> wrote:

>  If everyone has the same understanding, I would ask the chairs to make
> it *very clear* in the final minutes ;)****
>
> ** **
>
> Regards,****
>
> ** **
>
> Christer****
>
> ** **
>
> ** **
>
> ** **
>
> *Lähettäjä:* Mary Barnes [mailto:[email-masked]]
> *Lähetetty:* 7. elokuuta 2013 18:25
> *Vastaanottaja:* Christer Holmberg
> *Kopio:* Paul Kyzivat; [email-masked]
>
> [email-masked]> wrote:****
>
> Hi,****
>
>  ****
>
> My personal understanding of the scope is:****
>
> [MB] That is also my understanding. [/MB] ****
>
>   ****
>
> 1)      JSEP; and****
>
> 2)      Browser-to-browser cases where we KNOW there are no
>         Paul****

---

From: Matthew Kaufman <[email-masked]>
Date: Fri, 09 Aug 2013 16:11:29 -0700

On 8/9/2013 3:35 PM, Justin Uberti wrote:
> That is not my understanding. If we don't care about intermediaries, 
> we could have made BUNDLE and UP a lot simpler.
>
> I think the expectation should be that Matthew's proposed case will 
> work, modulo any implementation bugs on the remote device.
>

I agree. Otherwise we're doing this "standards" thing wrong OR shouldn't 
be reusing *this* standard for *that* application.

Matthew Kaufman

---

From: "Parthasarathi R" <[email-masked]>
Date: Sun, 11 Aug 2013 00:33:54 +0530

Matthew,

I like your argument of "shouldn't be reusing *this* standard for *that*
application". I have already mentioned in draft-partha-rtcweb-jsep-sip-00
that SDP usage in WebRTC is making the complication in interworking with
SIP. The current Unified plan (UP) is adding fuel to the fire. In case UP
plan is not going to work with SIP/RFC 3264 based mechanism, I agree with
your statement of "we're doing this "standards" thing wrong". 

I started thinking the standards are going wrong after the current UP
discussion as 

1) Some of the web developers are already not interested in current WebRTC
SDP (last month Public-webrtc discussion)
2) WebRTC SDP will not be suitable for future SIP based devices as well and
not just legacy PSTN/PLMN/Enterprise SIP devices.
3) My guess from your words is that WebRTC SDP is not so useful/flexible for
proprietary VoIP apps like Skype. 
4) I'm getting the feeling that WebRTC SDP mechanism will work only for
Jingle (XMPP based) sort of mechanism and not for anything else.
(Disclaimer: I don't know much about Jingle).

Having said that, I guess that UP will be updated to work at least with RFC
3264 (offer/answer) requirements and WebRTC SDP shall be reused for SIP
application. 

Thanks
Partha

PS: CU-WebRTC kind of WebRTC API will be more useful to interop with SIP
than current UP based WebRTC API as SDP required for SIP shall be built
using JavaScript/another W3C API in case CU-WebRTC kind of API exists. 

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Matthew Kaufman
> Sent: Saturday, August 10, 2013 4:41 AM
> To: [email-masked]

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 12 Aug 2013 11:18:32 -0400

From a chair point of view, the intent with "scope is WebRTC" was 
largely what Paul described as option 1) below although I'd change 
"solely" to "primarily" (intent being that WebRTC is the primary driver, 
but if we can trivially and without controversy provide solutions that 
apply beyond that, then that would be desirable).

As Keith points out, this limited scope deliverable creates a new 
question in terms of scope for all the derived deliverables that have to 
be developed in the various WGs. It's not clear that we will have a 
single answer for all of these and taking BUNDLE as an example, it's 
currently an MMUSIC WG item, but its scope so far has not been limited 
to WebRTC (and I believe Colin argued in favor of keeping it that way at 
the Berlin meeting as well).

Thanks

-- Flemming

On 8/7/13 1:26 PM, DRAGE, Keith (Keith) wrote:
> .

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 12 Aug 2013 11:20:49 -0400

On 8/7/13 11:27 AM, Christer Holmberg wrote:
> it *very clear* in the final minutes ;)
>
I think the minutes should only reflect what was actually discussed in 
the meeting so I'm not sure we can record it there. However if we can 
conclude this thread with general agreement on the interpretation, then 
we can add a pointer/note to that effect.

Thanks

-- Flemming

> Regards,
>
> Christer
>
> *Lähettäjä:*Mary Barnes [mailto:[email-masked]]
> *Aihe:* Re: [MMUSIC] UP: Meaning of "scope is WEBRTC"
>
> On Wed, Aug 7, 2013 at 10:21 AM, Christer Holmberg 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
> Hi,
>
> For example, if I implement a JavaScript SIP app, and want to use the 
> UP with SIP on the wire, would that be a "RTCWEB usage"? My 
> understanding is that it would NOT be.
>
>     1)JSEP; and
>     2)Browser-to-browser cases where we KNOW there are no
>     intermediaries etc in between.
>
>     Regards,
>
>     Christer
>
>     *Lähettäjä:[email-masked]
>     <mailto:[email-masked]> [mailto:[email-masked]
>     <mailto:[email-masked]>] *Puolesta *Mary Barnes
>     *Kopio:* [email-masked] <mailto:[email-masked]>
>     *Aihe:* Re: [MMUSIC] UP: Meaning of "scope is WEBRTC"
>
>     On Wed, Aug 7, 2013 at 8:40 AM, Paul Kyzivat
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>         1) that the changes should be designed solely with RTCWEB
>         usage in mind? (But are still applicable in other environments
>         that find them useful and choose to adopt them.)
>
>         Or do you mean:
>
>     [MB] I would agree with your (1), however, not with the
>     parenthetical part.  I would suggest that be "But MAY still be
>     applicable in other environments... "   My concern is that at this
>     point in time, you can't say that the changes ARE applicable to
>     other environments ....  [/MB]
>
>
>                 Thanks,
>                 Paul
>
>         Keith
>
>         *From:[email-masked]
>         <mailto:[email-masked]>
>         [mailto:[email-masked]
>         <mailto:[email-masked]>] *On
>         Behalf Of *Bernard Aboba
>         [email-masked] <mailto:[email-masked]>
>         [email-masked] <mailto:[email-masked]>

---

From: "Roni Even" <[email-masked]>
Date: Tue, 13 Aug 2013 09:56:50 +0300

Hi, 
I agree with Paul's first option.
I think that section 2 of the UP draft provides the solution overview and
some of the points are solely RTCweb while some  of the points may be used
by other solution.

One important point made in the presentation was that this does not change
RFC3264 so others can choose different solution, for example, instead of the
first two bullet items in section 2 while not changing RFC3264 . 

Since this solution does not change RFC3264 I see no problem on the scope of
work in other WG. It just need to be clear about the applicability of the
work and having it address both RFC3264 and UP. 

Roni Even

> Behalf Of Flemming Andreasen
> Sent: 12 August, 2013 6:19 PM
> To: DRAGE, Keith (Keith)
> Cc: [email-masked]; Paul Kyzivat
>  From a chair point of view, the intent with "scope is WebRTC" was largely
> what Paul described as option 1) below although I'd change "solely" to
> "primarily" (intent being that WebRTC is the primary driver, but if we can
> trivially and without controversy provide solutions that apply beyond
that,
> then that would be desirable).
> 
> As Keith points out, this limited scope deliverable creates a new question
in
> terms of scope for all the derived deliverables that have to be developed
in
> the various WGs. It's not clear that we will have a single answer for all
of
> these and taking BUNDLE as an example, it's currently an MMUSIC WG item,
> but its scope so far has not been limited to WebRTC (and I believe Colin
> argued in favor of keeping it that way at the Berlin meeting as well).
> 
> Thanks
> 
> -- Flemming
> 
> 
> > I said that all the involved groups need to make a second step with all
their
> deliverables, which is to decide whether what they are doing is used
> generally, or solely in the context of WEBRTC.
> >
> > Deciding whether it is 1) or 2) has not been defined in my
understanding,
> and would really come under the scope of the second decision.
> >
> > I for one am hoping as much of this as possible comes out as being
> generally applicable, and obviously designed as such as a result, but the
> MMUSIC WG did not appear to be ready to say that last week. So some steps
> to get there.
> >
> > Keith
> >
> >
> >> Behalf Of Paul Kyzivat
> >>> As one of those that used the term, my intention was that the
> >>> initial decision was to agree to define what RTCWEB needed.
> >>>
> >>> As each dependent working group looks at the extensions they need to
> >>> do, then they need to make the decision as to whether a wider scope
> >>> of possible, desirable, or dangerous.
> >>>
> >>> So the BUNDLE status at the moment is that any changes for the
> >>> unified plan should work for RTCWEB usage, but not for general. It
> >>> would probably make sense to make it more generally applicable, but
> >>> that is the next step in the decision process, and may need some
> >>> other technical decisions before it happens.
> >>> "While cleaning up my MMUSIC notes today, I was listening to the
> >>> audio recording, in order to get a clarification regarding what
> >>> "scope is WEBRTC" really means.  However, unless I missed something,
> >>> I didn't get a clear answer.
> >>>
> >>> something that can be sent out on the wire (as long as it is not
> >>> SIP) by a browser?
> >>>
> >>> Since signaling is out of scope for WebRTC, applications that use
> >>> the JSEP API might or might not use the "Unified Plan" SDP in
> >>> signaling on the wire.
> >>>
> >>> However, "Unified Plan" includes normative references to published
> >>> SDP specifications that were developed for general use, and the
> >>> adoption of "Unified Plan" (or even an applicability statement
> >>> within the "Unified Plan" document) doesn't change the applicability
of
> those documents.
> >>> Ultimately, I am expecting the work involved in "Unified Plan" to
> >>> span multiple documents, and to clarify the applicability,  those
> >>> individual documents will need to explain what they apply to (just
> >>> WebRTC use or more general use).
> >>>
> >>>
> >>>