Re: [dispatch] Disaggregated Media in SIP

Paul Kyzivat <pkyzivat@cisco.com> Mon, 06 July 2009 20:45 UTC

Return-Path: <pkyzivat@cisco.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C39603A68A2 for <dispatch@core3.amsl.com>; Mon, 6 Jul 2009 13:45:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.59
X-Spam-Level:
X-Spam-Status: No, score=-6.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8+ZxvWJC2haT for <dispatch@core3.amsl.com>; Mon, 6 Jul 2009 13:45:00 -0700 (PDT)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 9E9273A67FF for <dispatch@ietf.org>; Mon, 6 Jul 2009 13:45:00 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.42,358,1243814400"; d="scan'208";a="49507487"
Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 06 Jul 2009 20:43:16 +0000
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n66KhGM3007368; Mon, 6 Jul 2009 16:43:16 -0400
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n66KhG5r010487; Mon, 6 Jul 2009 20:43:16 GMT
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Jul 2009 16:43:16 -0400
Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Jul 2009 16:43:16 -0400
Message-ID: <4A5261E2.4050506@cisco.com>
Date: Mon, 06 Jul 2009 16:43:14 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: Henry Sinnreich <hsinnrei@adobe.com>
References: <C6779E89.487E%hsinnrei@adobe.com>
In-Reply-To: <C6779E89.487E%hsinnrei@adobe.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
X-OriginalArrivalTime: 06 Jul 2009 20:43:16.0145 (UTC) FILETIME=[63412A10:01C9FE7A]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4055; t=1246912996; x=1247776996; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20<pkyzivat@cisco.com> |Subject:=20Re=3A=20[dispatch]=20Disaggregated=20Media=20in =20SIP |Sender:=20 |To:=20Henry=20Sinnreich=20<hsinnrei@adobe.com>; bh=9PpPVCF+aSWY5wtByYojorGzBHFlcM+9iLcn+NO+nuw=; b=qhPVGx6MIW3ZBLEJZXQShmhSp1XQX2k3xNrvBg28rJ3uN+aMF75vhI/V3w 4NuyNjGpHXutvLrnKRkkAOhkq9Lj62TehY0o12aB4I/KtyoGGa6TbhEiP0v/ 7QMgWo2z4a;
Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; );
Cc: "dispatch@ietf.org" <dispatch@ietf.org>
Subject: Re: [dispatch] Disaggregated Media in SIP
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Jul 2009 20:45:01 -0000

Henry Sinnreich wrote:
>>We've looked at various approaches to solve this important
>>problem several times before
> 
> Actually there is one more: IM-ing a URI to some resource, mentioned by 
> Henning Schulzrinne (I don’t recall the document or presentation).
> 
> My two cents is that IM-ing a URL is the most general solution, or is it?

Past suggestions by various people to send control signals (intended to 
be acted upon by automata rather than people) via IM have generally been 
rejected as inappropriate. (The exception so far has been file transfer, 
which has some control behavior and some expected human interaction.)

Now if you just want to say "Bob, please make a video call to 
sip:alice_camera@alice.com in order to see me" then I guess IM is ok. 
But IMO its not otherwise good. Its just a hack.

	Thanks,
	Paul

> Henry
> 
> 
> On 7/6/09 12:07 PM, "Francois Audet" <audet@nortel.com> wrote:
> 
>     I'm glad to see this topic coming back.
> 
>     I see that this draft doesn't propose a solution to problem: it list
>     three options, and describes why they are not adequate. I agree with
>     the conclusions.
> 
>     We've looked at various approaches to solve this important problem
>     several times before:
> 
>     - Feature ref (refer to urn: indicating specific features)
>       http://tools.ietf.org/html/draft-audet-sipping-feature-ref-00
> 
>     - Remote control using REFER to requests & responses
>       http://tools.ietf.org/html/draft-mahy-sip-remote-cc-05
>       (Also, versions -04, -03,-02, -00)
> 
>     - Remore control using REFER with XML body describing function
>       http://tools.ietf.org/html/draft-mahy-sip-remote-cc-01
> 
>     - Remote control using MBUS
>       http://tools.ietf.org/html/draft-mahy-mmusic-mbus-remotecc-01 &
>       http://tools.ietf.org/html/draft-mahy-mmusic-mbus-sdp-01
> 
>     On top of that there are various proprietary mechanisms, and even
>     some legacy
>     PBX-CTI protocols.
> 
>     >  -----Original Message-----
>     >  From: dispatch-bounces@ietf.org
>     >  [mailto:dispatch-bounces@ietf.org] On Behalf Of Salvatore Loreto
>     >  Sent: Monday, July 06, 2009 09:33
>     >  To: dispatch@ietf.org
>     >  Subject: [dispatch] Disaggregated Media in SIP
>     >
>     >  Hi there,
>     >
>     >  I have just submitted a draft that talks of Disaggregated
>     >  Media in the Session Initiation Protocol (SIP).
>     >  http://www.ietf.org/internet-drafts/draft-loreto-dispatch-disa
>     ggregated-media-00.txt
>     >
>     >
>     >  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.
>     >
>     >
>     >  cheers
>     >  Sal
>     >  _______________________________________________
>     >  dispatch mailing list
>     >  dispatch@ietf.org
>     >  https://www.ietf.org/mailman/listinfo/dispatch
>     >
>     _______________________________________________
>     dispatch mailing list
>     dispatch@ietf.org
>     https://www.ietf.org/mailman/listinfo/dispatch
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch