Re: [rtcweb] Forking & Early Media - Was Re: Minimal SDP negotiation mechanism

[Roman Shpount <[e-mail]>]

We should have an option to clone (or conditionally clone) the
PeerConnection based on the new answer as well as provide an answer update
to the exiting PeerConnection. In the first case, application can create a
separate media connection to a forked response and render it separately. In
the second, application can start rendering input from a new answer as well
as sending media to it. This way we can address all the possible scenarios
and leave control in the application developer's hands.

As far as offer/answer is concerned RTC should be able to interop with it,
but I would assume we should be able to add new features and functionality
if they would enable us to build new applications or interop with existing
deployments. Processing answer updates or offer failures is not described in
offer.answer but it will not break interoperability of RTC with any
offer/answer solutions
_____________
Roman Shpount


On Wed, Sep 21, 2011 at 3:00 AM, Saúl Ibarra Corretgé
<[e-mail]>wrote:

>
> On Sep 21, 2011, at 8:25 AM, Ravindran Parthasarathi wrote:
>
> > Hi Roman,
> >
> > Thanks for the correction. I agree with you that there is no need to
> mention that forking is not support in RTCWeb. Your simple model works for
> browser as RTP End-point. One problem with the generic statement of multiple
> answer is that it may violate offer/answer model itself. For example: 18x
> and 200 having different answer for INVITE offer (standard implementation
> violation of offer/answer ;-))
> >
>
> I think that the case discussed before was that you may receive several 18x
> responses because the request forked in the SIP side. So, if more than one
> of these 18x responses do have an SDP, do we create a PeerConnection for
> each? One for the first? The last?
>
> --
> Saúl Ibarra Corretgé
> AG Projects
>
>
>
>