IETF Logo Mail Archive

Re: [rtcweb] Question about JSEP createOffer

"Ravindran, Parthasarathi" <pravindran@sonusnet.com> Wed, 09 May 2012 06:25 UTC

Return-Path: <pravindran@sonusnet.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 3CA4221F85EF for <rtcweb@ietfa.amsl.com>; Tue, 8 May 2012 23:25:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.518
X-Spam-Level:
X-Spam-Status: No, score=-6.518 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 B64keaVsrp3M for <rtcweb@ietfa.amsl.com>; Tue, 8 May 2012 23:25:10 -0700 (PDT)
Received: from na3sys010aog105.obsmtp.com (na3sys010aog105.obsmtp.com [74.125.245.78]) by ietfa.amsl.com (Postfix) with ESMTP id 464D421F85EE for <rtcweb@ietf.org>; Tue, 8 May 2012 23:25:09 -0700 (PDT)
Received: from usma-ex-hub1.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob105.postini.com ([74.125.244.12]) with SMTP ID DSNKT6oNxfG8HuwF53gi9vJlEk5xVt5f0dqo@postini.com; Tue, 08 May 2012 23:25:10 PDT
Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by usma-ex-hub1.sonusnet.com (66.203.90.16) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 9 May 2012 02:25:19 -0400
Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0355.002; Wed, 9 May 2012 11:55:00 +0530
From: "Ravindran, Parthasarathi" <pravindran@sonusnet.com>
To: Roman Shpount <roman@telurix.com>, Justin Uberti <juberti@google.com>
Thread-Topic: [rtcweb] Question about JSEP createOffer
Thread-Index: AQHNLSluoHgR0lZnOEGRK8sd9ExIfZa/qTgAgAFS2DA=
Date: Wed, 09 May 2012 06:24:59 +0000
Message-ID: <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>
In-Reply-To: <CAD5OKxtKkhO5KU_mcWp7ahM+8ochiaL3yUXCW5kuP0RWeB8y_w@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.70.54.99]
Content-Type: multipart/alternative; boundary="_000_387F9047F55E8C42850AD6B3A7A03C6C160337BFinbamail01sonus_"
MIME-Version: 1.0
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: Wed, 09 May 2012 06:25:12 -0000

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.

2)       It is possible to change the codec in the middle of the Session as Roman mentioned.



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<mailto: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