Re: [rtcweb] Use of offer / answer semantics

Emil Ivov <emcho@jitsi.org> Wed, 07 September 2011 12:00 UTC

Return-Path: <emil@sip-communicator.org>
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 E618E21F8C1E for <rtcweb@ietfa.amsl.com>; Wed, 7 Sep 2011 05:00:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 n84-Esisjy39 for <rtcweb@ietfa.amsl.com>; Wed, 7 Sep 2011 05:00:23 -0700 (PDT)
Received: from mail-ey0-f174.google.com (mail-ey0-f174.google.com [209.85.215.174]) by ietfa.amsl.com (Postfix) with ESMTP id 2A24B21F8C17 for <rtcweb@ietf.org>; Wed, 7 Sep 2011 05:00:22 -0700 (PDT)
Received: by eyx24 with SMTP id 24so4894004eyx.19 for <rtcweb@ietf.org>; Wed, 07 Sep 2011 05:02:11 -0700 (PDT)
Received: by 10.213.9.70 with SMTP id k6mr2573449ebk.146.1315396931589; Wed, 07 Sep 2011 05:02:11 -0700 (PDT)
Received: from camionet.local ([78.90.181.123]) by mx.google.com with ESMTPS id d59sm215769eea.3.2011.09.07.05.02.09 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 07 Sep 2011 05:02:10 -0700 (PDT)
Message-ID: <4E675D40.4020702@jitsi.org>
Date: Wed, 07 Sep 2011 15:02:08 +0300
From: Emil Ivov <emcho@jitsi.org>
Organization: Jitsi
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; bg; rv:1.9.2.21) Gecko/20110830 Thunderbird/3.1.13
MIME-Version: 1.0
To: Cullen Jennings <fluffy@cisco.com>
References: <DB0C463A-FF5F-4C15-B2B4-E81B7DF92351@cisco.com> <4E6640FC.8080108@jitsi.org> <4B62E0EE-DA11-49A0-AB59-3AB1C6DF2B1C@cisco.com>
In-Reply-To: <4B62E0EE-DA11-49A0-AB59-3AB1C6DF2B1C@cisco.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: rtcweb@ietf.org
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: Wed, 07 Sep 2011 12:00:24 -0000

На 07.09.11 03:59, Cullen Jennings написа:
> On Sep 6, 2011, at 9:49 AM, Emil Ivov wrote:
>>> 1) The media negotiations will be done using the same SDP 
>>> offer/answer semantics that are used in SIP.
>> 
>> Does this cover media format negotiation only or does it also
>> cover transport negotiation? I believe you once mentioned you were
>> a fan of "sending ICE candidates as they become available" and for
>> that to happen we'd probably need something more XMPP-like than
>> SIP/SDP-like.
> 
> The SDP offer / answer cover both and in fact mix them together 

Yup, hence my question.

> in a way that is a bit hard to untangle,

I suppose I was (again) thinking about something along the lines of
Jingle where the separation is quite straightforward spec-wise. I do
however understand your point about how this would make it complicated
to have singnaling-only gateways with SIP ... and I do agree that this
is important, so point taken.

Thanks for explaining!

Emil
> so yes, what I am proposing here
> is that it would cover both.
> 
> In general, I am a fan of the separating the setup of the ICE
> transport channels from the negotiation of what goes over them but I
> think we are just too late at this point to really get into doing
> that and I don't see much support for it. The hard part of this is
> how to design a signaling GW that does not require a media GW but can
> map between this and SIP. Thought we might be able to do this, and I
> think it would be architecturally cleaner, it's a lot more
> complicated to done. I don't see the work happening to make something
> like this happen in a time span where it will be relevant. I think
> people are just looking for something much closer to existing
> implementations in Chrome and Firefox.
> 
> 
> 

-- 
http://jitsi.org