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

Roman Shpount <roman@telurix.com> Wed, 21 September 2011 14:43 UTC

Return-Path: <roman@telurix.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00D941F0C4C for <rtcweb@ietfa.amsl.com>; Wed, 21 Sep 2011 07:43:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.526
X-Spam-Level:
X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tebT8+5vEkiR for <rtcweb@ietfa.amsl.com>; Wed, 21 Sep 2011 07:43:06 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id D10D11F0C36 for <rtcweb@ietf.org>; Wed, 21 Sep 2011 07:43:05 -0700 (PDT)
Received: by ywa6 with SMTP id 6so1467504ywa.31 for <rtcweb@ietf.org>; Wed, 21 Sep 2011 07:45:34 -0700 (PDT)
Received: by 10.236.80.66 with SMTP id j42mr5719399yhe.98.1316616334092; Wed, 21 Sep 2011 07:45:34 -0700 (PDT)
Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx.google.com with ESMTPS id d5sm3566656yhl.19.2011.09.21.07.45.32 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 21 Sep 2011 07:45:33 -0700 (PDT)
Received: by gwj18 with SMTP id 18so1792107gwj.27 for <rtcweb@ietf.org>; Wed, 21 Sep 2011 07:45:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.20.135 with SMTP id n7mr793681pbe.375.1316616332045; Wed, 21 Sep 2011 07:45:32 -0700 (PDT)
Received: by 10.68.55.39 with HTTP; Wed, 21 Sep 2011 07:45:31 -0700 (PDT)
In-Reply-To: <8508ACC4-75A0-4556-8474-66175539F102@ag-projects.com>
References: <4E777500.5030201@alvestrand.no> <69262135-CF5D-4E79-85CD-82DFDC4250C0@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A05852233F6F222@ESESSCMS0356.eemea.ericsson.se> <4E788458.1090108@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852233F6F2A0@ESESSCMS0356.eemea.ericsson.se> <4E788E5C.9090306@alvestrand.no> <11209B22-4D96-4367-BC31-A4D586B55A83@edvina.net> <27019ED4-BE01-474C-886E-D237DBD6CD2C@cisco.com> <6916F9BA-3296-46DD-9F06-01E3928A8184@acmepacket.com> <2E239D6FCD033C4BAF15F386A979BF510F0E5E@sonusinmail02.sonusnet.com> <CAD5OKxvq3DhAimZ4UeRBxTCbeQhqCP9+gkWJwsUa0Tb5CS5OdA@mail.gmail.com> <2E239D6FCD033C4BAF15F386A979BF510F0E6B@sonusinmail02.sonusnet.com> <8508ACC4-75A0-4556-8474-66175539F102@ag-projects.com>
Date: Wed, 21 Sep 2011 10:45:31 -0400
Message-ID: <CAD5OKxvMXZTQb0r_Gq9rwOSDRfcBZ5sorZJDKQY3_2M0JAoLog@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: =?ISO-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= <saul@ag-projects.com>
Content-Type: multipart/alternative; boundary=bcaec5215915c6f08404ad74a0bc
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Forking & Early Media - Was Re: Minimal SDP negotiation mechanism
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Sep 2011 14:43:07 -0000

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é
<saul@ag-projects.com>wrote;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
>
>
>
>