Re: [rtcweb] Question about JSEP createOffer

Justin Uberti <juberti@google.com> Thu, 10 May 2012 13:48 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 A371721F864B for <rtcweb@ietfa.amsl.com>; Thu, 10 May 2012 06:48:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.526
X-Spam-Level:
X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.450, 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 oMRErnerBVWL for <rtcweb@ietfa.amsl.com>; Thu, 10 May 2012 06:48:58 -0700 (PDT)
Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 652B121F8629 for <rtcweb@ietf.org>; Thu, 10 May 2012 06:48:58 -0700 (PDT)
Received: by qadz3 with SMTP id z3so361154qad.10 for <rtcweb@ietf.org>; Thu, 10 May 2012 06:48:58 -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=ZlERH/3JVzl4gkX7ZMqxcfYWYVnxrs76vzH82NgXObc=; b=QzfuEyE7Joj40BNRtZQVFMTnP1sHH1cxUEodI611FbxAFOPZmdvl1ULU3w2jTeI1Jd rcNMFsalZPssAZoMZ6qZ4w+dcF/6Va9QJ8r/F9tQNPpYoY2YdKp+tB39RmYW+Hcya+JT HL0awnL4szr/mWD9dyUmlxq5cwm8GVa4NhiK5cfQHhTlgQzr92IM4D4vCKcZ7tM88Par 65nXChjYXpTRn2fIfB4IinWVPgOTPxigLVOBWH+srqzqWpvMWlWaN371WJOL+YSwIoty a0vmByJkiTBqR12YWoUXtT8SDGFBIITr/6ewXdxprPg/Ys44ADf1oQhZcchrrfIcvPAZ amWQ==
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=ZlERH/3JVzl4gkX7ZMqxcfYWYVnxrs76vzH82NgXObc=; b=Vg545T8ITS1QCGWFPyeSTpwn/WKku/AwxVfpB4hN9VtrK927zaylNkG8ZxXRWG6DdG of3nruvFH5xKtHiNhpElfwNNThC24qImhzfoNxaogExPrcwbway1Ut6ATJKqzOqioos+ VEhNuATuiaIyDuH4WP1Qz4Ahb3C4u8oAUu/YIGjDid64ZGuIT8j1rHQsiBTaXhBQ84uF 1zIyA3EvR61kVp0WUeQwU+EHxQkwR9h9C3639mtPCE30Nt8wb/fXrQEMHoAF4f+mMWMR Rb1Qwun47t3VhOmvNbdDSYFbSwCnZcpaobZdRo5ws8nsKCQUMbpdxg2maG67BMcnDtIl fhhQ==
Received: by 10.224.215.135 with SMTP id he7mr11763969qab.48.1336657737789; Thu, 10 May 2012 06:48:57 -0700 (PDT)
Received: by 10.224.215.135 with SMTP id he7mr11763930qab.48.1336657737484; Thu, 10 May 2012 06:48:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.217.129 with HTTP; Thu, 10 May 2012 06:48:37 -0700 (PDT)
In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C16033CC2@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> <CAOJ7v-14=rSFiN=EKsWj=KX6YytcpjYDJtd4Ljao8L6cyiquYQ@mail.gmail.com> <387F9047F55E8C42850AD6B3A7A03C6C16033CC2@inba-mail01.sonusnet.com>
From: Justin Uberti <juberti@google.com>
Date: Thu, 10 May 2012 09:48:37 -0400
Message-ID: <CAOJ7v-1J+GLRea=3r4Ees5SadQ60grogACEbofoZ0Jh5VrpY6g@mail.gmail.com>
To: "Ravindran, Parthasarathi" <pravindran@sonusnet.com>
Content-Type: multipart/alternative; boundary=20cf300513f6a10a7104bfaee1c5
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQmTdzpi4Jq/k9a9YpGwRSh/OXqIHL+0VrnBK6iJ/T43igRYbo04mzwWGjiwFKZj5Oj5MukNbk+xjTlm444mTRJ+5TneUO2DAdCTHZVukOsYWtRnhbjo2JGx5inR9MyADSSaUNQu
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 13:48:59 -0000

On Thu, May 10, 2012 at 4:10 AM, Ravindran, Parthasarathi <
pravindran@sonusnet.com> wrote:

>  Justin,****
>
> ** **
>
> The new media type/codec change by the answerer requires the complete set
> of codec from offerer. It is not appropriate to remember the previously
> offered codec & capabilities as it is subject to vary in the mid-session.
> For example, it is possible for the offerer to remove webcam in the middle
> of the audio session wherein answerer should not expect that video is
> supported by offerer as it was offered initially.****
>
> ** **
>
> Please read inline for more comments.****
>
> ** **
>
> Thanks****
>
> Partha****
>
> ** **
>
> *From:* Justin Uberti [mailto:juberti@google.com]
> *Sent:* Thursday, May 10, 2012 8:32 AM
> *To:* Ravindran, Parthasarathi
> *Cc:* Roman Shpount; rtcweb@ietf.org
>
> *Subject:* Re: [rtcweb] Question about JSEP createOffer****
>
>  ** **
>
> ** **
>
> 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. ****
>
> <partha>  IIUC for audio session, each time re-offer MUST contain “full”
> offer for video section </partha>
>

If you have an audio session, and you add video, the offer to add video
will include a "full" offer for video. But changes just to the audio
session itself will obviously not include anything about video. Maybe I
don't understand what you are suggesting.

> ****
>
>  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. ****
>
> <partha> Your proposal is limiting as the answerer has no choice to the
> select the preferred codec </partha>
>

I thought the offerer wanted to change the codec. Why would the answerer
need to make a selection? If the 'answerer' wants to use a different codec,
it should make an offer of its own.

****
>
> ** **
>
> 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.****
>
> <partha> your API proposal looks good  as it is possible to re-use the
> existing or offer full based on the application needs. But the application
> developer  MUST aware of the implication as it calls for interop issue in
> case of federation scenario if the full offer is not sent across. </partha>
>

The application developer only needs to do this if supporting these edge
cases is relevant to their application.

> ****
>
>  ****
>
>   ****
>
>  ****
>
>  ****
>
> *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****
>
>  ** **
>