Subject: [MMUSIC] [Fwd: MMUSIC Interim Meeting on RTSP, May 19-20, 2008]

From: Tom Taylor <[email-masked]>
Date: Fri, 11 Apr 2008 19:21:26 -0400

I note without any personal interest that there is an IPTV-related ITU-T meeting 
in Geneva at that time. The collision is unfortunate.

-------- Original Message --------
Subject: MMUSIC Interim Meeting on RTSP, May 19-20, 2008
Date: Fri, 11 Apr 2008 09:30:01 -0700 (PDT)
From: IETF Secretariat <[email-masked]>
To: [email-masked]

The IETF MMUSIC WG is holding an Interim meeting on the topic of RTSP
the 19th and 20th of May 2008 in Stockholm, Sweden. The meeting will
start at lunch time 12.00 and continue until 18.00 on Monday the 19th.
On Tuesday it will start at 9.00 and end at latest at 17.00.

The purpose of the meeting is the following: First, to discuss the open
issues that at that time exists on the RTSP 2.0 core specification.
Secondly, to discuss any liaison response from other standards
developing organizations using RTSP. Especially their desired extensions
to RTSP and their impact on the RTSP 2.0 core specification. We
especially encourage persons from such organizations to participate in
this meeting. Third, to discuss issues and ways to progress already
existing MMUSIC WG item extensions to RTSP. Fourth, to discuss any RTSP
extensions proposed to become MMUSIC WG items. The main goal is to help
ensure the timely completion of the RTSP 2.0 core specification while
ensuring that the potential user's requirements have been considered and
the necessary extension mechanisms are in place.

The RTSP 2.0 core specification editors intends to submit an updated
version of the draft in good time (2-3 weeks) prior to the meeting to
allow everyone to prepare. At that time a more detailed agenda will also
be published taking requests for topics and the incoming liaisons into
account.

Participants are required to register prior to the event to ensure that
the facilities can accommodate the participants. The last day of
registration is the 5th of May. Registration shall be sent to
[email-masked] with the subject line "MMUSIC RTSP
interim meeting" indicating the participant's name and also any specific
agenda requests. The meeting will most likely be held out in Kista (20
min subway ride from downtown Stockholm).

Any questions on this event can be directed to the MMUSIC WG chairs
Joerg Ott ([email-masked]) and Jean-Francois Mule ([email-masked]) or
the meeting organizer Magnus Westerlund
([email-masked]).

References:
Current WG documents:
http://tools.ietf.org/wg/mmusic/draft-ietf-mmusic-rfc2326bis/
http://tools.ietf.org/wg/mmusic/draft-ietf-mmusic-rtsp-nat/
http://tools.ietf.org/wg/mmusic/draft-ietf-mmusic-rtsp-nat-evaluation/

RTSP Core issue tracker:
http://sourceforge.net/projects/rtspspec
_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf-announce

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

---

From: "Daniel Park" <[email-masked]>
Date: Thu, 17 Apr 2008 09:59:07 +0900

Hi,

This is a good reaction from the IPTV aspect. Here is a quick question
on the RTSP extension. Apology if I am bring up the past issues in
this WG.

ITU-T IPTV Requirements say:
=============================
- The IPTV architecture is recommended to support a mechanism for
obtaining information pertaining to terminal device capabilities

- The IPTV architecture is recommended to adapt dynamically to change
in wireless networks characteristics when the service is delivered
over a mobile network (e.g., bandwidth, packet loss rate, etc)

- In case a IPTV terminal is mobile, it is recommended to support
mobility functionalities for service continuity when in motion. An
optional signalling architecture for exchanging wireless network
characteristics between an IPTV terminal (mobile device) and Service
Provider Server. It allows Server to adjust their sending rate for
ongoing video service according to the received information (e.g.,
bandwidth, packet loss, etc.) from the IPTV terminal. Piggybacking the
information on the existing IP based Protocol is available.

- Wireless network characteristics: The characteristics of a wireless
network expressed in terms of current available bandwidth, packet loss
and possibly other to-be-defined wireless network information
parameters for a specific wireless link type, e.g., WLAN, Cellular,
WPAN or WMAN.
=============================

Presumably, RTSP can be a part of the existing IP based Protocol for
piggybacking the terminal characteristic information to the server in
order to adjust their sending rate for ongoing video service according
to the received information.

Question: RTSP can provide this facility to the IPTV architecture ? If
not, is there any possiblity to take care of this function in this
interim meeting ?

Thanks in advance,

---
Daniel Park [at] Samsung Electronics

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 17 Apr 2008 11:56:46 +0200

Hi Daniel,

Please see inline for part of the response. One of the goal with the 
RTSP meeting is to discuss potential extensions and how they fit the 
core specification. There will be no decisions on adopting any such 
extension at this meeting, but discussion around them is welcome.

> ITU-T IPTV Requirements say:

I know of at least one solution based on RTSP. In 3GPP in TS 26.234 they 
have defined a RTSP header that carries a URI identifying the UAProf 
device capability description for that device to be included in DESCRIBE 
requests.

> over a mobile network (e.g., bandwidth, packet loss rate, etc)

Basic bit-rate adaptations are clearly intended to be solved by the 
media delivery layer, most commonly RTP. The issue that is touching RTSP 
is if the media configuration needs to be changed. At the moment this 
doesn't work in RTSP. Some may argue that RSTP 1.0 Announce method can 
be used for this, but the issue remain on how to confirm and be certain 
that the RTSP client is capable of handling the request.

As I see it proposals for this type functionality is one possible 
extension to RTSP 2.0.

> information on the existing IP based Protocol is available.

When it comes to network characteristic there exist some basic 
functionality in RTSP for it. Others, like 3GPP, have defined additional 
data to be signalled. There is also some expectation for the network 
layer to carry its view on the traffic characteristic.

When it comes to the mobility aspects, there exist support for 
renegotiation of network parameters to where the media data is to be 
delivered. Although usage of lower layer mobility solutions may provide 
better service.

As state above, media being delivered is expected to have some bit-rate 
adaptation capability to cope with large part of the dynamics. For 
mobility resulting is large differences in capabilities some additional 
mechanism may be needed.

> parameters for a specific wireless link type, e.g., WLAN, Cellular,

As said above, this type of information have been included in RTSP.

> to the received information.

Yes, it clearly can.

> not, is there any possiblity to take care of this function in this

The first question is not easy to answer without some studies. I think 
it can provide a lot of the functionality. However, some extensions are 
likely to be required. What is clear is that the interim meeting can't 
take care of anything. However, if you can propose an agenda item and 
participate with prepared material we clearly can discuss what issues 
exist.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Färögatan 6                | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Daniel Park" <[email-masked]>
Date: Tue, 22 Apr 2008 11:23:48 +0900

Hi Magnus,

On Thu, Apr 17, 2008 at 6:56 PM, Magnus Westerlund
<[email-masked]> wrote:
> Hi Daniel,
>
> Please see inline for part of the response. One of the goal with the RTSP
> meeting is to discuss potential extensions and how they fit the core
> specification. There will be no decisions on adopting any such extension at
> this meeting, but discussion around them is welcome.
>
> Daniel Park skrev:
>
> > Hi,
> >
> have defined a RTSP header that carries a URI identifying the UAProf device
> capability description for that device to be included in DESCRIBE requests.
>
>
> >
> Basic bit-rate adaptations are clearly intended to be solved by the media
> delivery layer, most commonly RTP. The issue that is touching RTSP is if the
> media configuration needs to be changed. At the moment this doesn't work in
> RTSP. Some may argue that RSTP 1.0 Announce method can be used for this, but
> the issue remain on how to confirm and be certain that the RTSP client is
> capable of handling the request.
>
> As I see it proposals for this type functionality is one possible extension
> to RTSP 2.0.

For example; MPEG is delivering a scalable video coding according to
the client dynamic capabilities. For that, client has to piggyback its
changable information to media server. It is a part of worklist in
RTSP 2.0 extension. Right ?

> When it comes to network characteristic there exist some basic functionality
> in RTSP for it. Others, like 3GPP, have defined additional data to be
> signalled. There is also some expectation for the network layer to carry its
> view on the traffic characteristic.

Could you elaborate on the first sentence "...basic functionality in RTSP" ?

> When it comes to the mobility aspects, there exist support for renegotiation
> of network parameters to where the media data is to be delivered. Although
> usage of lower layer mobility solutions may provide better service.
>
> adaptation capability to cope with large part of the dynamics. For mobility
> resulting is large differences in capabilities some additional mechanism may
> be needed.
>
>
> >

same as the previous note. please kindly point out which sections in
RTSP specification says...

> The first question is not easy to answer without some studies. I think it
> can provide a lot of the functionality. However, some extensions are likely
> to be required. What is clear is that the interim meeting can't take care of
> anything. However, if you can propose an agenda item and participate with
> prepared material we clearly can discuss what issues exist.

I am thinking to be attending this adhoc. Now, I am trying to clarify
what I should do in there before making the final journey. If
necessary, I will bring with some of knowledge about IPTV and Network
Characteristics aspect of course.

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 23 Apr 2008 11:55:42 +0200

> RTSP 2.0 extension. Right ?

It is listed as a feature request for RTSP 2.0. However, I don't see how 
we can fulfill this request as part of the core specification. It is 
also clearly a part that can be developed as a extension. So if you have 
interest in this, please start writing on a individual draft on such an 
extension.

> Could you elaborate on the first sentence "...basic functionality in RTSP" ?

There is the Bandwidth and Blocksize headers.

> RTSP specification says...

Please look at the 3GPP defined header 3GPP-Link-Char header defined in 
3GPP TS 26.234.

> Characteristics aspect of course.

I think it would be great if you would attend.

Cheers

Magnus Westerlund