Re: [splices] FW: New Version Notification for draft-loreto-splices-disaggregated-media-02.txt
"Shekh-Yusef, Rifaat (Rifaat)" <rifatyu@avaya.com> Wed, 29 June 2011 01:57 UTC
Return-Path: <rifatyu@avaya.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 4593E9E8018 for <splices@ietfa.amsl.com>; Tue, 28 Jun 2011 18:57:35 -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 0HP4tlwS6ChG for <splices@ietfa.amsl.com>; Tue, 28 Jun 2011 18:57:34 -0700 (PDT)
Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 59C469E8004 for <splices@ietf.org>; Tue, 28 Jun 2011 18:57:34 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvgAAA6GCk7GmAcF/2dsb2JhbABSglGVQINXfIpmd64gApsvhjAElyiEL4cF
X-IronPort-AV: E=Sophos; i="4.65,440,1304308800"; d="scan'208,217"; a="287643021"
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 28 Jun 2011 21:57:30 -0400
Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by co300216-co-erhwest-out.avaya.com with ESMTP; 28 Jun 2011 21:56:43 -0400
Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.172]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Tue, 28 Jun 2011 21:57:30 -0400
From: "Shekh-Yusef, Rifaat (Rifaat)" <rifatyu@avaya.com>
To: Peter Musgrave <musgravepj@gmail.com>
Date: Tue, 28 Jun 2011 21:57:30 -0400
Thread-Topic: [splices] FW: New Version Notification for draft-loreto-splices-disaggregated-media-02.txt
Thread-Index: Acw14S6ptBmnn+rzR6ypOwCilc0eBwAHeADh
Message-ID: <6369CB70BFD88942B9705AC1E639A33822CE7CF843@DC-US1MBEX4.global.avaya.com>
References: <AQHMMzqBy1sccPwpBkmAYEmBU4E3tA==> <6369CB70BFD88942B9705AC1E639A33822CE7CF83F@DC-US1MBEX4.global.avaya.com>, <BANLkTimUMzip48s9oHMFno-sePeSWKEv0g@mail.gmail.com>
In-Reply-To: <BANLkTimUMzip48s9oHMFno-sePeSWKEv0g@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_6369CB70BFD88942B9705AC1E639A33822CE7CF843DCUS1MBEX4glo_"
MIME-Version: 1.0
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 01:57:35 -0000
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<mailto: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<mailto:internet-drafts@ietf.org> [internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>] Sent: Saturday, June 25, 2011 9:11 AM To: Shekh-Yusef, Rifaat (Rifaat) Cc: salvatore.loreto@ericsson.com<mailto:salvatore.loreto@ericsson.com>; Shekh-Yusef, Rifaat (Rifaat); gonzalo.camarillo@ericsson.com<mailto: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<mailto: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)