Subject: [rtcweb] Media forking solution for SIP interoperability (without a media gateway)

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

Hi, the next suggestion would allow media serial/parallel forking
scenarios when interoperating with a SIP network. It is just a
*suggestion*.

Assumtions
------------------

- WebRTC specs don't allow sharing a local PeerConnection for sending
and receiving media to/from more than a single remote peer.

- The remote pure SIP peers implement ICE+SRTP and can interoperate
with a WebRTC client in the media plane without requiring media
gateways.

The problem
------------------

Let's assume a WebRTC client implementing SIP at JavaScript level
(although there could be a signaling gateway).

- The WebRTC client makes an outgoing call which arrives to a SIP
proxy and forking occurs (serial or parallel).

- The WebRTC client receives more than a single SIP 183 response with
different To-tags and different SDPs (so they are different remote SIP
peers).

- And/or the WebRTC client receives a 200 OK with a Totag and SDP
different than the one received in the previous 183.

In this case, given the first assumption above, the WebRTC client must
choose a single remote SIP peer and can just send and receive media to
the chosen peer (limitation 1).
If the SIP 200 OK arriving to the WebRTC client belongs to a remote
peer different than the chosen one, the WebRTC client cannot reuse the
already open local PeerConnection since it was created passing it a
different remote SDP (limitation 2).

Solution
------------

- The WebRTC client sends the call and receives a 183 with Totag
"AAAA" and SDP "SDP_A" from SIP_PEER_A.

- It creates a PeerConnection passing it "SDP_A", sends like a ROAP
Answer to the peer and media flow starts between client and
SIP_PEER_A.

- Later (or very soon) another 183 with Totag "BBBB" and SDP "SDP_B"
arrives to the WebRTC client from SIP_PEER_B.

- The client creates a *new* PeerConnection *without* passing it
"SDP_B" and sends a SIP UPDATE with the associated ROAP Offer to
SIP_PEER_B.

- If SIP_PEER_B implements SIP UPDATE it will reply a 200 OK with a
new "SDP_B2" (it could be the same as "SDP_B").

- The client then passes "SDP_B2" to the second PeerConnection and
media flow starts between client and SIP_PEER_A.

- Later a SIP 200 OK with Totag "CCCC" and SDP "SDP_C" arrives to the
client from SIP_PEER_C.

- The client creates a *new* PeerConnection *without* passing it
"SDP_C" and sends a SIP re-INVITE with the associated ROAP Offer to
SIP_PEER_C.

- SIP_PEER_C will reply a 200 OK with a new "SDP_C2" (it could be the
same as "SDP_C").

- The client then passes "SDP_C2" to the third PeerConnection and
media flow starts between client and SIP_PEER_C. At the same time the
client destroys the first and second PeerConnections.

And we are done. Limitation solved. Of course if SIP_PEER_B does not
implement UPDATE we have a problem, but RFC 3311 (SIP UPDATE Method)
is a standard since 2002, come on!

Conclusion
----------------

SIP media forking can be implemented in JavaScript without mandating
special requirements in WebRTC for interoperating with "legacy" SIP
(why do we call "legacy" to SIP???). And we just need  tu use existing
SIP mechanisms.

No signaling gateway is required (of course !!) nor a media gateway
(if second bullet in "Assumtions" section above is satisfied).

We all are happy (but those who have in mind a market selling
WebRTC-SIP gateway boxes and want that the specs satisfy their
business model).

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

---

From: Stefan Håkansson <[email-masked]>
Date: Sun, 30 Oct 2011 11:06:17 +0100

I assume that part of the solution here is that the new PeerConnection's 
reuse the same candidates as the first one created?

Br,
Stefan

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sun, 30 Oct 2011 11:20:00 +0100

> reuse the same candidates as the first one created?

Well, if that would be possible then my solution is not needed at all :)

My solution is a "workaround" for the case in which WebRTC does not
allow reusing the same local candidates. In my suggestion I create N
*independent* PeerConnection instances.

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

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 30 Oct 2011 16:58:09 +0100

Hi,

I don't like the idea of having to send UPDATE/re-INVITE for every new early dialog.

In addition, I am not even sure it would work with ICE. Remember that ICE allows the UAS to send an "answer" unreliably (the unreliabe 18x is re-transmitted a few times), but since it's not a real answer, the UAC is not allowed to send an UDPATE.

In my opinion a better solution is to create a new PeerConnection for every new early dialog, which uses the *same* address/candidate parameters as the "parent" PeerConnection. In such case there is no need to send an UPDATE.

Regards,

Chrsiter

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Iñaki Baz Castillo [[email-masked]]
Sent: Saturday, October 29, 2011 8:29 PM
To: [email-masked]
Subject: [rtcweb] Media forking solution for SIP interoperability (without a    media gateway)

Assumtions
------------------

The problem
------------------

Solution
------------

Conclusion
----------------

--
Iñaki Baz Castillo
<[email-masked]>
_______________________________________________
rtcweb mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sun, 30 Oct 2011 20:12:22 +0100

> I don't like the idea of having to send UPDATE/re-INVITE for every new early dialog.

Hi Christer, it was just a suggestion, I'm not traying to mandating or
standarizing nothing :)

> In addition, I am not even sure it would work with ICE. Remember that ICE allows the UAS to send an "answer" unreliably (the unreliabe 18x is re-transmitted a few times), but since it's not a real…

I don't agree. If the UAC receives a 180 it means that the 180 has
been received (regardless it was unreliable), so UPDATE is possible.

> In my opinion a better solution is to create a new PeerConnection for every new early dialog, which uses the *same* address/candidate parameters as the "parent" PeerConnection. In such case there i…

Sure! but my suggestion was based on the assumption that WebRTC won't
allow reusing the same local address/candidates in two different
PeerConnection's.

Regards.

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

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 30 Oct 2011 20:24:17 +0100

Hi, 

> Hi Christer, it was just a suggestion, I'm not traying to mandating or standarizing nothing :)

And I didn't like the suggestion :)

>> In addition, I am not even sure it would work with ICE. Remember that ICE allows the UAS to send 
>> an "answer" unreliably (the unreliabe 18x is re-transmitted a few times), but since it's not a real 
>> answer, the UAC is not allowed to send an UDPATE.
>
> I don't agree. If the UAC receives a 180 it means that the 180 has been received (regardless it was 
> unreliable), so UPDATE is possible.

Ok, small correction: you are not allowed to send a new offer before you have received the previous answer in a reliably sent response :)

Regards,

Christer

>> In my opinion a better solution is to create a new PeerConnection for every new early dialog, which uses the 
>> *same* address/candidate parameters as the "parent" PeerConnection. In such case there is no need to send an UPDATE.
>
> Sure! but my suggestion was based on the assumption that WebRTC won't allow reusing the same local address/candidates in two different PeerConnection's.

Regards.

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sun, 30 Oct 2011 20:41:31 +0100

> Ok, small correction: you are not allowed to send a new offer before you have received the previous answer in a reliably sent response :)

Ok, PRACK (RFC 3262) dates from 2002, so just add "Require: 100rel" in
the INVITE and you are done. Of course, if the remote SIP peer does
not implement PRACK I am sure it won't implement ICE and SRTP, so
interoperability with a WebRTC client is not possible anyway.

Anyhow, let's remember that the purpose of WebRTC is not the
interoperability with old SIP phones which implement nothing but plain
SIP and plain RTP. So I don't expect that WebRTC will allow reusing
the same local candidates in a new PeerConnection just to allow SIP
media forking.

Regards.

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

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 30 Oct 2011 21:11:18 +0100

Hi, 

>> Ok, small correction: you are not allowed to send a new offer before 
>> you have received the previous answer in a reliably sent response :)
>
> Ok, PRACK (RFC 3262) dates from 2002, so just add "Require: 100rel" in the INVITE and you are done. Of course, if 
> the remote SIP peer does not implement PRACK I am sure it won't implement ICE and SRTP, so interoperability with a WebRTC client is not possible anyway.

Dude, where were you when they wrote RFC 5245? The reason they specified the re-transmission of un-reliable 18x responses was so that ICE entities would NOT have to support PRACK :)

Having said that, *today* PRACK support may be more common (75%, according to the SIPit report) than back in those days, and if in addition SRTP mandates PRACK support there might not be a real-life problem.

> Anyhow, let's remember that the purpose of WebRTC is not the interoperability with old SIP phones which 
> implement nothing but plain SIP and plain RTP. 

I agreed.

And, my main concern is not whether endpoints will support PRACK, but having to send new offers just because of forking. 

Of course, nobody prevents you from doing that, if you want :)

> So I don't expect that WebRTC will allow reusing the same local candidates in a new PeerConnection just to allow SIP media forking.

Well, that's what we have to figure out.

And, just for the record: based on what do you make that assumption?

Regards,

Christer

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sun, 30 Oct 2011 21:32:43 +0100

> Dude, where were you when they wrote RFC 5245? The reason they specified the re-transmission of un-reliable 18x responses was so that ICE entities would NOT have to support PRACK :)

Sure, but WebRTC is not SIP and must not be designed just in order to
interoperate with SIP.

> Having said that, *today* PRACK support may be more common (75%, according to the SIPit report) than back in those days, and if in addition SRTP mandates PRACK support there might not be a real-lif…

Oh, I didn't know that SRTP mandates PRACK, then we are done :)

> And, my main concern is not whether endpoints will support PRACK, but having to send new offers just because of forking.

Of course I prefer not having to use that but, should WebRTC modify
PeerConnection specs just for allowing SIP media forking?

> Well, that's what we have to figure out.

I would also like to know what non-SIP folks think about this.

> And, just for the record: based on what do you make that assumption?

Ok: in order to allow SIP media forking, WebRTC should allow reusing
the same local candidates in a new PeerConnection (or making a single
PeerConnection capable of sending and receiving RTP to/from more than
a single remote peer).

Remember that WebRTC does not mandate a protocol in-the-wire, so a
developer could make a new/custom protocol in which for each "early
response containing media" it creates a new PeerConnection. However
that does not fit well with SIP. But this is just a SIP issue, not a
WebRTC issue.

Should PeerConnection become more complex just for those willing to
implement SIP (or something that can be mapped to SIP) in WebRTC and
interoperate with SIP?

I insist: this limitation *just* affects to SIP (due to SIP nature in
which a UAC MUST be able to send/receive RTP to different peers using
the same local address). Any other protocol implemented on top of
WebRTC could avoid this limitation with a proper design. So should
WebRTC be conditionated by SIP protocol requirements? I don't think
so, regardless the number of SIP folks participating in this WG (I
still think WebRTC is something for the Web).

So this is the reason of my assumption.

Regards.

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

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 30 Oct 2011 22:39:24 +0100

Hi, 

>> Having said that, *today* PRACK support may be more common (75%, according to the SIPit report) than back in those 
>> days, and if in addition SRTP mandates PRACK support there might not be a real-life problem.
>

I don't think SRTP as such mandates PRACK. But, whatever media negotiations, that require reliably sent SDP, you want to do during the early dialog require PRACK.

>>> interoperability with old SIP phones which implement nothing but plain SIP and plain RTP.
>>
>> I agreed.
>>
> Of course I prefer not having to use that but, should WebRTC modify PeerConnection specs just for allowing SIP media forking?

WebRTC is not going to modify anything. AFAIK, we will ask W3C to do it, based on our wishes and requirements.

However, it would only be needed if we decide to support parallel forking. If we choose to only require support of serial forking, you may not have to create new PeerConnections - if you can modify the remote media parameters of the existing one.

As I've said before, I am personally fine with supporting serial forking, but if we can get parallel forking "for free" that's of course good.

>> I would also like to know what non-SIP folks think about this.

First I think the SIP folks shall agree on what THEY want. Then we'll see whether/how it's possible to achieve, and what others think.

Regards,

Christer

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 30 Oct 2011 12:41:24 -0600

On Oct 30, 2011, at 9:58 , Christer Holmberg wrote:

> In my opinion a better solution is to create a new PeerConnection for every new early dialog, which uses the *same* address/candidate parameters as the "parent" PeerConnection. 

Hmm we should talk about this - I have a hard time seeing how that is going to work. I was working on the assumption that  PeerConnection could deal with more than one offer/answer pair at a time. Given the current WebRTC API and something like ROAP - it seems like that should just work.

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 30 Oct 2011 18:08:33 -0700

> Hmm we should talk about this - I have a hard time seeing how that is going to work. I was working on the assumption that  PeerConnection could deal with more than one offer/answer pair at a time.…
I think having a single PeerConnection object send media to multiple 
peers at the same time breaks the model we've been working from.

It may be reasonable to give a PeerConnection the ability to switch from 
one remote peer to another remote peer (to support 180-like things), but 
I don't think it's reasonable to have it connected to multiple remote peers.

So if we support real forking, we'll have to create multiple 
PeerConnections to do that.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 31 Oct 2011 10:21:30 +0100

2011/10/31 Harald Alvestrand <[email-masked]>:
> I think having a single PeerConnection object send media to multiple peers
> at the same time breaks the model we've been working from.
>
> It may be reasonable to give a PeerConnection the ability to switch from one
> remote peer to another remote peer (to support 180-like things), but I don't
> think it's reasonable to have it connected to multiple remote peers.
>
> So if we support real forking, we'll have to create multiple PeerConnections
> to do that.

AFAIK there are three alternatives here:

1) PeerConnection can just communicate with a single peer.

2) PeerConnection can just communicate with a single peer but the per
can be replaced later (so still we reuse the same local candidates,
but ICE+SRTP must be "restarted". This solves serial forking.

3) PeerConnection can communicate with multiple peers at the same
time. This solves serial and parallel forking.

In my opinion:

- Option 1) is very limited.

- Option 2) is a MUST.

- Option 3) would be great but it introduces some complexity. Imagine
there is parallel forking and the WebRTC client recives 3 SDP's from 3
different peers, and passes all of them to the same PeerConnection. At
same point a remote peer stops sending media so we get a callback
"peerStopsSendingMedia()" in out PeerConnection. Does it mean that we
can close the PeerConnection? not, because we must check whether there
are other active peers yet (and there are in this case). So this
introduces complexity at JavaScript level. The question is: is this
complexity not so hard? can it be limited by some parameter when
creating a PeerConnection? I imagine soemthing like:

   new PeerConnection( capabilities=[], allow_multiple_peers=false/true)

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

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 31 Oct 2011 10:40:19 +0100

Hi, 

>>> In my opinion a better solution is to create a new 
>>> PeerConnection for every new early dialog, which uses the 
>>> *same* address/candidate parameters as the "parent" PeerConnection.
>> Hmm we should talk about this - I have a hard time seeing 
>> how that is going to work. I was working on the assumption 
>> that  PeerConnection could deal with more than one 
>> offer/answer pair at a time. Given the current WebRTC API and 
>> something like ROAP - it seems like that should just work.
>
> I think having a single PeerConnection object send media to 
> multiple peers at the same time breaks the model we've been 
> working from.
>
> It may be reasonable to give a PeerConnection the ability to 
> switch from one remote peer to another remote peer (to 
> support 180-like things), but I don't think it's reasonable 
> to have it connected to multiple remote peers.
>

We could create new PeerConnections objects for every early dialog, but the idea was that the new object could use the same local parameter (IP address:port, candidates etc) as the "parent" object, so that one does not need to send a new offer.

However, for serial forking we would only need a single PeerConnection object, assuming we could switch the remote parameter.

So, again, I think we should first agree on WHAT we want, and then we can start thinking on HOW to get it.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 31 Oct 2011 11:01:39 +0100

Hi, 

>> multiple peers at the same time breaks the model we've been working from.
>>
>> It may be reasonable to give a PeerConnection the ability to switch 
>> from one remote peer to another remote peer (to support 180-like 
>> things), but I don't think it's reasonable to have it 
>> connected to multiple remote peers.
>>
> 2) PeerConnection can just communicate with a single peer but 
> the per can be replaced later (so still we reuse the same 
> local candidates, but ICE+SRTP must be "restarted". This 
> solves serial forking.
> 
> 3) PeerConnection can communicate with multiple peers at the 
> same time. This solves serial and parallel forking.
> 
> 
> In my opinion:
> 
> - Option 3) would be great but it introduces some complexity. 
> Imagine there is parallel forking and the WebRTC client 
> recives 3 SDP's from 3 different peers, and passes all of 
> them to the same PeerConnection. At same point a remote peer 
> stops sending media so we get a callback 
> "peerStopsSendingMedia()" in out PeerConnection. Does it mean 
> that we can close the PeerConnection? not, because we must 
> check whether there are other active peers yet (and there are 
> in this case). So this introduces complexity at JavaScript 
> level. The question is: is this complexity not so hard? can 
> it be limited by some parameter when creating a 
> PeerConnection? I imagine soemthing like:
> 

I am not sure whether option 3) uses a single PeerConnection, but one alternative is that we use multiple PC objects, but they all share the local parameters and candidates.

Personally I think option 2) would be ok for most cases, and enough to support in "phase 1".

And, IF someone really wants to support parallel forking, there is always the possibility to create new PC objects, send offers associated with them etc.

Regards,

Christer

---

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

> I am not sure whether option 3) uses a single PeerConnection, but one alternative is that we use multiple PC objects, but they all share the local parameters and candidates.

Maybe I'm wrong, but AFAIK the local candidates are generated when
creating a PeerConnection object. This is: you create a PC object and
internally it gets the candidates, so you cannot create a second PC
and use the same local candidates. Am I wrong?

> Personally I think option 2) would be ok for most cases, and enough to support in "phase 1".

I also agree. Also, many SIP phones just render a single media stream
even when media parallel forking occurs, and switch to the definitive
SDP when the 200 arrives, so IMHO this is not a great limitation for
WebRTC.

> And, IF someone really wants to support parallel forking, there is always the possibility to create new PC objects, send offers associated with them etc.

Right.

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

---

From: Ravindran Parthasarathi <[email-masked]>
Date: Mon, 31 Oct 2011 12:21:08 +0000

Harald,

As per F11 & F12 of draft-ietf-rtcweb-use-cases-and-requirements-06 , 

   "F11             The browser MUST be able to transmit streams to
                   several peers concurrently.

   F12             The browser MUST be able to receive streams from
                   multiple peers concurrently."

The above browser requirement makes me to guess that it is possible to support SIP parallel forking sort of services in case proper JS APIs are provided (May be current form of peerconnection does not). Please let me know your opinion on this.

Thanks
Partha

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf
>Of Harald Alvestrand
>Sent: Monday, October 31, 2011 6:39 AM
>To: Cullen Jennings
>Cc: [email-masked]
>Subject: Re: [rtcweb] Media forking solution for SIP interoperability
>(without a media gateway)
>
>>> In my opinion a better solution is to create a new PeerConnection for
>every new early dialog, which uses the *same* address/candidate
>parameters as the "parent" PeerConnection.
>> Hmm we should talk about this - I have a hard time seeing how that is
>going to work. I was working on the assumption that  PeerConnection
>could deal with more than one offer/answer pair at a time. Given the
>current WebRTC API and something like ROAP - it seems like that should
>just work.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 31 Oct 2011 13:25:52 +0100

> The above browser requirement makes me to guess that it is possible to support SIP parallel forking sort of services in case proper JS APIs are provided (May be current form of peerconnection does…

The above requirements don't say that a *single* PeerConnection MUST
be able to send and receive streams to/from several peers
concurrently. It just says that the *browser* MUST be able, and a way
to achieve that is by creating multiple concurrent PeerConnection
objects.

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

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 31 Oct 2011 13:37:58 +0100

Hi,

I would suggest that, instead of talking about a single PeerConnection, we talk about using the same local IP parameters and candicates for multiple remote endpoints. It could be a single PC, or it could be multiple "cloned" PCs.

Again, let's first decide whether we need it - then we can start thinking of how to get it :)

Regards,

Christer

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Iñaki Baz Castillo
> Sent: 31. lokakuuta 2011 14:26
> To: Ravindran Parthasarathi
> Cc: [email-masked]
> Subject: Re: [rtcweb] Media forking solution for SIP 
> interoperability (without a media gateway)
> 
> > As per F11 & F12 of 
> draft-ietf-rtcweb-use-cases-and-requirements-06 ,
> >
> > The above browser requirement makes me to guess that it is 
> possible to support SIP parallel forking sort of services in 
> case proper JS APIs are provided (May be current form of 
> peerconnection does not). Please let me know your opinion on this.
> 
> The above requirements don't say that a *single* 
> PeerConnection MUST be able to send and receive streams 
> to/from several peers concurrently. It just says that the 
> *browser* MUST be able, and a way to achieve that is by 
> creating multiple concurrent PeerConnection objects.
> 
> 
> 
> 
> --
> Iñaki Baz Castillo
> <[email-masked]>

---

From: Ravindran Parthasarathi <[email-masked]>
Date: Mon, 31 Oct 2011 12:51:22 +0000

Hi Christer,

I agree with you. By reading ROAP draft, I got the feel that it is possible to connect to multiple peer from single local offer and also, it is possible to update multiple peers during each offer/answer exchange.  It is slightly upper version of SIP parallel forking wherein multiple dialogs are created in terms of SIP due to forking and update each dialogs using RE-INVITE for media change. I like this usecase as this infrastructure helps for building complex media services in browser.

Thanks
Partha

>From: Christer Holmberg [mailto:[email-masked]]
>Sent: Monday, October 31, 2011 6:08 PM
>To: Iñaki Baz Castillo; Ravindran Parthasarathi
>Cc: [email-masked]
>Subject: RE: [rtcweb] Media forking solution for SIP interoperability
>I would suggest that, instead of talking about a single PeerConnection,
>we talk about using the same local IP parameters and candicates for
>multiple remote endpoints. It could be a single PC, or it could be
>multiple "cloned" PCs.
>

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 31 Oct 2011 05:57:59 -0700

Cullen said:

> Hmm we should talk about this - I have a hard time seeing how that is going to work. I was working on the assumption that  PeerConnection 
>could deal with more than one offer/answer pair at a time. Given the current WebRTC API and something like ROAP - it seems like that should just work. 

[BA] We have an issue with the API spec if that it is possible for people to come to very different conclusions about whether this and other things
"should just work".   BTW, this was *not* my reading of the spec -- it seems to me that there are inherent assumptions about the state machines,
ICE and other aspects that would restrict a PeerConnection to one offer/answer pair at a time.

---

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

> I would suggest that, instead of talking about a single PeerConnection, we talk about using the same local IP parameters and candicates for multiple remote endpoints. It could be a single PC, or it…

Hi Christer, as I replied you in other mail this needs to be clarified:

When are local candidates generated? when creating a new
PeerConnection object? or when creating a new ROAP Offer/Answer
object?

In the first case case you cannot reuse the same local candidates in a
new PeerConnection. In the second case you can do it (if we assume
that first we create a ROAP Offer, it creates local candidates and we
pass the ROAP object to a new PeerConnection) then it would be
possible just if the API allows that.

> Again, let's first decide whether we need it - then we can start thinking of how to get it :)

Assuming the second case above I vote for the API to allow passing an
already used local candidates into a new PeerConnection so we cover
all the media forking cases.

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

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 31 Oct 2011 17:10:56 +0000

On Oct 29, 2011, at 1:29 PM, Iñaki Baz Castillo wrote:

[snipped example implementation scenario]

> Conclusion

Right, as I said before, we don't actually have to implement ROAP forking in the browser, because the JS+Server code can be clever enough to do it, even to SIP.

The question is if we should implement it in the browser anyway, to make things work better for the scenarios where they do go to SIP.

We know that even an interworking-function can "hide" the forking, because they do that right now for SIP-H.323; but we also know that doing so is error-prone and causes media-clipping.

So if it's not too difficult/complicated to implement, handling it natively in the browser is likely to yield the best user experience.  And the nice thing is that if the browsers get it wrong, or the WebApp doesn't want to do it, the JS+Server can still fix it or make it not happen.

> WebRTC-SIP gateway boxes and want that the specs satisfy their

I hope you don't think I'm arguing for things for the purpose of selling WebRTC-SIP gateways.  I'm trying very hard to list all the things a WebRTC domain must do if it wants to *avoid* gateways.  
[Not because my company doesn't plan on selling WebRTC-SIP gateways - but because people should use gateways/SBCs when they need to for security/control/etc., but not simply to interoperate.]

-hadriel

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 31 Oct 2011 18:27:21 +0100

> So if it's not too difficult/complicated to implement, handling it natively in the browser is likely to yield the best user experience.  And the nice thing is that if the browsers get it wrong, or…

I agree. In case it does not add a great complexity at API level it
would be great if we can reuse same local candidates in more than a
single PeerConnection.

> I hope you don't think I'm arguing for things for the purpose of selling WebRTC-SIP gateways.

Not at all, of course. You try to make WebRTC design open so any
developer can implement whatever he wants without being constrained to
specific and mandatory in-the-wire protocol or message format.

> I'm trying very hard to list all the things a WebRTC domain must do if it wants to *avoid* gateways.

Yes, it's clear in the draft ;)

> [Not because my company doesn't plan on selling WebRTC-SIP gateways - but because people should use gateways/SBCs when they need to for security/control/etc., but not simply to interoperate.]

Agreed.

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