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

From: Magnus Westerlund <[email-masked]>
Date: Thu, 03 Nov 2005 15:59:38 +0100

Hi Henry

Henry Sinnreich wrote:
> 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?
> 

Because there are already are defined. We don't need multiple 
definitions of the same thing. They are however in the process of being 
registered correctly with IANA.
http://www.ietf.org/internet-drafts/draft-westerlund-mmusic-3gpp-sdp-rtsp-02.txt

> 
>>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
> :-)
> 
Sure, lets stop that part of the debate. The important thing I liked to 
push is that IETF benefits to take other organizations requirement into 
account.

cheers

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]

_______________________________________________
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: "Burger, Eric" <[email-masked]>
Date: Sun, 6 Nov 2005 15:08:03 -0500

Another alternative is the mediactrl work.  Most of the same features
are being examined there, as well.

I'm still not fully bought in to the MRCPv2-as-RTSP replacement
protocol, as I still see it being optimized for ASR/TTS/SI/SV.

I also don't buy the argument, "There is too much RTSP out there to even
think of migrating to SIP."  If that was the case, let me offer there is
too much SS7 out there to even think of migrating to SIP :)

On my ToDo list has been "Write-up the three RTSP methods not supported
by SIP with SIP methods / procedures."  Those of you who know why I go
to Chicago a lot lately understand why I haven't done that yet.

I would suggest folks check out the stuff on the mediactrl Supplemental
Site, <http://flyingfox.snowshore.com/i-d/mediactrl>, which will be up
shortly.

Note the official focus is for conference control.  However, all of the
major parties expect this to be the general SIP-based media server
control protocol.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of David R Oran
Sent: Wednesday, November 02, 2005 9:16 AM
To: Magnus Westerlund
Cc: [email-masked]; Uzelac,Adam; sipping WG; IETF MMUSIC
working group
Subject: Re: [Sipping] What role (if any) for IMS/SIP in a Streaming
Service:IMS/SIP - RTSP interworking

On Nov 2, 2005, at 4:09 AM, Magnus Westerlund wrote:

> Hi,
>
> As the current editor of the RTSP update and also being involved in  
> these discussion the last couple of years I do have some views.
>
Me too. I've worked on SIP for a long time and am traversing a crash  
learning course in entertainment video which has my head spininng (a  
bit, anyway).

> First I think an updated RTSP specification is need. RTSP and its  
> model is so well spread for certain applications to move to SIP and  
> all its baggage.
I agree. I think the SIP/IMS advocates are glossing over the (quite  
significant to me anyway) differences between content-oriented  
request routing and person-to-person rendezvous. I also suspect that  
when we peel the onion a bit more we will discover that the AAA  
requirements for streaming content access (which is called  
"entitlement processing" in the entertainment video world) are vastly  
different from what we see for AAA in the interpersonal- 
communications world, and that content placement (called "asset  
management" in the entertainment video world) is substantially  
different from contact registration in SIP.

> However for other usage SIP could provide a number of benefits.
>
I agree, especially for "source-based" streaming like webcams as  
opposed to "published content access" like last night's episode of  
"desperate Housewives".

> So I think it will be necessary to get RTSP/2.0 out there as soon  
> as possible. However there is a good possibility to start new work  
> for a mechanism that uses SIP for media session and control session  
> establishment. For that work I would not base it on RTSP, instead I  
> would do an playback control addition to MRCP/2.0. MRCP is almost  
> finished in SPEECHSC WG and provides a lot of the basic features  
> you would need for having a well behaved playback control protocol.  
> Including asynchronous messages upon completion of requests.
>
Magnus is right. MRCP has nearly all the playback features needed,  
and a control structure that would allow content-based features as  
well as time-based features. For example, in MRCP you could say "skip  
to where Humphrey Bogarts says `play it again, Sam'". One of the  
things we struggled with in MRCP was the overlap with RTSP's data- 
phase control capabilities. There may be substantial benefit to  
looking at refactoring the boundaries among SIP, RTSP, and MRCP.

Regards, Dave Oran.

> Cheers