Re: [dispatch] Disaggregated Media in SIP
"Francois Audet" <audet@nortel.com> Tue, 07 July 2009 16:31 UTC
Return-Path: <AUDET@nortel.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 A154128C501 for <dispatch@core3.amsl.com>; Tue, 7 Jul 2009 09:31:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.086
X-Spam-Level:
X-Spam-Status: No, score=-5.086 tagged_above=-999 required=5 tests=[AWL=-0.942, BAYES_00=-2.599, FRT_ADOBE2=2.455, 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 YevWEAvXnTLT for <dispatch@core3.amsl.com>; Tue, 7 Jul 2009 09:31:45 -0700 (PDT)
Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id DC51E28C4EF for <dispatch@ietf.org>; Tue, 7 Jul 2009 09:31:44 -0700 (PDT)
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n67FqCl01815; Tue, 7 Jul 2009 15:52:12 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 07 Jul 2009 10:51:57 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF1ED91E6B@zrc2hxm0.corp.nortel.com>
In-Reply-To: <C6780707.48F5%hsinnrei@adobe.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [dispatch] Disaggregated Media in SIP
thread-index: Acn+em+0BaLXNsLrTai84REw9nbCHwAHsoYnAABrlGAAAKd/zQAeV9IQ
References: <1ECE0EB50388174790F9694F77522CCF1ED91794@zrc2hxm0.corp.nortel.com> <C6780707.48F5%hsinnrei@adobe.com>
From: Francois Audet <audet@nortel.com>
To: Henry Sinnreich <hsinnrei@adobe.com>, Paul Kyzivat <pkyzivat@cisco.com>
Cc: 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: Tue, 07 Jul 2009 16:31:46 -0000
You asked for real-life data. I've seen many ways to achieve this type of "remote call control" functionality: 1 - Proprietary Master/Slave protocols This is similar to H.248, but proprietary. Specifically, when in "remote control mode", the device (e.g.., a phone) sees the UA (e.g. a PC client) as it's "PBX". In this mode, the Phone is not a SIP UA anymore in control mode. When control is relinquished, Phone re-SIPifies itself. 2 - CTI-like protocols Things like ECMA TR-87 (CSTA tunnelled over SIP). The two devices remain SIP UAs at all time, and attempt to "coordinate" their state. 3 - Layer 1/2 integration The device on the LAN is seen as a peripheral (i.e., remote speaker/ microphone/camera) to the device (e.g., PC) controlling it, when in control mode. Typically, this is USB or Bluetooth, or some emulation over Ethernet. Like number 1, the Phone is not a SIP UA anymore in control mode. When control is relinquished, Phone re-SIPifies itself. 4 - SIP extensions/B2BUA You can do a lot directly with SIP, if you have a B2BUA, but it is non-trivial. Number 3, and we don't need to standardized anything at IETF for this. I do not think that it is adequate for all applications, and a much more loosely coupled mechanism is what we would need for those applications. And by "loosely coupled", I really mean it: not media control. More like session sharing, where each UA ultimately retains control over their own destiny. Something akin to Feature Referal. It could be based on presence or other mechanisms. ________________________________ From: Henry Sinnreich [mailto:hsinnrei@adobe.com] Sent: Monday, July 06, 2009 17:55 To: Audet, Francois (SC100:3055); Paul Kyzivat Cc: Salvatore Loreto; dispatch@ietf.org Subject: Re: [dispatch] Disaggregated Media in SIP Francois Audet wrote: >spec and all of us in the Enterprise space have been trying to do for years. Now this makes sense. But still, can you share some data of its real life usage, as compared to what is out today in various SIP Communicators? That would rule our the person-to-person IM scenarios? >I don't think "other protocols" is a good answer: it has to be routable just like SIP. This again makes sense to me. (neglecting the facts about Jabber IM [such as in the IETF], Skype, etc.) Henry On 7/6/09 7:41 PM, "Francois Audet" <audet@nortel.com> wrote: I think what Paul calls automata is the application on the IM client, so that would undermine what this spec and all of us in the Enterprise space have been trying to do for years. I will note that the "istyping" indication is already done today with MESSAGE. And the istyping indicator is certainly an automata. And that is an RFC today, and is widly deployed. I personally don't really care if its a MESSAGE, a REFER, or an INFO (although we certainly can rule out MBUS). Or a new message. I don't think "other protocols" is a good answer: it has to be routable just like SIP. ________________________________ From: Henry Sinnreich [mailto:hsinnrei@adobe.com] Sent: Monday, July 06, 2009 17:24 To: Paul Kyzivat Cc: Audet, Francois (SC100:3055); Salvatore Loreto; dispatch@ietf.org Subject: Re: [dispatch] Disaggregated Media in SIP Paul Kyzivat wrote: >Past suggestions by various people to send control signals (intended tobe acted upon >by automata rather than >people) via IM have generally been >rejected as inappropriate. I am not sure how many people expect a usage scenario for IM with an automata in the middle or what the deployment statistics are for such automata (I have never encountered one). All SIP (or other protocol ) Communicator packages have IM and the URI works there very nicely. Do you have any usage statistics that justifies the assertion automata are the key usage scenario and "plain person to person" IM does not count? Henry On 7/6/09 3:43 PM, "Paul Kyzivat" <pkyzivat@cisco.com> wrote: 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
- [dispatch] Disaggregated Media in SIP Salvatore Loreto
- Re: [dispatch] Disaggregated Media in SIP Francois Audet
- Re: [dispatch] Disaggregated Media in SIP Francois Audet
- Re: [dispatch] Disaggregated Media in SIP Paul Kyzivat
- Re: [dispatch] Disaggregated Media in SIP Henry Sinnreich
- Re: [dispatch] Disaggregated Media in SIP Paul Kyzivat
- Re: [dispatch] Disaggregated Media in SIP Francois Audet
- Re: [dispatch] Disaggregated Media in SIP Henry Sinnreich
- Re: [dispatch] Disaggregated Media in SIP Henry Sinnreich
- Re: [dispatch] Disaggregated Media in SIP Paul Kyzivat
- Re: [dispatch] Disaggregated Media in SIP Paul Kyzivat
- Re: [dispatch] Disaggregated Media in SIP DRAGE, Keith (Keith)
- Re: [dispatch] Disaggregated Media in SIP Francois Audet
- Re: [dispatch] Disaggregated Media in SIP Francois Audet
- Re: [dispatch] Disaggregated Media in SIP Paul Kyzivat
- Re: [dispatch] Disaggregated Media in SIP Francois Audet
- Re: [dispatch] Disaggregated Media in SIP Paul Kyzivat
- Re: [dispatch] Disaggregated Media in SIP Francois Audet
- Re: [dispatch] Disaggregated Media in SIP Paul Kyzivat
- Re: [dispatch] Disaggregated Media in SIP Henry Sinnreich
- Re: [dispatch] Disaggregated Media in SIP Francois Audet
- Re: [dispatch] Disaggregated Media in SIP Paul Kyzivat
- Re: [dispatch] Disaggregated Media in SIP Elwell, John
- Re: [dispatch] Disaggregated Media in SIP Dale Worley
- Re: [dispatch] Disaggregated Media in SIP Salvatore Loreto
- Re: [dispatch] Disaggregated Media in SIP Gonzalo Camarillo
- Re: [dispatch] Disaggregated Media in SIP Salvatore Loreto
- Re: [dispatch] Disaggregated Media in SIP Paul Kyzivat
- Re: [dispatch] Disaggregated Media in SIP Paul Kyzivat
- Re: [dispatch] Disaggregated Media in SIP Gonzalo Camarillo
- Re: [dispatch] Disaggregated Media in SIP Elwell, John
- Re: [dispatch] Disaggregated Media in SIP Gonzalo Camarillo
- Re: [dispatch] Disaggregated Media in SIP Elwell, John
- Re: [dispatch] Disaggregated Media in SIP Gonzalo Camarillo
- Re: [dispatch] Disaggregated Media in SIP Francois Audet
- Re: [dispatch] Disaggregated Media in SIP Anders Kristensen
- Re: [dispatch] Disaggregated Media in SIP Francois Audet
- Re: [dispatch] Disaggregated Media in SIP Anders Kristensen
- Re: [dispatch] Disaggregated Media in SIP Gonzalo Camarillo
- Re: [dispatch] Disaggregated Media in SIP Francois Audet
- Re: [dispatch] Disaggregated Media in SIP Gonzalo Camarillo
- Re: [dispatch] Disaggregated Media in SIP Paul Kyzivat
- Re: [dispatch] Disaggregated Media in SIP Paul Kyzivat
- Re: [dispatch] Disaggregated Media in SIP Francois Audet
- Re: [dispatch] Disaggregated Media in SIP Gonzalo Camarillo
- Re: [dispatch] Disaggregated Media in SIP Paul Kyzivat
- Re: [dispatch] Disaggregated Media in SIP Francois Audet
- Re: [dispatch] Disaggregated Media in SIP Gonzalo Camarillo
- Re: [dispatch] Disaggregated Media in SIP Paul Kyzivat
- Re: [dispatch] Disaggregated Media in SIP Dale Worley
- Re: [dispatch] Disaggregated Media in SIP Gonzalo Camarillo
- Re: [dispatch] Disaggregated Media in SIP Salvatore Loreto
- Re: [dispatch] Disaggregated Media in SIP Paul Kyzivat
- Re: [dispatch] Disaggregated Media in SIP Gonzalo Camarillo
- Re: [dispatch] Disaggregated Media in SIP Paul Kyzivat
- Re: [dispatch] Disaggregated Media in SIP Gonzalo Camarillo
- Re: [dispatch] Disaggregated Media in SIP Salvatore Loreto
- Re: [dispatch] Disaggregated Media in SIP Paul Kyzivat
- Re: [dispatch] Disaggregated Media in SIP Gonzalo Camarillo