headers
steven.d.whitehead | 1 Nov 2005 17:49
Picon

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
mmusic <at> ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic
Permalink | Reply | 0 comments |
headers
Uzelac, Adam | 1 Nov 2005 18:21

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

________________________________

From: sipping-bounces <at> ietf.org [mailto:sipping-bounces <at> ietf.org] On
Behalf Of steven.d.whitehead <at> verizon.com
Sent: Tuesday, November 01, 2005 11:49 AM
To: mmusic <at> ietf.org; sipping <at> ietf.org
Cc: steven.d.whitehead <at> verizon.com
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 sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP
Permalink | Reply | 43 comments |
headers
Pascal Dore | 1 Nov 2005 19:34

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

Hi Steven,

 

Maybe this link could be interesting to look:

Internet Streaming Media Alliance:

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: sipping-bounces <at> ietf.org [mailto:sipping-bounces <at> ietf.org] On Behalf Of steven.d.whitehead <at> verizon.com
Sent: 1 novembre 2005 11:49
To: mmusic <at> ietf.org; sipping <at> ietf.org
Cc: steven.d.whitehead <at> verizon.com
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
mmusic <at> ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic
Permalink | Reply | 17 comments |
headers
Jonathan Rosenberg | 1 Nov 2005 20:11
Picon
Favicon

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: sipping-bounces <at> ietf.org [mailto:sipping-bounces <at> ietf.org] On
> Behalf Of steven.d.whitehead <at> verizon.com
> Sent: Tuesday, November 01, 2005 11:49 AM
> To: mmusic <at> ietf.org; sipping <at> ietf.org
> Cc: steven.d.whitehead <at> verizon.com
> 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 sip-implementors <at> cs.columbia.edu for questions on current sip
> Use sip <at> ietf.org 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
jdrosen <at> cisco.com                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com
Permalink | Reply | 41 comments |
headers
Chris Steck | 1 Nov 2005 20:37
Picon
Favicon

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

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: CSteck <at> real.com 

-----Original Message-----
From: mmusic-bounces <at> ietf.org [mailto:mmusic-bounces <at> ietf.org] On Behalf Of
Jonathan Rosenberg
Sent: Tuesday, November 01, 2005 11:12 AM
To: Uzelac, Adam
Cc: steven.d.whitehead <at> verizon.com; sipping <at> ietf.org; mmusic <at> ietf.org
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: sipping-bounces <at> ietf.org [mailto:sipping-bounces <at> ietf.org] On 
> Behalf Of steven.d.whitehead <at> verizon.com
> Sent: Tuesday, November 01, 2005 11:49 AM
> To: mmusic <at> ietf.org; sipping <at> ietf.org
> Cc: steven.d.whitehead <at> verizon.com
> 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 
> sip-implementors <at> cs.columbia.edu for questions on current sip Use 
> sip <at> ietf.org 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
jdrosen <at> cisco.com                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
mmusic mailing list
mmusic <at> ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic
Permalink | Reply | 0 comments |
headers
Jonathan Rosenberg | 1 Nov 2005 20:40
Picon
Favicon

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

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: CSteck <at> real.com 
> 
> -----Original Message-----
> From: mmusic-bounces <at> ietf.org [mailto:mmusic-bounces <at> ietf.org] On Behalf Of
> Jonathan Rosenberg
> Sent: Tuesday, November 01, 2005 11:12 AM
> To: Uzelac, Adam
> Cc: steven.d.whitehead <at> verizon.com; sipping <at> ietf.org; mmusic <at> ietf.org
> 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: sipping-bounces <at> ietf.org [mailto:sipping-bounces <at> ietf.org] On 
>>Behalf Of steven.d.whitehead <at> verizon.com
>>Sent: Tuesday, November 01, 2005 11:49 AM
>>To: mmusic <at> ietf.org; sipping <at> ietf.org
>>Cc: steven.d.whitehead <at> verizon.com
>>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 
>>sip-implementors <at> cs.columbia.edu for questions on current sip Use 
>>sip <at> ietf.org 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
jdrosen <at> cisco.com                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com
Permalink | Reply | 6 comments |
headers
Uzelac, Adam | 1 Nov 2005 20:50

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

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:jdrosen <at> cisco.com] 
Sent: Tuesday, November 01, 2005 2:12 PM
To: Uzelac, Adam
Cc: steven.d.whitehead <at> verizon.com; mmusic <at> ietf.org; sipping <at> ietf.org
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: sipping-bounces <at> ietf.org [mailto:sipping-bounces <at> ietf.org] On 
> Behalf Of steven.d.whitehead <at> verizon.com
> Sent: Tuesday, November 01, 2005 11:49 AM
> To: mmusic <at> ietf.org; sipping <at> ietf.org
> Cc: steven.d.whitehead <at> verizon.com
> 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 
> sip-implementors <at> cs.columbia.edu for questions on current sip Use 
> sip <at> ietf.org 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
jdrosen <at> cisco.com                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP
Permalink | Reply | 0 comments |
headers
steven.d.whitehead | 1 Nov 2005 21:27
Picon

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

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:Adam.Uzelac <at> globalcrossing.com] 
Sent: Tuesday, November 01, 2005 12:21 PM
To: Steven D. Whitehead; mmusic <at> ietf.org; sipping <at> ietf.org
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 

________________________________

From: sipping-bounces <at> ietf.org [mailto:sipping-bounces <at> ietf.org] On
Behalf Of steven.d.whitehead <at> verizon.com
Sent: Tuesday, November 01, 2005 11:49 AM
To: mmusic <at> ietf.org; sipping <at> ietf.org
Cc: steven.d.whitehead <at> verizon.com
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
Permalink | Reply | 0 comments |
headers
Colin Perkins | 1 Nov 2005 21:42

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

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:
>
>> 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: CSteck <at> real.com -----Original Message-----
>> From: mmusic-bounces <at> ietf.org [mailto:mmusic-bounces <at> ietf.org] On  
>> Behalf Of
>> Jonathan Rosenberg
>> Sent: Tuesday, November 01, 2005 11:12 AM
>> To: Uzelac, Adam
>> Cc: steven.d.whitehead <at> verizon.com; sipping <at> ietf.org; mmusic <at> ietf.org
>> 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: sipping-bounces <at> ietf.org [mailto:sipping-bounces <at> ietf.org]  
>>> On Behalf Of steven.d.whitehead <at> verizon.com
>>> Sent: Tuesday, November 01, 2005 11:49 AM
>>> To: mmusic <at> ietf.org; sipping <at> ietf.org
>>> Cc: steven.d.whitehead <at> verizon.com
>>> 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  
>>> sip-implementors <at> cs.columbia.edu for questions on current sip Use  
>>> sip <at> ietf.org 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
> jdrosen <at> cisco.com                              FAX:   (973) 952-5050
> http://www.jdrosen.net                         PHONE: (973) 952-5000
> http://www.cisco.com
>
> _______________________________________________
> mmusic mailing list
> mmusic <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/mmusic
Permalink | Reply | 4 comments |
headers
steven.d.whitehead | 1 Nov 2005 21:57
Picon

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

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

 

 

_______________________________________________
mmusic mailing list
mmusic <at> ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic
Permalink | Reply | 0 comments |

Gmane