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

Christer Holmberg <christer.holmberg@ericsson.com> Thu, 03 May 2012 20:31 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 2EFBF21F8664 for <rtcweb@ietfa.amsl.com>; Thu, 3 May 2012 13:31:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.136
X-Spam-Level:
X-Spam-Status: No, score=-6.136 tagged_above=-999 required=5 tests=[AWL=0.113, 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 e7OT2cAe1iCx for <rtcweb@ietfa.amsl.com>; Thu, 3 May 2012 13:31:53 -0700 (PDT)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 0568921F8618 for <rtcweb@ietf.org>; Thu, 3 May 2012 13:31:52 -0700 (PDT)
X-AuditID: c1b4fb30-b7b07ae000006839-81-4fa2eb379035
Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id DE.D7.26681.73BE2AF4; Thu, 3 May 2012 22:31:51 +0200 (CEST)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.64]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Thu, 3 May 2012 22:31:51 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Roman Shpount <roman@telurix.com>, Randell Jesup <randell-ietf@jesup.org>
Date: Thu, 03 May 2012 22:29:04 +0200
Thread-Topic: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP
Thread-Index: Ac0pawdf27xb6g6ySFCkuOuj31BxfAAAFp/k
Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C44001338@ESESSCMS0356.eemea.ericsson.se>
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> <7F2072F1E0DE894DA4B517B93C6A05852C44001337@ESESSCMS0356.eemea.ericsson.se> <4FA2E264.4040207@jesup.org>, <CAD5OKxs3AqvbookWYPDgOuAkjPZGVUdSEhqz6P_p9E4h_ZHJGQ@mail.gmail.com>
In-Reply-To: <CAD5OKxs3AqvbookWYPDgOuAkjPZGVUdSEhqz6P_p9E4h_ZHJGQ@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="iso-8859-1"
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 20:31:54 -0000

Hi,

You could also choose not to alert the remote user until the ICE procedures have finished - more or less using ICE with preconditions.

Of course, that is going to trigger actions in STUN/TURN servers, even if the called party won't accept the call, but at least from a user experience perspective that is still better than lifting the hook, and having to wait for whatever-time-it-takes-for-ICE-to-finish seconds before one can start to talk.

Regards,

Christer

________________________________
From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] On Behalf Of Roman Shpount [roman@telurix.com]
Sent: Thursday, May 03, 2012 11:26 PM
To: Randell Jesup
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP

On Thu, May 3, 2012 at 3:54 PM, Randell Jesup <randell-ietf@jesup.org<mailto:randell-ietf@jesup.org>> wrote:

Call setup delay causes clipping, unless you in some manner use feedback to the answerer to hold them off from talking.  The classic problem you probably all know is "pickup receiver, say "hello" - if call setup takes (or media is clipped by) more than a couple hundred ms, the clipping is audible to the caller.  And it gets worse (100ms or perhaps even less) for "click-to-answer".  The only thing to help you there is possible visual indication that it's not connected yet to encourage the answerer to wait before talking, and in some uses that's not possible or isn't sufficiently obvious.  (audio-only connections, especially in a context where you're paying attention to other things as well (game, VR conference, etc)).

Unfortunately this is unavoidable with ICE. Once you have ICE setup enabled you normally end up with at least a RTT delay. If this is a call from east to west coast in US, this typically means that about 100 ms worth of media is clipped (pretty much means no initial hello). If you add DTLS setup on top of this, you end up with more then half a second worth of audio clipped, so this typically means people saying hello several times to see if there is a person on the other side. All of this for the calls in continental US. If you are talking to somebody over a satellite link, situation is much worse. The way I've seen dealt with this was playing some sort of audio and media to the answering party until call is actually connected to prevent them from speaking.
_____________
Roman Shpount