Subject: [rtcweb] draft-kaplan-rtcweb-sip-interworking-requirements-00

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 24 Oct 2011 23:30:11 +0000

Howdy,
I've submitted a draft listing some use-cases and resulting requirements for interworking from RTCWeb (or "WebRTC" as the case may be), to deployed SIP domains/devices.
The draft also discusses the functions which may be required in an interworking device, should some of the requirements not be met.

The purpose of the draft is to put pen-to-paper on some of the emails flying around the past month, to stimulate discussion, and hopefully drive consensus decisions sooner rather than later.
Info below.

Note that most of the doc is about media-plane issues, rather than about SIP/SDP as I expect Cullen's soon-to-be-announced ROAP signaling-gateway draft will be.

-hadriel

Begin forwarded message:

> From: <[email-masked]>
> Subject: I-D Action: draft-kaplan-rtcweb-sip-interworking-requirements-00.txt
> Date: October 24, 2011 6:42:57 PM EDT
> To: <[email-masked]>
> Reply-To: <[email-masked]>
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 	Title           : Requirements for Interworking RTCWeb with Current SIP Deployments
> 	Author(s)       : Hadriel Kaplan
> 	Filename        : draft-kaplan-rtcweb-sip-interworking-requirements-00.txt
> 	Pages           : 22
> 	Date            : 2011-10-24
> 
>   The IETF RTCWEB WG has been discussing how to interwork with
>   deployed SIP equipment and domains.  Doing so may require an
>   Interworking Function middlebox in the media-plane.  This document
>   lists some RTCWeb-to-SIP use-cases, the RTCWeb requirements to
>   support such, and the complexity involved in interworking if the
>   requirements cannot be met.
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-kaplan-rtcweb-sip-interworking-requirements-00.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-kaplan-rtcweb-sip-interworking-requirements-00.txt
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Tue, 25 Oct 2011 10:26:38 +0530

Hadriel,

It is nice to see the discussion on Federation protocol for WebRTC
(RTCWeb). I agree that the high level architecture will be same as you
projected in your draft. Even in case ROAP is accepted as standard
interface, there will be no change in the architecture. But I'm not in
agreement with the requirement in Sec 6 and Sec 7 of your document
because it influence the specific implementation. 

I'll take A1-1 requirement of SIP forking wherein it is very much
possible for RTCWEB-SIP gateway to hide the forking functionality from
browser and it is normal B2BUA (SBC in market term) functionality in SIP
wherein originating SIP UA does not support forking properly. IOW,
please don't add requirement in RTCWeb for the sake SIP interop and it
is possible to design the better gateway if required. I'm looking for
standard RTCWeb signaling protocol like ROAP by which better solution
for RTCWeb-federation gateway is documented in IETF.

Also, I'm interested in hearing about other RTCWeb federation protocol
like Jingle before doing the deep-dive into the requirement because my
gut feeling is that we will end-up in multiple federation protocol
rather than single.

Thanks
Partha 

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On
Behalf
>Of Hadriel Kaplan
>Sent: Tuesday, October 25, 2011 5:00 AM
>To: [email-masked]
>Subject: [rtcweb] draft-kaplan-rtcweb-sip-interworking-requirements-00
>
>Howdy,
>I've submitted a draft listing some use-cases and resulting
requirements
>for interworking from RTCWeb (or "WebRTC" as the case may be), to
>deployed SIP domains/devices.
>The draft also discusses the functions which may be required in an
>interworking device, should some of the requirements not be met.
>
>The purpose of the draft is to put pen-to-paper on some of the emails
>flying around the past month, to stimulate discussion, and hopefully
>drive consensus decisions sooner rather than later.
>Info below.
>
>Note that most of the doc is about media-plane issues, rather than
about
>SIP/SDP as I expect Cullen's soon-to-be-announced ROAP
signaling-gateway
>draft will be.
>rtcweb mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/rtcweb

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Tue, 25 Oct 2011 11:36:52 +0530

Just adding one more point regarding architecture, Media plane
interworking function is an optional element for the next generation
(release) of SIP devices wherein Media agent of SIP UA will be able to
interop directly with browser media plane without intermediate
media-plane gateways.

Thanks
Partha

>From: Ravindran Parthasarathi
>Sent: Tuesday, October 25, 2011 10:27 AM
>To: 'Hadriel Kaplan'; [email-masked]
>Subject: RE: [rtcweb]
draft-kaplan-rtcweb-sip-interworking-requirements-
>00
>>SIP/SDP as I expect Cullen's soon-to-be-announced ROAP signaling-
>gateway
>>draft will be.
>>
>>-hadriel
>>
>>
>>Begin forwarded message:
>>

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 25 Oct 2011 06:33:05 +0000

Partha,
comments inline...

On Oct 25, 2011, at 12:56 AM, Ravindran Parthasarathi wrote:

> But I'm not in

Just to be clear, and the draft is a bit confusing about this: the draft isn't stating that the RTCWEB Working Group has to comply with all the requirements - in fact, I expect some can't be complied with due to security issues or IPR issues.  It's merely stating what has to be done to avoid needing an interworking function in the signaling and/or media-planes, for various common use-cases; and what the complexity is for the different interworking functions should they be needed.

There was an expressed desire from some of the WG members that interworking with deployed SIP devices be possible, with as little complexity as possible, and this draft is just stating what that would entail for various use-cases.  That way we can come to some consensus on what RTCWeb needs to support and how.

> for RTCWeb-federation gateway is documented in IETF.

Of course an SBC or gateway could do that - an SBC or gateway can do all of it, obviously, and some already do most of it already today.  That's not the point.  The point is there's complexity involved in the functions, which translates to cost ultimately, and if we want to keep the complexity down we need to try to avoid needing to do them, or as many of them as possible/practical.  For example many SBCs can do transcoding, but it costs money and potentially impacts call quality, so we should try avoiding that... especially since it's easy to avoid in the G.711 case. (G.711 is trivial to implement and not under IPR, afaik)

> gut feeling is that we will end-up in multiple federation protocol

The draft isn't suggesting SIP be a mandated "federation" protocol.  I don't believe we can nor should mandate a federation protocol, nor any protocol outside of RTCWeb.  But SIP is an IETF protocol and quite popular, so this is just an Informational draft stating what would be needed to do so, to/from deployed SIP domains/devices.

Also, I don't use the word "federation" in the draft for a reason: an obvious use-case for RTCWeb is one where an Enterprise uses RTCWeb on their Web servers, for either their employees or for customer pages such as support or sales pages, but needs to interwork that to SIP internally to their SIP systems for numerous reasons.  Likewise a SIP Service Provider could use RTCWeb as another means of customer universal access, and interface it to SIP to reach their SIP devices/systems.  It's not "federation" - it's just going from RTCWeb to deployed SIP devices/systems, possibly in the same administrative organization/company.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 25 Oct 2011 06:45:18 +0000

> interop directly with browser media plane without intermediate

Do you mean that statement as an argument against the draft?  That was why I kept using the term "deployed" throughout the draft. :)

Or did you mean it in the sense of an additional requirement that should be added to draft?  That would make sense and I can add it.  Something like:

"It MUST be possible to determine whether interworking is required on a session-by-session basis in order to avoid performing interworking when it is not needed."

Does that capture what you meant?

I think that's possible to do for pretty much everything in the draft, except RTCP generation. (which is possibly the ugliest interworking to have to do in the whole doc)

-hadriel

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 25 Oct 2011 10:39:13 +0200

2011/10/25 Ravindran Parthasarathi <[email-masked]>:
> is possible to design the better gateway if required.

Please take into account that some of us also desire to interoperate
with SIP but we *don't* need a B2BUA/SBC neither a protocol gateway
for such interconnection (instead we are using *now* a SIP proxy
implementing SIP over WebSocket so the JavaScript application becomes
a real SIP UA).

Having said that, SIP forking is a *feature* rather than a punishment.
It adds complexity of course, but still it's an useful feature. Some
of us want to deal with that complexity at UA level (JavaScript). Some
others would prefer not to allow forking in their RTC-Web scenarios so
have no need to deal with forking. Let's the people choose it.

> I'm looking for

Yes, you want to mandate some specific in-the-wire signaling protocol
in RTCweb and force me, and others, to use a RTCWeb-SIP gateway box
(regardless I already have my RTCweb solution ready to interop with a
SIP network in the signaling plane without using protocol gateways). I
would ask you to read this draft in which different RTCweb scenarios
are described:

  http://tools.ietf.org/html/draft-sipdoc-rtcweb-open-wire-protocol-00

> gut feeling is that we will end-up in multiple federation protocol

I hope that we will end with *no one* federation protocol so each
website can decide what to use in case it wants to federate with other
website. Web will decide, as it always does. The important point here
is to leave the Web the freedom to choose whichever federation
mechanism. Some mechanism/protocol will success more than others and
will become de facto RTCweb federation protocol in the Web. This is
how things work in the Web.

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 25 Oct 2011 11:50:04 +0200

> I've submitted a draft listing some use-cases and resulting requirements for interworking from RTCWeb (or "WebRTC" as the case may be), to deployed SIP domains/devices.

I think this draft is useful, but IMHO this WG is becoming too much
oriented to "interoperability with SIP", even worse, "interoperability
with *already* existing SIP domains" (those that don't implement
security at all given the fact that most of the SIP deployments run in
private or trusted networks).

I expect that 99% of websites interested in offering RTCweb
capabilities won't be interested (or won't need) interoperability with
a SIP network neither inter-federation with other RTCweb "domains".
IMHO RTCweb should focus on making easy the RTCweb adoption by those
99% of websites. Interoperability with SIP is important, but IMHO it
should not be the main purpose of RTCweb.

Having said that, more participation of Web folks in this WG would be
nice. Probably they cannot help in technical RTC subjects by they can
give us a real vision of what is needed in the current Web model (just
my opinion).

> The draft also discusses the functions which may be required in an interworking device, should some of the requirements not be met.

Let me a question about section 4.2.2:

----------------------------
4.2.2     SRTP Termination    [...]   It should be noted that if SRTP
is required to be used for every    call by RTCWeb but the [SDES] key
exchange model cannot be used on    the RTCWeb side, then the
Interworking Function likely has to    terminate SRTP from RTCWeb even
if the SIP-domain supports SRTP,    because [SDES] is the most
commonly used form of key exchange in SIP
today.------------------------------

I was not aware of such limitation. Could you please point me to some
draft or mail thread in which that limitation (SDES key exchange model
cannot be used on the RTCWeb side) is explained?

Thanks a lot.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 25 Oct 2011 11:56:01 +0200

> give us a real vision of what is needed in the current Web model (just

Sorry:

s/by they can/but they can/

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 25 Oct 2011 17:32:40 +0000

> Let me a question about section 4.2.2:

There were discussions at a previous meeting and an email thread a while back on whether (1) SRTP should be mandatory to use, and (2) on whether it must be dtls-srtp key exchange.

I believe one thread on this was started here:
http://www.ietf.org/mail-archive/web/rtcweb/current/msg00460.html

I don't know if a conclusion/consensus was reached. Thus I wrote that section of the draft assuming it could go either way. 

-hadriel

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Fri, 28 Oct 2011 23:26:15 +0530

By looking at draft-ietf-rtcweb-use-cases-and-requirements-06, I could not see any specific requirement for RTCWeb forking. In case SIP forking is the only requirement for RTCWeb and also, RTCWeb does not have any specific forking requirement, then the gateway between RTCWeb & SIP shall take care of the functionality. I'm asking this question to get the clarity on whether SIP forking feature has to impact RTCWeb client requirement or not. 

Thanks
Partha

>From: Iñaki Baz Castillo [mailto:[email-masked]]
>Sent: Tuesday, October 25, 2011 2:09 PM
>To: Ravindran Parthasarathi
>Cc: Hadriel Kaplan; [email-masked]
>Subject: Re: [rtcweb] draft-kaplan-rtcweb-sip-interworking-requirements-
>00
>

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 28 Oct 2011 11:27:31 -0700

On 10/28/2011 10:56 AM, Ravindran Parthasarathi wrote:
> By looking at draft-ietf-rtcweb-use-cases-and-requirements-06, I could not see any specific requirement for RTCWeb forking. In case SIP forking is the only requirement for RTCWeb and also, RTCWeb does not have any specific forking requirement, then the gateway between RTCWeb&  SIP shall take care of the functionality. I'm asking this question to get the clarity on whether SIP forking feature has to impact RTCWeb client requirement or not.
I believe the "Fedex IVR" case was specifically intended to surface the 
requirement for "non-final responses" (switching a media stream from the 
initial responder to a next responder).
That's one form of forking ("serial fork"?)

I haven't understood forking to be a requirement in any other use case.

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Sat, 29 Oct 2011 00:44:03 +0530

Harald,

Thanks for the clarification. "Fedex IVR" usecase is under browser to GW/server section (sec 4.3) which is a SIP based forking requirement. If you look at carefully, "Fedex IVR non-final response" scenario could have be achieved cleanly using two separate offer/answer exchange & two final responses (INVITE/200/ACK, RE-INVITE/200/ACK) :

1) customer - fedex IVR offer/answer exchange
2) fedex agent - Customer offer/answer exchange

but it may be avoided in legacy for billing reasons which should not be major concern for RTCWeb. In case of SIP forking, it is assumed that 2nd answer override the 1st answer in the media plane.

As I mentioned earlier, SIP (serial) forking requirement shall be met by gateway signaling and no extra requirement for browser. Also, switching media stream from one responder to other responder in Fedex IVR usecase is not so easy because of legacy media handling (ICE, RTCP) differences as mentioned in draft-kaplan-rtcweb-sip-interworking-requirements-00.

ISTM, we don't have RTCWeb specific forking usecase till now.

Thanks
Partha 
 
>From: Harald Alvestrand [mailto:[email-masked]]
>Sent: Friday, October 28, 2011 11:58 PM
>Cc: Iñaki Baz Castillo; [email-masked]; Hadriel Kaplan
>Subject: Re: [rtcweb] RTCWeb Forking usecase [was RE: draft-kaplan-
>rtcweb-sip-interworking-requirements-00]
>
>> By looking at draft-ietf-rtcweb-use-cases-and-requirements-06, I could
>not see any specific requirement for RTCWeb forking. In case SIP forking
>is the only requirement for RTCWeb and also, RTCWeb does not have any
>specific forking requirement, then the gateway between RTCWeb&  SIP
>shall take care of the functionality. I'm asking this question to get
>the clarity on whether SIP forking feature has to impact RTCWeb client
>requirement or not.

---

From: Roman Shpount <[email-masked]>
Date: Fri, 28 Oct 2011 15:29:19 -0400

On Fri, Oct 28, 2011 at 3:14 PM, Ravindran Parthasarathi <
[email-masked]> wrote:

>
> Thanks for the clarification. "Fedex IVR" usecase is under browser to
> GW/server section (sec 4.3) which is a SIP based forking requirement. If you
> look at carefully, "Fedex IVR non-final response" scenario could have be
> achieved cleanly using two separate offer/answer exchange & two final
> responses (INVITE/200/ACK, RE-INVITE/200/ACK) :
>
>
This is actually wrong, unless we specify that WebRTC is always using the
same media stream address parameters (list of ICE candidates) within the
same call. If in WebRTC this cannot be guaranteed, serial forking cannot be
implemented unless multiple answers can be provided to the same offer. In
other words we either get the same offer from WebRTC client so we can
quietly not send it, or multiple answers need to be provided.

In addition to Fedex IVR scenario, we also have find-me/follow-me scenarios
where either multiple early media sources are playing at the same time (land
line ring back and cell phone ring back). We also sometimes end up with
situations where two people answer the same call, such as boss and a
secretary answering the same call.
_____________
Roman Shpount

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 28 Oct 2011 21:34:16 +0200

2011/10/28 Ravindran Parthasarathi <[email-masked]>:
> As I mentioned earlier, SIP (serial) forking requirement shall be met by gateway signaling and no extra requirement for browser.

Do it in your gateway if you want, but don't try to mandate it please.
As I also mentioned earlier, some of us are willing to handle forking
in the WebRTC client (at JavaScript level) and that is perfectly
possible.

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Sat, 29 Oct 2011 01:13:12 +0530

Inaki,

ISTM, SIP specific functionality is pushed into WebRTC client unnecessary without well-defined WebRTC usecase. 

Thanks
Partha

>Sent: Saturday, October 29, 2011 1:04 AM
>Cc: Harald Alvestrand; [email-masked]; Hadriel Kaplan
>> As I mentioned earlier, SIP (serial) forking requirement shall be met
>by gateway signaling and no extra requirement for browser.
>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 28 Oct 2011 21:49:54 +0200

Hi,

In my opinion, interworking with SIP is itself such use-case :)

I think the question is whether a browser should be able to handle parallel forking, or if serial forking is enough.

In my opinion serial forking is enough, ie the JS app (or, if you want, a gateway) informs the browser about the currently active remote media parameters.

Regards,

Christer

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Ravindran Parthasarathi [[email-masked]]
Sent: Friday, October 28, 2011 10:43 PM
To: Iñaki Baz Castillo
Cc: [email-masked]
Subject: Re: [rtcweb] RTCWeb Forking usecase [was RE:   draft-kaplan-rtcweb-sip-interworking-requirements-00]

Inaki,

Thanks
Partha

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Sat, 29 Oct 2011 01:18:24 +0530

Roman,

The point is that WebRTC browser is not required to get multiple answer
for single offer in case RTCWeb-SIP interop scenario with SIP forking
and it applies for "Fedex IVR" usecase.  Could you please point out the
exact usecase for "find-me/follow-me" in
draft-ietf-rtcweb-use-cases-and-requirements-06.

Thanks

Partha

From: Roman Shpount [mailto:[email-masked]] 
Sent: Saturday, October 29, 2011 12:59 AM
To: Ravindran Parthasarathi
Cc: Harald Alvestrand; [email-masked]
Subject: Re: [rtcweb] RTCWeb Forking usecase [was RE:
draft-kaplan-rtcweb-sip-interworking-requirements-00]

On Fri, Oct 28, 2011 at 3:14 PM, Ravindran Parthasarathi
<[email-masked]> wrote:

Thanks for the clarification. "Fedex IVR" usecase is under browser to
GW/server section (sec 4.3) which is a SIP based forking requirement. If
you look at carefully, "Fedex IVR non-final response" scenario could
have be achieved cleanly using two separate offer/answer exchange & two
final responses (INVITE/200/ACK, RE-INVITE/200/ACK) :

This is actually wrong, unless we specify that WebRTC is always using
the same media stream address parameters (list of ICE candidates) within
the same call. If in WebRTC this cannot be guaranteed, serial forking
cannot be implemented unless multiple answers can be provided to the
same offer. In other words we either get the same offer from WebRTC
client so we can quietly not send it, or multiple answers need to be
provided.

In addition to Fedex IVR scenario, we also have find-me/follow-me
scenarios where either multiple early media sources are playing at the
same time (land line ring back and cell phone ring back). We also
sometimes end up with situations where two people answer the same call,
such as boss and a secretary answering the same call.
_____________
Roman Shpount

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 28 Oct 2011 22:04:56 +0200

> ISTM, SIP specific functionality is pushed into WebRTC client unnecessary without well-defined WebRTC usecase.

It's unnecessary for you. For me it's *necessary*. Are you propossing
that the specs should prevent this use case just because it seems
unnecessary for you?

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Sat, 29 Oct 2011 01:43:29 +0530

Hi Christer,

In case of SIP forking interop with WebRTC, it is possible for WebRTC-SIP gateway to handle this scenario and not by browser. In fact, it is my review comment to draft-kaplan-rtcweb-sip-interworking-requirements-00 (Para 2 in http://www.ietf.org/mail-archive/web/rtcweb/current/msg02316.html) where this mail thread started.

Even if WebRTC supports both serial & parallel forking, whether WebRTC signaling will take up the same shape of SIP forking wherein initial INVITE only forks and not for RE-INVITE? In case of WebRTC forking, it is very much possible for different shape of forking. The well defined WebRTC usecase & requirement may clarify these doubts.

Thanks
Partha

>From: Christer Holmberg [mailto:[email-masked]]
>Sent: Saturday, October 29, 2011 1:20 AM
>To: Ravindran Parthasarathi; Iñaki Baz Castillo
>Cc: [email-masked]
>Subject: RE: [rtcweb] RTCWeb Forking usecase [was RE:draft-kaplan-
>I think the question is whether a browser should be able to handle
>parallel forking, or if serial forking is enough.
>
>In my opinion serial forking is enough, ie the JS app (or, if you want,
>a gateway) informs the browser about the currently active remote media
>parameters.
>
>Regards,
>
>Christer
>
>
>From: [email-masked] [[email-masked]] On Behalf Of
>Ravindran Parthasarathi [[email-masked]]
>ISTM, SIP specific functionality is pushed into WebRTC client
>unnecessary without well-defined WebRTC usecase.
>
>Thanks
>Partha
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 28 Oct 2011 20:27:37 +0000

We've debated serial and parallel forking a number of times but I don't know if there's been consensus.

But your email is really two different questions/topics:
1) Is there a use-case for forking within WebRTC?
2) Does supporting SIP forking mean the Browser has to handle the SDP/media behavior of it, vs. the Web-server/Interworking-function handling it?

For the first question, I can certainly envision a Web-app wanting to let Alice press a single button on her Browser and end up communicating with Bob no matter where he may be, or letting her single button-press end up communicating with Bob first and then Charlie, or letting her single button-press end up communicating with Bob and Charlie at the same time.  But I think such things can be accomplished through clever Web-app code without needing the Browser to be aware it's a forked ROAP/SDP scenario. 
[Note: though this may depend on what W3C decides the user-consent UI model is relative to PeerConnections, MediaStreams and ROAP]

With regards to the second question, there was a long email thread on this which started here I think:
http://www.ietf.org/mail-archive/web/rtcweb/current/msg01354.html

-hadriel

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 28 Oct 2011 22:37:17 +0200

Hi,

>In case of SIP forking interop with WebRTC, it is possible for WebRTC-SIP gateway to handle this scenario and not by browser. In fact, it is my review comment to 
>draft-kaplan-rtcweb-sip-interworking-requirements-00 (Para 2 in http://www.ietf.org/mail-archive/web/rtcweb/current/msg02316.html) where this mail thread started.

In theory, I'm sure the gateway could handle most cases.

Things may look simple on a PowerPoint slide, showing a simple use-case, but from my experience you may end up with very complex and "clumsy" procedures, depending on how complex your call establishment procedures are.

>Even if WebRTC supports both serial & parallel forking, whether WebRTC signaling will take up the same shape of SIP forking wherein initial INVITE only forks and not for RE-INVITE? In case of WebRTC 
>forking, it is very much possible for different shape of forking.

Well, we can not only say that we support forking. We do need to specify exactly what we mean by "forking support", and what possible restrictions we have.

Regards,

Christer

---

From: Randell Jesup <[email-masked]>
Date: Fri, 28 Oct 2011 18:01:59 -0400

> 1) Is there a use-case for forking within WebRTC?

As discussed, given that users will be "logged into" a service from 
multiple devices, and that we don't know what the application desired 
behavior will be, we need to support multiple ANSWER responses to a 
OFFER, and support allowing multiple of those answers to become active. 
  (For example, OFFER sent to "my Team", answered by 3 members of the 
team.)  As for implementation: probably by cloning the PeerConnection or 
a Factory (this has been discussed before and I haven't gone over the 
messages to see where it ended up).

-- 
Randell Jesup
[email-masked]

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 28 Oct 2011 22:18:41 +0000

On Oct 28, 2011, at 6:01 PM, Randell Jesup wrote:

> As discussed, given that users will be "logged into" a service from multiple devices, and that we don't know what the application desired behavior will be, we need to support multiple ANSWER responses to a OFFER, and support allowing multiple of those answers to become active.  (For example, OFFER sent to "my Team", answered by 3 members of the team.)  As for implementation: probably by cloning the PeerConnection or a Factory (this has been discussed before and I haven't gone over the messages to see where it ended up).

Yes, but in theory we don't need to support ROAP forking to let you do that, because you don't need to do it that way.  For example you can write the JS to send a "session request" message without any ROAP/SDP, and as each "session response" comes back from each team member with a ROAP OFFER, the local JS creates a new PeerConnection and sends back to each team member a ROAP ANSWER from you.  So basically mimicking the offerless-INVITE model of SIP.

Or send a JS "session request" and get back a "session response" from each team member without any ROAP, then create each PeerConnection and send a new distinct "session request" with ROAP OFFER separately to each team member.  Kind of like a 3xx response model of SIP.

Or send a JS query to get back a list of URLs each representing a team member, and create a PeerConnection for each and send a ROAP OFFER to each URL.  Really like a 3xx response model of SIP.

-hadriel

---

From: Roman Shpount <[email-masked]>
Date: Fri, 28 Oct 2011 19:00:37 -0400

On Fri, Oct 28, 2011 at 6:01 PM, Randell Jesup <[email-masked]>wrote:

> behavior will be, we need to support multiple ANSWER responses to a OFFER,
> and support allowing multiple of those answers to become active.  (For
> example, OFFER sent to "my Team", answered by 3 members of the team.)  As
> for implementation: probably by cloning the PeerConnection or a Factory
> (this has been discussed before and I haven't gone over the messages to see
> where it ended up).
>

I agree with this completely.

I think the most encouraging response I got before on this list was that the
API should always produce the same list of ICE candidates for a given Web
browser session. Because of this, all the offers from the WebRTC client
would be the same and simultaneous forking can be implemented by creating a
new peer connection for each answer, generating and discarding the offer
(since it is the same as the offer from the original peer connection in this
session) and feeding a new answer to it. I am not sure this behavior is
defined anywhere, but this could definitely work and would allow to
implement all forking scenarios without cloning or factory API calls. I
would feel a bit more comfortable if the API would actually reflect this
usage (i.e. have one method that always returns an offer for this web
session and peer connection only processing answers or responses to remote
offers).
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Fri, 28 Oct 2011 19:10:55 -0400

On Fri, Oct 28, 2011 at 6:18 PM, Hadriel Kaplan <[email-masked]>wrote:

> Yes, but in theory we don't need to support ROAP forking to let you do
> that, because you don't need to do it that way.  For example you can write
> the JS to send a "session request" message without any ROAP/SDP, and as each
> "session response" comes back from each team member with a ROAP OFFER, the
> local JS creates a new PeerConnection and sends back to each team member a
> ROAP ANSWER from you.  So basically mimicking the offerless-INVITE model of
> SIP.
>
> Or send a JS "session request" and get back a "session response" from each
> team member without any ROAP, then create each PeerConnection and send a new
> distinct "session request" with ROAP OFFER separately to each team member.
>  Kind of like a 3xx response model of SIP.
>
> Or send a JS query to get back a list of URLs each representing a team
> member, and create a PeerConnection for each and send a ROAP OFFER to each
> URL.  Really like a 3xx response model of SIP.
>
>
If you do not need to inter-operate with SIP you can implement forking like
functionality with signaling only. If you do, you need forking support (or a
some sort of SBC or gateway solution).

In general, I think it makes sense to support forking if it does not greatly
complicate the WebRTC client implementation, makes API more complex or has
some security implications. Forking support is a good thing, since it will
allow for better interoperability and more flexible future signaling
scenarios. I don't think it is hard to add support for forking in WebRTC
(all you need to do is to reuse the same ICE candidates for all calls in the
same browser session), and this model encourages better resource usage. It
does mean that the same TURN/STUN servers should be used for all calls in
the session, but other then that it does not limit any of the functionality.

_____________
Roman Shpount

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sat, 29 Oct 2011 13:56:59 +0200

> some sort of SBC or gateway solution).

Even more, some WebRTC scenario could just not allow forking at all.
Since the in-the-wire protocol is up to the developer he does not need
to accomplish all the features and use cases of SIP, but just those
his scenario needs.

> the session, but other then that it does not limit any of the functionality.

I hope this is achieved as it opens the door to cool  scenarios
(indeed this is required in SIP, but could also be required by some
future scenarios we cannot imagine right now).

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Harald Alvestrand <[email-masked]>
Date: Sat, 29 Oct 2011 09:06:58 -0700

On 10/28/2011 04:00 PM, Roman Shpount wrote:
>
> On Fri, Oct 28, 2011 at 6:01 PM, Randell Jesup <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>     As discussed, given that users will be "logged into" a service
>     from multiple devices, and that we don't know what the application
>     desired behavior will be, we need to support multiple ANSWER
>     responses to a OFFER, and support allowing multiple of those
>     answers to become active.  (For example, OFFER sent to "my Team",
>     answered by 3 members of the team.)  As for implementation:
>     probably by cloning the PeerConnection or a Factory (this has been
>     discussed before and I haven't gone over the messages to see where
>     it ended up).
>
>
> I think the most encouraging response I got before on this list was 
> that the API should always produce the same list of ICE candidates for 
> a given Web browser session. Because of this, all the offers from the 
> WebRTC client would be the same and simultaneous forking can be 
> implemented by creating a new peer connection for each answer, 
> generating and discarding the offer (since it is the same as the offer 
> from the original peer connection in this session) and feeding a new 
> answer to it.
I considered it when we discussed this last, but I'm not sure it works.

If we support SDES, the offer also contains crypto keys. Reusing crypto 
keys for all created connections would be a huge security vulnerability.

That's why I ended up with the somewhat more complex "factory" model I 
proposed in an earlier mail; another method would be to have a 
PeerConnection constructor that takes an offer AND an answer as creation 
parameters.

Of course we could mandate DTLS-SRTP key negotiation.....

> I am not sure this behavior is defined anywhere, but this could 
> definitely work and would allow to implement all forking scenarios 
> without cloning or factory API calls. I would feel a bit more 
> comfortable if the API would actually reflect this usage (i.e. have 
> one method that always returns an offer for this web session and peer 
> connection only processing answers or responses to remote offers).
> _____________
> Roman Shpount
>
>
>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sat, 29 Oct 2011 18:14:25 +0200

SIPit29 summary says:

> 80% of the endpoints present supported SRTP using sdes.
> There were no dtls-srtp implementations at this SIPit.

Just a comment. Of coure the current status of SRTP implementations in
SIP world should not be the only argument for WebRTC.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Harald Alvestrand <[email-masked]>
Date: Sat, 29 Oct 2011 09:18:51 -0700

On 10/29/2011 09:14 AM, Iñaki Baz Castillo wrote:
> 2011/10/29 Harald Alvestrand<[email-masked]>:
I was partially joking.... I wanted to point out that the argument for 
supporting SIP-style forking and the argument for supporting SDES or 
non-encrypted RTP is based in the same "legacy interop" desire.

I don't think we can satisfy all desires in that area.

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 29 Oct 2011 18:37:55 +0000

On Oct 29, 2011, at 12:06 PM, Harald Alvestrand wrote:

> If we support SDES, the offer also contains crypto keys. Reusing crypto keys for all created connections would be a huge security vulnerability.

The SDES key is used in the sending direction, not the receive.  That means everyone receiving the ROAP Offer will get the key and be able to decrypt the Offerer's transmitted media, but only the receivers of the ROAP Answer will be able to decrypt the Answerer's media.  So yes obviously if the ROAP Offer is generated by a Browser and sent to multiple parties, all of those parties would be able to render the media (and possibly spoof it to the others).  

But that vulnerability exists with SDES regardless of whether we support ROAP forking or not.  Even if the WebRTC browser only allows one ROAP Answer for any given Offer, if SDES is supported at all then we have to trust the JS and Web server, and trust them not to send the ROAP Offer to multiple parties, or we have to trust all those parties - assuming ROAP contains an SDES key and the Browser ends up using it.  For example, even if we don't support ROAP forking, a benign JS and Web-server might still send the ROAP Offer to multiple Browsers and only send back one ROAP Answer from the first answering Browser, not realizing that doing so introduced a vulnerability.

My point is that supporting SDES to begin with opens up vulnerabilities, regardless of whether we support forking.  If we want to support SDES for interop with SIP, which I think we do, then what we could do is mandate the Browsers support both SDES and DTLS-SRTP, and that if they receive a ROAP Offer or Answer with DTLS-SRTP in the SDP they use it for that peer, ignoring SDES.  And also that in the Browser's security-info display that would otherwise show the DTLS-SRTP fingerprint/SAS, if SDES is used it says so and gives some info about its vulnerabilities. {Note: I'm assuming Browsers will be required to provide the DTLS-SRTP fingerprint/SAS in some display box if the human wants to see them]

Fundamentally SDES relies on trusting the Web server(s) and the clients it's given to.  In the Web you already rely on that, for any JS-created/seen message.  For example Web-based mail or IM.  You have to trust the JS+Server, and trust them to not send your message to parties which shouldn't get to see them.  I'm not saying that makes using SDES ok, but just noting it, fwiw.

> Of course we could mandate DTLS-SRTP key negotiation…..

Assume we did that.  Then to interop with SIP, the Web-server or an interworking device would terminate DTLS-SRTP on one side, and use SDES or plaintext RTP on the other, including to multiple SIP-forked parties.  What have you gained?  The only benefit is that if the human checks the fingerprint/SAS in the Browser's display-box, and verifies that the other side did not have the same SAS or none at all, then the human would know the media is potentially not secure end-to-end.  But you can display "The media is potentially not secure end-to-end" even if SDES were used by the Browser itself, without even needing the human to verify an SAS with the other side.

-hadriel
p.s. draft-wing-srtp-keying-eval-00 discussed this forking issue and recommended re-keying in forking scenarios, for SIP.  No one does that as far as I know, though.

---

From: Harald Alvestrand <[email-masked]>
Date: Sat, 29 Oct 2011 11:49:15 -0700

> But that vulnerability exists with SDES regardless of whether we support ROAP forking or not.  Even if the WebRTC browser only allows one ROAP Answer for any given Offer, if SDES is supported at al…
I don't think I expressed myself clearly....

Consider:
we create PC A, and it creates an offer with key A1
we get answer B1, and give it to PC A. Media flows, encrypted with A1 
from A.
we get answer B2, create a new PC B.
How does PC B know to use key A1 to encrypt media to B?

Two possibilities:
- All PCs created in this script use the same sending key. That seems 
like opening up vulnerabilities when creating PCs that connect to 
different places.
- The creation of PC B gets some special initialization data to tell it 
to use key A1

My earlier note about sending the offer as an initialization parameter 
to the creation of PC B was one possibility for that. Using a factory 
class to hold the information about key A1 is another.

....
> p.s. draft-wing-srtp-keying-eval-00 discussed this forking issue and recommended re-keying in forking scenarios, for SIP.  No one does that as far as I know, though.
Thanks for the pointer.

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 29 Oct 2011 23:44:26 +0200

Hi,

> Yes, but in theory we don't need to support ROAP forking to let you do that, because you don't need to do it that way.  For example you
> can write the JS to send a "session request" message without any ROAP/SDP, and as each "session response" comes back from each team 
> member with a ROAP OFFER, the local JS creates a new PeerConnection and sends back to each team member a ROAP ANSWER from you. 
> So basically mimicking the offerless-INVITE model of SIP.

That would cause issues with SIP interworking. I hope we can agree on the fact that many (most?) SIP environments and use-cases rely on the SDP offer being sent in the INVITE. The gateway would end up having to map SIP answers into ROAP offers, and vice verse, which could become very messy.

And, when the gateway receveis on offerless ROAD offer, if it needs to map it into an INVITE with an SDP offer, what information would it include in the SDP offer?

Regards.

Christer

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sun, 30 Oct 2011 00:26:32 +0200

> And, when the gateway receveis on offerless ROAD offer, if it needs to map it into an INVITE with an SDP offer, what information would it include in the SDP offer?

Take into account that not all of us will require a protocol gateway :)

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 30 Oct 2011 08:36:51 +0100

Hi,

>> That would cause issues with SIP interworking. I hope we can agree on the fact that many (most?) SIP environments and use-cases rely
>> on the SDP offer being sent in the INVITE. The gateway would end up having to map SIP answers into ROAP offers, and vice verse, which 
>> could become very messy.
>

Sure, but assuming you would still use ROAP on the JS-browser API, you wouldl have to do similar "interworking" in your JS app.

Regards,

Christer

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Sun, 30 Oct 2011 14:00:03 -0700

>> a given Web browser session. Because of this, all the offers from the

I don't think this is possible, depending on what you mean by "web 
browser session". People's web browsers move around, change which 
networking device they're using, etc., at any time. At a minimum, you 
need some interface to raise an error and deal with the fallout when you 
require this behavior and it can't be provided. The PeerConnection 
factory/cloning solution could potentially give you that (it could 
simply fail if it can't use the same ICE candidates anymore).

> I considered it when we discussed this last, but I'm not sure it works.

I'm confident it doesn't. Again, external cameras can be plugged in and 
unplugged, etc., by the user at any time, and these can change the 
capabilities exposed in the offer. This is also something you have to 
deal with, if you really rely on "same offer" behavior.

> keys for all created connections would be a huge security vulnerability.

I'm starting to come to the opinion that we shouldn't support SDES. If 
we're doing it just for interop with legacy, we'd get better interop 
with fewer headaches by supporting plain RTP. We'd have a distinction 
between the two that I could actually explain to users, and less chance 
of (unnoticed) downgrade attacks.

---

From: Ravindran Parthasarathi <[email-masked]>
Date: Mon, 31 Oct 2011 13:23:55 +0000

Usecase:  Media forking in browser

Description: User forks local stream/stream components to multiple peers simultaneously and able to receive multiple streams from multiple peers. 

Functional requirement: F11, F12, (any new requirement has to be added ?)

API requirement:   The Web API MUST provide means for the web application to initiate sending/receiving of stream/stream components to a multiple peer simultaneously and relate each of these streams individually by web application.

Having said that, I'm not very sure whether this usecase falls under the category of remote-recording by John.

Hadriel,

Thanks for the clarification on the current status and practical usecases.

Thanks
Partha

>From: Hadriel Kaplan [mailto:[email-masked]]
>Sent: Saturday, October 29, 2011 1:58 AM
>Cc: Harald Alvestrand; Iñaki Baz Castillo; <[email-masked]>
>Subject: Re: [rtcweb] RTCWeb Forking usecase [was RE:draft-kaplan-
>2) Does supporting SIP forking mean the Browser has to handle the
>SDP/media behavior of it, vs. the Web-server/Interworking-function
>handling it?
>
>For the first question, I can certainly envision a Web-app wanting to
>let Alice press a single button on her Browser and end up communicating
>with Bob no matter where he may be, or letting her single button-press
>end up communicating with Bob first and then Charlie, or letting her
>single button-press end up communicating with Bob and Charlie at the
>same time.  But I think such things can be accomplished through clever
>Web-app code without needing the Browser to be aware it's a forked
>ROAP/SDP scenario.
>[Note: though this may depend on what W3C decides the user-consent UI
>model is relative to PeerConnections, MediaStreams and ROAP]
>
>> but it may be avoided in legacy for billing reasons which should not
>be major concern for RTCWeb. In case of SIP forking, it is assumed that
>2nd answer override the 1st answer in the media plane.
>>
>by gateway signaling and no extra requirement for browser. Also,
>switching media stream from one responder to other responder in Fedex
>IVR usecase is not so easy because of legacy media handling (ICE, RTCP)
>differences as mentioned in draft-kaplan-rtcweb-sip-interworking-
>requirements-00.
>>

---

From: Stefan Håkansson <[email-masked]>
Date: Mon, 31 Oct 2011 14:45:20 +0100

> deal with, if you really rely on "same offer" behavior.

I have some faith in that it should work. Remember that we're dealing 
with candidates for one local port only (regardless of the 
MediaStream(s) added), so it should be possible to re-use that part. The 
application must of course make sure that it adds the right MediaStreams 
before the browsers enters a stable state. A bit complicated for the web 
developer maybe, but SIP-compatible forking in itself is a corner case 
from a webrtc perspective so I think that would be OK.

---

From: Roman Shpount <[email-masked]>
Date: Mon, 31 Oct 2011 10:26:01 -0400

As a lot of people pointed out here there are two issues here:

1. Use Case for Parallel Forking

It is obviously needed for SIP interop. There are ways around it by using
different signaling scenarios, or there are way to cheat this for some use
cases (serial forking), but in the end of the day, to work with the widest
possible set of end points parallel forking is highly desirable.

Once again, a lot of people here raised the concern that parallel forking
is only needed for SIP interop and nothing else. In some sense this is
true, but in general, ability to do parallel forking should save a round
trip and some complexity during call setup. Imagine a scenario where a call
is answered by a single peer most of the times and by multiple peers in few
cases. This can be the case when some of the peers are either groups or
"shared lines" in PSTN speak. If we have parallel forking, WebRTC client
will send an offer with media description. If the client gets a single
answer it will setup a call as soon as this answer is available. If the
client gets multiple answers,  it will clone the PeerConnection and process
each of those answers independently. Now, if we do not have parallel
forking, WebRTC client will need to start a call without an offer, get
offers from all the potential call destinations, and then create a
PeerConnection for each and send an answer. Extra round trip and more code,
even when the call is setup to one destination only (since the client does
not know in advance if the destination it is calling is a single person or
a group). So, yes, everything can be implemented without parallel forking,
but will be a bit more complex.

2. Complexity this will introduce to the API: I think all we need is a
single clone method on the PeerConnection. If you do not need parallel
forking, you never call the clone method and no additional complexity is
introduced. If you need parallel forking, it is available to you.
_____________
Roman Shpount

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 31 Oct 2011 15:35:24 +0100

2011/10/31 Roman Shpount <[email-masked]>:
> Once again, a lot of people here raised the concern that parallel forking is
> only needed for SIP interop and nothing else. In some sense this is true,
> but in general, ability to do parallel forking should save a round trip and
> some complexity during call setup. Imagine a scenario where a call is
> answered by a single peer most of the times and by multiple peers in few
> not know in advance if the destination it is calling is a single person or a
> group). So, yes, everything can be implemented without parallel forking, but
> will be a bit more complex.
>

Ok so, if we all agree here (since it seems not to add too much
complexity to the API), can we ask for the API to support this need?

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 31 Oct 2011 09:00:09 -0700

> Description: User forks local stream/stream components to multiple peers simultaneously and able to receive multiple streams from multiple peers.
Ravindran,

I see this as an implementation description, and not an use case.

Could you rephrase this in terms that make it clear what the user will 
be trying to do, and that this technology (forking) is the appropriate 
solution for that problem?

That will also help uncover more requirements that the use case will 
imply. For instance, if the idea is that the user talks to multiple 
persons simultaneously, and they are able to hear each other without a 
direct connection to each other, there is an added requirement that the 
user be able to mix audio from local and remote sources.

Thank you!

      Harald Alvestrand

>> Cc: Harald Alvestrand; Iñaki Baz Castillo;<[email-masked]>
>> have be achieved cleanly using two separate offer/answer exchange&  two