Re: [splices] FW: New Version Notification for draft-loreto-splices-disaggregated-media-02.txt
Peter Musgrave <musgravepj@gmail.com> Wed, 29 June 2011 10:51 UTC
Return-Path: <musgravepj@gmail.com>
X-Original-To: splices@ietfa.amsl.com
Delivered-To: splices@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A80C29E8029 for <splices@ietfa.amsl.com>; Wed, 29 Jun 2011 03:51:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level:
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C3JNO2qLNxdN for <splices@ietfa.amsl.com>; Wed, 29 Jun 2011 03:51:23 -0700 (PDT)
Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by ietfa.amsl.com (Postfix) with ESMTP id 6C0689E801F for <splices@ietf.org>; Wed, 29 Jun 2011 03:51:23 -0700 (PDT)
Received: by fxe4 with SMTP id 4so1403947fxe.27 for <splices@ietf.org>; Wed, 29 Jun 2011 03:51:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HXhV2/6/u1LccSLtqkdVM5dgE43FT9rwQIZpFAiwr1I=; b=a7IAJKINafik0CY+gbvn/2GF2JDZCWmQUtdlP45PSVAZ2fDAw9/bWnCEBrkT/Yn3NF Z2yB63uOO8hbXZ8XVjZZMqMjRXxPPQJoL/dCmKJ4Kqn1EBLY+P94p7M39fV2KAiA/7+E ZzQRpE+QkkHxiG3MYvYj/xgDdrRgnlxkJvWKs=
MIME-Version: 1.0
Received: by 10.223.65.73 with SMTP id h9mr1054962fai.58.1309344682377; Wed, 29 Jun 2011 03:51:22 -0700 (PDT)
Received: by 10.223.125.200 with HTTP; Wed, 29 Jun 2011 03:51:22 -0700 (PDT)
In-Reply-To: <6369CB70BFD88942B9705AC1E639A33822CE7CF843@DC-US1MBEX4.global.avaya.com>
References: <6369CB70BFD88942B9705AC1E639A33822CE7CF83F@DC-US1MBEX4.global.avaya.com> <BANLkTimUMzip48s9oHMFno-sePeSWKEv0g@mail.gmail.com> <6369CB70BFD88942B9705AC1E639A33822CE7CF843@DC-US1MBEX4.global.avaya.com>
Date: Wed, 29 Jun 2011 06:51:22 -0400
Message-ID: <BANLkTin1ZM5AzaAR2g72yC=MqebUqshUjQ@mail.gmail.com>
From: Peter Musgrave <musgravepj@gmail.com>
To: "Shekh-Yusef, Rifaat (Rifaat)" <rifatyu@avaya.com>
Content-Type: multipart/alternative; boundary="001517475434ae823104a6d79011"
Cc: "splices@ietf.org" <splices@ietf.org>
Subject: Re: [splices] FW: New Version Notification for draft-loreto-splices-disaggregated-media-02.txt
X-BeenThere: splices@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" <splices.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/splices>, <mailto:splices-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/splices>
List-Post: <mailto:splices@ietf.org>
List-Help: <mailto:splices-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/splices>, <mailto:splices-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Jun 2011 10:51:28 -0000
Right. I remember now. This example is a good candidate for the next version of the draft. Peter On Tue, Jun 28, 2011 at 9:57 PM, Shekh-Yusef, Rifaat (Rifaat) < rifatyu@avaya.com> wrote: > Thanks Peter, > > The mechanism is flexable enough to allow any party to answe or initiate a > call and take the controller role. > Take a look at the following email with an example of the video device > initiating a call and taking the controller role. > http://www.ietf.org/mail-archive/web/splices/current/msg00123.html > > Regards, > Rifaat > > > > > ------------------------------ > *From:* Peter Musgrave [musgravepj@gmail.com] > *Sent:* Tuesday, June 28, 2011 6:17 PM > > *To:* Shekh-Yusef, Rifaat (Rifaat) > *Cc:* splices@ietf.org > *Subject:* Re: [splices] FW: New Version Notification for > draft-loreto-splices-disaggregated-media-02.txt > > HI Rifaat, > > I like the additions to the draft - makes it very concrete. > > This matches what I remember being discussed on the list. It seems that > an unstated principle in section 4 is that the device which will establish > the audio connection is the device which answers the call, even if it is not > in the controller role. Is it worthwhile making that principle explicit? > > Do you envisage a case where the device taking only video is the one to > answer the call? > > Regards, > > Peter Musgrave > > On Sat, Jun 25, 2011 at 9:14 AM, Shekh-Yusef, Rifaat (Rifaat) < > rifatyu@avaya.com> wrote: > >> Hi, >> >> We have just submitted a new version for the >> draft-loreto-splices-disaggregated-media draft. >> https://datatracker.ietf.org/doc/draft-loreto-splices-disaggregated-media/ >> >> We would appreciate it if you review it and provide us with your feedback. >> >> Regards, >> Rifaat >> >> ________________________________________ >> From: internet-drafts@ietf.org [internet-drafts@ietf.org] >> Sent: Saturday, June 25, 2011 9:11 AM >> To: Shekh-Yusef, Rifaat (Rifaat) >> Cc: salvatore.loreto@ericsson.com; Shekh-Yusef, Rifaat (Rifaat); >> gonzalo.camarillo@ericsson.com >> Subject: New Version Notification for >> draft-loreto-splices-disaggregated-media-02.txt >> >> A new version of I-D, draft-loreto-splices-disaggregated-media-02.txt has >> been successfully submitted by Rifaat Shekh-Yusef and posted to the IETF >> repository. >> >> Filename: draft-loreto-splices-disaggregated-media >> Revision: 02 >> Title: Disaggregated Media in the Session Initiation Protocol >> (SIP) >> Creation date: 2011-06-25 >> WG ID: Individual Submission >> Number of pages: 18 >> >> Abstract: >> Disaggregated media refers to the ability for a user to create a >> multimedia session combining different media streams, coming from >> different devices under his or her control, so that they are treated >> by the far end of the session as a single media session. This >> document lists several use cases that involve disaggregated media in >> SIP. Additionally, this document analyzes what types of >> disaggregated media can be implemented using existing protocol >> mechanisms, and the pros and cons of using each of those mechanisms. >> Finally, this document describes scenarios that are not covered by >> current mechanisms and proposes new IETF work to cover them. >> >> >> >> >> The IETF Secretariat >> _______________________________________________ >> splices mailing list >> splices@ietf.org >> https://www.ietf.org/mailman/listinfo/splices >> > >
- [splices] FW: New Version Notification for draft-… Shekh-Yusef, Rifaat (Rifaat)
- Re: [splices] FW: New Version Notification for dr… Peter Musgrave
- Re: [splices] FW: New Version Notification for dr… Shekh-Yusef, Rifaat (Rifaat)
- Re: [splices] FW: New Version Notification for dr… Peter Musgrave
- Re: [splices] FW: New Version Notification for dr… Worley, Dale R (Dale)
- Re: [splices] FW: New Version Notification for dr… Salvatore Loreto
- Re: [splices] FW: New Version Notification for dr… Worley, Dale R (Dale)
- Re: [splices] FW: New Version Notification for dr… Salvatore Loreto
- Re: [splices] FW: New Version Notification for dr… Worley, Dale R (Dale)