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

From: "Uzelac, Adam" <[email-masked]>
Date: Tue, 1 Nov 2005 12:21:01 -0500

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?

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: Jonathan Rosenberg <[email-masked]>
Date: Tue, 01 Nov 2005 14:11:36 -0500

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.

-- 
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: Magnus Westerlund <[email-masked]>
Date: Wed, 02 Nov 2005 10:09:28 +0100

Hi,

As the current editor of the RTSP update and also being involved in 
these discussion the last couple of years I do have some views.

First I think an updated RTSP specification is need. RTSP and its model 
is so well spread for certain applications to move to SIP and all its 
baggage. However for other usage SIP could provide a number of benefits.

So I think it will be necessary to get RTSP/2.0 out there as soon as 
possible. However there is a good possibility to start new work for a 
mechanism that uses SIP for media session and control session 
establishment. For that work I would not base it on RTSP, instead I 
would do an playback control addition to MRCP/2.0. MRCP is almost 
finished in SPEECHSC WG and provides a lot of the basic features you 
would need for having a well behaved playback control protocol. 
Including asynchronous messages upon completion of requests.

Cheers

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]

---

From: "Chris Steck" <[email-masked]>
Date: Tue, 1 Nov 2005 11:37:20 -0800

This sounds like a good BoF discussion for Vancouver if it's still possible
to get it on the agenda... 

-Chris

Chris Steck
Manager -Mobile Systems

RealNetworks
2601 Elliott Ave.
Seattle, WA USA 98121
Tel: +1.206.892.6885
Mobile/SMS: +1.206.849.3898
Email: [email-masked] 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Jonathan Rosenberg
Sent: Tuesday, November 01, 2005 11:12 AM
To: Uzelac, Adam
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: [MMUSIC] 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:

> 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
> 
> 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?
> 
> 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:
> 
> 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.
> 
> 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
> 

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: David R Oran <[email-masked]>
Date: Wed, 2 Nov 2005 09:16:29 -0500

> these discussion the last couple of years I do have some views.
Me too. I've worked on SIP for a long time and am traversing a crash  
learning course in entertainment video which has my head spininng (a  
bit, anyway).

> First I think an updated RTSP specification is need. RTSP and its  
> model is so well spread for certain applications to move to SIP and  
> all its baggage.
I agree. I think the SIP/IMS advocates are glossing over the (quite  
significant to me anyway) differences between content-oriented  
request routing and person-to-person rendezvous. I also suspect that  
when we peel the onion a bit more we will discover that the AAA  
requirements for streaming content access (which is called  
"entitlement processing" in the entertainment video world) are vastly  
different from what we see for AAA in the interpersonal- 
communications world, and that content placement (called "asset  
management" in the entertainment video world) is substantially  
different from contact registration in SIP.

> However for other usage SIP could provide a number of benefits.
>
I agree, especially for "source-based" streaming like webcams as  
opposed to "published content access" like last night's episode of  
"desperate Housewives".

> So I think it will be necessary to get RTSP/2.0 out there as soon  
> as possible. However there is a good possibility to start new work  
> for a mechanism that uses SIP for media session and control session  
> finished in SPEECHSC WG and provides a lot of the basic features  
> you would need for having a well behaved playback control protocol.  
Magnus is right. MRCP has nearly all the playback features needed,  
and a control structure that would allow content-based features as  
well as time-based features. For example, in MRCP you could say "skip  
to where Humphrey Bogarts says `play it again, Sam'". One of the  
things we struggled with in MRCP was the overlap with RTSP's data- 
phase control capabilities. There may be substantial benefit to  
looking at refactoring the boundaries among SIP, RTSP, and MRCP.

Regards, Dave Oran.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 06 Nov 2005 16:55:13 -0500

To be clear, I would not propose to stop or change RTSP/2.0 - that work 
should continue as there are customers for it.

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...

Thanks,
Jonathan R.

---

From: David R Oran <[email-masked]>
Date: Sun, 6 Nov 2005 18:27:39 -0500

On Nov 6, 2005, at 4:55 PM, Jonathan Rosenberg wrote:

> To be clear, I would not propose to stop or change RTSP/2.0 - that  
> work should continue as there are customers for it.
>
OK.

> 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.

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.

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).

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

Cheers, Dave.

> Thanks,
> Jonathan R.
>
> Magnus Westerlund wrote:
>
>> Hi,
>> As the current editor of the RTSP update and also being involved  
>> in these discussion the last couple of years I do have some views.
>> model is so well spread for certain applications to move to SIP  
>> and all its baggage. However for other usage SIP could provide a  
>> number of benefits.
>> for a mechanism that uses SIP for media session and control  
>> session establishment. For that work I would not base it on RTSP,  
>> instead I would do an playback control addition to MRCP/2.0. MRCP  
>> is almost finished in SPEECHSC WG and provides a lot of the basic  
>> features you would need for having a well behaved playback control  
>> protocol. Including asynchronous messages upon completion of  
>> requests.
>> Cheers
>> Magnus Westerlund

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 07 Nov 2005 09:45:44 -0500

David R Oran wrote:

> forward,rewind, and the current positioning schemata, while they  accept 
> time codes, aren't optimized for that (they are optimized for  

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.

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

> protocol layer (e.g. tons of SIP UA's are also HTTP clients, some are  

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  

Heh heh, true.

-Jonathan R.