IETF Logo Mail Archive

Re: [rtcweb] Question about JSEP createOffer

Roman Shpount <roman@telurix.com> Tue, 08 May 2012 15:33 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 34D7921F85D9 for <rtcweb@ietfa.amsl.com>; Tue, 8 May 2012 08:33:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.888
X-Spam-Level:
X-Spam-Status: No, score=-2.888 tagged_above=-999 required=5 tests=[AWL=0.088, 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 d3PLuN1GygAq for <rtcweb@ietfa.amsl.com>; Tue, 8 May 2012 08:33:12 -0700 (PDT)
Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id A525221F85D6 for <rtcweb@ietf.org>; Tue, 8 May 2012 08:33:12 -0700 (PDT)
Received: by pbcwy7 with SMTP id wy7so8278892pbc.31 for <rtcweb@ietf.org>; Tue, 08 May 2012 08:33:12 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=4D8U5MsOzVUBi5RwJXT4blQ/9pfVwHG94307HD722Bw=; b=BcnmlVVL15vRfGIr1KZY0eJCW+kvTAA7IpyNcOBe2l09SD+2MTuKxRd6gUlseygCq7 xu0ZPkfSb4ddEHMj/RT0bOQnMpqhoeqqKwLEPGXrRfN9tCk7h/7J7H39mEsqV4m58ksV P48pxtLoF3lOAfVEkoDtqLfJ78IFgrgn7AK1n2rvawTn48vqe6bo9mzL/TzZtmoKgtTU shlRE0xgvphw54K2VvWDkI2N3qPxeTolNf+X2/qPgYCFicTWw/YMzj4TajHaAMqQNg9A MKuINDtrc3fF4E3KswfvmGn40BPDEAeA4cpdWTlQ3d619iVi0SBrHC89B4i5domhDiVh 6Maw==
Received: by 10.68.197.8 with SMTP id iq8mr8251371pbc.65.1336491192478; Tue, 08 May 2012 08:33:12 -0700 (PDT)
Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by mx.google.com with ESMTPS id kb12sm2725673pbb.15.2012.05.08.08.33.11 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 08 May 2012 08:33:11 -0700 (PDT)
Received: by pbcwy7 with SMTP id wy7so8278858pbc.31 for <rtcweb@ietf.org>; Tue, 08 May 2012 08:33:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.191.74 with SMTP id gw10mr9365734pbc.90.1336491191033; Tue, 08 May 2012 08:33:11 -0700 (PDT)
Received: by 10.68.129.161 with HTTP; Tue, 8 May 2012 08:33:10 -0700 (PDT)
In-Reply-To: <CAOJ7v-041Lhp1EkEsH--pWhpikf74Luq-iyasVdpP5mN-4TskA@mail.gmail.com>
References: <6F428EFD2B8C2F49A2FB1317291A76C11364EC0288@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <CAOJ7v-041Lhp1EkEsH--pWhpikf74Luq-iyasVdpP5mN-4TskA@mail.gmail.com>
Date: Tue, 08 May 2012 11:33:10 -0400
Message-ID: <CAD5OKxtKkhO5KU_mcWp7ahM+8ochiaL3yUXCW5kuP0RWeB8y_w@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: Justin Uberti <juberti@google.com>
Content-Type: multipart/alternative; boundary="e89a8fb20896afe13f04bf881a1e"
X-Gm-Message-State: ALoCoQla0YhVM57wDjl4pRxhC90Rs3vzEvvIHmNKv+xPq9xLLylKRo/3O+nwWoa1YxvD2fNH2z3r
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Question about JSEP createOffer
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: Tue, 08 May 2012 15:33:13 -0000

On Tue, May 8, 2012 at 10:46 AM, Justin Uberti <juberti@google.com> wrote:

> Richard,
>
> That is an interesting point. Could you give a short example of when such
> a "full" re-OFFER would be used? There are a few ways we could handle this
> case.
>
>
Actually I was the person who argued that "full" capabilities should be
present in original SIP O/A, when new offer is generated in an existing
session. The use case for this are B2BUA that connect an existing session
to a new call or another existing session. Typically, B2BUA would ask one
of the call parties for the offer (send an INVITE with no body in SIP), get
the new offer, and send this offer to the newly placed call. In order for
this to work, all the calling party capabilities should be listed in this
new offer, in particular all the codecs and all the communications types
(audio, video, text, etc), or call would not be successfully established.
_____________
Roman Shpount

v2.23.0 | Report a Bug | By Email