Subject: [Sipping] What role (if any) for IMS/SIP in a Streaming Service: IMS/SIP - RTSP interworking

From: [email-masked]
Date: Tue, 1 Nov 2005 11:49:28 -0500

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 it). 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 TV?

At a minimum, IMS brings with it:

            - an authentication/authorization framework & assoc standards

            - 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 world?

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.  

Thanks,

-Steve

_______________________________________________
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: "Uzelac, Adam" <[email-masked]>
Date: Tue, 1 Nov 2005 14:50:54 -0500

Jonathan,

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.

Adam

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]] 
Sent: Tuesday, November 01, 2005 2:12 PM
To: Uzelac, Adam
Cc: [email-masked]; [email-masked]; [email-masked]
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
with SIP.

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,
Jonathan R.

Uzelac, Adam wrote:

> Steven,
> 
> 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.
> 
> Adam
> 
> ________________________________
> 
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: Tuesday, November 01, 2005 11:49 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> 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
it).
> 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
TV?
> 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
world?
> 
> 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.
> 
> 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.
> 
> Thanks,
> 
> -Steve
> 
> 
> 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
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: [email-masked]
Date: Tue, 1 Nov 2005 15:27:03 -0500

Adam,
Thanks for the reply.

Ironically, it's the features of IMS (or shall I say the 'infrastucture
services' that I get with IMS) that drive me toward wanting to use a
SIP/IMS solution for a streaming service. 

SIP in it's pure form doesn't mandate a common approach to authentication,
authorization, user-profiles, accounting, network resource management,
etc. It's the IMS architecture -- and all its elaborations -- that
*promise* this framework for delivering IP Multimedia services. It's the
infrastructure services that come with the IMS framework I want to reuse
for a video streaming service. But, to a very large degree, IMS is based
on SIP. Hence my question. So I don't see it really so much of a SIP vs
RTSP question. If it were just SIP vs RTSP, I'd just use RTSP. But when
you put it into the broader context of IMS and a 'converged services
architecture', then the question is more interesting.

-Steve

-----Original Message-----
From: Uzelac, Adam [mailto:[email-masked]] 
Sent: Tuesday, November 01, 2005 12:21 PM
To: Steven D. Whitehead; [email-masked]; [email-masked]
Subject: RE: [Sipping] What role (if any) for IMS/SIP in a Streaming
Service: IMS/SIP - RTSP interworking

Steven,

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.

Adam 

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 it).
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 TV?

            - an authentication/authorization framework & assoc
standards

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 world?

Here's the problem:

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.

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?

Thanks,

-Steve

---

From: [email-masked]
Date: Tue, 1 Nov 2005 15:57:15 -0500

Pascal, 

Thanks for the pointer. I agree it'd be useful to work towards a consensus
around this topic. And I think it's necessary to have input from members
of the organizations you mentioned. 

ISMA may well be the right venue. But I'm relatively new to this domain so
I don't have a strong opinion. It seems like relevant IETF WGs would also
be a natural venue.

-Steve

---

From: [email-masked]
Date: Tue, 1 Nov 2005 16:48:02 -0500

I had been thinking along the same lines as the approach Jonathan
articulated: Use SIP to initiate a "session" which include a) one or more
media-streams and b) a media control stream (RTSP). 

If such a model were followed, I wonder though if RTSP could be used in a
way that would allow for its own SETUP phase to be bypassed, moving
straight into a READY Phase, where the client could just "start" the
stream(s). 

That'd be desirable since it would eliminate a second (largely redundant)
session SETUP exchange. In order for that to happen though, the SIP-based
exchange would need to provide a means for transferring or otherwise
synchronizing the RTSP session-id value(s). Perhaps the media-stream
session-ids could be returned as part of the SIP offer/answer SDP.

A "Purely" SIP-based approach would be interesting to consider, though I
hadn't thought of that. My reluctance to a purely sip-based solution was
for fear of adding application-level signaling to SIP. Where do you draw
the line or stop? What about gaming or other apps that have a
session-orientation, but application specific signaling? It'd be
interesting to hear how a PURELY SIP-based solution would work, especially
if it could be done via some kind of clean extension mechanism. 

As an aside: It seems some of the recent SDP drafts related to key
management could be used to exchange the necessary info to protect both
the media and media-control streams. So that could dovetail in nicely.

-Steve

-----Original Message-----
From: Uzelac, Adam [mailto:[email-masked]] 
Sent: Tuesday, November 01, 2005 2:51 PM
To: Jonathan Rosenberg
Cc: Steven D. Whitehead; [email-masked]; [email-masked]
Subject: RE: [Sipping] What role (if any) for IMS/SIP in a Streaming
Service: IMS/SIP - RTSP interworking

Jonathan,

Adam

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]] 
Sent: Tuesday, November 01, 2005 2:12 PM
To: Uzelac, Adam
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Sipping] What role (if any) for IMS/SIP in a Streaming
Service: IMS/SIP - RTSP interworking

My two cents,
Jonathan R.

it).
TV?
world?

---

From: [email-masked]
Date: Mon, 7 Nov 2005 10:35:52 -0500

I'll confirm Jonathan's hypothesis. My main motivation for using SIP to
support streaming-media sessions, was the possibility of *infrastructure
re-use*. And honestly, IMS was squarely in my sight. Areas for potential
reuse I see in this regard are:
	- User Authentication & Authorization mechanisms 
	- Network Resource Management mechanisms (e.g, the PDF/RACF
entities in IMS/NGN)
	- Accounting mechanisms

As Jonathan noted, these mechanisms are (or will be) built into SIP
servers. Being able to re-use them for streaming-services as well as
conversational services could simplify the network design & operation.

I find the Network Resource Management aspect particularly interesting.
Ironically, I don't see the PDF/RACS functions as a means of enforcing a
walled-garden (personally, I think these gardens are doomed), but rather
as a means of allowing a carrier to provision the network resources needed
to insure sufficient QOS as streams traverse the network. Moreover as
voice-traffic gets lost in the noise, I see video traffic (conversational
and streaming) as the primary driver for this type of QOS capability. 

The other items Jonathan mentioned, too, are good reasons to consider SIP
as a common session signaling protocol. 

I'd say it's definitely worth exploring. An alternative answer may be to
get reuse at a layer below the signaling protocol (e.g., try to re-use
PDF/RACS, Accounting, Auth & Auth) infrastructure without re-using the
signaling protocol. But alas, this seems less likely to me, especially in
the AAA areas. 

-Steve

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]] 
Sent: Monday, November 07, 2005 9:46 AM
To: David R Oran
Cc: Magnus Westerlund; Steven D. Whitehead; Uzelac, Adam;
[email-masked]; [email-masked]
Subject: Re: [Sipping] What role (if any) for IMS/SIP in a Streaming
Service: IMS/SIP - RTSP interworking

David R Oran wrote:

>> There appears to ALSO be interest in a direction that converges  with 
>> SIP. I hadn't thought about MRCP for the control parts; I'll  need to 
>> consider that some more...
>>
> Well, MRCP isn't ideal either, because it has tons of baggage that  
> isn't necessary if all you want to do is play/pause,fast- 
> forward,rewind, and the current positioning schemata, while they  accept

> time codes, aren't optimized for that (they are optimized for  
> positioning inside a markup.

OK. I'm not really familiar with MRCP. Eric also commented that it 
wasn't a great match. If neither of you think its a match it probably
isnt.

> 
> One idea I don't particularly like is to use SIP to set up RTSP  
> sessions, with some modified state machines fo bypass the describe/ 
> setup phases and just use it for in-session control.

That is more or less what I had in mind. Why don't you like that?

> 
> We can certainly explore the problem space together. I think our  
> starting point ought to be an enumeration of "what's to be gained" in  
> converging the protocols, since lots of applications simultaneously  
> emit multiple protocols and coordinate state above the signaling  
> protocol layer (e.g. tons of SIP UA's are also HTTP clients, some are  
> also HTTP servers).

I agree, working on the benefits is the first goal. I think there are 
really several classes of benefits:

1. Protocol reuse: SIP has developed many (perhaps too many) 
capabilities in session setup and management, many of which can be used 
for streaming media controls. These come in especially handy with end 
user content. Examples include ICE, preconditions, etc.

2. Infrastructure reuse: SIP servers have developed lots of features 
over the years, providing functions that can be used for streaming 
services too. I think this is what Steven was referring to about reuse 
of IMS infrastructure.

3. Use Case convergence: Certain use cases blur the line between 
streaming and conversational media. These include connecting to end user 
content, converting a streaming session to conversational, and so on.

> 
> There's a reason why layer 7 isn't at the narrow waist of the  
> hourglass....

Heh heh, true.

-Jonathan R.