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

[Stefan Håkansson <[e-mail]>]

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

On 10/29/2011 07:29 PM, Iñaki Baz Castillo wrote:
> 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).
>
>
>