Re: [dispatch] Disaggregated Media in SIP

[Paul Kyzivat <[e-mail]>]

Henry Sinnreich wrote:
> Paul,
> 
> This is getting interesting, so let’s see...
> 
>>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.
> 
> No matter what type of communicator we use: SIP, Skype, Jabber, iChat, 
> etc., most courteous people will first IM to ask if the other party can 
> speak right now or later. While talking, they may also chose to add 
> video. And if planned, also add desktop sharing.

I don't think that most people consider that to be required of courteous 
people. AFAIK most people with cell phones don't send an SMS first to 
ask "can I call you?"

I think this is more a matter of differences in opinion about what the 
preferred medium of communication is. For some people it is definitely 
voice, for others IM or email. So people who consider IM their preferred 
mode of conversation may well IM first and then "escalate to voice" if 
that seems justified. I do that. And currently it often involves IMing a 
phone number. But I would much rather simply have an "add voice" button 
on my IM client.

I think we are just starting to get to the point where multimedia 
communication is common enough that we need to develop an etiquette for 
using it:
- how do we indicate and enforce our preferences of media?
- is it polite to request to receive video without offering
   to send it?
- is it ok to initiate addition of another medium to a call
   without first negotiating its use person to person via the
   existing media?

> So the natural order of communications seems to be mostly:
> Presence (or the web conference URI), IM, voice, video, desktop sharing, 
> conferencing, but certainly it all starts with a URI for the rendezvous 
> function.

I think that is just *your* natural order. (And probably mine too.) But 
not for the world at large. For many the natural order is: voice, then 
SMS if the voice doesn't work.

As long as people endeavor to have one URI that works for all the media 
they support, then that is indeed the starting point.

> It seems we differ (or do we?) on three points:
> 
>    1. Communicator “calls” are not the poor mans choice,
>    2. It most often starts with presence and IM,
>    3. The URI (or Skype name) of the other party in the address book is
>       all that’s required. Or the social network as an address book.

I've answered above. IMO there is no one answer to this.

If everyone had presence on every communication device they use, then it 
would likely be a starting point when it provided useful info. But note 
that I am unlikely to ever have presence data about all the people I 
want to communicate with.

> Now leaving for a moment telephony aside, let’s look at some new usage 
> scenarios:
> 
>     * People in social networks (Twitter, Facebook, etc.)
>     * Telepresence (business)
>     * Digital living room (consumer)
> 
> It is a pretty safe guess that SIP PBX-style voice communications are 
> not the right model for these emerging scenarios. I guess even contact 
> centers for customer care may benefit from looking at the emerging Web 
> applications for communications and especially for sharing of documents 
> (having a URI).
> Don’t we often prefer to IM or email so as not to be tortured by IVR Hell?
> And even for voice, just to be called back by an agent?

As I noted earlier, we are in the very early stages of this because of 
the diversity of devices with varying capabilities. There currently is 
no least common denominator that is shared by all. The closest to one is 
probably still voice. And we still haven't converged the address spaces 
for these things. So its all very cumbersome.

I agree with you that there is a lot of room for progress in this space.

> Now if we could only outlaw “automata”   :-)

You can outlaw them for yourself. Personally I *like* automata that do 
useful services for me. Of note I very much like the automaton that 
answers voice calls, takes voice messages, and sends me an email with a 
text translation of the voice as well as the recorded audio.

The key is that it is an automaton that I have chosen to act as an agent 
on my behalf.

Maybe you don't want to talk to my automaton. That is fine. If you'd 
rather send me an email in the first place, that's fine too.

	Thanks,
	Paul

> Henry
> 
> 
> On 7/7/09 8:03 AM, "Paul Kyzivat" <[e-mail]> wrote:
> 
>     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" <[e-mail]> 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:[e-mail] 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" <[e-mail]> 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: [e-mail]
>     >      >      >  [mailto:[e-mail]] On Behalf Of
>     Salvatore
>     >      Loreto
>     >      >      >  Sent: Monday, July 06, 2009 09:33
>     >      >      >  To: [e-mail]
>     >      >      >  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
>     >      >      >  [e-mail]
>     >      >      >  https://www.ietf.org/mailman/listinfo/dispatch
>     >      >      >
>     >      >      _______________________________________________
>     >      >      dispatch mailing list
>     >      >      [e-mail]
>     >      >      https://www.ietf.org/mailman/listinfo/dispatch
>     >      >
>     >      >
>     >      >
>     >
>         ------------------------------------------------------------------------
>     >      >
>     >      >  _______________________________________________
>     >      >  dispatch mailing list
>     >      >  [e-mail]
>     >      >  https://www.ietf.org/mailman/listinfo/dispatch
>     >
>