Re: [rtcweb] Question about JSEP createOffer

Justin Uberti <juberti@google.com> Thu, 10 May 2012 03:02 UTC

Return-Path: <juberti@google.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 2935911E80E9 for <rtcweb@ietfa.amsl.com>; Wed, 9 May 2012 20:02:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.485
X-Spam-Level:
X-Spam-Status: No, score=-102.485 tagged_above=-999 required=5 tests=[AWL=0.491, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 MXc-p3IXFDPF for <rtcweb@ietfa.amsl.com>; Wed, 9 May 2012 20:02:40 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 47D6F11E80B0 for <rtcweb@ietf.org>; Wed, 9 May 2012 20:02:40 -0700 (PDT)
Received: by yhq56 with SMTP id 56so1231160yhq.31 for <rtcweb@ietf.org>; Wed, 09 May 2012 20:02:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=mvACcfLeMov1xdres+n1+CjUw1u5SKdqGNBll1inQtM=; b=kvPFimsxDo7BA5WH5QbRKsinF/m2AELptNFR/9TDPc2v9efhrQDBeOZb/6RTrAU/wA L6BAn9fpnFQ3nwiud5ZnC9nnG+uKZxh5d6F73ZPKDbMjpEHIsKWqGCWwr0HRj4hxKO0z NfY39TOGdWlWvW0DPuc8pbz/xEAhk2ErvzDGoPAjWBxcroGmYTpJ5rT8/F7xGQbdJ1Ey qTfzajZTk7jqlNnh54ppDhmOxpunQC5RBX2AOPApgj7PRyd7rpRKfpcVzX1FqKwvHLr2 je8ESJaJ9TdybQ5di+Al5JZoewzMcFFTXNqCX7M9qqOnUfF9MDnC/11IgKfGx/Hfu8Ot 8UvQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=mvACcfLeMov1xdres+n1+CjUw1u5SKdqGNBll1inQtM=; b=fAT6WieWMsIVrQMtGYW9BvG05DWp1HC2tKxw7UmZ1vgEGPwWAvclFr9qQC94Vz7/lL ZFKJYtt6qm58sHr4YfQkiP3hGczNRewlGjiXgF9bmf4Fge+yuWWLBUQOoBHC6Lal8oog H7vYDi2d4b7f8/RwqhQ2E5+w1Il7GtUJ4lnXHfSJLQj500hMYwg6yOPpAysF23LdHRIQ 1w+azlg+lkyzFV2I6A/EQpSr3LwbcCwChwFUesNu5p7l/r0Fu6c0vu8M+48P9Rf0mbw3 vCPB97pecvARs/DeVT6VflmpSqcTQsdklKkA30eOW1vIE3UQMzyzHEe11kOTO7104fNj rLvQ==
Received: by 10.50.149.226 with SMTP id ud2mr1423502igb.74.1336618959789; Wed, 09 May 2012 20:02:39 -0700 (PDT)
Received: by 10.50.149.226 with SMTP id ud2mr1423496igb.74.1336618959634; Wed, 09 May 2012 20:02:39 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.193.218 with HTTP; Wed, 9 May 2012 20:02:16 -0700 (PDT)
In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C160337BF@inba-mail01.sonusnet.com>
References: <6F428EFD2B8C2F49A2FB1317291A76C11364EC0288@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <CAOJ7v-041Lhp1EkEsH--pWhpikf74Luq-iyasVdpP5mN-4TskA@mail.gmail.com> <CAD5OKxtKkhO5KU_mcWp7ahM+8ochiaL3yUXCW5kuP0RWeB8y_w@mail.gmail.com> <387F9047F55E8C42850AD6B3A7A03C6C160337BF@inba-mail01.sonusnet.com>
From: Justin Uberti <juberti@google.com>
Date: Wed, 09 May 2012 23:02:16 -0400
Message-ID: <CAOJ7v-14=rSFiN=EKsWj=KX6YytcpjYDJtd4Ljao8L6cyiquYQ@mail.gmail.com>
To: "Ravindran, Parthasarathi" <pravindran@sonusnet.com>
Content-Type: multipart/alternative; boundary="e89a8f2347b54a00e904bfa5da3b"
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQmIUEsXQNYiHivo7jSeqc5ZcPi7PIO8SYNkZ4qNvtd0sM3WAMdh0YsNTWWNk2w6XePJseOOxI0YWvU0qMnORFjeQMY4AEKxS3W5UMe6/ovyIsXMLugbjalsPhrk390wJsbP5qos
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: Thu, 10 May 2012 03:02:41 -0000

On Wed, May 9, 2012 at 2:24 AM, Ravindran, Parthasarathi <
pravindran@sonusnet.com> wrote:

>  I agree with Richard & Roman. “Full” re-OFFER MUST supported required
> for couple of mid session scenario like ****
>
> ** **
>
> **1)      **The session is established with audio and then video shall be
> added in the middle in case complete offer is provided in re-OFFER.
>
You don't need a complete offer here, just a "full" offer for the video m=
section. This should already work today.

> ****
>
> **2)      ** It is possible to change the codec in the middle of the
> Session as Roman mentioned.
>
This also doesn't require a complete offer. The application would need to
remember what codecs are available so that it could change the offered
codec to something other than what it is currently using, but it would not
need to resend all codecs.

I agree Roman's case of a B2BUA seems like it would need a full offer,
although the idea of connecting an existing call to a new destination seems
like an uncommon case; the application could simply start a new call (i.e.
create a new PeerConnection), right?

If we decide we need to support this, the simplest way of handling this
would be to simply extend the |hints| parameter in createOffer to have some
sort of "complete" flag.


> ****
>
> ** **
>
> ** **
>
> ** **
>
> *From:* rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] *On
> Behalf Of *Roman Shpount
> *Sent:* Tuesday, May 08, 2012 9:03 PM
> *To:* Justin Uberti
> *Cc:* rtcweb@ietf.org
> *Subject:* Re: [rtcweb] Question about JSEP createOffer****
>
> ** **
>
>
> ****
>
> 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****
>