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

From: "Pascal Dore" <[email-masked]>
Date: Tue, 1 Nov 2005 13:34:18 -0500

Hi Steven,

Maybe this link could be interesting to look:

Internet Streaming Media Alliance:

http://www.isma.tv/ <http://www.isma.tv/> 

I think there is a need for a partnership between IETF, 3GPP, Packet
Cable 2.0 effort and ISMA for that particuliar service definition of
Content-On-Demand.  Same kind of work that have been done to define the
IMS architecture. ISMA could be the place to drive this requirement (NGN
Streaming Services Architecture) with links to other working groups.

- Pascal.D

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: 1 novembre 2005 11:49
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: "Henry Sinnreich" <[email-masked]>
Date: Wed, 2 Nov 2005 11:17:05 -0600

Since the IETF works for the _OPEN_ Internet, there seems to be no rationale
in a partnership with organizations that promote walled gardens, such as
3GPP or Packet Cable. Closed systems can deploy anything they want.

It would be regrettable IMHO if the IETF would legitimize walled gardens in
any shape or form, since they are the very opposite of the Internet. There
is no way to gloss over this fact.

Thanks, Henry

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Pascal Dore
Sent: Tuesday, November 01, 2005 12:34 PM
To: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Sipping] What role (if any) for IMS/SIP in a Streaming
Service:IMS/SIP - RTSP interworking

Hi Steven,

 <http://www.isma.tv/> http://www.isma.tv/

I think there is a need for a partnership between IETF, 3GPP, Packet Cable
2.0 effort and ISMA for that particuliar service definition of
Content-On-Demand.  Same kind of work that have been done to define the IMS
architecture. ISMA could be the place to drive this requirement (NGN
Streaming Services Architecture) with links to other working groups.

- Pascal.D

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: 1 novembre 2005 11:49
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?

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

            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

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 03 Nov 2005 10:27:13 +0100

Hi Henry,

Packet-based Streaming Service (PSS) which is defined by 3GPP SA4 WG has 
a model that isn't related to a walled garden at all. The intention of 
that work is to allow RTSP streaming clients to use content both in the 
operators service network and on the Internet.

In fact the whole solution is based on very minor sub-setting of RTSP 
and with a well defined set of codecs. It does provide some more 
features in the later releases, like bit-rate adaptation, Quality of 
Experience reporting, possibility to serve DRM handled content.

The basic idea was to ensure that there was a description of how RTSP 
based streaming can be done to mobile phones and which can be 
implemented with in the restrictions the mobile phone provides. The goal 
is interoperability with an open standard allowing for competition. 
Which is something that has succeeded. There are very many different 
implementations of the PSS client and servers. They are interoperating 
as IMTC IOTs has shown.

So not everything is walled gardens, and when it comes to 
content-delivery wall garden becomes very difficult for your business. 
Content is most likely available from outside of your own network and 
locking the users into what you as an operator provide is bad for business.

What an operator can benefit from is to provide a charging solution for 
premium content. Thus simplifying for both users and content-providers. 
But this is benefiting from having more information rather than locking 
the users in.

You should also be aware of several other groups (e.g. ISMA, DLNA) that 
do provide streaming solutions which is heavily loaded with IETF defined 
components. Sure, several of different groups has defined extensions 
that they have seen need for. Mostly due to that IETF moves so slowly, 
but also a felling that it wasn't need somewhere else than in there 
usage model. The last may or may not be true. In fact several of the 
extensions that 3GPP has come up in the PSS context seem to be escaping 
out into more general usage.

 From this I at least can conclude that any new work in the area of 
content-distribution should ensure that it receives requirements and 
feedback from these groups. Otherwise the end-product will not be as 
useful for them and the wide spread use of open protocols may be 
hampered. Also more profiling or sub-setting would probably be used 
reducing the interoperability between solutions and introduce higher 
costs for everyone as less reuse of solutions will occur.

Cheers

Magnus

-- 

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: "Henry Sinnreich" <[email-masked]>
Date: Thu, 3 Nov 2005 08:48:28 -0600

Magnus,

>Packet-based Streaming Service (PSS) which is defined by 3GPP SA4 WG 
>has a model that isn't related to a walled garden at all.

Then why not subject it to the IETF review and standards process?

>What an operator can benefit from is to provide a charging solution 
>for premium content.

You are describing technology promoted by companies and consortiums to
support their business development plans, in this case putting the
"operator" in the middle between the content provider and the user. 

While this is perfectly legal business, it is hardly in the Interest of the
IETF to promote any particular technology in support of a business model.
There are far too many other stakeholders on the Internet, not even counting
users that may not happen to like your business plans in the first place,
since it empowers carriers over end users and negates the e2e Internet
control principle.

I would go on, but sorry to all on the list. This discussion does not belong
here. Just let us know where we can step outside to continue this discussion
:-)

Thanks, Henry

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]] 
Sent: Thursday, November 03, 2005 3:27 AM
To: [email-masked]
Cc: 'Pascal Dore'; [email-masked]; [email-masked];
[email-masked]
Subject: Re: [Sipping] What role (if any) for IMS/SIP in a Streaming
Service:IMS/SIP - RTSP interworking

Hi Henry,

Cheers

Magnus

-- 

Magnus Westerlund