IETF Logo Mail Archive

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

"Ejzak, Richard P (Richard)" <richard.ejzak@alcatel-lucent.com> Fri, 11 May 2012 20:19 UTC

Return-Path: <richard.ejzak@alcatel-lucent.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 4590D21F8739 for <rtcweb@ietfa.amsl.com>; Fri, 11 May 2012 13:19:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.299
X-Spam-Level:
X-Spam-Status: No, score=-7.299 tagged_above=-999 required=5 tests=[AWL=-0.700, BAYES_00=-2.599, 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 DC4mPY1eLMDU for <rtcweb@ietfa.amsl.com>; Fri, 11 May 2012 13:19:27 -0700 (PDT)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id B002B21F8716 for <rtcweb@ietf.org>; Fri, 11 May 2012 13:19:27 -0700 (PDT)
Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q4BKJQlE028270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <rtcweb@ietf.org>; Fri, 11 May 2012 15:19:27 -0500 (CDT)
Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q4BKJQIK027691 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <rtcweb@ietf.org>; Fri, 11 May 2012 15:19:26 -0500
Received: from USNAVSXCHMBSA1.ndc.alcatel-lucent.com ([135.3.39.124]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Fri, 11 May 2012 15:19:26 -0500
From: "Ejzak, Richard P (Richard)" <richard.ejzak@alcatel-lucent.com>
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
Date: Fri, 11 May 2012 15:19:25 -0500
Thread-Topic: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP
Thread-Index: Ac0vh2JWI2I2SnrgQPiDqAUzhcRMHQAKXZnQ
Message-ID: <6F428EFD2B8C2F49A2FB1317291A76C1136D546AFC@USNAVSXCHMBSA1.ndc.alcatel-lucent.com>
References: <387F9047F55E8C42850AD6B3A7A03C6C0E23B102@inba-mail01.sonusnet.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> <7F2072F1E0DE894DA4B517B93C6A05852C442AC0DA@ESESSCMS0356.eemea.ericsson.se> <CAD5OKxuv7T6YrEXEeVECKbGtRg4feoRYTgvC57yqWXTBK43ypg@mail.gmail.com> <4FA2B447.7010504@jesup.org> <4FA2E264.4040207@jesup.org> <7F2072F1E0DE894DA4B517B93C6A05852C4400! 1 338@ESESSCMS0356.eemea.ericsson.se> <CAD5OKxuq14_DfSJuFEHq_ZEubbOYt7NFTcXWpLND8ggAr37QhA@mail.gmail.com> <7F2072F1E0DE894DA4B517B93C6A05852C44001339@ESESSCMS0356.eemea.ericsson.se> <CAD5OKxvFYy-9XAE5GG0n58xX2HKRX3o5qkTZ2o6rugakaM77Ew@mail.gmail.com> <7F2072F1E0DE894DA4B517B93C6A05852C4400133A@ESESSCMS0356.eemea.ericsson.se> <CAOJ7v-1Ue=q4MAh0csiDLvRFfMGaJ4vWrDxhir-S-OjSTsymaw@mail.gmail.com> <387F9047F55E8C42850AD6B3A7A03C6C160337F1@inba-mail01.sonusnet.com> <6E35F409-3B3F-4D92-91F2-451E0910CFDE@iii.ca> <CABkgnnVO5UyhHjiWVPsLYAoXSKPsfn6Fnb10hQr_6-kgq0FC3g@mail.gmail.com> <F0D1114C-0B6C-4AED-BDD3-4E3D6A219485@iii.ca> <CABkgnnWNLOb_xLUfOoZ5d7sKVsJDvjmNhmRqFcupO4S4p8Nrfw@mail.gmail.com> <219EC9F7-87B8-4E7B-8D6F-58A5B9773D29@iii.ca> <6F428EFD2B8C2F49A2FB1317291A76C1136D546819@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <6BF70DE5-5C59-4B64-BAFC-394E7BBF9442@belltower.co.uk>
In-Reply-To: <6BF70DE5-5C59-4B64-BAFC-394E7BBF9442@belltower.co.uk>
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-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10
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: Fri, 11 May 2012 20:19:28 -0000

Neil,
That's the point.  This discussion is with reference to parallel forking.  To avoid clipping, you need to establish the media channels with the registered targets before they are alerted because you don't know which one will answer.  This requires MediaConnection cloning so you can properly support parallel forking and do ICE and DTLS with each target in parallel before 200 OK from one of the targets.  Delaying delivery of answer indication to the caller (as you seem to imply) does not help.

Richard

-----Original Message-----
From: Neil Stratford [mailto:neils@vipadia.com] On Behalf Of Neil Stratford
Sent: Friday, May 11, 2012 10:05 AM
To: Ejzak, Richard P (Richard)
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP


On 11 May 2012, at 15:26, Ejzak, Richard P (Richard) wrote:

> But things are different with ICE and DTLS, particularly if you want to avoid media intermediaries.  Significant clipping is a real possibility if we have to restart ICE/DTLS after the "winner" responds with 200 OK.
> 
> This is not a separate use case, but a given aspect of interworking with SIP.

The whole problem of clipping audio due to the delay between the 200OK and the media actually flowing raises a flag that we are triggering upper layers of the stack on the wrong event. 

Why is anyone sending media before the media channel is fully established? Why tell the user (or IVR etc) that the call is answered before we have a working media channel?

Neil

v2.23.0 | Report a Bug | By Email