From hishigh@gmail.com  Mon Jun  1 07:51:16 2009
Return-Path: <hishigh@gmail.com>
X-Original-To: mmusic@core3.amsl.com
Delivered-To: mmusic@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F2E83A6D04 for <mmusic@core3.amsl.com>; Mon,  1 Jun 2009 07:51:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.091
X-Spam-Level: 
X-Spam-Status: No, score=-1.091 tagged_above=-999 required=5 tests=[AWL=0.907,  BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQcWms1jeExY for <mmusic@core3.amsl.com>; Mon,  1 Jun 2009 07:51:15 -0700 (PDT)
Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by core3.amsl.com (Postfix) with ESMTP id 512B73A6813 for <mmusic@ietf.org>; Mon,  1 Jun 2009 07:51:15 -0700 (PDT)
Received: by yx-out-2324.google.com with SMTP id 8so7614915yxb.49 for <mmusic@ietf.org>; Mon, 01 Jun 2009 07:51:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=QJBCEpMbOnHpJaxAlCEbeKaczt4+VPhXKUFrfpAJXBk=; b=Ob7KJnsKtSI3/8u6TlwP+hfJZiHoZVBMDVQ7z6esjpjklpcL/cyY1Rrtkf+LZxL8I8 tEqEllKSfYlfVI0My6HZ2el+l2qzd3ZK2NFRHfWrxvA10Isec/xDRGRYmF5PIguZxZzN /D4ra7Q+NcLkleQrqPBK+ugzfiS1/AXUToniU=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=nxyRTNUgFRWlaOIJGUtYjt8Ll0pj3b7EXK6czzmwoF+3BoEShfoDehJSfo+iRR2tXJ rpKxlLWAFrEfXYF1i3RZaGQjeXr7x63PkiZIPDVb9ISfORPptvx/v7FmrMLe0CyIbfgH Ec/HsuxRDiYdrPeDANNdF5pNSQiSGNTkVvruo=
MIME-Version: 1.0
Received: by 10.150.230.1 with SMTP id c1mr11807291ybh.256.1243867872885; Mon,  01 Jun 2009 07:51:12 -0700 (PDT)
Date: Mon, 1 Jun 2009 22:51:12 +0800
Message-ID: <8bd755250906010751i4d154786gf5e8f5b6ee1cbc9a@mail.gmail.com>
From: yunfei zhang <hishigh@gmail.com>
To: mmusic@ietf.org
Content-Type: multipart/alternative; boundary=000e0cd519bab5fed2046b4a8e99
Subject: [MMUSIC] call for comments of peer to peer streaming problem statement
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Jun 2009 14:51:16 -0000

--000e0cd519bab5fed2046b4a8e99
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

 Hi,all,
    I have submitted problem statement draft of peer to peer streaming
protocol(PPSP)to IETF website in the following
link.(http://www.ietf.org/internet-drafts/draft-zhang-ppsp-problem-statement-03.txt)
<http://www.ietf.org/internet-drafts/draft-zhang-ppsp-problem-statement-03.txt>
which
may related to MMUSIC WG.Any comments and suggestions are highly
welcome.
The abstract is as follows:

We propose to develop an open peer-to-peer (P2P) streaming protocol named
PPSP. This document describes the problems related to PPSP and outlines
considerations that have to be taken in account when arriving at equitable
solutions.



          BR

              Yunfei

--000e0cd519bab5fed2046b4a8e99
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>
<div>Hi,all,</div>
<div>=A0=A0=A0 I have <font face=3D"Verdana" size=3D"2">submitted problem s=
tatement draft of peer to peer streaming protocol(PPSP)to IETF website in t=
he following link.(</font><a onclick=3D"return top.js.OpenExtLink(window,ev=
ent,this)" href=3D"http://www.ietf.org/internet-drafts/draft-zhang-ppsp-pro=
blem-statement-03.txt" target=3D"_blank"><font face=3D"Verdana" size=3D"2">=
http://www.ietf.org/internet-drafts/draft-zhang-ppsp-problem-statement-03.t=
xt) </font></a><font face=3D"Verdana" size=3D"2">=A0which may related to=A0=
MMUSIC WG.Any comments and suggestions are highly welcome.</font>=20
<div><font face=3D"Verdana" size=3D"2">=A0=A0=A0=A0=A0=A0 The abstract is a=
s follows:</font></div>
<div>
<p style=3D"MARGIN: 0cm 0cm 12pt 21.6pt"><font face=3D"Verdana"><font size=
=3D"2"><span lang=3D"EN-US">We propose to develop an open peer-to-peer (</s=
pan><span lang=3D"EN-US">P2P)</span><span lang=3D"EN-US"> streaming protoco=
l named PPSP. This document describes the problems related to PPSP and outl=
ines considerations that have to be taken in account when arriving at equit=
able solutions.</span></font></font></p>

<p style=3D"MARGIN: 0cm 0cm 12pt 21.6pt"><font face=3D"Verdana"><font size=
=3D"2"><span lang=3D"EN-US"></span></font></font>=A0</p>
<p style=3D"MARGIN: 0cm 0cm 12pt 21.6pt"><font face=3D"Verdana"><font size=
=3D"2"><span lang=3D"EN-US">=A0=A0=A0=A0=A0=A0=A0=A0=A0 BR</span></font></f=
ont></p>
<p style=3D"MARGIN: 0cm 0cm 12pt 21.6pt"><font face=3D"Verdana"><font size=
=3D"2"><span lang=3D"EN-US">=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Yunfei<=
/span></font></font></p></div></div></div>

--000e0cd519bab5fed2046b4a8e99--

From ingemar.s.johansson@ericsson.com  Thu Jun  4 02:22:07 2009
Return-Path: <ingemar.s.johansson@ericsson.com>
X-Original-To: mmusic@core3.amsl.com
Delivered-To: mmusic@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E803E28C273 for <mmusic@core3.amsl.com>; Thu,  4 Jun 2009 02:22:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.649
X-Spam-Level: 
X-Spam-Status: No, score=-5.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2T+ylEBVt-bS for <mmusic@core3.amsl.com>; Thu,  4 Jun 2009 02:22:07 -0700 (PDT)
Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 7ACDC3A6DD6 for <mmusic@ietf.org>; Thu,  4 Jun 2009 02:22:06 -0700 (PDT)
X-AuditID: c1b4fb3e-b7b2dae00000205f-15-4a27923f2783
Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 7E.91.08287.F32972A4; Thu,  4 Jun 2009 11:22:07 +0200 (CEST)
Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 4 Jun 2009 11:20:54 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 4 Jun 2009 11:20:54 +0200
Message-ID: <130EBB38279E9847BAAAE0B8F9905F8C01427210@esealmw109.eemea.ericsson.se>
In-Reply-To: <130EBB38279E9847BAAAE0B8F9905F8C012A5320@esealmw109.eemea.ericsson.se>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Moving draft-ietf-mmusic-image-attributes (was RE: mmusic Digest, Vol 60, Issue 5)
Thread-Index: AcnNdciVKfEfWBdvRYy8+8d3GCS07AQZIC2QAcbXyLA=
References: <mailman.64.1240254008.28215.mmusic@ietf.org> <130EBB38279E9847BAAAE0B8F9905F8CFE7804@esealmw109.eemea.ericsson.se> <9AAEDF491EF7CA48AB587781B8F5D7C601C76FC8@srvxchg3.cablelabs.com> <4A0024D2.5020807@ericsson.com> <130EBB38279E9847BAAAE0B8F9905F8C012A5320@esealmw109.eemea.ericsson.se>
From: "Ingemar Johansson S" <ingemar.s.johansson@ericsson.com>
To: "Jean-Francois Mule" <jf.mule@cablelabs.com>, <jo@acm.org>
X-OriginalArrivalTime: 04 Jun 2009 09:20:54.0642 (UTC) FILETIME=[C2FF9520:01C9E4F5]
X-Brightmail-Tracker: AAAAAA==
Cc: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>, Magnus Westerlund <magnus.westerlund@ericsson.com>, mmusic@ietf.org, Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>
Subject: Re: [MMUSIC] Moving draft-ietf-mmusic-image-attributes (was RE: mmusic Digest, Vol 60, Issue 5)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Jun 2009 09:22:08 -0000

> -----Original Message-----
> From: Ingemar Johansson S=20
> Sent: den 26 maj 2009 10:31
> To: Jean-Francois Mule; jo@acm.org
> Cc: mmusic@ietf.org; Magnus Westerlund; Gonzalo Camarillo;=20
> kyunghun.jung@samsung.com; Ingemar Johansson S
> Subject: RE: Moving draft-ietf-mmusic-image-attributes (was=20
> RE: mmusic Digest, Vol 60, Issue 5)
>=20
> Hi
>=20
> In
> http://www.ietf.org/mail-archive/web/mmusic/current/msg07613.html
> Kyunghun Jung gave a response regarding 3GPP SA4s view on the draft.
>=20
> In
> http://www.ietf.org/mail-archive/web/mmusic/current/msg07614.html
> I beleieve I have clarified the issues that was raised during=20
> the AVT session and the discussion with Roni Even and=20
> Jonathan Lennox afterwards.
>=20
> With this in mind I would like to know what is missing in=20
> order to make this draft advance to WGLC.
>=20
> Regards
> Ingemar=20
> =20
>=20
> > -----Original Message-----
> > From: Gonzalo Camarillo
> > Sent: den 5 maj 2009 13:37
> > To: Jean-Francois Mule
> > Cc: Ingemar Johansson S; jo@acm.org; mmusic@ietf.org; Magnus=20
> > Westerlund
> > Subject: Re: Moving draft-ietf-mmusic-image-attributes (was
> > RE: mmusic Digest, Vol 60, Issue 5)
> >=20
> > Hi,
> >=20
> > yes, Jean Francois suggested way forward sounds perfect.=20
> > Let's make sure that whatever we advance in MMUSIC meets 3GPP's=20
> > expectations. They can review the drafts without the need=20
> of sending=20
> > LSs back and forth.
> >=20
> > Cheers,
> >=20
> > Gonzalo
> >=20
> > Jean-Francois Mule wrote:
> > > Ingemar,
> > >=20
> > >   Thank you for the ping and the updated draft.
> > >=20
> > >   Before issuing the WGLC, I would like to understand a=20
> few things,=20
> > > mostly because there has been limited to no traffic on this
> > draft on
> > > the MMUSIC list.
> > >=20
> > > 1) Follow-ups from IETF#74 in San Francisco You had asked a
> > bunch of
> > > questions in your presentation during the last mmusic meeting.
> > > On some, you got feedback from Roni Even, Jonathan Lennox
> > and others.
> > > Can you summarize the related changes if any and they=20
> address those=20
> > > comments? (Roni re: distortion, Jonathan Lennox re: sender
> > behavior to
> > > accommodate different behaviors for cases like when the source=20
> > > supports non squared pixels).
> > > Also, on a few other questions, there were no comments at
> > the mike and
> > > nothing on the list since the meeting.  Can you jot them
> > down outside
> > > ppt and generate or close some discussion points related to these?
> > >=20
> > >=20
> > > 2) 3GPP
> > > Finally MMUSIC had received a LS from 3GPP related to this=20
> > >=20
> (https://datatracker.ietf.org/documents/LIAISON/file541.doc).  The=20
> > > liaison had Magnus Westerlund and Kyunghun Jung as
> > technical contacts
> > > for 3GPP (K Jung is a co-author of the ID).  Has this work been=20
> > > reviewed there by folks who might use it?  Can some of these=20
> > > individuals send text to the IETF MMUSIC list to say they
> > review the
> > > document and think it is ready for WGLC.
> > > On behalf of MMUSIC, we can send a formal liaison back to=20
> 3GPP via=20
> > > Gonzalo anyway but if we get a sense that this draft=20
> meets the 3gpp=20
> > > requirements and folks are ok with the solution directly on
> > the MMUSIC
> > > list, we speed things up and avoid paperwork.
> > >=20
> > > Thanks,
> > > Jean-Francois.
> > > MMUSIC co-chair
> > >=20
> > >> -----Original Message-----
> > >> From: Ingemar Johansson S=20
> [mailto:ingemar.s.johansson@ericsson.com]
> > >> Sent: Monday, May 04, 2009 4:32 AM
> > >> To: jo@acm.org; Jean-Francois Mule
> > >> Cc: mmusic@ietf.org
> > >> Subject: RE: mmusic Digest, Vol 60, Issue 5
> > >>
> > >> Hi
> > >>
> > >> I would like to have draft-ietf-mmusic-image-attributes
> > advanced to
> > >> WGLC.
> > >>
> > >> Regards
> > >> Ingemar
> > >>>=20
> -----------------------------------------------------------------
> > >> -----
> > >>> Message: 1
> > >>> Date: Mon, 20 Apr 2009 12:56:37 +0200
> > >>> From: "Ingemar Johansson S" <ingemar.s.johansson@ericsson.com>
> > >>> Subject: Re: [MMUSIC] I-D
> > >>> 	Action:draft-ietf-mmusic-image-attributes-02.txt
> > >>> To: <mmusic@ietf.org>
> > >>> Message-ID:
> > >>>
> > >>>
> > >>=20
> <130EBB38279E9847BAAAE0B8F9905F8CE1D957@esealmw109.eemea.ericsson.s
> > >> e>
> > >>> Content-Type: text/plain;	charset=3D"us-ascii"
> > >>>
> > >>> Hi
> > >>>
> > >>> As you can see below, a new version of=20
> > >>> draft-ietf-mmusic-image-attributes has been submitted.
> > With this I
> > >>> would say that the open issues that was existing before
> > are resolved
> > >>> and that the document is ready for WGLC.
> > >>>
> > >>> Regards
> > >>> /Ingemar
> > >>>
> >=20
> >=20
>=20

From jan.lindquist@ericsson.com  Wed Jun 10 07:32:52 2009
Return-Path: <jan.lindquist@ericsson.com>
X-Original-To: mmusic@core3.amsl.com
Delivered-To: mmusic@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44BB328C1B8 for <mmusic@core3.amsl.com>; Wed, 10 Jun 2009 07:32:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.248
X-Spam-Level: 
X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YW4ZXMTA0YrL for <mmusic@core3.amsl.com>; Wed, 10 Jun 2009 07:32:50 -0700 (PDT)
Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id DF00528C1B2 for <mmusic@ietf.org>; Wed, 10 Jun 2009 07:32:49 -0700 (PDT)
X-AuditID: c1b4fb3c-b7b9cae00000140d-bc-4a2fc4159e80
Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id CC.92.05133.514CF2A4; Wed, 10 Jun 2009 16:32:54 +0200 (CEST)
Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Wed, 10 Jun 2009 16:32:53 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9E9D8.569658C1"
Date: Wed, 10 Jun 2009 16:32:52 +0200
Message-ID: <8FE6AA8853337149919BB383582462F7031BDF7F@esealmw106.eemea.ericsson.se>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: New draft on "SIP/SDP Overlap with RTSP"
Thread-Index: Acnp2FZObMEXJTJTS/qiz6Hjm65ZpA==
From: "Jan Lindquist" <jan.lindquist@ericsson.com>
To: <mmusic@ietf.org>
X-OriginalArrivalTime: 10 Jun 2009 14:32:53.0635 (UTC) FILETIME=[56DDBD30:01C9E9D8]
X-Brightmail-Tracker: AAAAAA==
Cc: xavier.marjou@orange-ftgroup.com, priyarajagopal@motorola.com
Subject: [MMUSIC] New draft on "SIP/SDP Overlap with RTSP"
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Jun 2009 14:32:52 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01C9E9D8.569658C1
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello,

A new draft has been uploaded titled "SIP/SDP Overlap with RTSP" =
(draft-lindquist-mmusic-sip-rtsp-00). The draft is co-signed by Jan =
Lindquist, Jouni Maenpaa, Priya Rajagopal and Xavier Marjou. A slot is =
requested in MMUSIC for the July Stockholm meeting to present the draft.

http://www3.ietf.org/proceedings/staging/draft-lindquist-mmusic-sip-rtsp-=
00.txt

For your convenience here is the abstract taken from the draft.

   The Session Initiation Protocol (SIP) is widely used for establishing
   multimedia sessions, whereas the Real Time Streaming Protocol (RTSP)
   is a protocol for use in streaming media systems.  RTSP has a dual
   role: it establishes a media session for the delivery of streaming
   media as well as controls the streaming session once it has been set
   up.  Since RTSP is also used for session establishment, there exists
   an overlap between the functionality provided by SIP and RTSP.  In
   this document, we analyze a model in which SIP and the SDP offer/
   answer model are used to set up a streaming session with an RTSP
   control channel and one or more media delivery streams.  Such a model
   is beneficial since it allows the reuse of current architecture and
   functionality (e.g., authentication, charging, and QoS) established
   around SIP also for RTSP-based streaming.

If there are any questions or comments on the new draft we will be glad =
to answer them.

Best Regards,
Jan Lindquist



------_=_NextPart_001_01C9E9D8.569658C1
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7654.12">
<TITLE>New draft on &quot;SIP/SDP Overlap with RTSP&quot;</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT SIZE=3D2 FACE=3D"Arial">Hello,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">A new draft has been uploaded titled =
&quot;SIP/SDP Overlap with RTSP&quot; =
(draft-lindquist-mmusic-sip-rtsp-00). The draft is co-signed by Jan =
Lindquist, Jouni Maenpaa, Priya Rajagopal and Xavier Marjou. A slot is =
requested in MMUSIC for the July Stockholm meeting to present the =
draft.</FONT></P>

<P><A =
HREF=3D"http://www3.ietf.org/proceedings/staging/draft-lindquist-mmusic-s=
ip-rtsp-00.txt"><U><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">http://www3.ietf.org/proceedings/staging/draft-lindquist-m=
music-sip-rtsp-00.txt</FONT></U></A>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">For your convenience here is the =
abstract taken from the draft.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; The Session Initiation =
Protocol (SIP) is widely used for establishing</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; multimedia sessions, =
whereas the Real Time Streaming Protocol (RTSP)</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; is a protocol for use in =
streaming media systems.&nbsp; RTSP has a dual</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; role: it establishes a =
media session for the delivery of streaming</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; media as well as controls =
the streaming session once it has been set</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; up.&nbsp; Since RTSP is =
also used for session establishment, there exists</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; an overlap between the =
functionality provided by SIP and RTSP.&nbsp; In</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; this document, we analyze =
a model in which SIP and the SDP offer/</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; answer model are used to =
set up a streaming session with an RTSP</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; control channel and one =
or more media delivery streams.&nbsp; Such a model</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; is beneficial since it =
allows the reuse of current architecture and</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; functionality (e.g., =
authentication, charging, and QoS) established</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; around SIP also for =
RTSP-based streaming.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">If there are any questions or comments =
on the new draft we will be glad to answer them.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Best Regards,</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Jan Lindquist</FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C9E9D8.569658C1--

From alex.giladi@gmail.com  Wed Jun 10 10:03:14 2009
Return-Path: <alex.giladi@gmail.com>
X-Original-To: mmusic@core3.amsl.com
Delivered-To: mmusic@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 838D028C23A for <mmusic@core3.amsl.com>; Wed, 10 Jun 2009 10:03:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fHInh+Kzw15a for <mmusic@core3.amsl.com>; Wed, 10 Jun 2009 10:03:13 -0700 (PDT)
Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by core3.amsl.com (Postfix) with ESMTP id 2E55A28C239 for <mmusic@ietf.org>; Wed, 10 Jun 2009 10:03:13 -0700 (PDT)
Received: by bwz9 with SMTP id 9so890351bwz.37 for <mmusic@ietf.org>; Wed, 10 Jun 2009 10:03:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=XEDD6ofQ1S+jolOKu46qOrCMbyWUok/Hr36PaiTDSks=; b=WCYLWZX7o4O9JFLQJaynAtG77lViXMwp5ugTYR0BZbAFQlkXLwh2pA+1LlBVwxi6DV vPWgrEnc/d2RT/K9n2wFMdxLWYNFDM9ZIJDoctyV2euIaC1kthrW/luK3Gb5J5lYyCLt Wi25J6dlSwESAYIfc58OkAUeIhZV8vyfvPKkI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=X9EHYtlJJuhdoG0dYNrFOCP3NMmaUBwMR5n1sPdsLN5xGqgyrY1gWxZGWUBEFClkmH C9KZMNP76Du284KhZOMuYGC93XKip3eu8MuLpfxgHFDO2TgZXgTJfD7b8OjkrgESi7wB nt/e0WwURiBo+B6iIEBw5iucEMW8KpVJ7jmIs=
MIME-Version: 1.0
Received: by 10.204.69.66 with SMTP id y2mr1507259bki.49.1244653396967; Wed,  10 Jun 2009 10:03:16 -0700 (PDT)
In-Reply-To: <8FE6AA8853337149919BB383582462F7031BDF7F@esealmw106.eemea.ericsson.se>
References: <8FE6AA8853337149919BB383582462F7031BDF7F@esealmw106.eemea.ericsson.se>
Date: Wed, 10 Jun 2009 11:03:16 -0600
Message-ID: <57a9e15d0906101003g4059ca22ib8859eb7cb6e65cd@mail.gmail.com>
From: Alex Giladi <alex.giladi@gmail.com>
To: Jan Lindquist <jan.lindquist@ericsson.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: xavier.marjou@orange-ftgroup.com, mmusic@ietf.org, priyarajagopal@motorola.com
Subject: Re: [MMUSIC] New draft on "SIP/SDP Overlap with RTSP"
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Jun 2009 17:03:14 -0000

Jan,
A couple of comments:
In 7, you have an additional method of reserving / releasing resources
on the media server. However, after a TEARDOWN session is most
probably already invalid (see 10.7 in RFC2326), its resources invalid,
and issuing a TEARDOWN with a non-existent session id may actually
break an unsuspecting RTSP server.
Resource allocation at the VoD server side regularly happens as a part
of SETUP. It is AFAIK perfectly legal to issue SETUP with a Session
header, so you can easily generate session ID at the controller.
Also, you only consider the case of orderly session termination.
However you may have to drop the session at the server (e.g. you have
reached the end of your VoD content).
Regards,
Alex.


On Wed, Jun 10, 2009 at 8:32 AM, Jan
Lindquist<jan.lindquist@ericsson.com> wrote:
> Hello,
>
> A new draft has been uploaded titled "SIP/SDP Overlap with RTSP"
> (draft-lindquist-mmusic-sip-rtsp-00). The draft is co-signed by Jan
> Lindquist, Jouni Maenpaa, Priya Rajagopal and Xavier Marjou. A slot is
> requested in MMUSIC for the July Stockholm meeting to present the draft.
>
> http://www3.ietf.org/proceedings/staging/draft-lindquist-mmusic-sip-rtsp-=
00.txt
>
> For your convenience here is the abstract taken from the draft.
>
> =C2=A0=C2=A0 The Session Initiation Protocol (SIP) is widely used for est=
ablishing
> =C2=A0=C2=A0 multimedia sessions, whereas the Real Time Streaming Protoco=
l (RTSP)
> =C2=A0=C2=A0 is a protocol for use in streaming media systems.=C2=A0 RTSP=
 has a dual
> =C2=A0=C2=A0 role: it establishes a media session for the delivery of str=
eaming
> =C2=A0=C2=A0 media as well as controls the streaming session once it has =
been set
> =C2=A0=C2=A0 up.=C2=A0 Since RTSP is also used for session establishment,=
 there exists
> =C2=A0=C2=A0 an overlap between the functionality provided by SIP and RTS=
P.=C2=A0 In
> =C2=A0=C2=A0 this document, we analyze a model in which SIP and the SDP o=
ffer/
> =C2=A0=C2=A0 answer model are used to set up a streaming session with an =
RTSP
> =C2=A0=C2=A0 control channel and one or more media delivery streams.=C2=
=A0 Such a model
> =C2=A0=C2=A0 is beneficial since it allows the reuse of current architect=
ure and
> =C2=A0=C2=A0 functionality (e.g., authentication, charging, and QoS) esta=
blished
> =C2=A0=C2=A0 around SIP also for RTSP-based streaming.
>
> If there are any questions or comments on the new draft we will be glad t=
o
> answer them.
>
> Best Regards,
> Jan Lindquist
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>
>

From philip_matthews@magma.ca  Wed Jun 10 18:03:13 2009
Return-Path: <philip_matthews@magma.ca>
X-Original-To: mmusic@core3.amsl.com
Delivered-To: mmusic@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B167C3A692E for <mmusic@core3.amsl.com>; Wed, 10 Jun 2009 18:03:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7jBS+lS6nu4v for <mmusic@core3.amsl.com>; Wed, 10 Jun 2009 18:03:12 -0700 (PDT)
Received: from mail-09.primus.ca (mail10.primus.ca [216.254.141.177]) by core3.amsl.com (Postfix) with ESMTP id BE9AC3A692C for <mmusic@ietf.org>; Wed, 10 Jun 2009 18:03:12 -0700 (PDT)
Received: from [24.139.16.154] (helo=[10.0.1.2]) by mail-09.primus.ca with esmtpa (Exim 4.69) (envelope-from <philip_matthews@magma.ca>) id 1MEYhL-0001Fp-1p; Wed, 10 Jun 2009 21:03:19 -0400
Message-Id: <A9F9D2ED-1379-4114-9F6B-B05AD44B6E09@magma.ca>
From: Philip Matthews <philip_matthews@magma.ca>
To: Simon Perreault <simon.perreault@viagenie.ca>
In-Reply-To: <4A109F75.6060406@viagenie.ca>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Wed, 10 Jun 2009 18:25:17 -0400
References: <4A109F75.6060406@viagenie.ca>
X-Mailer: Apple Mail (2.929.2)
X-Authenticated: philip_matthews@magma.ca - ([10.0.1.2]) [24.139.16.154]
Cc: mmusic WG <mmusic@ietf.org>
Subject: Re: [MMUSIC] ICE + TURN permissions
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Jun 2009 01:03:13 -0000

Yes.
This is one of the things that needs to be added before the ICE spec  
gets published.

- Philip

On Sun, 17-May-09, at 19:36 , Simon Perreault wrote:

> Hello,
>
> ICE doesn't mention how the UA installs permissions related to the  
> TURN
> allocation. It definitely should. I think it doesn't because explicit
> TURN permissions are a fairly new feature, departing from the original
> implicit permissions model.
>
> Thanks,
> Simon
> -- 
> STUN/TURN server    --> http://numb.viagenie.ca
> Interplanetary news --> http://reeves.viagenie.ca
> vCard 4.0           --> http://www.vcarddav.org
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>


From jan.lindquist@ericsson.com  Thu Jun 11 00:34:56 2009
Return-Path: <jan.lindquist@ericsson.com>
X-Original-To: mmusic@core3.amsl.com
Delivered-To: mmusic@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 662813A6899 for <mmusic@core3.amsl.com>; Thu, 11 Jun 2009 00:34:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G0djQST-1Zty for <mmusic@core3.amsl.com>; Thu, 11 Jun 2009 00:34:55 -0700 (PDT)
Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id C31613A67A1 for <mmusic@ietf.org>; Thu, 11 Jun 2009 00:34:54 -0700 (PDT)
X-AuditID: c1b4fb3c-b7b9cae00000140d-b7-4a30b3a379bc
Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 81.68.05133.3A3B03A4; Thu, 11 Jun 2009 09:34:59 +0200 (CEST)
Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 11 Jun 2009 09:34:57 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 11 Jun 2009 09:30:38 +0200
Message-ID: <8FE6AA8853337149919BB383582462F7031BE3DF@esealmw106.eemea.ericsson.se>
In-Reply-To: <57a9e15d0906101003g4059ca22ib8859eb7cb6e65cd@mail.gmail.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [MMUSIC] New draft on "SIP/SDP Overlap with RTSP"
Thread-Index: Acnp7Vnv+prJcCu6Tb20OTg9dD5D6QAdzxGw
References: <8FE6AA8853337149919BB383582462F7031BDF7F@esealmw106.eemea.ericsson.se> <57a9e15d0906101003g4059ca22ib8859eb7cb6e65cd@mail.gmail.com>
From: "Jan Lindquist" <jan.lindquist@ericsson.com>
To: "Alex Giladi" <alex.giladi@gmail.com>
X-OriginalArrivalTime: 11 Jun 2009 07:34:57.0451 (UTC) FILETIME=[1EB577B0:01C9EA67]
X-Brightmail-Tracker: AAAAAA==
Cc: xavier.marjou@orange-ftgroup.com, mmusic@ietf.org, priyarajagopal@motorola.com
Subject: Re: [MMUSIC] New draft on "SIP/SDP Overlap with RTSP"
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Jun 2009 07:34:56 -0000

Hello Alex,

Thanks for the comments.

On the question of resource release I agree that a Media Server would =
release the resources at Teardown. We tried to generalize the actions on =
the Media Server. There might be a proxy for all communicaton to the =
Media Server so neither the Controller or UE signal directly to the =
Media Server but through a proxy component. On the other hand there =
could be a seperation of signalling where the controller wants to have =
control of preparing the resource and the release. This is what the =
signal flows show.

As for the Media Server dropping the session due to end of stream I =
would refer to the usage of ANNOUNCE or RTSPv2 PLAY_NOTIFY. Sessions are =
not simply dropped but in my view should be triggered by the UE after =
getting the notification. The UE may want to rewind or start from the =
initial position

Best regards,
JanL

> -----Original Message-----
> From: Alex Giladi [mailto:alex.giladi@gmail.com]=20
> Sent: den 10 juni 2009 19:03
> To: Jan Lindquist
> Cc: mmusic@ietf.org; xavier.marjou@orange-ftgroup.com;=20
> priyarajagopal@motorola.com
> Subject: Re: [MMUSIC] New draft on "SIP/SDP Overlap with RTSP"
>=20
> Jan,
> A couple of comments:
> In 7, you have an additional method of reserving / releasing=20
> resources on the media server. However, after a TEARDOWN=20
> session is most probably already invalid (see 10.7 in=20
> RFC2326), its resources invalid, and issuing a TEARDOWN with=20
> a non-existent session id may actually break an unsuspecting=20
> RTSP server.
> Resource allocation at the VoD server side regularly happens=20
> as a part of SETUP. It is AFAIK perfectly legal to issue=20
> SETUP with a Session header, so you can easily generate=20
> session ID at the controller.
> Also, you only consider the case of orderly session termination.
> However you may have to drop the session at the server (e.g.=20
> you have reached the end of your VoD content).
> Regards,
> Alex.
>=20
>=20
> On Wed, Jun 10, 2009 at 8:32 AM, Jan
> Lindquist<jan.lindquist@ericsson.com> wrote:
> > Hello,
> >
> > A new draft has been uploaded titled "SIP/SDP Overlap with RTSP"
> > (draft-lindquist-mmusic-sip-rtsp-00). The draft is co-signed by Jan=20
> > Lindquist, Jouni Maenpaa, Priya Rajagopal and Xavier=20
> Marjou. A slot is=20
> > requested in MMUSIC for the July Stockholm meeting to=20
> present the draft.
> >
> >=20
> http://www3.ietf.org/proceedings/staging/draft-lindquist-mmusic-sip-rt
> > sp-00.txt
> >
> > For your convenience here is the abstract taken from the draft.
> >
> > =A0=A0 The Session Initiation Protocol (SIP) is widely used for=20
> > establishing
> > =A0=A0 multimedia sessions, whereas the Real Time Streaming Protocol =

> > (RTSP)
> > =A0=A0 is a protocol for use in streaming media systems.=A0 RTSP=20
> has a dual
> > =A0=A0 role: it establishes a media session for the delivery of=20
> streaming
> > =A0=A0 media as well as controls the streaming session once it has =
been=20
> > set
> > =A0=A0 up.=A0 Since RTSP is also used for session establishment, =
there=20
> > exists
> > =A0=A0 an overlap between the functionality provided by SIP and=20
> RTSP.=A0 In
> > =A0=A0 this document, we analyze a model in which SIP and the SDP =
offer/
> > =A0=A0 answer model are used to set up a streaming session with an =
RTSP
> > =A0=A0 control channel and one or more media delivery streams.=A0 =
Such a=20
> > model
> > =A0=A0 is beneficial since it allows the reuse of current=20
> architecture and
> > =A0=A0 functionality (e.g., authentication, charging, and QoS)=20
> established
> > =A0=A0 around SIP also for RTSP-based streaming.
> >
> > If there are any questions or comments on the new draft we will be=20
> > glad to answer them.
> >
> > Best Regards,
> > Jan Lindquist
> >
> > _______________________________________________
> > mmusic mailing list
> > mmusic@ietf.org
> > https://www.ietf.org/mailman/listinfo/mmusic
> >
> >
>=20

From jf.mule@cablelabs.com  Tue Jun 16 13:10:41 2009
Return-Path: <jf.mule@cablelabs.com>
X-Original-To: mmusic@core3.amsl.com
Delivered-To: mmusic@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 221F23A6B2F for <mmusic@core3.amsl.com>; Tue, 16 Jun 2009 13:10:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.363
X-Spam-Level: 
X-Spam-Status: No, score=-0.363 tagged_above=-999 required=5 tests=[AWL=0.100,  BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fffIEoXynS2a for <mmusic@core3.amsl.com>; Tue, 16 Jun 2009 13:10:40 -0700 (PDT)
Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 463393A68B1 for <mmusic@ietf.org>; Tue, 16 Jun 2009 13:10:40 -0700 (PDT)
Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.3/8.14.3) with ESMTP id n5GKAW7Q003881; Tue, 16 Jun 2009 14:10:32 -0600
Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Tue, 16 Jun 2009 14:10:33 -0700 (MST)
X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 16 Jun 2009 14:10:00 -0600
Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C601EED279@srvxchg3.cablelabs.com>
In-Reply-To: <A9F9D2ED-1379-4114-9F6B-B05AD44B6E09@magma.ca>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [MMUSIC] ICE + TURN permissions -- propose text addition to the list
Thread-Index: AcnqMGtHW4ZbJLPrSWiyAC0SSsQFNwEjVywg
References: <4A109F75.6060406@viagenie.ca> <A9F9D2ED-1379-4114-9F6B-B05AD44B6E09@magma.ca>
From: "Jean-Francois Mule" <jf.mule@cablelabs.com>
To: "Philip Matthews" <philip_matthews@magma.ca>, "Simon Perreault" <simon.perreault@viagenie.ca>
X-Approved: ondar
Cc: draft-ietf-mmusic-ice@tools.ietf.org, mmusic WG <mmusic@ietf.org>
Subject: Re: [MMUSIC] ICE + TURN permissions -- propose text addition to the list
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Jun 2009 20:10:41 -0000

Hi,

   Can one of you propose some text changes to the list to address this
issue re: UA and explicit TURN permissions (section, new proposed txt,
etc)?
Just want to make sure this gets reviewed given the late stage and
recorded by Jonathan.

Thanks,
Jean-Francois


> -----Original Message-----
> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On
> Behalf Of Philip Matthews
> Sent: Wednesday, June 10, 2009 4:25 PM
> To: Simon Perreault
> Cc: mmusic WG
> Subject: Re: [MMUSIC] ICE + TURN permissions
>=20
> Yes.
> This is one of the things that needs to be added before the ICE
> spec
> gets published.
>=20
> - Philip
>=20
> On Sun, 17-May-09, at 19:36 , Simon Perreault wrote:
>=20
> > Hello,
> >
> > ICE doesn't mention how the UA installs permissions related to
> the
> > TURN
> > allocation. It definitely should. I think it doesn't because
> explicit
> > TURN permissions are a fairly new feature, departing from the
> original
> > implicit permissions model.
> >
> > Thanks,
> > Simon
> > --
> > STUN/TURN server    --> http://numb.viagenie.ca
> > Interplanetary news --> http://reeves.viagenie.ca
> > vCard 4.0           --> http://www.vcarddav.org
> > _______________________________________________
> > mmusic mailing list
> > mmusic@ietf.org
> > https://www.ietf.org/mailman/listinfo/mmusic
> >
>=20
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic

From jan.lindquist@ericsson.com  Wed Jun 17 07:16:54 2009
Return-Path: <jan.lindquist@ericsson.com>
X-Original-To: mmusic@core3.amsl.com
Delivered-To: mmusic@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED6EA3A6E6B for <mmusic@core3.amsl.com>; Wed, 17 Jun 2009 07:16:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.248
X-Spam-Level: 
X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1sqzkbtmyDp for <mmusic@core3.amsl.com>; Wed, 17 Jun 2009 07:16:54 -0700 (PDT)
Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 599B23A6E5E for <mmusic@ietf.org>; Wed, 17 Jun 2009 07:16:52 -0700 (PDT)
X-AuditID: c1b4fb3c-b7b0bae00000673a-3f-4a38fa9b8a70
Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 75.81.26426.B9AF83A4; Wed, 17 Jun 2009 16:15:56 +0200 (CEST)
Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Wed, 17 Jun 2009 16:15:41 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9EF56.181B1343"
Date: Wed, 17 Jun 2009 16:15:40 +0200
Message-ID: <8FE6AA8853337149919BB383582462F703278096@esealmw106.eemea.ericsson.se>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: New draft on "SIP/SDP Overlap with RTSP"
Thread-Index: Acnp2FZObMEXJTJTS/qiz6Hjm65ZpAFWNAsg
From: "Jan Lindquist" <jan.lindquist@ericsson.com>
To: "Jan Lindquist" <jan.lindquist@ericsson.com>, <mmusic@ietf.org>
X-OriginalArrivalTime: 17 Jun 2009 14:15:41.0773 (UTC) FILETIME=[18B857D0:01C9EF56]
X-Brightmail-Tracker: AAAAAA==
Cc: xavier.marjou@orange-ftgroup.com, priyarajagopal@motorola.com
Subject: Re: [MMUSIC] New draft on "SIP/SDP Overlap with RTSP"
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Jun 2009 14:16:55 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01C9EF56.181B1343
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello,

A new link is provided to draft. Note that the submission date of the =
draft has changed since the previously uploaded draft.=20

http://www.ietf.org/internet-drafts/draft-lindquist-mmusic-sip-rtsp-00.tx=
t


Best Regards,
JanL

PS- The reason for change in submission date was due to the portal for =
uploading drafts silently rejected the upload. The rejection was due to =
date uploaded was off by more than 3 days from the date in the draft.


> _____________________________________________=20
> From: 	Jan Lindquist =20
> Sent:	den 10 juni 2009 17:33
> To:	'mmusic@ietf.org'
> Cc:	priyarajagopal@motorola.com; 'xavier.marjou@orange-ftgroup.com'; =
Jouni M=E4enp=E4=E4
> Subject:	New draft on "SIP/SDP Overlap with RTSP"
>=20
> Hello,
>=20
> A new draft has been uploaded titled "SIP/SDP Overlap with RTSP" =
(draft-lindquist-mmusic-sip-rtsp-00). The draft is co-signed by Jan =
Lindquist, Jouni Maenpaa, Priya Rajagopal and Xavier Marjou. A slot is =
requested in MMUSIC for the July Stockholm meeting to present the draft.
>=20
> =
http://www3.ietf.org/proceedings/staging/draft-lindquist-mmusic-sip-rtsp-=
00.txt
>=20
> For your convenience here is the abstract taken from the draft.
>=20
>    The Session Initiation Protocol (SIP) is widely used for =
establishing
>    multimedia sessions, whereas the Real Time Streaming Protocol =
(RTSP)
>    is a protocol for use in streaming media systems.  RTSP has a dual
>    role: it establishes a media session for the delivery of streaming
>    media as well as controls the streaming session once it has been =
set
>    up.  Since RTSP is also used for session establishment, there =
exists
>    an overlap between the functionality provided by SIP and RTSP.  In
>    this document, we analyze a model in which SIP and the SDP offer/
>    answer model are used to set up a streaming session with an RTSP
>    control channel and one or more media delivery streams.  Such a =
model
>    is beneficial since it allows the reuse of current architecture and
>    functionality (e.g., authentication, charging, and QoS) established
>    around SIP also for RTSP-based streaming.
>=20
> If there are any questions or comments on the new draft we will be =
glad to answer them.
>=20
> Best Regards,
> Jan Lindquist
>=20
>=20

------_=_NextPart_001_01C9EF56.181B1343
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7654.12">
<TITLE>RE: New draft on &quot;SIP/SDP Overlap with RTSP&quot;</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Hello,</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">A new link is =
provided to draft. Note that the submission date of the draft has =
changed since the previously uploaded draft. </FONT></P>

<P><A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-lindquist-mmusic-sip-rt=
sp-00.txt"><U></U><U><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier =
New">http://www.ietf.org/internet-drafts/draft-lindquist-mmusic-sip-rtsp-=
00.txt</FONT></U></A>
</P>
<BR>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Best Regards,</FONT>

<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">JanL</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">PS- The reason for =
change in submission date was due to the portal for uploading drafts =
silently rejected the upload. The rejection was due to date uploaded was =
off by more than 3 days from the date in the draft.</FONT></P>
<BR>
<UL>
<P><FONT SIZE=3D1 =
FACE=3D"Tahoma">_____________________________________________ </FONT>

<BR><B><FONT SIZE=3D1 FACE=3D"Tahoma">From: &nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Tahoma">Jan Lindquist&nbsp; </FONT>

<BR><B><FONT SIZE=3D1 FACE=3D"Tahoma">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Tahoma">den 10 juni 2009 17:33</FONT>

<BR><B><FONT SIZE=3D1 =
FACE=3D"Tahoma">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Tahoma">'mmusic@ietf.org'</FONT>

<BR><B><FONT SIZE=3D1 =
FACE=3D"Tahoma">Cc:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Tahoma">priyarajagopal@motorola.com; =
'xavier.marjou@orange-ftgroup.com'; Jouni M=E4enp=E4=E4</FONT>

<BR><B><FONT SIZE=3D1 =
FACE=3D"Tahoma">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Tahoma">New draft on &quot;SIP/SDP Overlap =
with RTSP&quot;</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Hello,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">A new draft has been uploaded titled =
&quot;SIP/SDP Overlap with RTSP&quot; =
(draft-lindquist-mmusic-sip-rtsp-00). The draft is co-signed by Jan =
Lindquist, Jouni Maenpaa, Priya Rajagopal and Xavier Marjou. A slot is =
requested in MMUSIC for the July Stockholm meeting to present the =
draft.</FONT></P>

<P><A =
HREF=3D"http://www3.ietf.org/proceedings/staging/draft-lindquist-mmusic-s=
ip-rtsp-00.txt"><U><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">http://www3.ietf.org/proceedings/staging/draft-lindquist-m=
music-sip-rtsp-00.txt</FONT></U></A>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">For your convenience here is the =
abstract taken from the draft.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; The Session Initiation =
Protocol (SIP) is widely used for establishing</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; multimedia sessions, =
whereas the Real Time Streaming Protocol (RTSP)</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; is a protocol for use in =
streaming media systems.&nbsp; RTSP has a dual</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; role: it establishes a =
media session for the delivery of streaming</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; media as well as controls =
the streaming session once it has been set</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; up.&nbsp; Since RTSP is =
also used for session establishment, there exists</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; an overlap between the =
functionality provided by SIP and RTSP.&nbsp; In</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; this document, we analyze =
a model in which SIP and the SDP offer/</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; answer model are used to =
set up a streaming session with an RTSP</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; control channel and one =
or more media delivery streams.&nbsp; Such a model</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; is beneficial since it =
allows the reuse of current architecture and</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; functionality (e.g., =
authentication, charging, and QoS) established</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; around SIP also for =
RTSP-based streaming.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">If there are any questions or comments =
on the new draft we will be glad to answer them.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Best Regards,</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Jan Lindquist</FONT>
</P>
<BR>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01C9EF56.181B1343--

From simon.perreault@viagenie.ca  Wed Jun 17 16:48:53 2009
Return-Path: <simon.perreault@viagenie.ca>
X-Original-To: mmusic@core3.amsl.com
Delivered-To: mmusic@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 543663A689D for <mmusic@core3.amsl.com>; Wed, 17 Jun 2009 16:48:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.176
X-Spam-Level: 
X-Spam-Status: No, score=-0.176 tagged_above=-999 required=5 tests=[AWL=-0.269, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qqyAx2PovtC3 for <mmusic@core3.amsl.com>; Wed, 17 Jun 2009 16:48:52 -0700 (PDT)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 235213A689C for <mmusic@ietf.org>; Wed, 17 Jun 2009 16:48:52 -0700 (PDT)
Received: by jazz.viagenie.ca (Postfix, from userid 8) id 0803329E15D3; Wed, 17 Jun 2009 19:49:04 -0400 (EDT)
Received: from balaise.nomis80.org (ip216-239-75-191.vif.net [216.239.75.191]) by jazz.viagenie.ca (Postfix) with ESMTP id 999FC29E156C; Wed, 17 Jun 2009 19:49:03 -0400 (EDT)
Message-ID: <4A3980EE.8030803@viagenie.ca>
Date: Wed, 17 Jun 2009 19:49:02 -0400
From: Simon Perreault <simon.perreault@viagenie.ca>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b3pre) Gecko/20090513 Fedora/3.0-2.3.beta2.fc11 Thunderbird/3.0b2
MIME-Version: 1.0
To: Jean-Francois Mule <jf.mule@cablelabs.com>
References: <4A109F75.6060406@viagenie.ca> <A9F9D2ED-1379-4114-9F6B-B05AD44B6E09@magma.ca> <9AAEDF491EF7CA48AB587781B8F5D7C601EED279@srvxchg3.cablelabs.com>
In-Reply-To: <9AAEDF491EF7CA48AB587781B8F5D7C601EED279@srvxchg3.cablelabs.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: draft-ietf-mmusic-ice@tools.ietf.org, Philip Matthews <philip_matthews@magma.ca>, mmusic WG <mmusic@ietf.org>
Subject: Re: [MMUSIC] ICE + TURN permissions -- propose text addition to the list
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Jun 2009 23:48:53 -0000

On 06/16/2009 04:10 PM, Jean-Francois Mule wrote:
>     Can one of you propose some text changes to the list to address this
> issue re: UA and explicit TURN permissions (section, new proposed txt,
> etc)?

Let me take a shot at it...

- Create a new section between 5.3 and 5.4 with the following text:

-----------------------------------------------------------------------
5.4. Installing TURN Permissions

If relayed candidates have been gathered, it is necessary to install or 
refresh permissions on the TURN allocations for the offerer's 
candidates. The agent MUST send a CreatePermission request (see 
[draft-ietf-behave-turn-15], Section 9) to each TURN server on which it 
gathered a relayed candidate. Each candidate received from the offerer 
is encoded as a XOR-PEER-ADDRESS parameter.

5.4.1 Keeping Permissions Alive

Once permissions are installed, they MUST be kept alive until ICE 
processing has completed, as described in Section 8.3. The keepalive 
MUST be a CreatePermission request. Once ICE processing has completed, 
the agent MAY bind a channel to the nominated remote candidate using the 
ChannelBind request if the nominated local candidate is relayed. From 
this moment, the keepalive MUST be a ChannelBind request.
-----------------------------------------------------------------------

- Create a new section between 6.2 and 6.3 with the following text:

-----------------------------------------------------------------------
6.3. Installing TURN Permissions

The process for installing TURN permissions at the offerer is identical 
to the process followed by the answerer, as described in Section 5.4.
-----------------------------------------------------------------------

Simon
-- 
STUN/TURN server    --> http://numb.viagenie.ca
Interplanetary news --> http://reeves.viagenie.ca
vCard 4.0           --> http://www.vcarddav.org

From root@core3.amsl.com  Wed Jun 17 19:30:01 2009
Return-Path: <root@core3.amsl.com>
X-Original-To: mmusic@ietf.org
Delivered-To: mmusic@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 0) id A7A313A6EDE; Wed, 17 Jun 2009 19:30:01 -0700 (PDT)
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20090618023001.A7A313A6EDE@core3.amsl.com>
Date: Wed, 17 Jun 2009 19:30:01 -0700 (PDT)
Cc: mmusic@ietf.org
Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-cs-01.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Jun 2009 02:30:01 -0000

--NextPart

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 Media Streams Over Circuit-Switched Bearers In The Public Switched Telephone Network (PSTN)
	Author(s)	: M. Garcia-Martin, S. Veikkolainen
	Filename	: draft-ietf-mmusic-sdp-cs-01.txt
	Pages		: 25
	Date		: 2009-6-17
	
This memo describes use cases, requirements, and protocol extensions
   for using the Session Description Protocol (SDP) Offer/Answer model
   for establishing audio media stream 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-01.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.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-sdp-cs-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2009-6-17191951.I-D@ietf.org>


--NextPart--


From Simo.Veikkolainen@nokia.com  Thu Jun 18 01:00:08 2009
Return-Path: <Simo.Veikkolainen@nokia.com>
X-Original-To: mmusic@core3.amsl.com
Delivered-To: mmusic@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE2FA3A6B69 for <mmusic@core3.amsl.com>; Thu, 18 Jun 2009 01:00:08 -0700 (PDT)
X-Quarantine-ID: <xVjYeXesIwwI>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER, MIME error: error: illegal encoding [base64] for MIME type message/external-body
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xVjYeXesIwwI for <mmusic@core3.amsl.com>; Thu, 18 Jun 2009 01:00:07 -0700 (PDT)
Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 714FF3A69A1 for <mmusic@ietf.org>; Thu, 18 Jun 2009 01:00:06 -0700 (PDT)
Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n5I806L4009123; Thu, 18 Jun 2009 11:00:10 +0300
Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 18 Jun 2009 11:00:04 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 18 Jun 2009 11:00:00 +0300
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Thu, 18 Jun 2009 09:59:58 +0200
From: <Simo.Veikkolainen@nokia.com>
To: <mmusic@ietf.org>
Date: Thu, 18 Jun 2009 09:59:57 +0200
Thread-Topic: I-D ACTION:draft-ietf-mmusic-sdp-cs-01.txt 
Thread-Index: AcnvvNGDfqgSPD1LTIy0U6kWSQ3DnwALblwg
Message-ID: <B23B311878A0B4438F5F09F47E01AAE03A6D2C4917@NOK-EUMSG-01.mgdnok.nokia.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/mixed; boundary="_003_B23B311878A0B4438F5F09F47E01AAE03A6D2C4917NOKEUMSG01mgd_"
MIME-Version: 1.0
X-OriginalArrivalTime: 18 Jun 2009 08:00:00.0356 (UTC) FILETIME=[C766D240:01C9EFEA]
X-Nokia-AV: Clean
Subject: [MMUSIC] FW: I-D ACTION:draft-ietf-mmusic-sdp-cs-01.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Jun 2009 08:00:08 -0000

--_003_B23B311878A0B4438F5F09F47E01AAE03A6D2C4917NOKEUMSG01mgd_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

We submitted a new version of draft-ietf-mmusic-sdp-cs which adds some text=
 to address John's comments on how to behave when no correlation informatio=
n is received in the CS call setup, and on security considerations. =20

Further comments are very welcome!

Regards,
Simo

>-----Original Message-----
>From: i-d-announce-bounces@ietf.org=20
>[mailto:i-d-announce-bounces@ietf.org] On Behalf Of ext=20
>Internet-Drafts@ietf.org
>Sent: 18 June, 2009 05:30
>To: i-d-announce@ietf.org
>Cc: mmusic@ietf.org
>Subject: I-D ACTION:draft-ietf-mmusic-sdp-cs-01.txt=20
>
>A New Internet-Draft is available from the on-line=20
>Internet-Drafts directories.
>This draft is a work item of the Multiparty Multimedia Session=20
>Control Working Group of the IETF.
>
>	Title		: Session Description Protocol (SDP)=20
>Extension For Setting Up Audio Media Streams Over=20
>Circuit-Switched Bearers In The Public Switched Telephone=20
>Network (PSTN)
>	Author(s)	: M. Garcia-Martin, S. Veikkolainen
>	Filename	: draft-ietf-mmusic-sdp-cs-01.txt
>	Pages		: 25
>	Date		: 2009-6-17
>=09
>This memo describes use cases, requirements, and protocol extensions
>   for using the Session Description Protocol (SDP) Offer/Answer model
>   for establishing audio media stream 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-01.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=20
>reader implementation to automatically retrieve the ASCII=20
>version of the Internet-Draft.
>=

--_003_B23B311878A0B4438F5F09F47E01AAE03A6D2C4917NOKEUMSG01mgd_
Content-Type: message/external-body; name="draft-ietf-mmusic-sdp-cs-01.url"
Content-Description: draft-ietf-mmusic-sdp-cs-01.url
Content-Disposition: attachment; filename="draft-ietf-mmusic-sdp-cs-01.url";
	size=92; creation-date="Thu, 18 Jun 2009 04:31:00 GMT";
	modification-date="Thu, 18 Jun 2009 04:31:00 GMT"
Content-Transfer-Encoding: base64


W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0
cy9kcmFmdC1pZXRmLW1tdXNpYy1zZHAtY3MtMDEudHh0DQo=

--_003_B23B311878A0B4438F5F09F47E01AAE03A6D2C4917NOKEUMSG01mgd_
Content-Type: text/plain; name="ATT00001.txt"
Content-Description: ATT00001.txt
Content-Disposition: attachment; filename="ATT00001.txt"; size=258;
	creation-date="Thu, 18 Jun 2009 04:31:00 GMT";
	modification-date="Thu, 18 Jun 2009 04:31:00 GMT"
Content-Transfer-Encoding: base64

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v
dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0
Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCkludGVybmV0LURyYWZ0IGRpcmVj
dG9yaWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sDQpvciBmdHA6Ly9mdHAuaWV0
Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0K

--_003_B23B311878A0B4438F5F09F47E01AAE03A6D2C4917NOKEUMSG01mgd_--

From root@core3.amsl.com  Fri Jun 19 06:30:01 2009
Return-Path: <root@core3.amsl.com>
X-Original-To: mmusic@ietf.org
Delivered-To: mmusic@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 0) id 9387C3A69C5; Fri, 19 Jun 2009 06:30:01 -0700 (PDT)
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20090619133001.9387C3A69C5@core3.amsl.com>
Date: Fri, 19 Jun 2009 06:30:01 -0700 (PDT)
Cc: mmusic@ietf.org
Subject: [MMUSIC] I-D Action:draft-ietf-mmusic-rfc2326bis-21.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Jun 2009 13:30:01 -0000

--NextPart

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           : Real Time Streaming Protocol 2.0 (RTSP)
	Author(s)       : H. Schulzrinne, et al.
	Filename        : draft-ietf-mmusic-rfc2326bis-21.txt
	Pages           : 283
	Date            : 2009-06-19

This memorandum defines RTSP version 2.0 which obsoletes RTSP version
1.0 which is defined in RFC 2326.

The Real Time Streaming Protocol, or RTSP, is an application-level
protocol for setup and control of the delivery of data with real-time
properties.  RTSP provides an extensible framework to enable
controlled, on-demand delivery of real-time data, such as audio and
video.  Sources of data can include both live data feeds and stored
clips.  This protocol is intended to control multiple data delivery
sessions, provide a means for choosing delivery channels such as UDP,
multicast UDP and TCP, and provide a means for choosing delivery
mechanisms based upon RTP (RFC 3550).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rfc2326bis-21.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.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-rfc2326bis-21.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2009-06-19062747.I-D@ietf.org>


--NextPart--

From Stiemerling@nw.neclab.eu  Fri Jun 19 06:35:18 2009
Return-Path: <Stiemerling@nw.neclab.eu>
X-Original-To: mmusic@core3.amsl.com
Delivered-To: mmusic@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 917B23A6A17 for <mmusic@core3.amsl.com>; Fri, 19 Jun 2009 06:35:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F9yC50AmKgzw for <mmusic@core3.amsl.com>; Fri, 19 Jun 2009 06:35:17 -0700 (PDT)
Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 6CB563A692D for <mmusic@ietf.org>; Fri, 19 Jun 2009 06:35:17 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 5109F2C01C9AF for <mmusic@ietf.org>; Fri, 19 Jun 2009 15:35:30 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office)
Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34W0FaSNTP91 for <mmusic@ietf.org>; Fri, 19 Jun 2009 15:35:30 +0200 (CEST)
Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id 1E8692C01C8EC for <mmusic@ietf.org>; Fri, 19 Jun 2009 15:35:25 +0200 (CEST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C9F0E2.CD12BCC9"
Date: Fri, 19 Jun 2009 15:35:24 +0200
Message-ID: <547F018265F92642B577B986577D671C9E382A@VENUS.office>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: I-D Action:draft-ietf-mmusic-rfc2326bis-21.txt 
Thread-Index: Acnw4kn1+kieSyD1TlK/9yEIKMLRcgAAFoNQ
From: "Martin Stiemerling" <Stiemerling@nw.neclab.eu>
To: <mmusic@ietf.org>
Subject: [MMUSIC] FW: I-D Action:draft-ietf-mmusic-rfc2326bis-21.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Jun 2009 13:35:18 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01C9F0E2.CD12BCC9
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

There is an updated RTSP 2.0 draft (see below) that solely contains =
editorial changes.

Let me know any comment you have.

Thanks,

 Martin

stiemerling@nw.neclab.eu

NEC Laboratories Europe - Network Research Division
NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, =
London W3 6BL | Registered in England 2832014=20

> -----Original Message-----
> From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-
> bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org
> Sent: Friday, June 19, 2009 3:30 PM
> To: i-d-announce@ietf.org
> Cc: mmusic@ietf.org
> Subject: I-D Action:draft-ietf-mmusic-rfc2326bis-21.txt
>=20
> 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.
>=20
>=20
> 	Title           : Real Time Streaming Protocol 2.0 (RTSP)
> 	Author(s)       : H. Schulzrinne, et al.
> 	Filename        : draft-ietf-mmusic-rfc2326bis-21.txt
> 	Pages           : 283
> 	Date            : 2009-06-19
>=20
> This memorandum defines RTSP version 2.0 which obsoletes RTSP version
> 1.0 which is defined in RFC 2326.
>=20
> The Real Time Streaming Protocol, or RTSP, is an application-level
> protocol for setup and control of the delivery of data with real-time
> properties.  RTSP provides an extensible framework to enable
> controlled, on-demand delivery of real-time data, such as audio and
> video.  Sources of data can include both live data feeds and stored
> clips.  This protocol is intended to control multiple data delivery
> sessions, provide a means for choosing delivery channels such as UDP,
> multicast UDP and TCP, and provide a means for choosing delivery
> mechanisms based upon RTP (RFC 3550).
>=20
> A URL for this Internet-Draft is:
> =
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rfc2326bis-21.txt
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.

------_=_NextPart_001_01C9F0E2.CD12BCC9
Content-Type: application/octet-stream;
	name="draft-ietf-mmusic-rfc2326bis-21.URL"
Content-Transfer-Encoding: base64
Content-Description: draft-ietf-mmusic-rfc2326bis-21.URL
Content-Disposition: attachment;
	filename="draft-ietf-mmusic-rfc2326bis-21.URL"

W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0
cy9kcmFmdC1pZXRmLW1tdXNpYy1yZmMyMzI2YmlzLTIxLnR4dA0K

------_=_NextPart_001_01C9F0E2.CD12BCC9
Content-Type: text/plain;
	name="ATT3064403.txt"
Content-Transfer-Encoding: base64
Content-Description: ATT3064403.txt
Content-Disposition: attachment;
	filename="ATT3064403.txt"

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v
dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0
Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCkludGVybmV0LURyYWZ0IGRpcmVj
dG9yaWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sDQpvciBmdHA6Ly9mdHAuaWV0
Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0K

------_=_NextPart_001_01C9F0E2.CD12BCC9--

From web-usrn@ISI.EDU  Fri Jun 19 06:52:59 2009
Return-Path: <web-usrn@ISI.EDU>
X-Original-To: mmusic@core3.amsl.com
Delivered-To: mmusic@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 189F63A698B for <mmusic@core3.amsl.com>; Fri, 19 Jun 2009 06:52:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.314
X-Spam-Level: 
X-Spam-Status: No, score=-17.314 tagged_above=-999 required=5 tests=[AWL=0.285, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9isQF+jDJ5bO for <mmusic@core3.amsl.com>; Fri, 19 Jun 2009 06:52:58 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 4569E3A6879 for <mmusic@ietf.org>; Fri, 19 Jun 2009 06:52:58 -0700 (PDT)
Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n5JDpBwJ002814 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 19 Jun 2009 06:51:12 -0700 (PDT)
Received: (from web-usrn@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id n5JDpAhX002805; Fri, 19 Jun 2009 06:51:10 -0700 (PDT)
Date: Fri, 19 Jun 2009 06:51:10 -0700 (PDT)
Message-Id: <200906191351.n5JDpAhX002805@boreas.isi.edu>
To: M.Handley@cs.ucl.ac.uk, van@packetdesign.com, csp@csperkins.org, rjsparks@nostrum.com, fluffy@cisco.com, jo@acm.org, jf.mule@cablelabs.com
From: RFC Errata System <rfc-editor@rfc-editor.org>
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: web-usrn@boreas.isi.edu
Cc: llucax@gmail.com, mmusic@ietf.org, rfc-editor@rfc-editor.org
Subject: [MMUSIC] [Technical Errata Reported] RFC4566 (1795)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Jun 2009 13:52:59 -0000

The following errata report has been submitted for RFC4566,
"SDP: Session Description Protocol".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=4566&eid=1795

--------------------------------------
Type: Technical
Reported by: Leandro Lucarella <llucax@gmail.com>

Section: 9

Original Text
-------------
   decimal-uchar =       DIGIT
                         / POS-DIGIT DIGIT
                         / ("1" 2*(DIGIT))
                         / ("2" ("0"/"1"/"2"/"3"/"4") DIGIT)
                         / ("2" "5" ("0"/"1"/"2"/"3"/"4"/"5"))


Corrected Text
--------------
   decimal-uchar =       DIGIT
                         / POS-DIGIT DIGIT
                         / ("1" 2(DIGIT))
                         / ("2" ("0"/"1"/"2"/"3"/"4") DIGIT)
                         / ("2" "5" ("0"/"1"/"2"/"3"/"4"/"5"))


Notes
-----
The "*" is removed from the 3rd line.

The current RFC accepts any number starting with "1" and followed by
2 or more digits (like 1000 or 123456789) as a valid "decimal-uchar"
because of this error, because "1" 2*(DIGIT) means 2 or more digits
following a "1". The correction, 2(DIGIT) means *exactly* 2 digits
following a "1", which covers the range 100-199.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC4566 (draft-ietf-mmusic-sdp-new-26)
--------------------------------------
Title               : SDP: Session Description Protocol
Publication Date    : July 2006
Author(s)           : M. Handley, V. Jacobson, C. Perkins
Category            : PROPOSED STANDARD
Source              : Multiparty Multimedia Session Control
Area                : Real-time Applications and Infrastructure
Stream              : IETF
Verifying Party     : IESG

From Stiemerling@nw.neclab.eu  Fri Jun 19 07:04:08 2009
Return-Path: <Stiemerling@nw.neclab.eu>
X-Original-To: mmusic@core3.amsl.com
Delivered-To: mmusic@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A97FA3A6945 for <mmusic@core3.amsl.com>; Fri, 19 Jun 2009 07:04:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i7Ni4InwVG3F for <mmusic@core3.amsl.com>; Fri, 19 Jun 2009 07:04:07 -0700 (PDT)
Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 96F663A6C72 for <mmusic@ietf.org>; Fri, 19 Jun 2009 07:03:52 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 7D31A2C01C8EC for <mmusic@ietf.org>; Fri, 19 Jun 2009 16:04:05 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office)
Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nD7NHKOkyelR for <mmusic@ietf.org>; Fri, 19 Jun 2009 16:04:05 +0200 (CEST)
Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id 54FE82C0004E5 for <mmusic@ietf.org>; Fri, 19 Jun 2009 16:04:00 +0200 (CEST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 19 Jun 2009 16:03:59 +0200
Message-ID: <547F018265F92642B577B986577D671C9E383C@VENUS.office>
In-Reply-To: <9AAEDF491EF7CA48AB587781B8F5D7C601C76FC0@srvxchg3.cablelabs.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [MMUSIC]  WGLC on draft-ietf-mmusic-media-path-middleboxes-02
Thread-Index: Acmr11c/I2DD1ePbTTSnW9nT3UJ8+Qg4vsWQCQrpQGA=
References: <684A09E6-57C0-4E54-BD63-0DB77D13C247@cisco.com> <9AAEDF491EF7CA48AB587781B8F5D7C601C76FC0@srvxchg3.cablelabs.com>
From: "Martin Stiemerling" <Stiemerling@nw.neclab.eu>
To: "MMUSIC WG" <mmusic@ietf.org>
Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-media-path-middleboxes-02
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Jun 2009 14:04:08 -0000

Hi,

I'm a bit late with my comments, but I haven't seen any WGLC closing =
message or similar.=20

I also see the document pretty much done, with a few comments only:
- The document talks the whole time about MIDCOM but without going into =
any protocol details of MIDCOM at all. Is MIDCOM the right term, or =
should better read MIDCOM-style (or similar), as there also other =
MIDCOM-style solutions out there, e.g., MEGACO.=20
- a nit in REC #4: it reads "...the answer should send the SDP =
answer...". I cannot parse this.
- REC#2: what is a nominal amount of traffic? Is there a chance to get =
some example calculations for DTLS-SRTP on what nominal can roughly =
mean?

  Martin

stiemerling@nw.neclab.eu

NEC Laboratories Europe - Network Research Division
NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, =
London W3 6BL | Registered in England 2832014=20

> -----Original Message-----
> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On
> Behalf Of Jean-Francois Mule
> Sent: Monday, May 04, 2009 3:27 PM
> To: MMUSIC WG
> Cc: Cullen Jennings; Martin Stiemerling; obsidian97@gmail.com
> Subject: [MMUSIC] WGLC on draft-ietf-mmusic-media-path-middleboxes-02
>=20
> This note starts a Working Group Last Call for comments on
> http://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes-02
>=20
> During the last MMUSIC meeting in San Francisco, a few folks
> volunteered
> to review the draft during WGLC (they are in the cc list along with =
the
> authors).  Cullen sent comments to the list on 3/23, see below -
> consider them as early WGLC comments.
>=20
> Please provide any comments to the authors and the mmusic mailing list
> by May 19, 2009 COB (two weeks from today).
>=20
> Thank you,
> Joerg and Jean-Francois.
>=20
> > -----Original Message-----
> > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On
> > Behalf Of Cullen Jennings
> > Sent: Monday, March 23, 2009 10:48 AM
> > To: MMUSIC WG
> > Subject: [MMUSIC] Review on draft-ietf-mmusic-media-path-
> > middleboxes-02
> >
> >
> > I like this document and it looks mostly done. Few comments.
> >
> > When I look at the figures, for example the one in 4.1.1. the UAC
> > side
> > has rule that allows from 47.0.0.2 to 47.0.0.1 and the other side
> > has
> > rule for 47.0.0.1 to 47.0.0.2 but if seems like no media can flow
> > either way with these two rules. I'm sure this is just a slight
> > over
> > sight but it seems like some of the rules and when they get
> > installed
> > is missing.
> >
> > I think this draft should show how the RTCP flows and when the
> > gates
> > open for that. Might also have a few sentences to discuss things
> > like
> > RSVP for the media.
> >
> > I think it needs to talk a little more about the consequences of
> > blocking early media when doing PSTN interoperability and things
> > like
> > 1-800-go-fedex
> >
> > Cullen <in my role as individual contributor>
>=20
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic

From john.elwell@siemens-enterprise.com  Wed Jun 24 08:21:26 2009
Return-Path: <john.elwell@siemens-enterprise.com>
X-Original-To: mmusic@core3.amsl.com
Delivered-To: mmusic@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB69E3A6F36 for <mmusic@core3.amsl.com>; Wed, 24 Jun 2009 08:21:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bT-8oxzToNe9 for <mmusic@core3.amsl.com>; Wed, 24 Jun 2009 08:21:26 -0700 (PDT)
Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id B874D3A6CAC for <mmusic@ietf.org>; Wed, 24 Jun 2009 08:21:25 -0700 (PDT)
Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KLR0015Y1B9IL@siemenscomms.co.uk> for mmusic@ietf.org; Wed, 24 Jun 2009 16:21:09 +0100 (BST)
Date: Wed, 24 Jun 2009 16:21:14 +0100
From: "Elwell, John" <john.elwell@siemens-enterprise.com>
In-reply-to: <B23B311878A0B4438F5F09F47E01AAE03A6D2C4917@NOK-EUMSG-01.mgdnok.nokia.com>
To: Simo.Veikkolainen@nokia.com, mmusic@ietf.org
Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0021057BC@GBNTHT12009MSX.gb002.siemens.net>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: quoted-printable
Thread-Topic: [MMUSIC] FW: I-D ACTION:draft-ietf-mmusic-sdp-cs-01.txt
Thread-Index: AcnvvNGDfqgSPD1LTIy0U6kWSQ3DnwALblwgAT0mzbA=
Content-class: urn:content-classes:message
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
References: <B23B311878A0B4438F5F09F47E01AAE03A6D2C4917@NOK-EUMSG-01.mgdnok.nokia.com>
Subject: Re: [MMUSIC] FW: I-D ACTION:draft-ietf-mmusic-sdp-cs-01.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jun 2009 15:21:26 -0000

Simo,

I think the Security Considerations section should remind people that it
is not possible to secure the media (SRTP is not available).

John=20

> -----Original Message-----
> From: mmusic-bounces@ietf.org=20
> [mailto:mmusic-bounces@ietf.org] On Behalf Of=20
> Simo.Veikkolainen@nokia.com
> Sent: 18 June 2009 09:00
> To: mmusic@ietf.org
> Subject: [MMUSIC] FW: I-D ACTION:draft-ietf-mmusic-sdp-cs-01.txt
>=20
> We submitted a new version of draft-ietf-mmusic-sdp-cs which=20
> adds some text to address John's comments on how to behave=20
> when no correlation information is received in the CS call=20
> setup, and on security considerations. =20
>=20
> Further comments are very welcome!
>=20
> Regards,
> Simo
>=20
> >-----Original Message-----
> >From: i-d-announce-bounces@ietf.org=20
> >[mailto:i-d-announce-bounces@ietf.org] On Behalf Of ext=20
> >Internet-Drafts@ietf.org
> >Sent: 18 June, 2009 05:30
> >To: i-d-announce@ietf.org
> >Cc: mmusic@ietf.org
> >Subject: I-D ACTION:draft-ietf-mmusic-sdp-cs-01.txt=20
> >
> >A New Internet-Draft is available from the on-line=20
> >Internet-Drafts directories.
> >This draft is a work item of the Multiparty Multimedia Session=20
> >Control Working Group of the IETF.
> >
> >	Title		: Session Description Protocol (SDP)=20
> >Extension For Setting Up Audio Media Streams Over=20
> >Circuit-Switched Bearers In The Public Switched Telephone=20
> >Network (PSTN)
> >	Author(s)	: M. Garcia-Martin, S. Veikkolainen
> >	Filename	: draft-ietf-mmusic-sdp-cs-01.txt
> >	Pages		: 25
> >	Date		: 2009-6-17
> >=09
> >This memo describes use cases, requirements, and protocol extensions
> >   for using the Session Description Protocol (SDP)=20
> Offer/Answer model
> >   for establishing audio media stream over circuit-switched=20
> 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-01.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=20
> >reader implementation to automatically retrieve the ASCII=20
> >version of the Internet-Draft.
> >
>=20

From rsf@ns.live555.com  Thu Jun 25 03:57:40 2009
Return-Path: <rsf@ns.live555.com>
X-Original-To: mmusic@core3.amsl.com
Delivered-To: mmusic@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8554E3A6CAB; Thu, 25 Jun 2009 03:57:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nxUokl3yp-3H; Thu, 25 Jun 2009 03:57:39 -0700 (PDT)
Received: from ns.live555.com (ns.live555.com [4.79.217.242]) by core3.amsl.com (Postfix) with ESMTP id B25383A6950; Thu, 25 Jun 2009 03:57:39 -0700 (PDT)
Received: from ns.live555.com (localhost.live555.com [127.0.0.1]) by ns.live555.com (8.14.3/8.14.3) with ESMTP id n5PAuvoV027603; Thu, 25 Jun 2009 03:56:57 -0700 (PDT) (envelope-from rsf@ns.live555.com)
Received: (from rsf@localhost) by ns.live555.com (8.14.3/8.14.3/Submit) id n5PAuvpS027596; Thu, 25 Jun 2009 03:56:57 -0700 (PDT) (envelope-from rsf)
Mime-Version: 1.0
Message-Id: <f06240807c668f32010ca@[66.80.62.44]>
In-Reply-To: <p06240859c6542b53968f@[10.0.1.8]>
References: <20090609024502.05A883A67F6@core3.amsl.com> <8987F5DB-1395-44F3-A4F0-44725FCC3D7E@gbiv.com> <p06240859c6542b53968f@[10.0.1.8]>
Date: Thu, 25 Jun 2009 03:56:51 -0700
To: avt@ietf.org, mmusic@ietf.org
From: Ross Finlayson <finlayson@live555.com>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Subject: Re: [MMUSIC] [AVT] I-D Action:draft-pantos-http-live-streaming-01.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jun 2009 10:57:40 -0000

I am pleased that Apple submitted this document as an Internet Draft. 
While I feel that much of the subsequent criticism has been 
excessively harsh (or in some cases, misguided), I do agree with the 
criticism that the document's title could be more descriptive.  The 
current title - "HTTP Live Streaming" - suggests that it is a broad, 
architectural overview document, which this really isn't.  A more 
meaningful title for this document might be something like
	"Using URI Playlist Files to Simulate Live Streaming"

Nonetheless, if this approach is seen as being useful, then I would 
like to see the IETF adopting and standardizing it (or something 
similar), because both media streaming and transport protocols 
(including HTTP/TCP - the transport protocol most commonly specified 
within URIs) are clearly within the IETF's arena.

However, this document focuses attention on a much bigger issue - a 
proverbial "elephant in the room" - that at some point the IETF in 
general, and the MMUSIC and AVT working groups in particular, are 
going to have to address:

Thanks to the ever increasing abundance of cheap mass storage, we are 
now in a world where media consumption is increasingly 'on demand' - 
e.g, via DVRs or online services like YouTube - rather than live.  It 
seems inevitable that on-demand media playback will dominate, with 
live media being relegated to relatively minor niches where 
timeliness remains essential.

Given this, we have to ask ourselves whether there is going to 
continue to be a practical role for specialized protocols for live 
media, or whether we will see more and more of the live media niches 
being satisfied by hacks (like the one described by this draft) that 
can make use of the increasingly dominant infrastructure that will 
already be in place for on-demand media?  Telephony currently remains 
a refuge for live media protocols, but how much beyond this in the 
future?  (There are even companies out there now that are providing 
videoconferencing over HTTP, within users' web browsers!)

I believe that, at the very least, the IETF should try to be more 
pragmatic about this (even if it means sometimes tarnishing 
architectural purity).  To give just one specific example, I'm 
disappointed that the IETF did not adopt and standardize Apple's 
earlier mechanism (developed several years ago) for tunneling 
RTSP/RTP over HTTP.  But given the points that I note above, I think 
we're going to have to think hard about the future of RTSP in 
general...

From rfc-editor@rfc-editor.org  Tue Jun 30 16:57:10 2009
Return-Path: <rfc-editor@rfc-editor.org>
X-Original-To: mmusic@core3.amsl.com
Delivered-To: mmusic@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF76E3A6EB2; Tue, 30 Jun 2009 16:57:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.937
X-Spam-Level: 
X-Spam-Status: No, score=-16.937 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_DEF_WHITELIST=-15]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rsNcEMrEEAR3; Tue, 30 Jun 2009 16:57:09 -0700 (PDT)
Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id C37873A68AA; Tue, 30 Jun 2009 16:57:09 -0700 (PDT)
Received: by bosco.isi.edu (Postfix, from userid 70) id 3E96A2E057D; Tue, 30 Jun 2009 16:55:01 -0700 (PDT)
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
From: rfc-editor@rfc-editor.org
Message-Id: <20090630235501.3E96A2E057D@bosco.isi.edu>
Date: Tue, 30 Jun 2009 16:55:01 -0700 (PDT)
Cc: mmusic@ietf.org, rfc-editor@rfc-editor.org
Subject: [MMUSIC] RFC 5576 on Source-Specific Media Attributes in the Session Description Protocol (SDP)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Jun 2009 23:57:11 -0000

A new Request for Comments is now available in online RFC libraries.

        
        RFC 5576

        Title:      Source-Specific Media Attributes in the 
                    Session Description Protocol (SDP) 
        Author:     J. Lennox, J. Ott,
                    T. Schierl
        Status:     Standards Track
        Date:       June 2009
        Mailbox:    jonathan@vidyo.com, 
                    jo@acm.org, 
                    ts@thomas-schierl.de
        Pages:      18
        Characters: 40454
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-mmusic-sdp-source-attributes-02.txt

        URL:        http://www.rfc-editor.org/rfc/rfc5576.txt

The Session Description Protocol (SDP) provides mechanisms to
describe attributes of multimedia sessions and of individual media
streams (e.g., Real-time Transport Protocol (RTP) sessions) within a
multimedia session, but does not provide any mechanism to describe
individual media sources within a media stream.  This document
defines a mechanism to describe RTP media sources, which are
identified by their synchronization source (SSRC) identifiers, in
SDP, to associate attributes with these sources, and to express
relationships among sources.  It also defines several source-level
attributes that can be used to describe properties of media sources.  
[STANDARDS TRACK]

This document is a product of the Multiparty Multimedia Session Control Working Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
USC/Information Sciences Institute



From jo@netlab.tkk.fi  Tue Jun 30 22:46:25 2009
Return-Path: <jo@netlab.tkk.fi>
X-Original-To: mmusic@core3.amsl.com
Delivered-To: mmusic@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB9FC3A6906 for <mmusic@core3.amsl.com>; Tue, 30 Jun 2009 22:46:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.421
X-Spam-Level: 
X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[AWL=0.178,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Zhg8sdrwMSF for <mmusic@core3.amsl.com>; Tue, 30 Jun 2009 22:46:25 -0700 (PDT)
Received: from smtp.netlab.hut.fi (keskus.netlab.hut.fi [130.233.154.176]) by core3.amsl.com (Postfix) with ESMTP id 2B6893A6768 for <mmusic@ietf.org>; Tue, 30 Jun 2009 22:46:24 -0700 (PDT)
Received: from pc89.netlab.hut.fi (keskus.netlab.hut.fi [130.233.154.176]) by smtp.netlab.hut.fi (Postfix) with ESMTP id 15F52C5100 for <mmusic@ietf.org>; Wed,  1 Jul 2009 08:46:39 +0300 (EET DST)
Message-ID: <4A4AF834.8000500@netlab.tkk.fi>
Date: Wed, 01 Jul 2009 08:46:28 +0300
From: Joerg Ott <jo@netlab.tkk.fi>
User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302)
MIME-Version: 1.0
To: mmusic@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [MMUSIC] RTSP server with support for Speed: > 1.0
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Jul 2009 05:46:26 -0000

Folks,

we are looking for an RTSP server implementation (ideally
open source, but a binary product would do, too) that supports
the Speed: header with values larger than 1.0 to enable
pro-active media streaming and caching at the client's
discretion.

Any pointers?

Thanks,
Joerg