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