Re: [rtcweb] Use of offer / answer semantics

Roman Shpount <roman@telurix.com> Thu, 08 September 2011 16:03 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 2C32E21F889A for <rtcweb@ietfa.amsl.com>; Thu, 8 Sep 2011 09:03:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.143
X-Spam-Level:
X-Spam-Status: No, score=-2.143 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666]
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 QmBl+Ky9kWeE for <rtcweb@ietfa.amsl.com>; Thu, 8 Sep 2011 09:03:17 -0700 (PDT)
Received: from mail-gx0-f181.google.com (mail-gx0-f181.google.com [209.85.161.181]) by ietfa.amsl.com (Postfix) with ESMTP id 4FD6221F87FA for <rtcweb@ietf.org>; Thu, 8 Sep 2011 09:03:17 -0700 (PDT)
Received: by gxk9 with SMTP id 9so40735gxk.40 for <rtcweb@ietf.org>; Thu, 08 Sep 2011 09:05:09 -0700 (PDT)
Received: by 10.68.1.34 with SMTP id 2mr1251430pbj.356.1315497909206; Thu, 08 Sep 2011 09:05:09 -0700 (PDT)
Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by mx.google.com with ESMTPS id u10sm13849516pbr.12.2011.09.08.09.05.08 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 08 Sep 2011 09:05:08 -0700 (PDT)
Received: by pzk33 with SMTP id 33so4778338pzk.18 for <rtcweb@ietf.org>; Thu, 08 Sep 2011 09:05:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.51.132 with SMTP id k4mr1191639pbo.456.1315497907556; Thu, 08 Sep 2011 09:05:07 -0700 (PDT)
Received: by 10.68.43.136 with HTTP; Thu, 8 Sep 2011 09:05:07 -0700 (PDT)
In-Reply-To: <4E68E4CA.8040400@alum.mit.edu>
References: <DB0C463A-FF5F-4C15-B2B4-E81B7DF92351@cisco.com> <4E6756C1.9060207@alvestrand.no> <BLU152-W507A8040FD123508451E51931E0@phx.gbl> <4E68E4CA.8040400@alum.mit.edu>
Date: Thu, 08 Sep 2011 12:05:07 -0400
Message-ID: <CAD5OKxtWqq6y+9yDZ4METAurtM1AwxRY2EvcEA5cRLBQyiKobw@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: rtcweb@ietf.org
Content-Type: multipart/alternative; boundary="bcaec51a77007b8f6804ac70392c"
Subject: Re: [rtcweb] Use of offer / answer semantics
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, 08 Sep 2011 16:03:18 -0000

If the goal is to create something that will interop with an existing SIP
infrastructure using a signalling proxy only, we would need is to fully
support RFC 3264. I think what we will need is an ability to generate an
initial offer (as SDP), process the provisional SDP response, process final
SDP response, process an offer and generate the response, and generate a new
offer for the existing call (similar to the response to the SIP INVITE with
no body) in accordance with rules in RFC 3264. We will need to decide which
SDP related RFC would need to be supported, but I think RFC 4566, RFC 3551,
RFC 5245, and RFC 3605 are the minimum.
_____________
Roman Shpount


On Thu, Sep 8, 2011 at 11:52 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

> On 9/8/11 12:45 AM, Bernard Aboba wrote:
>
>>
>>  > > 1) The media negotiations will be done using the same SDP
>> offer/answer semantics that are used in SIP.
>>  > To be precise - you're suggesting that we use RFC 3264 offer/answer
>>  > semantics. (That RFC is 25 pages long. RFC 3261, the core SIP document,
>>  > is 269 pages, and is NOT a normative reference from 3264. I am anxious
>>  > to avoid having a normative dependency on 3261.)
>>  >
>>  > I agree with this.
>>
>> [BA] I do *not* agree that RTCWEB should have to support every aspect of
>> SDP offer/answer. Basic offer/answer, sure. All potential corner cases?
>> Not necessarily.
>>
>
> I'm not sure where you are going here?
> Are you suggesting that all the mandatory to implement O/A semantics of
> 3264 might not be supported? Or are you saying that O/A support may not work
> for all defined SDP extensions?
>
> I think that all mandatory O/A should be supported. If you have something
> specific in mind that is problematic, then maybe we should investigate why
> you think it needs to be excluded. My guess is that maybe it is something
> broken in the spec that ought to be fixed there.
>
>
>   > > 2) It will be possible to gateway between legacy SIP devices that
>> support ICE and appropriate RTP / SDP mechanisms and codecs without
>> using a media gateway. A signaling gateway to convert between the
>> signaling on the web side to the SIP signaling may be needed.
>>
>>  > I agree with this - I think the "may be needed" will turn out to be
>>  > "will be needed", but some portion of that gateway can be implemented
>> by
>>  > Javascript running in the browser, if desirable.
>>
>> [BA] This seems like a good principle, but I'm not clear that it will
>> work with all use cases. For example, what happens in the E911 use cases
>> when an RTCWEB implementation attempts to make a call to a PSAP
>> implementing NENA i3 Stage 3? If you don't have a media gateway, then
>> the browser will need to implement one of the mandated codecs on the
>> PSAP side. So in those use cases, eliminating the media gateway implies
>> making G.711 and H.264 mandatory-to-implement.
>>
>
> AFAIK, not every rtcweb application will be obligated to support E911.
> (In particular, any application that doesn't identify callees by phone
> number is a good candidate to be exempt from E911.
>
> Certainly a server without a media gateway will be limited in what it can
> call based on codec compatibility. That may or may not be a limitation,
> depending on the application. Those that find it an unacceptable limitation
> will probably find a way to incorporate a transcoder when needed.
>
>        Thanks,
>        Paul
>
> ______________________________**_________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>