RE: What role (if any) for IMS/SIP in a Streaming Service: IMS/SIP - RTSP interworking
Uzelac, Adam <Adam.Uzelac <at> globalcrossing.com>
2005-11-01 19:50:54 GMT
I agree with all that you say, and while you point out the fuzzy
distinction, I was thinking about the play/rewind/fast-forward options I
have on my v-mail system that are enabled through SIP/DTMF. Without
knowing all the particulars of RTSP, I can't formulate a complete
argument. It indeed seems fuzzy, the distinction between the two.
From: Jonathan Rosenberg [mailto:jdrosen <at> cisco.com]
Sent: Tuesday, November 01, 2005 2:12 PM
To: Uzelac, Adam
Cc: steven.d.whitehead <at> verizon.com; mmusic <at> ietf.org; sipping <at> ietf.org
Subject: Re: [Sipping] What role (if any) for IMS/SIP in a Streaming
Service: IMS/SIP - RTSP interworking
This topic (RTSP/SIP convergence) has come up periodically over the
years. Here is my own two cents.
RTSP really does several things. One of them is the establishment of a
media session for delivery of streaming media. Another is the control of
such a streaming session once set up. Over the years, SIP has
accumulated many features for setting up and managing sessions - nat
traversal, preconditions, offer/answer, etc., all of which are
applicable to a streaming media session too. SIP, however, does not do
the control parts of RTSP (play, rewind, Fast-forward).
The right convergence model in my mind is that SIP is used to setup a
streaming session, and as part of the SDP exchange, one of the "media
streams" that gets established is a control channel. This control
channel is actually RTSP itself, used to control the media stream set up
One of the reasons I like this model is that the line between streaming
media and real time media is getting very fuzzy. If I have a camera in
my house that is showing a continuous picture of the activity in my
foyer (typical security type of application), and I connect to it, is
that streaming media or one-way video conferencing? Hard to tell.
Indeed, if you think that, over time, content will move to the edges,
such that I can find and connect to home movies and images stored at
someones home, then many of the rendezvous and call routing features of
SIP start to become applicable to streaming media applications.
My two cents,
Uzelac, Adam wrote:
> Should RTSP be understood as a control protocol for initiating and
> directing delivery of streaming multimedia from media servers, or
> other sources, then the question is can SIP meet the required
> functions for streaming applications. The focus should be on SIP,
> instead of IMS. If control functionality (pause, fast forward,
> reverse, absolute
> positioning) can be offered by SIP, then it could be argued that
> SIP/IMS is an option without RTSP. If it can't be done via SIP, which
> would surprise me, then some tunneling or mapping or RTSP to SIP
> functions might be an option. Either way it's SIP, not IMS that's
> pertinent here
> - IMO.
> From: sipping-bounces <at> ietf.org [mailto:sipping-bounces <at> ietf.org] On
> Behalf Of steven.d.whitehead <at> verizon.com
> Sent: Tuesday, November 01, 2005 11:49 AM
> To: mmusic <at> ietf.org; sipping <at> ietf.org
> Cc: steven.d.whitehead <at> verizon.com
> Subject: [Sipping] What role (if any) for IMS/SIP in a Streaming
> Service: IMS/SIP - RTSP interworking
> Is there a prevailing view in the IETF/SIP/MMUSIC community on what
> role (if any) IMS/SIP should play in a NGN (Video) Streaming Services
> architecture? Or alternatively, how should IMS/SIP interwork (if at
> all) with RTSP for streaming services in an NGN architecture?
> Most discussions of Streaming Services use RTSP as the signaling
> protocol (e.g., 3GPP's PSS architecture). But RTSP alone dosen't bring
> with it all the supporting infrastructure that IMS does (nor should
> Because IMS is SIP-based, and becuse SIP is oriented toward
> "interactive communication" services, does that preclude IMS from
> being used for streaming services like video on demand or pay-per-view
> At a minimum, IMS brings with it:
> - an authentication/authorization framework & assoc
> - an accounting framework & assoc standards
> - a network resource management scheme (at least for QOS
> authorization & CAC)
> - and of course a session setup/management protocol
> If I want to deploy a commercial VOD service, I'd like support for
> this functionality as well. If I'm designing a 'next-generation'
> services architecture, a logical question is: Can I use my IMS
> infrastrcture for my "communication" services as well as my
> "streaming" services? And if so how? How does RTSP fit into an IMS
> Here's the problem:
> IMS alone, isn't enough for Streaming services, because I
> need a stream control protocol (RTSP) to provide start, pause, skip,
> stop, etc control. RTSP alone isn't sufficient because I need
> infrastructure for authentication, authorization, accounting, resource
> management, etc. (Stuff I get with IMS).
> A combination of IMS/RTSP seems like it could be made to work, but
> there appears to be overlap in the session setup-signaling. In the
> most straightforard approach you could for example first use SIP to
> establish a session between a client and server -- exchanging SDP that
> describes the media streams AND the control stream (rtsp), then
> followup with an RTSP session that again proceeds through the "setup
> phase" and on to playing and media control. The redundancy is in the
> duplication of the "session setup" that occurs.
> Is there a consensus view on if/how these two should interwork? Am I
> barking up the wrong tree here? Just totally confused?
> One approach that appeals to me is to use IMS/SIP to establish the
> session (and all is associated baggage -- AAA, resource management,
> media negotiation) and then use RTSP as a kind of "application layer"
> control protocol that would be used to manage the media stream (but
> not necessarily be used to set it up, since IMS would have already
> done that). A similar type of two layer control design might also make
> sense for gaming applications.
> Thoughts? Insights?
> My apologies if this question is well known by all but me, but alas
> I've found scant discussion of it on the web and in recent mailing
> list archives -- perhaps I'm looking in the wrong place.
> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP Use
> sip-implementors <at> cs.columbia.edu for questions on current sip Use
> sip <at> ietf.org for new developments of core SIP
Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza
Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711
jdrosen <at> cisco.com FAX: (973) 952-5050
http://www.jdrosen.net PHONE: (973) 952-5000
Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP