Subject: [MMUSIC] comments on draft-whitehead-mmusic-sip-for-streaming-media-03

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 09 Mar 2008 13:43:52 -0400

There has been little discussion on this draft for a while; I found just 
a few messages over the last year and a half.

I remain unconvinced that this is a good idea. Lets look at the use cases:

> Server Control of Streaming Session
> 
> 
>    During a streaming session, the operator may want to redirect or move
>    pending sessions in order to for e.g., upgrade the server.

If I read this one right, its basically saying, "well SIP has call 
transfer, and we could use that, so lets use SIP instead of RTSP". 
Wouldn't it be easier to just add a transfer feature to RTSP? Transfer 
exists in web too. That doesn't mean it should use SIP.

> 3.4. Private/Firewalled video content
> 
> 
>    In this use case, the user, while not on his home network, wants to
>    access content that is stored on his personal or home network, e.g.,
>    a pre-recorded show on a PVR device, or a monitoring camera at his or
>    her home location that is capable of providing a live feed as well as
>    record it locally as a PVR asset.

You don't need SIP for nat traversal. Add RTSP to the long list of other 
protocols that have the same problem. RTSP is adding fw/nat traversal 
support; wouldn't that address this concern?

> 3.5. VOD services that requires resource or QOS-guarantees
> 
> 
>    Consider a Video on Demand (stored video) service provided as a
>    unicast session to an end user device from a server.  The user

Last I checked, QoS and SIP are not the same thing.
I think the real premise here is that IMS provides QoS, and IMS uses 
SIP, so to get QoS, I need SIP. I think this is an awfully bad idea. To 
quote Dave Oran, SIP is NOT the waist of the hourglass (its not IP 
either btw - see 
http://www.ietf.org/internet-drafts/draft-rosenberg-internet-waist-hourglass-00.txt). 
Tying network QoS access with SIP is an egregious design mistake. Lots 
of things can benefit from QoS when it exists - even non-media things. 
Wouldn't you like to be able to have faster access to web browsing? If 
the IMS guys allow QoS only for SIP, shame on them.

> 3.6. Intelligent selection of media encoding
> 
> 
>    A user orders content to be delivered to its current device the
>    content could exist in different format (e.g. standard definition 

I don't see why this requires SIP vs. RTSP.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: "Xavier Marjou" <[email-masked]>
Date: Sun, 9 Mar 2008 20:07:21 +0100

Thank you for your comments
See my response inline

Cheers,
Xavier

>  exists in web too. That doesn't mean it should use SIP.

I agree that SIP is not the only solution for the lines you have
extracted. However, the use-case also includes something like "the
streaming server wants to iniate the session towards the end-user and
still leave the playback-control to the end-user": SIP works in this
case, whereas RTSP does not.

>  support; wouldn't that address this concern?

I agree SIP is not the only solution for NAT traversal. However SIP
offers a nice way to reach an agent (e.g. a streaming server) located
behinds a residential NAT.

>  the IMS guys allow QoS only for SIP, shame on them.

I agree we may remove this one in the next version; instead we could
indicate that some deployments of SIP exist today, and simply adding a
playback media-control as a media negotiated by SIP enables to re-use
many mechanisms established around the SIP protocol (qos mechanisms,
charging...).

>  I don't see why this requires SIP vs. RTSP.

Behind that is a kind of technical use-case: the possibility to re-use
the offer-answer mechanism so that both peers can negotiate the media
paramaters.
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 16 Mar 2008 18:49:29 -0400

Howdy,
I've been listening to the archived MMUSIC meeting, and one topic that came up from Jonathan is what actual use-cases exist which need a streaming server to initiate a session to a client, but also need the media control properties of RTSP for that session.

I can think of the following use-cases:
1) Motion-detecting or pattern-matching cameras, which need to call the human when motion/pattern is detected, but have a buffer and thus can be paused/rewound/etc. by that human.  This could be for security cameras, or factory floor robots, or whatever.

2) Video wake-up: setting a timed TV video-feed, similar to setting a wake-up timer on the hotel TV.  Of course an RTSP client itself could just have that timer.

3) Video subscriptions: I subscribe on a webpage to get all new local high-school football games, or Voipsa blue-box podcasts ;)  I'd like my DVR/TV to pop up with the option to play them immediately, or record them to DVR, or neither.  The high-school football game is not available from cable TV, so the DVR doesn't have a schedule to know when to get it by itself.  Of course this could be done with an off-line indication, such as email, but it would be nice if my DVR didn't need to support email.

But to me, the much bigger use-case is based on the rendezvous behavior.  SIP and RTSP do not have the same rendezvous characteristics, because SIP supports one thing RTSP does not: Registrations/Registrars.  So imagine the use-case of remote DVR/Tivo/TV watching (i.e., similar to what the company Swing provides).  It is unreasonable to expect common users to setup a URL for the DVR server in DNS for it (DynDNS is beyond most folks), and a DMZ/pinhole and all.  It would be a lot easier for them to call their registered DVR UA using a SIP AoR.  And it would get through their NAT at both signaling and media layers.  It's not a complete solution, because it doesn't deal with how the user knows which streams are available and such, and other DVR features, but it's a use-case.  As is having SIP Subscribe for video subscription notifications, and program schedules, and config framework, and so on.

Honestly, if RTSP were under development starting now, wouldn't we all argue it should be using SIP instead?  Perhaps with TOTE for the commands? (I'm sure whoever wrote that TOTE draft was thinking of that ;)

-hadriel

---

From: "Montpetit Marie-Jose-MGIF0300" <[email-masked]>
Date: Sun, 16 Mar 2008 18:52:05 -0400

Thank you. We have the DVR use case you mention but it's nice to see
someone else shares the ideas. We have the intention to cycle the draft
in the next few weeks and will include your use cases.

Thanks for your suggestions.

/mjm 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Hadriel Kaplan
Sent: Sunday, March 16, 2008 6:49 PM
To: IETF MMUSIC WG
Subject: [MMUSIC] use-cases
fordraft-whitehead-mmusic-sip-for-streaming-media-03

Howdy,
I've been listening to the archived MMUSIC meeting, and one topic that
came up from Jonathan is what actual use-cases exist which need a
streaming server to initiate a session to a client, but also need the
media control properties of RTSP for that session.

I can think of the following use-cases:
1) Motion-detecting or pattern-matching cameras, which need to call the
human when motion/pattern is detected, but have a buffer and thus can be
paused/rewound/etc. by that human.  This could be for security cameras,
or factory floor robots, or whatever.

2) Video wake-up: setting a timed TV video-feed, similar to setting a
wake-up timer on the hotel TV.  Of course an RTSP client itself could
just have that timer.

3) Video subscriptions: I subscribe on a webpage to get all new local
high-school football games, or Voipsa blue-box podcasts ;)  I'd like my
DVR/TV to pop up with the option to play them immediately, or record
them to DVR, or neither.  The high-school football game is not available
from cable TV, so the DVR doesn't have a schedule to know when to get it
by itself.  Of course this could be done with an off-line indication,
such as email, but it would be nice if my DVR didn't need to support
email.

But to me, the much bigger use-case is based on the rendezvous behavior.
SIP and RTSP do not have the same rendezvous characteristics, because
SIP supports one thing RTSP does not: Registrations/Registrars.  So
imagine the use-case of remote DVR/Tivo/TV watching (i.e., similar to
what the company Swing provides).  It is unreasonable to expect common
users to setup a URL for the DVR server in DNS for it (DynDNS is beyond
most folks), and a DMZ/pinhole and all.  It would be a lot easier for
them to call their registered DVR UA using a SIP AoR.  And it would get
through their NAT at both signaling and media layers.  It's not a
complete solution, because it doesn't deal with how the user knows which
streams are available and such, and other DVR features, but it's a
use-case.  As is having SIP Subscribe for video subscription
notifications, and program schedules, and config framework, and so on.

Honestly, if RTSP were under development starting now, wouldn't we all
argue it should be using SIP instead?  Perhaps with TOTE for the
commands? (I'm sure whoever wrote that TOTE draft was thinking of that
;)

-hadriel

---

From: "Xavier Marjou" <[email-masked]>
Date: Tue, 18 Mar 2008 12:05:56 +0100

For information, 2 other old mails fully related with this topic:
http://www.ietf.org/mail-archive/web/mmusic/current/msg01610.html
http://www.ietf.org/mail-archive/web/mmusic/current/msg03773.html

Xavier