MMUSIC at IETF79

Our session has been tentatively scheduled for Wednesday afternoon, 
1510-1610 in the Emerald Room.

Tom Taylor

Re: Displaying side by side video streams draft-jennings-mmusic-adjacent-grouping

Hi

Thanks for the clarification. I agree that a full fledged solution for Telepresence will likely need some
more detail  (location of mic, loudspeakers, cameras...). I am not sure that SDP is the right place for this
information but I guess future work will show..

/Ingeamr

> -----Original Message-----
> From: Cullen Jennings [mailto:fluffy <at> cisco.com] 
> Sent: den 29 september 2010 22:17
> To: Ingemar Johansson S
> Cc: MMUSIC WG
> Subject: Re: [MMUSIC] Displaying side by side video streams 
> draft-jennings-mmusic-adjacent-grouping
> 
> 
> This was largely motivated from wall of screens for things 
> like video advertising, arrays of airport monitors with TV 
> updates, display on walls of surveillance screens and so on. 
> I had been waiting to see where the telepresence work will go 
> but I think that is a somewhat different problem. For 
> example, the telepresence people would like to be able to do 
> things like understand where camera really are relative to 
> viewers and the field of view of the cameras so that they can 
> display a speaker uh, "life size". That requires a far more 
> fine graining approach to position that saying this stream 
> goes on the left monitor and this one the right. I think 
> there is a reasonable good document on the some of the 
> telepresence uses cases. I used the word telepresence in this 

Re: RTSPv2 bandwidth indication

Hi,

New text proposal for the bandwidth header. Comments appreciated:

The Bandwidth request-header field describes the estimated bandwidth
available to the client, expressed as a positive integer and measured in
kilobits per second. The bandwidth available to the client may change
during an RTSP session, e.g., due to mobility, congestion, etc.

Clients may not be able to accurately determine the available bandwidth,
for example due to that first hop is not a bottleneck. For example most
local area networks (LAN) will not be a bottleneck if the server is not
in the same LAN. Thus link speeds of WLAN or Ethernet networks are
normally not a basis for estimating the available bandwidth. Cellular
devices or other devices directly connected to an modem or connection
enabling device may more accurately estimate the bottleneck bandwidth
and what is reasonable share of it for RTSP controlled media. It is
RECOMMENDED that only clients that has accurate and explicit information
about bandwidth bottlenecks uses this header.

This header is not a substitute for proper congestion control. Only a
method providing an initial estimate and coarsely determine if the
selected content can be delviered at all.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM

Re: SAVP and SAVP in draft-ietf-mmusic-rfc2326bis-23

Hi Dan,

Thanks for your comment. I agree that using MIKEY is not the greatest
fit for this and do require a certain amount of specification work that
currently is missing. I am starting to lean in the direction that
defining DTLS-SRTP for this might be actually easier. What I see needed
to be specified are:

- Use DTLS-SRTP when having negotiated that transport identifier.

- Include a DER fingerprint of the certificates that is going to be used
in the handshake, likely self signed on the client side in the transport
spec. In line with the SDP TLS fingerprint in RFC 4572

- Require that one support all 4 DTLS SRTP protection profile present in
RFC 5764. In other words SHA-1 80 or 32 bits integrity and AES 128 CM if
encryption is used.

- Recommend that for media that are already confidentiality protected
use only authentication and integrity protection.

Other comments on this?

Cheers

Magnus

Dan Wing skrev 2010-09-30 01:31:
>> -----Original Message-----
>> From: mmusic-bounces <at> ietf.org [mailto:mmusic-bounces <at> ietf.org] On

I-D Action:draft-ietf-mmusic-sdp-cs-05.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF.

	Title           : Session Description Protocol (SDP) Extension For Setting Up Audio and Video Media Streams Over
Circuit-Switched Bearers In The Public Switched Telephone Network (PSTN)
	Author(s)       : M. Garcia, S. Veikkolainen
	Filename        : draft-ietf-mmusic-sdp-cs-05.txt
	Pages           : 24
	Date            : 2010-10-08

This memo describes use cases, requirements, and protocol extensions
for using the Session Description Protocol (SDP) Offer/Answer model
for establishing audio and video media streams over circuit-switched
bearers in the Public Switched Telephone Network (PSTN).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-cs-05.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
mmusic mailing list
mmusic <at> ietf.org

FW: I-D Action:draft-garcia-mmusic-sdp-icap-bcap-00.txt

I have just submitted a new version of draft-garcia-mmusic-misc-cap according to Chair's mail back in
July (http://www.ietf.org/mail-archive/web/mmusic/current/msg08228.html).

The new draft has a new name since the earlier version of the draft was withdrawn, but essentially the
content is the same except for connection address capability ("ccap" attribute) which has been stripped.

The document can be found at http://www.ietf.org/internet-drafts/draft-garcia-mmusic-sdp-icap-bcap-00.txt

Regards,
Simo

>-----Original Message-----
>From: i-d-announce-bounces <at> ietf.org [mailto:i-d-announce-
>bounces <at> ietf.org] On Behalf Of ext Internet-Drafts <at> ietf.org
>Sent: 08 October, 2010 12:00
>To: i-d-announce <at> ietf.org
>Subject: I-D Action:draft-garcia-mmusic-sdp-icap-bcap-00.txt
>
>A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
>
>	Title           : Miscellaneous Capabilities Negotiation in the
>Session Description Protocol (SDP)
>	Author(s)       : M. Garcia, et al.
>	Filename        : draft-garcia-mmusic-sdp-icap-bcap-00.txt
>	Pages           : 13
>	Date            : 2010-10-08
>
>SDP has been extended with a capability negotiation mechanism framework
>that allows the endpoints to negotiate transport protocols and

Re: FW: I-D Action:draft-garcia-mmusic-sdp-icap-bcap-00.txt

Hi,

ccap is still mentioned in sections 3.2 and 5.2. 

Is that a misstake, or?

Regards,

Christer

> -----Original Message-----
> From: mmusic-bounces <at> ietf.org 
> [mailto:mmusic-bounces <at> ietf.org] On Behalf Of 
> Simo.Veikkolainen <at> nokia.com
> Sent: 8. lokakuuta 2010 16:14
> To: mmusic <at> ietf.org
> Subject: [MMUSIC] FW: I-D 
> Action:draft-garcia-mmusic-sdp-icap-bcap-00.txt
> 
> I have just submitted a new version of 
> draft-garcia-mmusic-misc-cap according to Chair's mail back 
> in July 
> (http://www.ietf.org/mail-archive/web/mmusic/current/msg08228.html).
> 
> The new draft has a new name since the earlier version of the 
> draft was withdrawn, but essentially the content is the same 
> except for connection address capability ("ccap" attribute) 
> which has been stripped.
> 

Re: FW: I-D Action:draft-garcia-mmusic-sdp-icap-bcap-00.txt

>Hi,
>
>ccap is still mentioned in sections 3.2 and 5.2.
>
>Is that a misstake, or?

Should've searched for "ccap" before submitting... Yes that is an error, thanks for pointing it out.

Simo

>Regards,
>
>Christer
>
>> -----Original Message-----
>> From: mmusic-bounces <at> ietf.org
>> [mailto:mmusic-bounces <at> ietf.org] On Behalf Of
>> Simo.Veikkolainen <at> nokia.com
>> Sent: 8. lokakuuta 2010 16:14
>> To: mmusic <at> ietf.org
>> Subject: [MMUSIC] FW: I-D
>> Action:draft-garcia-mmusic-sdp-icap-bcap-00.txt
>>
>> I have just submitted a new version of
>> draft-garcia-mmusic-misc-cap according to Chair's mail back
>> in July
>> (http://www.ietf.org/mail-archive/web/mmusic/current/msg08228.html).
>>
>> The new draft has a new name since the earlier version of the
>> draft was withdrawn, but essentially the content is the same

FW: I-D Action:draft-veikkolainen-mmusic-ice-suppress-checks-00.txt

Hello,

I have submitted a new I-D which defines an extension for ICE for suppressing connectivity checks for
certain candidate addresses.

http://www.ietf.org/internet-drafts/draft-veikkolainen-mmusic-ice-suppress-checks-00.txt

A bit of background: http://tools.ietf.org/html/draft-ietf-mmusic-sdp-cs-05 defines conventions
for describing circuit-switched audio and video streams in SDP. Earlier, we had another document,
draft-garcia-mmusic-misc-cap, which together with sdp-cs draft would have allowed describing
alternative PSTN and IP bearers in SDP using the SDP Capability Negotiation framework.

After long and winding discussions, the decision was to remove the connection address capability from
misc-cap draft, since it would have allowed offering alternative addresses of any type, and thus
circumventing ICE. 

So, another approach of offering alternative PSTN and IP bearer is to use ICE, but then we need a way to tell to
the agents that connectivity checks are not really meaningful for PSTN address candidates. The new draft
defines such an extension to ICE.

Other documents have also argued for the possibility of not always performing ICE connectivity checks
(http://tools.ietf.org/html/draft-hutton-mmusic-icemicrolite-01,
http://tools.ietf.org/html/draft-wing-dispatch-v6-migration-00 and http://tools.ietf.org/html/draft-boucadair-mmusic-altc-01).

This is a very first draft, and many things are probably still missing. However, I would like to hear folks'
opinions on the general idea already at this point.

regards,
Simo

Re: RTSPv2 bandwidth indication

Magnus

comments in-line

At 09:03 AM 10/6/2010, Magnus Westerlund wrote:
>Hi,
>
>New text proposal for the bandwidth header. Comments appreciated:
>
>
>
>The Bandwidth request-header field describes the estimated bandwidth
>available to the client, expressed as a positive integer and measured in
>kilobits per second.

a minor (by important distinction) - Is this 
basically the interface speed of the client, or 
is this the available BW that isn't being used at 
this time by the client? For example, if the 
client is doing a massive file download (e.g. a 
movie file), the interface speed can be 
significantly different than what is available to RTSP for a new session.

>The bandwidth available to the client may change
>during an RTSP session, e.g., due to mobility, congestion, etc.
>
>Clients may not be able to accurately determine the available bandwidth,
>for example due to that first hop is not a bottleneck. For example most
>local area networks (LAN) will not be a bottleneck if the server is not
>in the same LAN. Thus link speeds of WLAN or Ethernet networks are