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

[Iñaki Baz Castillo <[e-mail]>]

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
<[e-mail]>