Subject: [Sipping] RE: [MMUSIC] Re: [Sip] Appropriate usage of SIP and RTSP

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 11 Jul 2003 10:50:16 -0400

<I moved this thread off of sip/mmusic to sipping>
Yeah, except there is no media.

This does point out, however, the issue of whether KPML is the
way to go for these kinds of problems.   In both vmail and
FECC, the abstraction is very clear, the UI less so. For the
"server" to decide which buttons IMHO is not correct.  You
should describe the control abstraction, and let the end device
UI designer decide how best to implement that abstraction, based
on the capabilities and design guidelines of the device.

Brian

> -----Original Message-----
> From: Cullen Jennings [mailto:[email-masked]]
> Sent: Friday, July 11, 2003 10:16 AM
> To: Brian Rosen; 'Yutaka Takeda'; [email-masked]; [email-masked]
> Subject: Re: [MMUSIC] Re: [Sip] Appropriate usage of SIP and RTSP
> 
> 
> 
> In many ways, this problem is similar to the far end camera 
> control issues.
> Real time responses is needed, It is a 1:1 relationship between the
> controller and controlee, the control protocol needs to be extensible.
> 
> On 7/9/03 11:40, "Rosen, Brian" <[email-masked]> wrote:
> 
> > I've been thinking for a long time about what an appropriate
> > mechanism to provide a voice/videomail client on a sipphone
> > would be.  It's really clear that you record and play messages
> > with VCR like functionality.  For that, you need start/stop/pause/
> > rewind/fast forward, and so I was thinking RTSP.  On the other
> > hand, you surely establish the session to the voicemail server
> > with a sip call.
> > 
> > Thus, I like the way Jonathan is thinking, but you also need
> > message selection/creation/deletion functions, and for those
> > I was thinking KPML, and then you wonder if you just use that
> > as the signalling mechanism for the record/play, and I get
> > confused.
> > 
> > Brian
> > 
> >> -----Original Message-----
> >> From: Yutaka Takeda [mailto:[email-masked]]
> >> Sent: Wednesday, July 09, 2003 2:11 PM
> >> To: [email-masked]; [email-masked]
> >> Subject: RE: [MMUSIC] Re: [Sip] Appropriate usage of SIP and RTSP
> >> 
> >> 
> >> The applications that have need for SIP and RTSP features I
> >> can imagine are:
> >> 
> >> - Voice&video mail (similar to 'sipum' but VM server is in
> >> the SIP phone)
> >> - Personal broadcast station from my PC at home.
> >> - Watching video recorded with VCR at home or office from remote...
> >> 
> >> What I am not sure is if RTSP has any solution or a framework for a
> >> RTSP server behind a NAT. If not, the solution is likely to
> >> be a repeat
> >> of what SIP provides. I thought TURN could be used in order
> >> for signaling
> >> message to reach RTSP server behind a NAT, but I noticed that
> >> it is not 
> >> applicable (purposefully) for a server running behind a 
> NAT because of
> >> a security consideration. Lots of issues for RTSP in this 
> area alone?
> >> 
> >> I believe a lot of people are interested in this discussion.
> >> 
> >> Best regards,
> >> Yutaka
> >> 
> >> 
> >>> -----Original Message-----
> >>> From: Magnus Westerlund [mailto:[email-masked]]
> >>> Sent: Wednesday, July 09, 2003 5:53 AM
> >>> To: Pianigiani, Jacopo (Jacopo)
> >>> Cc: [email-masked]; [email-masked]
> >>> Subject: [MMUSIC] Re: [Sip] Appropriate usage of SIP and RTSP
> >>> 
> >>> 
> >>> Hi,
> >>> 
> >>> When it comes to IMS and 3G terminals, most will already
> >>> before having 
> >>> an IMS functionality have support for PSS. PSS is
> >>> Packet-based Streaming
> >>> Service which is an umbrella kind of standard for 
> streaming service
> >>> defined in 3GPP targeted at low bit-rates and mobile networks.
> >>> Specification available from Rel 4 in TS 26.233 and TS
> >>> 26.234. Already
> >>> today there exist GSM/GPRS phones that has a PSS client.
> >>> 
> >>> So I think that dual stack implementations will not be that
> >>> impossible 
> >>> to foresee.
> >>> 
> >>> However I think the main issue in this discussion is to
> >> look at what 
> >>> applications that has need for SIP-RTSP interactions. Based
> >>> on this we 
> >>> can see if there is solutions easily available or not.
> >>> 
> >>> I can agree with Rosenberg that if we where going to design a RTSP
> >>> functionality protocol today, looking at SIP for session
> >>> establishment 
> >>> would be interesting. However that opportunity has passed
> >> as RTSP has 
> >>> started to be deployed in increasing numbers. I think even
> >> the latest 
> >>> Windows media player does support RTSP.
> >>> 
> >>> 
> >>> Best Regards
> >>> 
> >>> Magnus Westerlund
> >>> 
> >>> 
> >>> Pianigiani, Jacopo (Jacopo) wrote:
> >>>> Hello all,
> >>>> In my undertanding RTSP is suitable for broadcast, unicast
> >>> or multicast streams distribution. The RTSP protocol was
> >>> ideated for typical content delivery, and in effect for this
> >>> application could be more than suitable. But referring to an
> >>> IMS domain, in my point of view adopting RSTP as media
> >>> streams control, would imply adopting at least a double
> >>> protocol stack in the terminal equipment. The IMS concept was
> >>> mainly driven by the concept - in my understanding - of
> >>> simplifying the terminal (making it simpler from a protocol
> >>> stack implementation means lowering costs and increasing
> >>> penetration on the market) by adopting a single protocol
> >>> stack in the terminal, and having the RAN and the core
> >>> evolving toward a unified transport mechanism for which an
> >>> almost unified level of control on the network resources
> >>> allocated to a session (whatever session we refer to, voice ,
> >>> multimedia p-t-t call, web browsing, multimedia session with
> >>> voice call and dynamic web pages).
> >>>> So in this sense, my understanding is that the RTSP could
> >>> be suitable for media content, but it would imply again new
> >>> complexity on the IMS UMTS/CDMA terminal itself, which is
> >>> against the idea of IMS of enhancing the services the user
> >>> can access by having an homogeneous protocol stack on the
> >>> terminal itself for all types of services.
> >>>> 
> >>>> After all, the RTSP , apart from content delivery (of
> >>> streams), could not definitely handle appropriately sessions
> >>> like Voice calls + Interactive Web Pages.
> >>>> Regards
> >>>> 
> >>>> Jacopo Pianigiani
> >>>> Lucent Technologies - Italy
> >>>> è39 335 7350536
> >>>> 
> >>>> -----Original Message-----
> >>>> From: Paolo Asprino [mailto:[email-masked]]
> >>>> Sent: Wednesday, July 09, 2003 9:40 AM
> >>>> To: NAKAMURA, Hidefumi; [email-masked]; [email-masked]
> >>>> Subject: Re: [Sip] Appropriate usage of SIP and RTSP
> >>>> 
> >>>> 
> >>>> Hi all
> >>>> 
> >>>> I'm thinking a solution to join SIP and RTSP in the 3G 
> IMS domain.
> >>>> In particular in the IMS, I think that to provide multilmedia
> >>>> service (i.e video on demand), one can estabilish a
> >>> subscription to the service by SIP and then activate the
> >>> service with RTSP by DIGEST autentication with the
> >>>> parameters exchanged early during the subscription
> >>> (username and password)
> >>>> 
> >>>> What do you think about that?
> >>>> 
> >>>> Best Regards 
> >>>> 
> >>>> ----- Original Message -----
> >>>> From: "NAKAMURA, Hidefumi" <[email-masked]>
> >>>> To: <[email-masked]>; <[email-masked]>
> >>>> Cc: <[email-masked]>
> >>>> Sent: Monday, July 07, 2003 9:49 AM
> >>>> Subject: [Sip] Appropriate usage of SIP and RTSP
> >>>> 
> >>>> 
> >>>> 
> >>>>> Hi, all.
> >>>>> 
> >>>>> I have a question about the relationship between SIP and RTSP.
> >>>>> 
> >>>>> In RFC3261, there is a description that says
> >>>>>   "SIP is not a vertically integrated communications
> >>> system.  SIP is
> >>>>>   rather a component that can be used with other IETF
> >> protocols to
> >>>>>   build a complete multimedia architecture.  Typically, these
> >>>>>   architectures will include protocols such as the
> >>> Real-time Transport
> >>>>>   Protocol (RTP) (RFC 1889 [28]) for transporting
> >>> real-time data and
> >>>>>   providing QoS feedback, the Real-Time streaming protocol
> >>> (RTSP) (RFC
> >>>>>   2326 [29]) for controlling delivery of streaming media, ..."
> >>>>>   (RFC3261 Section 2)
> >>>>> 
> >>>>> However, my understanding is that both SIP and RTSP have
> >>> the capability
> >>>>> for "discovery of UAs or media streams."
> >>>>> If I use SIP to establish a stream session and use RTSP 
> to control
> >>>>> the stream, there will be redundant sequences, i.e.
> >>> INVITE-OK-ACK and
> >>>>> SETUP-OK.
> >>>>> 
> >>>>> Was there any discussion on how to use these two protocols
> >>> appropriately?
> >>>>> 
> >>>>> With SIP application server, network providers can 
> provide various
> >>>>> services on contents delivery while we will not be able to
> >>> do so only
> >>>>> with RTSP, I think.  On the other hand, RTSP has enough
> >>> capability for
> >>>>> discovery of media streams and for negotiation of SDPs.
> >>>>> So, I think, for the simple delivery of contents, RTSP is
> >>> appropriate to
> >>>>> use, and for various session control services regarding contents
> >>>>> delivery, SIP with RTSP is appropriate to use.
> >>>>> 
> >>>>> Any opinions?
> >>>>> 
> >>>>> I wonder why no contents delivery server seems to prepare
> >>> SIP stack now. 
> >>>>> Is it because, up to now, there exists only a simple
> >>> contents delivery
> >>>>> service?
> >>>>> 
> >>>>> best regards,
> >>>>> 
> >>>>> -- 
> >>>>> NAKAMURA, Hidefumi
> >>>>> NTT ServiceIntegration /NetworkServiceSystems Labs.
> >>>>> tel: +81(422)59 3904; fax:+81(422)60 4012
> >>>>> ---
> >>>>> 
> >>>>> 
> >>>>> 
> >>>>> _______________________________________________
> >>>>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> >>>>> This list is for NEW development of the core SIP Protocol
> >>>>> Use [email-masked] for questions on 
> current sip
> >>>>> Use [email-masked] for new developments on the
> >> application of sip
> >>>>> 
> >>>> 
> >>>> 
> >>>> 
> >>>> ---
> >>>> Outgoing mail is certified Virus Free.
> >>>> Checked by AVG anti-virus system (http://www.grisoft.com).
> >>>> Version: 6.0.495 / Virus Database: 294 - Release Date:
> >>> 30/06/2003J*fj)bz    b²Øm¶>?ÿ> > >
0Ö'~Sàþf¢-f§þX¬¶)ß£û"¥8b²X¬¶+¢³DY×¯
> >>> zZ)(tm)éí¡ûayÊ+y">º-¡Ê%RÇ¬S~¦¦W¦z{h®Ç,r?n(tm)¸syÛY¢º®zËb¢{(Ë«
> >>> éí²*T±ë"¦~§''~Sà~Sç{^½éh¦g§¶Ê'¶s¦(tm)bq«b¢z
> >>>> 
> >>>> _______________________________________________
> >>>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> >>>> This list is for NEW development of the core SIP Protocol
> >>>> Use [email-masked] for questions on current sip
> >>>> Use [email-masked] for new developments on the
> >> application of sip
> >>>> 
> >>> 
> >>> 
> >>> -- 
> >>> 
> >>> Magnus Westerlund
> >>> 
> >>> Multimedia Technologies, Ericsson Research EAB/TVA/A
> >>> 
> >> 
> ----------------------------------------------------------------------
> >>> Ericsson AB                | Phone +46 8 4048287
> >>> Torshamsgatan 23           | Fax   +46 8 7575550
> >>> S-164 80 Stockholm, Sweden | mailto: 
> [email-masked]
> >>> 
> >>> 
> >>> _______________________________________________
> >>> mmusic mailing list
> >>> [email-masked]
> >>> https://www1.ietf.org/mailman/listinfo/mmusic
> >>> 
> >> 
> >> _______________________________________________
> >> mmusic mailing list
> >> [email-masked]
> >> https://www1.ietf.org/mailman/listinfo/mmusic
> >> 
> > 
> > _______________________________________________
> > mmusic mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/mmusic
> > 
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 16 Jul 2003 19:29:29 -0400

> on the capabilities and design guidelines of the device.

That would argue against a stimulus approach (i.e., KPML or HTML). I'm 
inclined to agree, and the fact that folks created a protocol to 
control streaming, and that these clients are not web clients, means 
others agree too.

Mike asked:
> Hmm. I'd always thought of SIP as a rendezvous
> protocol so this seems perfectly natural to me.
> Is the general problem here that the SDP
> announcement for an RTSP controlled session isn't
> defined? 

Thats part of it. The other part is that RTSP wasn't meant to be used 
as a control protocol in a session setup by someone else. So, its not 
entirely clear to me how to use RTSP in this way. Much of my confusion 
stems around naming and session identification issues, which are done 
differently in SIP and RTSP.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com