Re: [dispatch] Disaggregated Media in SIP

Henry Sinnreich wrote:
> 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

I don't know of one either.

But my observation is about using the IM message as a solution to the 
kinds of use cases that were presented in the draft, at least as I 
imagine them playing out.

My mental model is of an environment where a significant fraction of 
people have multimedia UAs, and an expectation that those various media 
will be available in calls that they make. Now add to that people who 
have support for various media, but not in a single device. They then 
want to play in that same multimedia environment.

In such a case, using IMs between people, so that they may establish 
separate calls for various media is clearly the poor man's choice - 
better than nothing but not ideal. And its especially poor if the 
"initial" call is not an IM call. Then just establishing an IM channel 
between the same two people is non-trivial.

	Thanks,
	Paul

> 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
> 