Subject: [MMUSIC] 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

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

---

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: "Chris Steck" <[email-masked]>
Date: Wed, 2 Nov 2005 11:43:09 -0800

Hi Henry, 
 
Maybe lack germane historical perspective, but I don't understand your
response.  
 
IMHO, there's a very big difference between legitimizing/endorsing walled
gardens and performing due diligence.  Most of the 3GPP specs I've read
(SA-4) begin with a big nod to the IETF by citing a laundry list of IETF
RFCs and Internet Drafts which comprise the basis of the core reqs.  -And
for that matter, most of the names I see post to AVT and MMUSIC lists are
the same folks.  
 
So If the IETF gathers the interop reqs of the walled gardens and addresses
their concerns in a timely fashion, it can provide the defacto standards
guiding FMC, at least at the upper layers.  Otherwise, another org will
likely rise to the occasion, or yet another one fill form to fill the need.
(And we'll all end up all having to cover that one too. :) )
 
It would be a shame if the walled gardens focusing on Fixed Mobile
Convergence all learn how to talk to each other but the conversation stops
at the _OPEN_Internet.
 
-Chris 

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Henry Sinnreich
Sent: Wednesday, November 02, 2005 9:17 AM
To: 'Pascal Dore'; [email-masked]; [email-masked];
[email-masked]
Subject: [MMUSIC] RE: [Sipping] What role (if any) for IMS/SIP in aStreaming
Service:IMS/SIP - RTSP interworking

Thanks, Henry

  _____  

Hi Steven,

- Pascal.D

  _____  

Here's the problem:

Thoughts? Insights?

Thanks,

-Steve

---

From: "Chris Steck" <[email-masked]>
Date: Sat, 5 Nov 2005 20:17:30 -0800

All, please ignore the resend below.
 
I didn't manually re-submit this, I don't know why it posted again, it isn't
in my sent mail twice.  I think it may have something to do that I only
belonged to mmusic list, and I joined the sip and sipping mail lists after
my first responses were manually approved. Maybe they auto-approved and sent
themselves again once I joined. 
 
Not sure what happened, but maybe someone in the know could look into it. 
 
Thanks,

-Chris 

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Chris Steck
Sent: Wednesday, November 02, 2005 11:43 AM
To: [email-masked]; 'Pascal Dore'; [email-masked];
[email-masked]; [email-masked]
Subject: RE: [MMUSIC] RE: [Sipping] What role (if any) for IMS/SIP
inaStreaming Service:IMS/SIP - RTSP interworking

Hi Henry, 

 

-Chris 

  _____  

Thanks, Henry

  _____  

Hi Steven,

- Pascal.D

  _____  

Here's the problem:

Thoughts? Insights?

Thanks,

-Steve