Re: [rtcweb] RTCWeb Forking usecase [was RE: draft-kaplan-rtcweb-sip-interworking-requirements-00]

[Christer Holmberg <[e-mail]>]

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?
>
> Take into account that not all of us will require a protocol gateway :)

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