Re: [dispatch] Disaggregated Media in SIP

["DRAGE, Keith (Keith)" <[e-mail]>]

I understood the key distinction for MESSAGE method contents was not what generated it, but how it was treated on reception. The prime use of the MESSAGE method was where the contents were rendered to the user (even if they are generated by something that is an automata). If the contents were to be understood by some automata, then PUBLISH or SUBSCRIBE / NOTIFY may be more appropriate, or if there is an INVITE dialog around that pertains to the communication, then something else.

Hopever the multiple methods for similar purposes discussion in SIP never really resolved itself so I would say there is no definitive answer to this.

regards

Keith

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Paul Kyzivat
> Sent: Tuesday, July 07, 2009 2:09 PM
> To: Francois Audet
> Cc: Henry Sinnreich; [e-mail]
> Subject: Re: [dispatch] Disaggregated Media in SIP
> 
> 
> 
> Francois Audet 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.
> 
> It is not something that is clear cut. I can make a case for 
> istyping - it is indeed a message intended for human eyes, it 
> is just encoded differently from plain text so that the 
> receiving application has more options in rendering it. In 
> that respect it isn't so different from html.
> 
> > 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 still remain unconvinced that it is either necessary or 
> appropriate for one end of a call to be involved in how the 
> other end aggregates media resources for the call.
> 
> 	Thanks,
> 	Paul
> 
> > 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
> > 
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch
>