IETF Logo Mail Archive

Re: [rtcweb] SIP Glare - Re: Minimal SDP negotiation mechanism

Roman Shpount <roman@telurix.com> Thu, 22 September 2011 14:53 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 EF56721F8B12 for <rtcweb@ietfa.amsl.com>; Thu, 22 Sep 2011 07:53:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.753
X-Spam-Level:
X-Spam-Status: No, score=-2.753 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 gwPkvuKRX2LF for <rtcweb@ietfa.amsl.com>; Thu, 22 Sep 2011 07:53:02 -0700 (PDT)
Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id E27DB21F8B10 for <rtcweb@ietf.org>; Thu, 22 Sep 2011 07:53:00 -0700 (PDT)
Received: by qyk32 with SMTP id 32so6318724qyk.10 for <rtcweb@ietf.org>; Thu, 22 Sep 2011 07:55:31 -0700 (PDT)
Received: by 10.229.180.104 with SMTP id bt40mr1742586qcb.184.1316703331263; Thu, 22 Sep 2011 07:55:31 -0700 (PDT)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by mx.google.com with ESMTPS id hn10sm8448079qab.20.2011.09.22.07.55.30 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 22 Sep 2011 07:55:31 -0700 (PDT)
Received: by gxk19 with SMTP id 19so2463749gxk.31 for <rtcweb@ietf.org>; Thu, 22 Sep 2011 07:55:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.5.1 with SMTP id o1mr4519045pbo.20.1316703329021; Thu, 22 Sep 2011 07:55:29 -0700 (PDT)
Received: by 10.68.55.39 with HTTP; Thu, 22 Sep 2011 07:55:27 -0700 (PDT)
In-Reply-To: <0FA1CB26-592C-4550-B449-AA2814817E51@acmepacket.com>
References: <4E777500.5030201@alvestrand.no> <4E78940C.4040405@ericsson.com> <ED2DB00E-A64B-405F-96AC-2269258F6FFC@cisco.com> <4E799ECC.8030306@ericsson.com> <DB6B2796-9762-47CA-9A45-62476146DF04@cisco.com> <57CCCB06-F4C3-4E23-AF09-B7B5285C5FAE@phonefromhere.com> <0FA1CB26-592C-4550-B449-AA2814817E51@acmepacket.com>
Date: Thu, 22 Sep 2011 10:55:27 -0400
Message-ID: <CAD5OKxsPrri56nNJd4tXgK4fHfoUCzmB_Sjkgg8SN=KCccDFyA@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: Hadriel Kaplan <HKaplan@acmepacket.com>
Content-Type: multipart/alternative; boundary="bcaec5314b51336e3104ad88e2f3"
Cc: "<rtcweb@ietf.org>" <rtcweb@ietf.org>
Subject: Re: [rtcweb] SIP Glare - 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: Thu, 22 Sep 2011 14:53:04 -0000

If we are planning to support SIP, then standard way of dealing with glare
actually works fairly well. We would probably not get as much glare even
with SIP if we would not use re-INVITEs for keep alive messages (SIP session
timers). If we do not plan to support SIP, all we need is an ability in the
API to cancel an offer and leave glare resolution to signaling. In general
glare is unavoidable, for instance in case were both parties in the call
decide for some reason to switch the video on.
_____________
Roman Shpount


On Thu, Sep 22, 2011 at 10:40 AM, Hadriel Kaplan <HKaplan@acmepacket.com>wrote:

>
> On Sep 22, 2011, at 9:57 AM, Tim Panton wrote:
>
> > At the risk of showing my ignorance - why are we expecting glare to be a
> problem?
> > To my mind glare only happens when you have a locked resource e.g. a busy
> line
> > or number . Rtcweb does not contain either of those concepts, what's the
> resource
> > that is being competed for here ?
>
> The resource being competed for is SDP state/media info of the same
> session.  If both sides send a new SDP offer during the session at the same
> time, one side has to win.
>
> One would think this would be ultra-rare, but in SIP it happens a lot in
> some deployments.
>
> -hadriel
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>

v2.23.0 | Report a Bug | By Email