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

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 01 Nov 2005 14:40:50 -0500

Its way too late for a formal bof. Perhaps we can organize something 
more informal for folks that are interested.

-Jonathan R.

Chris Steck wrote:

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

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

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

---

From: Colin Perkins <[email-masked]>
Date: Tue, 1 Nov 2005 20:42:12 +0000

We have some time available in the MMUSIC agenda, if it would be  
useful to have a discussion on this subject. Contact the MMUSIC  
chairs if you'd like to lead the discussion.

Colin

On 1 Nov 2005, at 19:40, Jonathan Rosenberg wrote:
> Its way too late for a formal bof. Perhaps we can organize  
> something more informal for folks that are interested.
>
> -Jonathan R.
>
> Chris Steck wrote:
>
>> 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
>> Email: [email-masked] -----Original Message-----
>>> 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
>>> 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]
>>> 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?
>>>
>>> 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).
>>>            - a network resource management scheme (at least for  
>>> QOS authorization & CAC)
>>>
>>> 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: Dean Willis <[email-masked]>
Date: Tue, 1 Nov 2005 17:36:48 -0600

> chairs if you'd like to lead the discussion.

Watching a "movie" is no more less interactive than is leaving a  
recording on a voice-mail server.  So obviously one could issue an  
INVITE with a receive-only offer to a "player", that would respond  
with a send-only answer, and voila, you're watching a movie. And  
clearly the authentication mechanisms, resource precondition  
mechanisms, and so one could be reused. We've been talking about this  
sort of thing for years,

There's also nothing fundamentally wrong, IMHO, with using SIP to  
discover/establish an RTSP session to control playout of a multimedia  
stream. There might be some tricky bits of SDP needed, and MMUSIC is  
definitely where that expertise is.

I have no objection to discussing this idea in MMUSIC, but would  
suggest that we phrase the discussion in the context of SIP and peer  
protocols (RTP, RTCP, RTSP, etc.) in the generally related IETF  
architecture, rather than in the context of IMS.

--
Dean

---

From: Colin Perkins <[email-masked]>
Date: Wed, 2 Nov 2005 00:06:57 +0000

On 1 Nov 2005, at 23:36, Dean Willis wrote:
> mechanisms, and so one could be reused. We've been talking about  
> this sort of thing for years,

Sure.

> discover/establish an RTSP session to control playout of a  
> multimedia stream. There might be some tricky bits of SDP needed,  
> and MMUSIC is definitely where that expertise is.

We've discussed this in the past in MMUSIC, and although there was no  
consensus to proceed down that path at the time, it might be worth us  
revisiting it in the light of more experience (especially given the  
recent decision to make RTSP/2.0).

> suggest that we phrase the discussion in the context of SIP and  
> peer protocols (RTP, RTCP, RTSP, etc.) in the generally related  
> IETF architecture, rather than in the context of IMS.

Any discussion in MMUSIC would have to fit our charter, which limits  
it to protocols relating to the IETF conferencing architecture.

Colin