Re: [dispatch] Disaggregated Media in SIP

[Henry Sinnreich <[e-mail]>]

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" <[e-mail]> 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:[e-mail]]
Sent: Monday, July 06, 2009  17:24
To: Paul Kyzivat
Cc: Audet, Francois (SC100:3055);  Salvatore Loreto; [e-mail]
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"  <[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