Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP

Christer Holmberg <christer.holmberg@ericsson.com> Thu, 03 May 2012 06:02 UTC

Return-Path: <christer.holmberg@ericsson.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 D490021F860B for <rtcweb@ietfa.amsl.com>; Wed, 2 May 2012 23:02:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.124
X-Spam-Level:
X-Spam-Status: No, score=-6.124 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
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 aLwRKyEoBxfL for <rtcweb@ietfa.amsl.com>; Wed, 2 May 2012 23:02:48 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 9251121F854C for <rtcweb@ietf.org>; Wed, 2 May 2012 23:02:47 -0700 (PDT)
X-AuditID: c1b4fb25-b7b18ae000000dce-1c-4fa21f857695
Authentication-Results: mailgw2.ericsson.se x-tls.subject="/CN=esessmw0256"; auth=fail (cipher=AES128-SHA)
Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0256", Issuer "esessmw0256" (not verified)) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id E3.DE.03534.58F12AF4; Thu, 3 May 2012 08:02:46 +0200 (CEST)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.64]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Thu, 3 May 2012 08:02:45 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Roman Shpount <roman@telurix.com>
Date: Thu, 3 May 2012 08:02:44 +0200
Thread-Topic: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP
Thread-Index: Ac0oqGjgQiWJ3cAZRvWmmuieyMazqQASTrzg
Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C442AC0DA@ESESSCMS0356.eemea.ericsson.se>
References: <387F9047F55E8C42850AD6B3A7A03C6C0E23B102@inba-mail01.sonusnet.com> <CA+rAfUMfZBHxAjR0zmwhSxftQbPK0X3sNuxu4UV6bnMvnJ_9xA@mail.gmail.com> <CAOJ7v-3K=NK6zCLr-E-aSHDKVv2hMqnUhZKroX0YoBTo6-nQ+Q@mail.gmail.com> <6F428EFD2B8C2F49A2FB1317291A76C1136029362A@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <4FA13816.6050003@alvestrand.no> <CAD5OKxsOAeTRdCgj2g4BY8maeG1n9nzCv29g8kaFPVZ4tf8C5w@mail.gmail.com> <4FA15898.1040204@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852C44001329@ESESSCMS0356.eemea.ericsson.se> <CAD5OKxsbTSpMPg30P4DSN6UasCx6na43tpZ5yT2ct6SLMpd9xQ@mail.gmail.com> <7F2072F1E0DE894DA4B517B93C6A05852C4400132C@ESESSCMS0356.eemea.ericsson.se> <6F428EFD2B8C2F49A2FB1317291A76C1136047B753@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05852C4400132F@ESESSCMS0356.eemea.ericsson.se> <CAD5OKxuy8_Ras3X-8tcY1qaLRTVJ-z-JuXQaf0NKaRwN_dU18Q@mail.gmail.com>
In-Reply-To: <CAD5OKxuy8_Ras3X-8tcY1qaLRTVJ-z-JuXQaf0NKaRwN_dU18Q@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP
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: Thu, 03 May 2012 06:02:49 -0000

Hi,

>> I think that is unlikely to happen, as forking is normally done in a serial manner (to avoid other issues associated with parallel forking).
>
> I am not sure why you would say that most forking is serial. It is quite often parallel. What is commonly done to avoid support for multiple 
> parallel media streams is playing media from the newest received RTP stream. In either case there is no guarantee that you picked the 
> winning stream, and you always need to make sure that you use the SDP received in the dialog that got 200 OK and that media playback 
> switches to RTP stream that remains. Making this work is often problematic in SIP since there is no way to associate received RTP with 
> received SDP information due to RTP being sent from a different IP/port from the one used in SDP. It should be easier with WebRTC 
> since ICE support is required and remote party IP/port can be determined for each flow.
>
> Finally, when you are dealing with forking you need to keep track of the remote IP/ports and ICE candidates for each dialog. You can 
> play media from only one of them, but this remote connection state is required to complete the call setup when 200 OK is received.

You are absolutely right. I still question whether we need to support parallel forking. If you say it occurs often, I can't argue against you, eventhough my own experience is different :)

(Another option, if we want to support parallel forking, would of course be to create a completely new PeerConnection, with a *new* local IP address:port. But, you would of course then have to provide that information to the remote peer.)

I have no strong feeling on whether we want to do cloning, but do people agree that, for a given PeerConnection, we only need to support a single remote peer (which can be modified, though)?

Regards,

Christer