From Jim.Kleck@8x8.com Fri Sep 4 16:46:39 2009 Return-Path: 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 7ABE13A6936 for ; Fri, 4 Sep 2009 16:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.601 X-Spam-Level: X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[AWL=0.540, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] 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 CB6OOS2NCuau for ; Fri, 4 Sep 2009 16:46:38 -0700 (PDT) Received: from mailx.8x8.com (ns25.8x8.com [192.84.19.225]) by core3.amsl.com (Postfix) with ESMTP id AB3C83A67E7 for ; Fri, 4 Sep 2009 16:46:38 -0700 (PDT) Received: from [10.0.2.15] (192.168.84.42) by 8X8EXCH01.8x8.com (192.168.84.92) with Microsoft SMTP Server id 8.1.336.0; Fri, 4 Sep 2009 16:46:59 -0700 Message-ID: <4AA1A6EA.6070104@8x8.com> Date: Fri, 4 Sep 2009 16:46:50 -0700 From: Jim Kleck User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.18) Gecko/20081030 Iceape/1.1.13 (Debian-1.1.13-1) MIME-Version: 1.0 To: "mmusic@ietf.org" , , Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Subject: [MMUSIC] ICE draft 19 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2009 23:46:39 -0000 Garth, here is a new email which I propose sending to mmusic, Eilon, and both of Rosenberg's email addrs. Could you read through it to make sure it is clear and correct? Thanks.


Hi,

I have a better understanding now of our confusion with the draft. Specifically, section 7.2.1.4 (which deals with the ICE agent processing a received Binding Request) states:

Next, the agent constructs a pair whose local candidate is equal to the transport address on which the STUN request was received, and a remote candidate equal to the source transport address where the request came from (which may be peer-reflexive remote candidate that was just learned).
How does the local ICE agent identify the transport address on which the STUN request was received? For example, say the local agent has the CONTROLLED role and that there are 3 remote candidates (host, srflx, and relay) and 3 local candidates (again host, srflx and relay), and that the local agent is behind a symmetric NAT. The local agent will build 6 check list pairs:

  1- local host candidate and remote host candidate
  2- local host candidate and remote srflx candidate
  3- local host candidate and remote relay candidate
  4- local relay candidate and remote host candidate
  5- local relay candidate and remote srflx candidate
  6- local relay candidate and remote relay candidate
(having pruned the check list pairs containing the local srflx candidate).

Say that the remote agent responds successfully to pair #s 1 and 2 (i.e. it sends the responses to the mapped addresses for these two requests), thus the local agent will build local prflx candidates with the mapped addresses as the transport addresses for these and build valid pairs referring to these new prflx candidates. Now the remote agent starts nominating (it is using REGULAR NOMINATION), and sends a new STUN Binding Request with USE-CANDIDATE to the mapped address for pair #2. This Binding request passes through the NAT and is received by the local agent. How can the local agent know that this nominating request came for pair #2 vs. pair #1? The NAT would forward either one to the same base address, and in passing through the NAT the original address to which the remote agent sent the request is lost. Furthermore, the request itself does not contain any information which the local agent could use to determine which of pair #2 or #1 the request was sent for. And without this information, the local agent does not know which pair is nominated (and even earlier in the process, before the remote agent starts nominating, on receiving a Binding Request without USE-CANDIDATE the local agent would not know which local candidate the request came for).

JimK
8x8, Inc.



From Jim.Kleck@8x8.com Fri Sep 4 16:47:40 2009 Return-Path: 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 AE2523A6999 for ; Fri, 4 Sep 2009 16:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.678 X-Spam-Level: X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[AWL=0.463, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] 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 EfA86GjSJJsF for ; Fri, 4 Sep 2009 16:47:40 -0700 (PDT) Received: from mailx.8x8.com (ns25.8x8.com [192.84.19.225]) by core3.amsl.com (Postfix) with ESMTP id 0EE153A67F1 for ; Fri, 4 Sep 2009 16:47:40 -0700 (PDT) Received: from [10.0.2.15] (192.168.84.42) by 8X8EXCH01.8x8.com (192.168.84.92) with Microsoft SMTP Server id 8.1.336.0; Fri, 4 Sep 2009 16:47:57 -0700 Message-ID: <4AA1A724.3090107@8x8.com> Date: Fri, 4 Sep 2009 16:47:48 -0700 From: Jim Kleck User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.18) Gecko/20081030 Iceape/1.1.13 (Debian-1.1.13-1) MIME-Version: 1.0 To: "mmusic@ietf.org" , "jdrosen@cisco.com" , "jdrosen@jdrosen.net" Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Subject: [MMUSIC] ICE draft 19 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2009 23:47:40 -0000
Hi,

I have a better understanding now of our confusion with the draft. Specifically, section 7.2.1.4 (which deals with the ICE agent processing a received Binding Request) states:

Next, the agent constructs a pair whose local candidate is equal to the transport address on which the STUN request was received, and a remote candidate equal to the source transport address where the request came from (which may be peer-reflexive remote candidate that was just learned).
How does the local ICE agent identify the transport address on which the STUN request was received? For example, say the local agent has the CONTROLLED role and that there are 3 remote candidates (host, srflx, and relay) and 3 local candidates (again host, srflx and relay), and that the local agent is behind a symmetric NAT. The local agent will build 6 check list pairs:

  1- local host candidate and remote host candidate
  2- local host candidate and remote srflx candidate
  3- local host candidate and remote relay candidate
  4- local relay candidate and remote host candidate
  5- local relay candidate and remote srflx candidate
  6- local relay candidate and remote relay candidate
(having pruned the check list pairs containing the local srflx candidate).

Say that the remote agent responds successfully to pair #s 1 and 2 (i.e. it sends the responses to the mapped addresses for these two requests), thus the local agent will build local prflx candidates with the mapped addresses as the transport addresses for these and build valid pairs referring to these new prflx candidates. Now the remote agent starts nominating (it is using REGULAR NOMINATION), and sends a new STUN Binding Request with USE-CANDIDATE to the mapped address for pair #2. This Binding request passes through the NAT and is received by the local agent. How can the local agent know that this nominating request came for pair #2 vs. pair #1? The NAT would forward either one to the same base address, and in passing through the NAT the original address to which the remote agent sent the request is lost. Furthermore, the request itself does not contain any information which the local agent could use to determine which of pair #2 or #1 the request was sent for. And without this information, the local agent does not know which pair is nominated (and even earlier in the process, before the remote agent starts nominating, on receiving a Binding Request without USE-CANDIDATE the local agent would not know which local candidate the request came for).

JimK
8x8, Inc.



From magnus.westerlund@ericsson.com Mon Sep 7 07:21:38 2009 Return-Path: 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 49C603A69C0 for ; Mon, 7 Sep 2009 07:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[AWL=0.602, 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 BFmdBU7HiPcg for ; Mon, 7 Sep 2009 07:21:37 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id DB04F3A692C for ; Mon, 7 Sep 2009 07:21:36 -0700 (PDT) X-AuditID: c1b4fb3c-b7b6eae000001984-b0-4aa51705ba89 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 47.2D.06532.50715AA4; Mon, 7 Sep 2009 16:22:02 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Sep 2009 16:21:56 +0200 Received: from [147.214.183.250] ([147.214.183.250]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Sep 2009 16:21:56 +0200 Message-ID: <4AA51704.5010803@ericsson.com> Date: Mon, 07 Sep 2009 16:21:56 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Y.J. Gu" References: <007001ca214a$6ef4e480$400ca40a@china.huawei.com> In-Reply-To: <007001ca214a$6ef4e480$400ca40a@china.huawei.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 07 Sep 2009 14:21:56.0827 (UTC) FILETIME=[8E248AB0:01CA2FC6] X-Brightmail-Tracker: AAAAAA== Cc: schulzrinne@cs.columbia.edu, mmusic@ietf.org Subject: Re: [MMUSIC] RFC2326bis-22, Section 16.19 need clarification. X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2009 14:21:38 -0000 Hi, The intention in this case was 1). That the proxy will have to ensure that the requests is sends towards a particular server has a joint sequence number space. Because there are no strong indication to the server that different requests are from different clients. Especially as a proxy may actually send only have a single RTSP session with the server despite serving multiple clients. Do you have a proposal for how to make the text clearer? Cheers Magnus Best Regards. Y.J. Gu skrev: > In RFC2326bis-22 > 16.19. CSeq > > The CSeq general-header field specifies the sequence number for an > RTSP request-response pair. This field MUST be present in all > requests and responses. For every RTSP request containing the given > sequence number, the corresponding response will have the same > number. Any retransmitted request MUST contain the same sequence > number as the original (i.e. the sequence number is not incremented > for retransmissions of the same request). For each new RTSP request > the CSeq value MUST be incremented by one. The initial sequence > number MAY be any number, however it is RECOMMENDED to start at 0. > Each sequence number series is unique between each requester and > responder, i.e. the client has one series for its request to a server > and the server has another when sending request to the client. Each > requester and responder is identified with its network address. > > Proxies that aggregate several sessions on the same transport will > regularly need to renumber the CSeq header field in requests and > responses to fulfill the rules for the header. > > I am not very clear about the colored words. > For each new RTSP request > the CSeq value MUST be incremented by one. > When Proxy aggregate serveral sessions, it can be understanded in > different way: > 1) Without regard of different sessions, proxy increase the CSeq by one > for each request it transmits. > +-----+ +-----------+ > +----------+ > | C1 | ---------| proxy | C1 setup, CSeq=1 | server | > +-----+ /+-----------+ C1 play, CSeq=2 +----------+ > / C2 setup, CSeq=3 > +-----+ / C1 pause, CSeq=4 > | C2 | / > +-----+ > 2) CSeq is incremented by one for each request of a particular session. > +-----+ +-----------+ > +----------+ > | C1 | ---------| proxy | C1 setup, CSeq=1 | server | > +-----+ /+-----------+ C1 play, CSeq=2 +----------+ > / C2 setup, CSeq=101 > +-----+ / C1 pause, CSeq=3 > | C2 | / C2 play, CSeq=102 > +-----+ > I guess it should be 2), but I am not sure, 'cause there can be various > explanations. > Each sequence number series is unique between each requester and > responder, i.e. the client has one series for its request to a server > and the server has another when sending request to the client. > What does unique mean? Are {0,1,2,3} and {1,2,3,4} unique, or {0,1,2,3} > and {101,102,103,104} unique? > > > > ------------------------------------------------------------------------ > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic -- Magnus Westerlund IETF Transport Area Director ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Mon Sep 7 07:25:29 2009 Return-Path: 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 5EF4F3A69C0 for ; Mon, 7 Sep 2009 07:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.668 X-Spam-Level: X-Spam-Status: No, score=-5.668 tagged_above=-999 required=5 tests=[AWL=0.581, 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 W2kY2pgzHOSl for ; Mon, 7 Sep 2009 07:25:28 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 26C2B3A692C for ; Mon, 7 Sep 2009 07:25:27 -0700 (PDT) X-AuditID: c1b4fb3c-b7b6eae000001984-51-4aa517f246c6 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 04.5D.06532.2F715AA4; Mon, 7 Sep 2009 16:25:54 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Sep 2009 16:25:54 +0200 Received: from [147.214.183.250] ([147.214.183.250]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Sep 2009 16:25:54 +0200 Message-ID: <4AA517F2.8080002@ericsson.com> Date: Mon, 07 Sep 2009 16:25:54 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Jose Rey References: <1FEB9B9F2EC38343955D02B2AE86AACB0133308C@lan-ex-02.panasonic.de> <200908041802.10341.remi.denis-courmont@nokia.com> <1FEB9B9F2EC38343955D02B2AE86AACB01333090@lan-ex-02.panasonic.de> In-Reply-To: <1FEB9B9F2EC38343955D02B2AE86AACB01333090@lan-ex-02.panasonic.de> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 07 Sep 2009 14:25:54.0447 (UTC) FILETIME=[1BC679F0:01CA2FC7] X-Brightmail-Tracker: AAAAAA== Cc: mmusic@ietf.org Subject: Re: [MMUSIC] GET_PARAMETER for keep-alive in RTSP 2.0? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2009 14:25:29 -0000 Jose Rey skrev: > But I don't really need parameters for keep-alive. An empty body is good enough...so is that still a problem? > I woulds say that it simply has been missed to be included in 10.5. If you read Section 13.8 it does say that it is allowed. I will correct this in the XML source so it will be included in the next version. Thanks for spotting this inconsistency. cheers Magnus Westerlund IETF Transport Area Director ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Mon Sep 7 07:36:01 2009 Return-Path: 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 5AC9A3A6988 for ; Mon, 7 Sep 2009 07:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.686 X-Spam-Level: X-Spam-Status: No, score=-5.686 tagged_above=-999 required=5 tests=[AWL=0.563, 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 gg0QNlImnFj6 for ; Mon, 7 Sep 2009 07:36:00 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 26E323A68D8 for ; Mon, 7 Sep 2009 07:35:59 -0700 (PDT) X-AuditID: c1b4fb3e-b7c00ae0000007bf-85-4aa51a6accd0 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id A8.98.01983.A6A15AA4; Mon, 7 Sep 2009 16:36:26 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Sep 2009 16:36:26 +0200 Received: from [147.214.183.250] ([147.214.183.250]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Sep 2009 16:36:26 +0200 Message-ID: <4AA51A6A.2000502@ericsson.com> Date: Mon, 07 Sep 2009 16:36:26 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Magnus Westerlund References: <1FEB9B9F2EC38343955D02B2AE86AACB0133308C@lan-ex-02.panasonic.de> <200908041802.10341.remi.denis-courmont@nokia.com> <1FEB9B9F2EC38343955D02B2AE86AACB01333090@lan-ex-02.panasonic.de> <4AA517F2.8080002@ericsson.com> In-Reply-To: <4AA517F2.8080002@ericsson.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 07 Sep 2009 14:36:26.0169 (UTC) FILETIME=[944F9A90:01CA2FC8] X-Brightmail-Tracker: AAAAAA== Cc: Jose Rey , mmusic@ietf.org Subject: Re: [MMUSIC] GET_PARAMETER for keep-alive in RTSP 2.0? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2009 14:36:01 -0000 A follow up question to the WG! I added GET_PARAMETER to the list in Section 10.5. However, I did it under a separate bullet so that I could avoid having multiple methods being RECOMMENDED for RTSP session keep-alive. Is GET_PARAMETER more commonly implemented and should be the recommended method instead of SET_PARAMETER? Magnus Magnus Westerlund skrev: > Jose Rey skrev: >> But I don't really need parameters for keep-alive. An empty body is good enough...so is that still a problem? >> > > I woulds say that it simply has been missed to be included in 10.5. If > you read Section 13.8 it does say that it is allowed. I will correct > this in the XML source so it will be included in the next version. > > Thanks for spotting this inconsistency. > > cheers > > Magnus Westerlund > > IETF Transport Area Director > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > -- Magnus Westerlund IETF Transport Area Director ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Mon Sep 7 07:46:56 2009 Return-Path: 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 EF8943A69C9 for ; Mon, 7 Sep 2009 07:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.704 X-Spam-Level: X-Spam-Status: No, score=-5.704 tagged_above=-999 required=5 tests=[AWL=0.545, 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 G0+i-QnJgjeU for ; Mon, 7 Sep 2009 07:46:56 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id E6ECF3A6949 for ; Mon, 7 Sep 2009 07:46:55 -0700 (PDT) X-AuditID: c1b4fb3c-b7b6eae000001984-8f-4aa51cfad7cf Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id AF.9E.06532.AFC15AA4; Mon, 7 Sep 2009 16:47:22 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Sep 2009 16:47:22 +0200 Received: from [147.214.183.250] ([147.214.183.250]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Sep 2009 16:47:21 +0200 Message-ID: <4AA51CF9.1080804@ericsson.com> Date: Mon, 07 Sep 2009 16:47:21 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Y.J. Gu" References: <001801ca1bbc$9a7b8bb0$400ca40a@china.huawei.com> In-Reply-To: <001801ca1bbc$9a7b8bb0$400ca40a@china.huawei.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 07 Sep 2009 14:47:21.0769 (UTC) FILETIME=[1B143990:01CA2FCA] X-Brightmail-Tracker: AAAAAA== Cc: 'Jaehwan Kim' , mmusic@ietf.org Subject: Re: [MMUSIC] Question about RTSP proxy X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2009 14:46:57 -0000 Y.J. Gu skrev: > I would like to compose a draft, in order to clarify the problem > clearly. I feel that there might be other scenarios that we haven't noticed. Hi, I don't understand what is broken assuming that you implement a proxy that keep sufficient state. I don't see how the proxy can avoid to keep track of any outstanding CSeq and their remappings and which session IDs that belongs to which clients over a joint TCP connection from proxy to server. IF you think there is an issue can you please try to be very clear on the situation and when the issue exists. If the issue does not exist after clarification over email, I do appreciate indication and text proposals for improvements to the text. Cheers Magnus Westerlund IETF Transport Area Director ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From guyingjie@huawei.com Mon Sep 7 19:17:54 2009 Return-Path: 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 9C8043A6778 for ; Mon, 7 Sep 2009 19:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.075 X-Spam-Level: X-Spam-Status: No, score=0.075 tagged_above=-999 required=5 tests=[AWL=0.570, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=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 g5rs3gvCf1kG for ; Mon, 7 Sep 2009 19:17:53 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 59C583A68FF for ; Mon, 7 Sep 2009 19:17:53 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KPM0048ERQBX8@szxga03-in.huawei.com> for mmusic@ietf.org; Tue, 08 Sep 2009 10:18:12 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KPM005K2RQB2F@szxga03-in.huawei.com> for mmusic@ietf.org; Tue, 08 Sep 2009 10:18:11 +0800 (CST) Received: from g00107907 ([10.164.12.64]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KPM00DBFRQBL9@szxml04-in.huawei.com> for mmusic@ietf.org; Tue, 08 Sep 2009 10:18:11 +0800 (CST) Date: Tue, 08 Sep 2009 10:18:11 +0800 From: "Y.J. Gu" In-reply-to: <4AA51704.5010803@ericsson.com> To: 'Magnus Westerlund' Message-id: <002101ca302a$9d0e4c00$400ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Thread-index: AcovzOJMBG0utqmuR5eV23Wh0/vOLQAV3qcg Cc: schulzrinne@cs.columbia.edu, mmusic@ietf.org Subject: Re: [MMUSIC] RFC2326bis-22, Section 16.19 need clarification. X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 02:17:54 -0000 Thank you for your explanation. This is an excellent draft, I did not mean to question it. Just because = I'm in the implementation of an RTSP proxy, I found that Cseq text is = ambiguous when considering proxy. =20 The first paragraph of your post has made the issue very clear.=20 There are still some implementations in which proxy may set up several = RTSP sessions, with a particular server, for several clients, in order to be compatible to servers who check clients' IP Adds before replying. So an added indication, "to a particular server", will help people to = understand the text without confused. I.e. " For each new RTSP request to a particular server, either in one = or several RTSP sessions of the same client/proxy, the CSeq value MUST be incremented by one." This is a coarse example. An illustration, especially for proxy, also helps people to get the = meaning at a first glance. =20 Regards Yingjie Gu =20 > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 > Sent: Monday, September 07, 2009 10:22 PM > To: Y.J. Gu > Cc: schulzrinne@cs.columbia.edu; mmusic@ietf.org > Subject: Re: [MMUSIC] RFC2326bis-22, Section 16.19 need clarification. >=20 > Hi, >=20 > The intention in this case was 1). That the proxy will have=20 > to ensure that the requests is sends towards a particular=20 > server has a joint sequence number space. >=20 > Because there are no strong indication to the server that=20 > different requests are from different clients. Especially as=20 > a proxy may actually send only have a single RTSP session=20 > with the server despite serving multiple clients. >=20 > Do you have a proposal for how to make the text clearer? >=20 > Cheers >=20 > Magnus >=20 > Best Regards. >=20 > Y.J. Gu skrev: > > In RFC2326bis-22 > > 16.19. CSeq > > =20 > > The CSeq general-header field specifies the sequence=20 > number for an > > RTSP request-response pair. This field MUST be present in all > > requests and responses. For every RTSP request=20 > containing the given > > sequence number, the corresponding response will have the same > > number. Any retransmitted request MUST contain the same sequence > > number as the original (i.e. the sequence number is not=20 > incremented > > for retransmissions of the same request). For each new=20 > RTSP request > > the CSeq value MUST be incremented by one. The initial sequence > > number MAY be any number, however it is RECOMMENDED to=20 > start at 0. > > Each sequence number series is unique between each requester and > > responder, i.e. the client has one series for its=20 > request to a server > > and the server has another when sending request to the=20 > client. Each > > requester and responder is identified with its network address. > > =20 > > Proxies that aggregate several sessions on the same=20 > transport will > > regularly need to renumber the CSeq header field in requests and > > responses to fulfill the rules for the header. > > =20 > > I am not very clear about the colored words. > > For each new RTSP request > > the CSeq value MUST be incremented by one.=20 > > When Proxy aggregate serveral sessions, it can be understanded in=20 > > different way: > > 1) Without regard of different sessions, proxy increase the CSeq by=20 > > one for each request it transmits. > > +-----+ +-----------+ =20 > =20 > > +----------+ > > | C1 | ---------| proxy | C1 setup, CSeq=3D1 =20 > | server | > > +-----+ /+-----------+ C1 play, CSeq=3D2=20 > +----------+ > > / C2 setup, = CSeq=3D3=20 > > +-----+ / C1 pause, CSeq=3D4 > > | C2 | / > > +-----+ > > 2) CSeq is incremented by one for each request of a=20 > particular session.=20 > > +-----+ +-----------+ =20 > =20 > > +----------+ > > | C1 | ---------| proxy | C1 setup, CSeq=3D1 =20 > | server | > > +-----+ /+-----------+ C1 play, CSeq=3D2=20 > +----------+ > > / C2=20 > setup, CSeq=3D101=20 > > +-----+ / C1 pause, CSeq=3D3 > > | C2 | / C2 play, = CSeq=3D102 > > +-----+ > > I guess it should be 2), but I am not sure, 'cause there can be=20 > > various explanations. > > Each sequence number series is unique between each requester and > > responder, i.e. the client has one series for its=20 > request to a server > > and the server has another when sending request to the client. > > What does unique mean? Are {0,1,2,3} and {1,2,3,4} unique, or=20 > > {0,1,2,3} and {101,102,103,104} unique? > > =20 > >=20 > >=20 > >=20 > ---------------------------------------------------------------------- > > -- > >=20 > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic >=20 >=20 > --=20 >=20 > Magnus Westerlund >=20 > IETF Transport Area Director > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > -------------------------------------------------------------- > -------- From hgs@cs.columbia.edu Wed Sep 9 16:58:12 2009 Return-Path: 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 203B33A69D2 for ; Wed, 9 Sep 2009 16:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.185 X-Spam-Level: X-Spam-Status: No, score=-4.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 NDQHzznZoLgM for ; Wed, 9 Sep 2009 16:58:11 -0700 (PDT) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id 46A1F3A6887 for ; Wed, 9 Sep 2009 16:58:11 -0700 (PDT) Received: from [172.18.159.228] (ip67-90-234-94.z234-90-67.customer.algx.net [67.90.234.94]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id n89NwgMg021401 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 9 Sep 2009 19:58:43 -0400 (EDT) Message-Id: <887EC221-2A8A-4457-B3A9-6A40BE8CD687@cs.columbia.edu> From: Henning Schulzrinne To: mmusic@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 9 Sep 2009 19:58:41 -0400 X-Mailer: Apple Mail (2.936) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.6 Subject: [MMUSIC] [off-topic] Conferencing annoyances X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 23:58:12 -0000 Since most of us are both users and designers of conferencing (and other collaboration) applications, I'd appreciate your input on what you consider deficiencies in currently available systems. I'm more interested in fundamental issues ("I wish I could add smells to the conference!") than bugs ("The icons on the XYZ system don't work on MacOS!"). Depending on the answers, I'm thinking of using these as ideas for student projects. Since this is unlikely to be interest to the whole WG, private replies please. Henning From guyingjie@huawei.com Wed Sep 9 18:35:14 2009 Return-Path: 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 A2F2728C0D6 for ; Wed, 9 Sep 2009 18:35:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.025 X-Spam-Level: X-Spam-Status: No, score=0.025 tagged_above=-999 required=5 tests=[AWL=0.520, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=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 zga6InHwJFXb for ; Wed, 9 Sep 2009 18:35:13 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 496213A6AD7 for ; Wed, 9 Sep 2009 18:35:13 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KPQ00CUSF3C2O@szxga03-in.huawei.com> for mmusic@ietf.org; Thu, 10 Sep 2009 09:35:36 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KPQ00J9AF3CII@szxga03-in.huawei.com> for mmusic@ietf.org; Thu, 10 Sep 2009 09:35:36 +0800 (CST) Received: from g00107907 ([10.164.12.64]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KPQ00AV1F3BOY@szxml06-in.huawei.com> for mmusic@ietf.org; Thu, 10 Sep 2009 09:35:36 +0800 (CST) Date: Thu, 10 Sep 2009 09:35:37 +0800 From: "Y.J. Gu" In-reply-to: To: 'Jaehwan Kim' , 'Magnus Westerlund' Message-id: <001101ca31b6$ffd49050$400ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable Thread-index: AcovzOJMBG0utqmuR5eV23Wh0/vOLQAV3qcgAGLjsxAAAMQwAA== Cc: schulzrinne@cs.columbia.edu, mmusic@ietf.org Subject: Re: [MMUSIC] RFC2326bis-22, Section 16.19 need clarification. X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 01:35:14 -0000 Thanks Jaehwan. Here is my implementation. In order to be compatible to those servers = who may maintain session states and check client IP Add, I did not set up = single RTSP to server multiple clients. Insead, e.g., Proxy set up 2 TCP connections with 2 servers, each TCP connection carries aggregate RTSP sessions with sequent CSeq series = start with 0.=20 During implementation, I find that Proxy will receives responses with = same Cseq from these 2 servers. So I have to take TCP sessionID into consideration when I try to distinguish these responses. So my CSeq = matching table on Proxy is as following.=20 ------------------------------------------- TCP SID | CSeq | Client info. ------------------------------------------- Proxy can work in this way, however RTSP relies too much on transport protocol in this case. Regards Yingjie Gu =20 > -----Original Message----- > From: Jaehwan Kim [mailto:jhkim@vidiator.com]=20 > Sent: Thursday, September 10, 2009 8:46 AM > To: Magnus Westerlund > Cc: schulzrinne@cs.columbia.edu; mmusic@ietf.org; Y.J. Gu > Subject: RE: [MMUSIC] RFC2326bis-22, Section 16.19 need clarification. >=20 > Hi Magnus, > Yingjie is trying to implement aggregated RTSP sessions in=20 > the same TCP session between Proxy and Server. >=20 > Regards, > Jaehwan >=20 > -----Original Message----- > From: mmusic-bounces@ietf.org=20 > [mailto:mmusic-bounces@ietf.org] On Behalf Of Y.J. Gu > Sent: Tuesday, September 08, 2009 11:18 AM > To: 'Magnus Westerlund' > Cc: schulzrinne@cs.columbia.edu; mmusic@ietf.org > Subject: Re: [MMUSIC] RFC2326bis-22, Section 16.19 need clarification. >=20 > Thank you for your explanation. > This is an excellent draft, I did not mean to question it.=20 > Just because I'm in the implementation of an RTSP proxy, I=20 > found that Cseq text is ambiguous when considering proxy. =20 >=20 > The first paragraph of your post has made the issue very clear.=20 > There are still some implementations in which proxy may set=20 > up several RTSP sessions, with a particular server, for=20 > several clients, in order to be compatible to servers who=20 > check clients' IP Adds before replying. So an added=20 > indication, "to a particular server", will help people to=20 > understand the text without confused. >=20 > I.e. " For each new RTSP request to a particular server,=20 > either in one or several RTSP sessions of the same=20 > client/proxy, the CSeq value MUST be incremented by one."=20 > This is a coarse example. >=20 > An illustration, especially for proxy, also helps people to=20 > get the meaning at a first glance. >=20 >=20 > =20 > Regards >=20 > Yingjie Gu >=20 > =20 >=20 > > -----Original Message----- > > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > > Sent: Monday, September 07, 2009 10:22 PM > > To: Y.J. Gu > > Cc: schulzrinne@cs.columbia.edu; mmusic@ietf.org > > Subject: Re: [MMUSIC] RFC2326bis-22, Section 16.19 need=20 > clarification. > >=20 > > Hi, > >=20 > > The intention in this case was 1). That the proxy will have=20 > to ensure=20 > > that the requests is sends towards a particular server has a joint=20 > > sequence number space. > >=20 > > Because there are no strong indication to the server that different=20 > > requests are from different clients. Especially as a proxy may=20 > > actually send only have a single RTSP session with the=20 > server despite=20 > > serving multiple clients. > >=20 > > Do you have a proposal for how to make the text clearer? > >=20 > > Cheers > >=20 > > Magnus > >=20 > > Best Regards. > >=20 > > Y.J. Gu skrev: > > > In RFC2326bis-22 > > > 16.19. CSeq > > > =20 > > > The CSeq general-header field specifies the sequence > > number for an > > > RTSP request-response pair. This field MUST be present in all > > > requests and responses. For every RTSP request > > containing the given > > > sequence number, the corresponding response will have the same > > > number. Any retransmitted request MUST contain the=20 > same sequence > > > number as the original (i.e. the sequence number is not > > incremented > > > for retransmissions of the same request). For each new > > RTSP request > > > the CSeq value MUST be incremented by one. The=20 > initial sequence > > > number MAY be any number, however it is RECOMMENDED to > > start at 0. > > > Each sequence number series is unique between each=20 > requester and > > > responder, i.e. the client has one series for its > > request to a server > > > and the server has another when sending request to the > > client. Each > > > requester and responder is identified with its network address. > > > =20 > > > Proxies that aggregate several sessions on the same > > transport will > > > regularly need to renumber the CSeq header field in=20 > requests and > > > responses to fulfill the rules for the header. > > > =20 > > > I am not very clear about the colored words. > > > For each new RTSP request > > > the CSeq value MUST be incremented by one.=20 > > > When Proxy aggregate serveral sessions, it can be understanded in=20 > > > different way: > > > 1) Without regard of different sessions, proxy increase=20 > the CSeq by=20 > > > one for each request it transmits. > > > +-----+ +-----------+ =20 > > =20 > > > +----------+ > > > | C1 | ---------| proxy | C1 setup, CSeq=3D1 =20 > > | server | > > > +-----+ /+-----------+ C1 play, CSeq=3D2=20 > > +----------+ > > > / C2=20 > setup, CSeq=3D3=20 > > > +-----+ / C1 pause, CSeq=3D4 > > > | C2 | / > > > +-----+ > > > 2) CSeq is incremented by one for each request of a > > particular session.=20 > > > +-----+ +-----------+ =20 > > =20 > > > +----------+ > > > | C1 | ---------| proxy | C1 setup, CSeq=3D1 =20 > > | server | > > > +-----+ /+-----------+ C1 play, CSeq=3D2=20 > > +----------+ > > > / C2=20 > > setup, CSeq=3D101 > > > +-----+ / C1 pause, CSeq=3D3 > > > | C2 | / C2 play,=20 > CSeq=3D102 > > > +-----+ > > > I guess it should be 2), but I am not sure, 'cause there can be=20 > > > various explanations. > > > Each sequence number series is unique between each requester and > > > responder, i.e. the client has one series for its > > request to a server > > > and the server has another when sending request to the client. > > > What does unique mean? Are {0,1,2,3} and {1,2,3,4} unique, or=20 > > > {0,1,2,3} and {101,102,103,104} unique? > > > =20 > > >=20 > > >=20 > > >=20 > >=20 > ---------------------------------------------------------------------- > > > -- > > >=20 > > > _______________________________________________ > > > mmusic mailing list > > > mmusic@ietf.org > > > https://www.ietf.org/mailman/listinfo/mmusic > >=20 > >=20 > > -- > >=20 > > Magnus Westerlund > >=20 > > IETF Transport Area Director > >=20 > ---------------------------------------------------------------------- > > Multimedia Technologies, Ericsson Research EAB/TVM > >=20 > ---------------------------------------------------------------------- > > Ericsson AB | Phone +46 10 7148287 > > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > > -------------------------------------------------------------- > > -------- >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From joe.pallas@gmail.com Thu Sep 10 16:28:07 2009 Return-Path: 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 18F1228C225 for ; Thu, 10 Sep 2009 16:28:07 -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 gdQZn+zeNwx8 for ; Thu, 10 Sep 2009 16:28:06 -0700 (PDT) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id 0364228C1FA for ; Thu, 10 Sep 2009 16:28:05 -0700 (PDT) Received: by ewy3 with SMTP id 3so687150ewy.42 for ; Thu, 10 Sep 2009 16:28:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=rfYbXWPlf3hk5N4wY0e3bjPt8sEPhq7Yuyn93OvskM0=; b=LLj8gbTU2RvNOd0+N1udlbVR6Vv6rzLT7dSUTGUfzqkjVUmu97cWV0DZNR+HUSBjIQ p3XjiVL/qLWmT0Xo9wxZx1BmsSohWq9QJqh8Ao6vV3MxiCArOwBnTvuKZSsXFz/fyfFx kjussgpi0Aycbirhs5rk0zumv+J6SmwPBkrl4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=srDl11T+SHTf2KMRNsT7OSrByQNA/JUmfmlSVbAK+ehlpde0qJ+noRd37m4uT/cExv v0rQ3yUZ7KQ5UoM6QfnexzPSQmOL3TxI5w2GznOEWNyprA0ZNUMEoVO9TJoR+0vjoJSX 3PDAPbR0UXODoTC6pZJ+RuI2bJJhBxrtxeqwY= Received: by 10.211.161.23 with SMTP id n23mr2458420ebo.52.1252625317029; Thu, 10 Sep 2009 16:28:37 -0700 (PDT) Received: from dhcp-umpk14-99-81.SFBay.Sun.COM (sca-ea-fw-1.Sun.COM [192.18.43.225]) by mx.google.com with ESMTPS id 7sm843829eyg.29.2009.09.10.16.28.33 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 10 Sep 2009 16:28:35 -0700 (PDT) Sender: Joe Pallas Message-Id: <00B2DEF6-EE9B-4A3D-B868-75889E3B25AC@cs.stanford.edu> From: Joe Pallas To: mmusic@ietf.org In-Reply-To: <001101ca31b6$ffd49050$400ca40a@china.huawei.com> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 10 Sep 2009 16:28:30 -0700 References: <001101ca31b6$ffd49050$400ca40a@china.huawei.com> X-Mailer: Apple Mail (2.936) Cc: Jaehwan Kim , Magnus Westerlund , schulzrinne@cs.columbia.edu Subject: Re: [MMUSIC] RFC2326bis-22, Section 16.19 need clarification. X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 23:28:07 -0000 Once again I will assert that CSeq is both unnecessary and, as we see =20= from this discussion, confusing. It should be removed. (Some =20 replacement may be needed for the Request-Status header of =20 PLAY_NOTIFY, however. The existing NOTIFY extension used with RTSP 1.0 =20= does not have an equivalent, so it's not clear it is necessary.) To recap: 1. CSeq was originally included in RTSP 1.0 to support unreliable =20 protocols such as UDP. 2. UDP support in RTSP 1.0 was never fully specified and no one has =20 claimed to have an implementation. 3. RTSP now explicitly assumes a reliable, connection-oriented stream =20= protocol such as TCP. 4. CSeq serves no purpose with a reliable transport layer. 5. HTTP seems to have achieved a modest degree of success in the =20 field, including proxy support, without any equivalent to CSeq; it =20 uses transport connections to distinguish conversations. The only argument I've heard for keeping CSeq is backward =20 compatibility with existing implementations. I don't think that's =20 very strong, because the draft explicitly denies compatibility with =20 RTSP 1.0. For it to matter, there would need to be an existing =20 implementation that assumes responses can arrive out of order and =20 relies on CSeq to match responses to requests. Does anyone know of =20 such? If we really can't remove it, can we at least deprecate it=97include =20 some text that clearly informs the reader that CSeq has no meaning and =20= should not be relied upon for anything? The rules would be something =20= like this: CSeq is not required on a request. If a server receives a =20 request with CSeq, it must include CSeq in the response. joe From ron.even.tlv@gmail.com Mon Sep 14 23:52:21 2009 Return-Path: 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 742313A69A5 for ; Mon, 14 Sep 2009 23:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.246 X-Spam-Level: ** X-Spam-Status: No, score=2.246 tagged_above=-999 required=5 tests=[AWL=4.845, 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 lSMJrreR+qZh for ; Mon, 14 Sep 2009 23:52:20 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by core3.amsl.com (Postfix) with ESMTP id F124B3A6940 for ; Mon, 14 Sep 2009 23:52:19 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id e21so657066fga.13 for ; Mon, 14 Sep 2009 23:53:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=Fq0pSUAQxw7Vdi0CrIdKgycAphrmG/2g62+49LrsBGM=; b=t5OYx9j7kULye1IVHPEcY3MBuwh/OJ5L1fUqoTSvoal0wYQcoSzRB3mG7HxvXcJXMr jwU5nd+SMk4hZx/DB9JPGMgsSiTV+Ng6wipMQR9pqk068F1vOUl7vOGibjptZYjVqeXS 9zePJcoX2GyG0KyLB78pxU8r7j1ywigWUENF0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=mhcyxYrEWaRlC8nJTlV+muZ68UIivRlXFHi8bei9dxegutHx+O+rOZOInZlMya2+2w abhW8G0+JAvgG/nda2nS7aGzM237Cc15IrMF3Uva9JkdLO/mEh4dXJYBdL8+2HIG2Dpb FnlyWn4TXH80IbqNUNEArVGQoW6TgHEB2xjDk= Received: by 10.86.13.7 with SMTP id 7mr5806774fgm.64.1252997582053; Mon, 14 Sep 2009 23:53:02 -0700 (PDT) Received: from windows8d787f9 (bzq-79-177-122-19.red.bezeqint.net [79.177.122.19]) by mx.google.com with ESMTPS id l12sm1467833fgb.13.2009.09.14.23.52.58 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 14 Sep 2009 23:53:00 -0700 (PDT) From: "Roni Even" To: "'Magnus Westerlund'" , "'Y.J. Gu'" References: <007001ca214a$6ef4e480$400ca40a@china.huawei.com> <4AA51704.5010803@ericsson.com> In-Reply-To: <4AA51704.5010803@ericsson.com> Date: Tue, 15 Sep 2009 09:51:14 +0300 Message-ID: <4aaf39cc.0c58560a.7202.5ca9@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acovxpv0tvajHkS2TdC/GvMBo9U2tAGCXFqA Content-Language: en-us Cc: schulzrinne@cs.columbia.edu, mmusic@ietf.org Subject: Re: [MMUSIC] RFC2326bis-22, Section 16.19 need clarification. X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2009 06:52:21 -0000 Magnus, I also agree that the intention is for number 1. I thought that the proxy will have separate sessions for each client = based on section 16.47: "However, multiple "user" sessions for the same URI from the same client will require use of different session identifiers. The session identifier is needed to distinguish several delivery requests for the same URI coming from the same client. " Do you think that we should try to make this text stronger Roni Even > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On > Behalf Of Magnus Westerlund > Sent: Monday, September 07, 2009 5:22 PM > To: Y.J. Gu > Cc: schulzrinne@cs.columbia.edu; mmusic@ietf.org > Subject: Re: [MMUSIC] RFC2326bis-22, Section 16.19 need clarification. >=20 > Hi, >=20 > The intention in this case was 1). That the proxy will have to ensure > that the requests is sends towards a particular server has a joint > sequence number space. >=20 > Because there are no strong indication to the server that different > requests are from different clients. Especially as a proxy may = actually > send only have a single RTSP session with the server despite serving > multiple clients. >=20 > Do you have a proposal for how to make the text clearer? >=20 > Cheers >=20 > Magnus >=20 > Best Regards. >=20 > Y.J. Gu skrev: > > In RFC2326bis-22 > > 16.19. CSeq > > > > The CSeq general-header field specifies the sequence number for = an > > RTSP request-response pair. This field MUST be present in all > > requests and responses. For every RTSP request containing the > given > > sequence number, the corresponding response will have the same > > number. Any retransmitted request MUST contain the same sequence > > number as the original (i.e. the sequence number is not > incremented > > for retransmissions of the same request). For each new RTSP > request > > the CSeq value MUST be incremented by one. The initial sequence > > number MAY be any number, however it is RECOMMENDED to start at = 0. > > Each sequence number series is unique between each requester and > > responder, i.e. the client has one series for its request to a > server > > and the server has another when sending request to the client. > Each > > requester and responder is identified with its network address. > > > > Proxies that aggregate several sessions on the same transport = will > > regularly need to renumber the CSeq header field in requests and > > responses to fulfill the rules for the header. > > > > I am not very clear about the colored words. > > For each new RTSP request > > the CSeq value MUST be incremented by one. > > When Proxy aggregate serveral sessions, it can be understanded in > > different way: > > 1) Without regard of different sessions, proxy increase the CSeq by > one > > for each request it transmits. > > +-----+ +-----------+ > > +----------+ > > | C1 | ---------| proxy | C1 setup, CSeq=3D1 | = server > | > > +-----+ /+-----------+ C1 play, CSeq=3D2 = +---------- > + > > / C2 setup, = CSeq=3D3 > > +-----+ / C1 pause, CSeq=3D4 > > | C2 | / > > +-----+ > > 2) CSeq is incremented by one for each request of a particular > session. > > +-----+ +-----------+ > > +----------+ > > | C1 | ---------| proxy | C1 setup, CSeq=3D1 | = server > | > > +-----+ /+-----------+ C1 play, CSeq=3D2 = +---------- > + > > / C2 setup, = CSeq=3D101 > > +-----+ / C1 pause, CSeq=3D3 > > | C2 | / C2 play, = CSeq=3D102 > > +-----+ > > I guess it should be 2), but I am not sure, 'cause there can be > various > > explanations. > > Each sequence number series is unique between each requester and > > responder, i.e. the client has one series for its request to a > server > > and the server has another when sending request to the client. > > What does unique mean? Are {0,1,2,3} and {1,2,3,4} unique, or > {0,1,2,3} > > and {101,102,103,104} unique? > > > > > > > > = --------------------------------------------------------------------- > --- > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic >=20 >=20 > -- >=20 > Magnus Westerlund >=20 > IETF Transport Area Director > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From jf.mule@cablelabs.com Tue Sep 15 20:12:10 2009 Return-Path: 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 B5FE23A67F8 for ; Tue, 15 Sep 2009 20:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.18 X-Spam-Level: X-Spam-Status: No, score=-0.18 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] 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 P7Im5bm8TmJ1 for ; Tue, 15 Sep 2009 20:12:08 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 48E3C3A681C for ; Tue, 15 Sep 2009 20:12:08 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.3/8.14.3) with SMTP id n8G3CtrF010759 for ; Tue, 15 Sep 2009 21:12:55 -0600 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Tue, 15 Sep 2009 21:12:55 -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: multipart/alternative; boundary="----_=_NextPart_001_01CA367B.95BFD7F3" Date: Tue, 15 Sep 2009 21:12:55 -0600 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C601ABA112@srvxchg3.cablelabs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF 75 MMUSIC meeting notes posted Thread-Index: Aco2e5WqFJnVGG4VREuPnSKrN9+rIw== From: "Jean-Francois Mule" To: X-Approved: ondar Subject: [MMUSIC] IETF 75 MMUSIC meeting notes posted X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2009 03:12:10 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA367B.95BFD7F3 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable See http://www.ietf.org/proceedings/75/minutes/mmusic.html=20 and below: Send any comments or corrections to the list. Regards, Joerg and Jean-Francois. --- --- = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- Multiparty Multimedia Session Control (MMUSIC) Working Group --- DRAFT Minutes for IETF#75 MMUSIC WG Meeting --- Thursday, July 30, 2009 - 9:00 to 11:30am --- = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CHAIRS: Joerg Ott Jean-Francois Mule The MMUSIC WG met on July 30 at IETF#73. The session was attended by 57 participants. The meeting was chaired by Joerg Ott and Jean-Francois Mule and the minutes are reported by Jean-Francois. 1/ Introduction and progress report Joerg and Jean-Francois presented the progress since the last meeting. =20 - 3 RFCs were published since March 2009: RFC 5547, RFC 5576 and RFC5583 - ICE is still in the RFC Editor queue and publication has been requested for connectivity preconditions and RFC 3388bis. - The capability negotiation draft received comments from IESG and needs revision. - The media path guidelines for middleboxes WGLC is complete and the ID needs an update - 3 I-Ds are in the queue for WGLC request (RFC4756bis, sdp media cap and image attributes after an udpate) - ICE TCP has not been updated and Simon Perreault who is the new editor plans to issue a revision after IETF. - Hadriel Kaplan volunteered to work with the authors of the media loopback ID to complete it and go to publication request by October 2009. See slides for more details. There were no comments or questions from the Working Group on the progress report. 1) RTSP-related Drafts 1.1. RTSP 2.0 http://tools.ietf.org/html/draft-ietf-mmusic-rfc2326bis-22 Magnus Westerlund presented an update on the latest RTSP draft. See slides for details on the changes. Two versions of the Internet-Draft were posted between IETF 74 and IETF 75. The one open issue is to update the "changes since RFC 2326" section. The authors believe the document is in good shape for working group last call. There were no comments on the plan to launch WGLC in September for 4 weeks. The following people volunteered to be reviewers during WGLC: Ingemar Johansson, Jeff Goldberg, and Ye-Kui Wang (thank you). =20 1.2 RTSP NAT http://tools.ietf.org/html/draft-ietf-mmusic-rtsp-nat-08 Magnus Westerlund presented the draft updates on RTSP NAT. The document received feedback from implementers. There was consensus to go to WGLC after RTSP/2.0. 1.3 Fast Content Switching with RTSP 2.0 http://tools.ietf.org/html/draft-einarsson-mmusic-rtsp-macuri-02 http://tools.ietf.org/html/draft-lohmar-mmusic-rtsp-fcs-00 Thorsten Lohmar presented RTSP extensions to support Fast Content Switching. There are existing extensions defined in 3GPP for RTSP 1.0 and the goal of this work would be to define extensions in IETF for RTSP 2.0. Joerg Ott asked how RTSP session parameters could be reused across streams in the context of multicast. Thorsten answered that the scope of the current ID is unicast and with unicast, channel change is faster if you use these RTSP extensions. On slide 7, Joerg commented that the proposed solution presented in the examples looks "unhealthy" because various feature parameters including SDP are put into one header line (it seems like the DESCRIBE message is encapsulated in PLAY). Thorsten indicated that this point was discussed in the past and given the number of SDP descriptions for video services like YouTube, the current direction is to not do DESCRIBEs to reduce the number of transactions. Jean-Francois noted that the examples show the 3gpp tags and their particular syntax. It would be benefitial to discuss the parameters required for fast channel switching first, then figure out how to convey them in the protocol. In the jabber room, Martin Stiemerling asked if the proposal is aligned with the RTSP/2.0 state machine where you can use PLAY on new URIs without SETUP first. Based on questions from Wolgang Beck (via jabber), there was a discussion on whether this work is required given the client has to wait for an I-frame for the new content channel. Brian Rosen responded that there is work in AVT in reducing the delay related to the I-frame and there is enough experience in 3GPP that this mechanism actually helps. Ye-Kui Wang indicated the issues related to the I-frame may be different than what is being addressed in AVT since the action is done by the server (the server may know where the I-frame is before starting channel change). Joerg pointed out that there is an assumption in the mechanism that the new SDP offer is going to be compatible (no DESCRIBE fetching). It implies that the client makes some assumptions. Thorsten agreed this is an open issue, even though the server could know what the client can support. Joerg added that if the server has multiple codec options, a SETUP might help for the client to choose from. Jeff Goldberg asked how this mechanism works with the RTSP NAT draft given the exchanges. We need to consider how the two mechanisms could work together. Thorsten indicated that there should be little impact but further analysis is indeed required. In summary, based on the discussions at this IETF#75 meeting, there is WG interest in progressing this work on the mailing list and see the Internet-Draft updated to address the feedback. 1.4 SIP-SDP Overlap with RTSP http://tools.ietf.org/html/draft-lindquist-mmusic-sip-rtsp-00 Jan Lindquist presented a draft on how the session related information could flow between SIP and RTSP session controllers. Jan indicated that ETSI TISPAN, 3GPP and the Open IPTV Forum are working on this topic. =20 Hadriel Kaplan asked what "session management protocol" refered to in the slides and whether it could be somethink like SIP without media description. Hadriel asked whether this work proposal should potentially go to DISPATCH given it goes beyond MMUSIC. Hadriel expressed support for this work. Tom Hiller expressed some concerns about the claim that OMA is working on this topic. Tom said that this was discussed in OMA and rejected. Tom indicated that RTSP should be left intact given the client implementations. Joerg suggested that Tom puts an email to the mmusic list to explain what OMA did to solve the requirements. Xavier Marjou expressed support for this work. There are people that use both SIP and RTSP and there is no work in IETF to make the 2 protocols work together. It would be good to take on this work. The chairs polled the room for interest in this work (13 peple interested, 5 opposed to do work on this). Dave Oran added 3 options that could get support in MMUSIC: a) stop RTSP 2.0 and step back to redefine it to meet the goals defined here b) designing new media control protocol inside a SIP session (put the PLAY controls in SIP) c) create an MRCP sub-set All of these would allow to use SIP to do media streaming server operations. Jan indicated this is good input. Gonzalo Camarillo agrees with Hadriel that this might be best discussed in the DISPATCH working group. The chairs concluded that more discussion is needed on this topic. =20 2) SDP Attributes 2.1 SDP Connectivity Capability (CCAP) http://tools.ietf.org/html/draft-boucadair-mmusic-ccap-00 Hadriel presented an Internet-Draft to solve some IPv4-IPv6 interworking issues. There were questions and comments about the characterization of the problem (slide 2). Cullen Jennings and Francois Audet commented that there is an implication that there are a lot of things broken, and the problem statement is exagerated. Cullen Jennings, it was pointed out that the WG decision to fix IPv4-IPv6 connectivity declarations in SDP was the ICE protocol. Xavier Marjou would like to do IPv6 in the very short-term with this draft, and perhaps this is an informational or experimental document, not standard-track. There were several questions and comments on the subsequent slides: - the c line in O/A does not need to have the same address family (Roni Even) - you have to do a re-INVITE since the answer should have the same c line (Dan Wing) - Capabiliy negotiation is "messy" and having two mechanisms would be even worse - the garcia draft to negotiate c lines is a potential solution (Christer Holmber). The garcia draft has been proposed as a WG item based on IETF#74 (Roni). - This is a special case of capability negotiation (Roni Even) but capneg is too complicated (Hadriel Kaplan) - This problem could be addressed based upon the garcia draft (Simo) - We always start out simple and it gets complex. We will need to implement all of this in the end process: we did discuss and agreed on a solution (Francois Audet) - The motivation is to do a "super-ice-lite mechanisms" - ICE-like negotiation without the connectivity checks. - This is a strategic direction we make for the wg (Gonzalo) - We should spend energy on solving generic SDP capability negotiation (Ingemar) There were additional comments from Roni, Jonathan Lennox, Derek, John Elwell and Christer Holmberg. In summary, the discussions asked: - how difficult would the solution be if it were to rely or build on capneg and draft-garcia? - how different is it from a solution re-using ICE? There was no consensus on this draft but many questions and comments recommending to re-use the tools that are available in MMUSIC including SDP Cap Neg and its extensions like the garcia draft for the c=3D line, ICE and new semantics to make this work. 2.2 SDP Attribute for Maximum Media Sources http://tools.ietf.org/html/draft-lennox-mmusic-sdp-max-sources-00 Jonathan Lennox presented a new draft on max media source count. Based on a comment from Dave Oran, the upper bound limit for maxbound should be 2^32-1 (unlimited). Christer asked how does the user know whether the media comes from different or a single source. Jonathan clarified that the use only cares whether media comes from a different SSRC: there are different buffers for playing media so the question is whether the endpoint supports more than one simulatenously. It has nothing to do with forking. =20 Gunnar Hellstrom sees good use of this mechanisms; he submitted a draft on text conferencing indicating that it can use multiple SSRCs. Hadriel added a few comments on SSRCs and their handling by SBCs. The take-away from the WG discussions is that the ID should progress and it should integrate more information about SSRC handling. 2.3 Media Source Selection in SDP = http://tools.ietf.org/html/draft-lennox-mmusic-sdp-source-selection-00 Jonathan Lennox introduced his draft allowing media source selection in SDP. There is potential IPR on this draft, check the IPR disclosure. Based on a discussion with Jonathan, Alan Johnston, and Roni Even, there was consensus that this work should continue in MMUSIC and also be presented and discussed in XCON given the related SIP/XCON conference package. =20 There was a question about how to associate a media stream with a certain SIP dialog when forking for example. Jonathan answered that RFC 5576 should be sufficient on its own for that. The chairs asked how many people are interested in this work by a show of hands: 7 people. =20 =20 2.4 SDP Extensions for audio over PSTN CS bearers http://tools.ietf.org/html/draft-ietf-mmusic-sdp-cs-01 Simo Veikkolainen presented an update on the above ID to integrate comments from John Elwell. The chairs asked for reviewers to send comments to the list. Cullen Jennings commented that this revision looks good. Given the meeting time constraints, Peter Fassberg had a few comments that should be discussed after the meeting and sent to the list as needed. 2.5 Misc Capability Negotiation in SDP (Simo Veikkolainen, 10) http://tools.ietf.org/html/draft-garcia-mmusic-sdp-misc-cap-01 Simo Veikkolainen indicated there were no technical changes in this revision. Hadriel Kaplan asked about the motivations of bundling the bundle i=3D and b=3D parameters. This should be clarified on the mailing list. Simo indicated that the goal was to be exhaustive on other SDP attributes. Hadriel Kaplan and Mohamed Boucadair raised questions about why comments expressed on the ccap draft presented earlier in the session do not apply to this draft. Jean-Francois clarified the motivations for this draft (ability to have capability negotiation for the c line), and that this has been discussed on the list and in previous meetings. =20 More discussion should continue on the list re: ccap and how the requirements or solution relate to this Internet-Draft. The meeting concluded. ------_=_NextPart_001_01CA367B.95BFD7F3 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IETF 75 MMUSIC meeting notes posted

See  http://ww= w.ietf.org/proceedings/75/minutes/mmusic.html
and below:

Send any comments or corrections to the list.
Regards,
Joerg and Jean-Francois.
---
--- = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- Multiparty Multimedia Session Control (MMUSIC) Working Group
--- DRAFT Minutes for IETF#75 MMUSIC WG Meeting
--- Thursday, July 30, 2009 - 9:00 to 11:30am
--- = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


CHAIRS:  Joerg Ott <jo@acm.org>
         Jean-Francois Mule = <jf.mule@cablelabs.com>

    The MMUSIC WG met on July 30 at IETF#73. The session = was attended
    by 57 participants. The meeting was chaired by Joerg = Ott and
    Jean-Francois Mule and the minutes are reported by = Jean-Francois.

1/ Introduction and progress report
   Joerg and Jean-Francois presented the progress since the = last
   meeting. 
        - 3 RFCs were published since = March 2009:
          RFC 5547, RFC = 5576 and RFC5583
        - ICE is still in the RFC = Editor queue and publication has
          been requested = for connectivity preconditions and RFC
          3388bis.
        - The capability negotiation = draft received comments from IESG
          and needs = revision.
        - The media path guidelines = for middleboxes WGLC is complete
          and the ID needs = an update
        - 3 I-Ds are in the queue for = WGLC request (RFC4756bis, sdp
          media cap and = image attributes after an udpate)
        - ICE TCP has not been = updated and Simon Perreault who is the
          new editor plans = to issue a revision after IETF.
        - Hadriel Kaplan volunteered = to work with the authors of the
          media loopback ID = to complete it and go to publication
          request by = October 2009.
   See slides for more details. There were no comments or = questions
   from the Working Group on the progress report.


1) RTSP-related Drafts

1.1. RTSP 2.0
   http:= //tools.ietf.org/html/draft-ietf-mmusic-rfc2326bis-22

   Magnus Westerlund presented an update on the latest RTSP = draft. See
   slides for details on the changes.  Two versions of = the
   Internet-Draft were posted between IETF 74 and IETF = 75.  The one
   open issue is to update the "changes since RFC = 2326" section.
   The authors believe the document is in good shape for = working group
   last call. There were no comments on the plan to launch = WGLC in
   September for 4 weeks.
   The following people volunteered to be reviewers during = WGLC:
   Ingemar Johansson, Jeff Goldberg, and Ye-Kui Wang (thank = you).
 

1.2 RTSP NAT
   http://= tools.ietf.org/html/draft-ietf-mmusic-rtsp-nat-08

   Magnus Westerlund presented the draft updates on RTSP = NAT.  The
   document received feedback from implementers.
   There was consensus to go to WGLC after RTSP/2.0.


1.3 Fast Content Switching with RTSP 2.0
   http://tools.ietf.org/html/draft-einarsson-mmusic-rtsp-macuri-02
=    http:= //tools.ietf.org/html/draft-lohmar-mmusic-rtsp-fcs-00

   Thorsten Lohmar presented RTSP extensions to support Fast = Content
   Switching.  There are existing extensions defined in = 3GPP for RTSP
   1.0 and the goal of this work would be to define extensions = in IETF
   for RTSP 2.0.

   Joerg Ott asked how RTSP session parameters could be reused = across
   streams in the context of multicast.  Thorsten = answered that the
   scope of the current ID is unicast and with unicast, = channel change
   is faster if you use these RTSP extensions.

   On slide 7, Joerg commented that the proposed solution = presented in
   the examples looks "unhealthy" because various = feature parameters
   including SDP are put into one header line (it seems like = the
   DESCRIBE message is encapsulated in PLAY).
   Thorsten indicated that this point was discussed in the = past and
   given the number of SDP descriptions for video services = like
   YouTube, the current direction is to not do DESCRIBEs to = reduce the
   number of transactions.

   Jean-Francois noted that the examples show the 3gpp tags = and
   their particular syntax. It would be benefitial to discuss = the
   parameters required for fast channel switching first, then = figure
   out how to convey them in the protocol.

   In the jabber room, Martin Stiemerling asked if the = proposal is
   aligned with the RTSP/2.0 state machine where you can use = PLAY
   on new URIs without SETUP first.

   Based on questions from Wolgang Beck (via jabber), there = was a
   discussion on whether this work is required given the = client has to
   wait for an I-frame for the new content channel.
   Brian Rosen responded that there is work in AVT in reducing = the
   delay related to the I-frame and there is enough experience = in 3GPP
   that this mechanism actually helps.

   Ye-Kui Wang indicated the issues related to the I-frame may = be
   different than what is being addressed in AVT since the = action is
   done by the server (the server may know where the I-frame = is before
   starting channel change).

   Joerg pointed out that there is an assumption in the = mechanism that
   the new SDP offer is going to be compatible (no DESCRIBE = fetching).
   It implies that the client makes some assumptions.
   Thorsten agreed this is an open issue, even though the = server
   could know what the client can support.
   Joerg added that if the server has multiple codec options, = a SETUP
   might help for the client to choose from.

   Jeff Goldberg asked how this mechanism works with the RTSP = NAT
   draft given the exchanges.  We need to consider how = the two
   mechanisms could work together.  Thorsten indicated = that there
   should be little impact but further analysis is indeed = required.

   In summary, based on the discussions at this IETF#75 = meeting, there
   is WG interest in progressing this work on the mailing list = and see
   the Internet-Draft updated to address the feedback.


1.4 SIP-SDP Overlap with RTSP
   ht= tp://tools.ietf.org/html/draft-lindquist-mmusic-sip-rtsp-00

   Jan Lindquist presented a draft on how the session = related
   information could flow between SIP and RTSP session = controllers.
   Jan indicated that ETSI TISPAN, 3GPP and the Open IPTV = Forum are
   working on this topic.
 
   Hadriel Kaplan asked what "session management = protocol" refered to
   in the slides and whether it could be somethink like SIP = without
   media description.
   Hadriel asked whether this work proposal should potentially = go to
   DISPATCH given it goes beyond MMUSIC. Hadriel expressed = support
   for this work.

   Tom Hiller expressed some concerns about the claim that OMA = is
   working on this topic. Tom said that this was discussed in = OMA and
   rejected.  Tom indicated that RTSP should be left = intact given the
   client implementations.
   Joerg suggested that Tom puts an email to the mmusic list = to
   explain what OMA did to solve the requirements.

   Xavier Marjou expressed support for this work.  There = are people
   that use both SIP and RTSP and there is no work in IETF to = make the
   2 protocols work together.  It would be good to take = on this
   work.

   The chairs polled the room for interest in this work (13 = peple
   interested, 5 opposed to do work on this).

   Dave Oran added 3 options that could get support in = MMUSIC:
        a) stop RTSP 2.0 and step = back to redefine it to meet the goals
           defined = here
        b) designing new media = control protocol inside a SIP session
           (put the = PLAY controls in SIP)
        c) create an MRCP sub-set
   All of these would allow to use SIP to do media streaming = server
   operations. Jan indicated this is good input.

   Gonzalo Camarillo agrees with Hadriel that this might be = best
   discussed in the DISPATCH working group.

   The chairs concluded that more discussion is needed on this = topic.



2) SDP Attributes

2.1 SDP Connectivity Capability (CCAP)
   http:/= /tools.ietf.org/html/draft-boucadair-mmusic-ccap-00

   Hadriel presented an Internet-Draft to solve some = IPv4-IPv6
   interworking issues.

   There were questions and comments about the = characterization of the
   problem (slide 2).
   Cullen Jennings and Francois Audet commented that there is = an
   implication that there are a lot of things broken, and the = problem
   statement is exagerated.
   Cullen Jennings, it was pointed out that the WG decision to = fix
   IPv4-IPv6 connectivity declarations in SDP was the ICE = protocol.

   Xavier Marjou would like to do IPv6 in the very short-term = with
   this draft, and perhaps this is an informational or = experimental
   document, not standard-track.

   There were several questions and comments on the subsequent = slides:
        - the c line in O/A does not = need to have the same address
          family (Roni = Even)
        - you have to do a re-INVITE = since the answer should have the
          same c line (Dan = Wing)
        - Capabiliy negotiation is = "messy" and having two mechanisms
          would be even = worse - the garcia draft to negotiate c lines
          is a potential = solution (Christer Holmber).
          The garcia draft = has been proposed as a WG item based on
          IETF#74 = (Roni).
        - This is a special case of = capability negotiation (Roni Even)
          but capneg is too = complicated (Hadriel Kaplan)
        - This problem could be = addressed based upon the garcia draft
          (Simo)
        - We always start out simple = and it gets complex. We will need
          to implement all = of this in the end process: we did discuss
          and agreed on a = solution (Francois Audet)
        - The motivation is to do a = "super-ice-lite mechanisms" -
          ICE-like = negotiation without the connectivity checks.
        - This is a strategic = direction we make for the wg (Gonzalo)
        - We should spend energy on = solving generic SDP capability
          negotiation = (Ingemar)
   There were additional comments from Roni, Jonathan Lennox, = Derek,
   John Elwell and Christer Holmberg.

   In summary, the discussions asked:
        - how difficult would the = solution be if it were to rely or
          build on capneg = and draft-garcia?
        - how different is it from a = solution re-using ICE?

   There was no consensus on this draft but many questions = and
   comments recommending to re-use the tools that are = available in
   MMUSIC including SDP Cap Neg and its extensions like the = garcia
   draft for the c=3D line, ICE and new semantics to make this = work.


2.2 SDP Attribute for Maximum Media Sources
   http://tools.ietf.org/html/draft-lennox-mmusic-sdp-max-sources-00
   Jonathan Lennox presented a new draft on max media source = count.
   Based on a comment from Dave Oran, the upper bound limit = for
   maxbound should be 2^32-1 (unlimited).

   Christer asked how does the user know whether the media = comes from
   different or a single source.  Jonathan clarified that = the use only
   cares whether media comes from a different SSRC: there = are
   different buffers for playing media so the question is = whether the
   endpoint supports more than one simulatenously.  It = has nothing to
   do with forking.

   Gunnar Hellstrom sees good use of this mechanisms; he = submitted a
   draft on text conferencing indicating that it can use = multiple
   SSRCs.

   Hadriel added a few comments on SSRCs and their handling by = SBCs.

   The take-away from the WG discussions is that the ID should = progress
   and it should integrate more information about SSRC = handling.


2.3 Media Source Selection in SDP
   http://tools.ietf.org/html/draft-lennox-mmusic-sdp-source-selectio= n-00

   Jonathan Lennox introduced his draft allowing media = source
   selection in SDP.  There is potential IPR on this = draft, check the
   IPR disclosure.

   Based on a discussion with Jonathan, Alan Johnston, and = Roni Even,
   there was consensus that this work should continue in = MMUSIC and
   also be presented and discussed in XCON given the related = SIP/XCON
   conference package.
 
   There was a question about how to associate a media stream = with a
   certain SIP dialog when forking for example.  Jonathan = answered
   that RFC 5576 should be sufficient on its own for that.

   The chairs asked how many people are interested in this = work by a
   show of hands: 7 people.
 
 
2.4 SDP Extensions for audio over PSTN CS bearers
   http://to= ols.ietf.org/html/draft-ietf-mmusic-sdp-cs-01

   Simo Veikkolainen presented an update on the above ID to = integrate
   comments from John Elwell.

   The chairs asked for reviewers to send comments to the = list.
   Cullen Jennings commented that this revision looks = good.
   Given the meeting time constraints, Peter Fassberg had a = few
   comments that should be discussed after the meeting and = sent to the
   list as needed.


2.5 Misc Capability Negotiation in = SDP         (Simo Veikkolainen, = 10)
   h= ttp://tools.ietf.org/html/draft-garcia-mmusic-sdp-misc-cap-01

   Simo Veikkolainen indicated there were no technical changes = in this
   revision.

   Hadriel Kaplan asked about the motivations of bundling the = bundle
   i=3D and b=3D parameters.  This should be clarified on = the mailing
   list.  Simo indicated that the goal was to be = exhaustive on other
   SDP attributes.

   Hadriel Kaplan and Mohamed Boucadair raised questions about = why
   comments expressed on the ccap draft presented earlier in = the
   session do not apply to this draft.
   Jean-Francois clarified the motivations for this draft = (ability to
   have capability negotiation for the c line), and that this = has been
   discussed on the list and in previous meetings.
 
   More discussion should continue on the list re: ccap and = how the
   requirements or solution relate to this Internet-Draft.

The meeting concluded.

------_=_NextPart_001_01CA367B.95BFD7F3-- From magnus.westerlund@ericsson.com Thu Sep 17 05:49:33 2009 Return-Path: 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 90E5C3A68A1 for ; Thu, 17 Sep 2009 05:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.532 X-Spam-Level: X-Spam-Status: No, score=-5.532 tagged_above=-999 required=5 tests=[AWL=0.717, 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 4y9JkfgjwbX6 for ; Thu, 17 Sep 2009 05:49:32 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 2EC5E3A67CC for ; Thu, 17 Sep 2009 05:49:31 -0700 (PDT) X-AuditID: c1b4fb3e-b7b75ae000003337-a2-4ab2308dc1a5 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 3C.E1.13111.D8032BA4; Thu, 17 Sep 2009 14:50:22 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Sep 2009 14:48:53 +0200 Received: from [147.214.183.250] ([147.214.183.250]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Sep 2009 14:48:53 +0200 Message-ID: <4AB23035.7090009@ericsson.com> Date: Thu, 17 Sep 2009 14:48:53 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Joe Pallas References: <001101ca31b6$ffd49050$400ca40a@china.huawei.com> <00B2DEF6-EE9B-4A3D-B868-75889E3B25AC@cs.stanford.edu> In-Reply-To: <00B2DEF6-EE9B-4A3D-B868-75889E3B25AC@cs.stanford.edu> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 17 Sep 2009 12:48:53.0840 (UTC) FILETIME=[368DD500:01CA3795] X-Brightmail-Tracker: AAAAAA== Cc: Jaehwan Kim , schulzrinne@cs.columbia.edu, mmusic@ietf.org Subject: Re: [MMUSIC] RFC2326bis-22, Section 16.19 need clarification. X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2009 12:49:33 -0000 Hi Joe, Joe Pallas skrev: > Once again I will assert that CSeq is both unnecessary and, as we see > from this discussion, confusing. It should be removed. (Some > replacement may be needed for the Request-Status header of PLAY_NOTIFY, > however. The existing NOTIFY extension used with RTSP 1.0 does not have > an equivalent, so it's not clear it is necessary.) > > To recap: > 1. CSeq was originally included in RTSP 1.0 to support unreliable > protocols such as UDP. > 2. UDP support in RTSP 1.0 was never fully specified and no one has > claimed to have an implementation. I know of one that has implemented RTSP 1.0 over UDP. > 3. RTSP now explicitly assumes a reliable, connection-oriented stream > protocol such as TCP. > 4. CSeq serves no purpose with a reliable transport layer. > 5. HTTP seems to have achieved a modest degree of success in the field, > including proxy support, without any equivalent to CSeq; it uses > transport connections to distinguish conversations. We are actually using CSeq for something these days. PLAY_NOTIFY's Request-Status header uses CSeq to refer to previous request. But I agree due to the strict ordering and the usage of reliable byte-stream oriented transport an RTSP agent can match the responses to the requests based on order. I think the proxy would need to keep track of things basically in the same way. Because if you aggregate together requests then you anyway need to keep track of which message in the order relates to which client. CSeq can be used or you can implement your own sequencing with local queue numbers. > > The only argument I've heard for keeping CSeq is backward compatibility > with existing implementations. I don't think that's very strong, > because the draft explicitly denies compatibility with RTSP 1.0. For it > to matter, there would need to be an existing implementation that > assumes responses can arrive out of order and relies on CSeq to match > responses to requests. Does anyone know of such? The draft currently says: Certain RTSP headers, such as the CSeq header (Section 16.19), which may appear to be relevant only to connectionless transport scenarios are still retained and must be implemented according to the specification. In the case of CSeq, it is quite useful for matching responses to requests if the requests are pipelined (see Section 12). It is also useful in proxies for keeping track of the different requests when aggregating several client requests on a single TCP connection. > > If we really can't remove it, can we at least deprecate it—include some > text that clearly informs the reader that CSeq has no meaning and should > not be relied upon for anything? The rules would be something like > this: CSeq is not required on a request. If a server receives a request > with CSeq, it must include CSeq in the response. > I think the compromise is problematic and as we actually are using CSeq for inter message references in the current spec I think removing it is less good. Sure you could do another solution for that, but I don't see it becoming easier than CSeq. Cheers Magnus Westerlund IETF Transport Area Director ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Thu Sep 17 05:55:09 2009 Return-Path: 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 C257F3A688D for ; Thu, 17 Sep 2009 05:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.541 X-Spam-Level: X-Spam-Status: No, score=-3.541 tagged_above=-999 required=5 tests=[AWL=-1.292, BAYES_00=-2.599, HELO_EQ_SE=0.35] 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 9kClyZnk1Iow for ; Thu, 17 Sep 2009 05:55:09 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 87D1A3A6953 for ; Thu, 17 Sep 2009 05:55:08 -0700 (PDT) X-AuditID: c1b4fb24-b7b21ae000006a0d-d0-4ab231deae26 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 5C.7E.27149.ED132BA4; Thu, 17 Sep 2009 14:55:58 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Sep 2009 14:55:58 +0200 Received: from [147.214.183.250] ([147.214.183.250]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 17 Sep 2009 14:55:58 +0200 Message-ID: <4AB231DE.7040109@ericsson.com> Date: Thu, 17 Sep 2009 14:55:58 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Roni Even References: <007001ca214a$6ef4e480$400ca40a@china.huawei.com> <4AA51704.5010803@ericsson.com> <4aaf39cc.0c58560a.7202.5ca9@mx.google.com> In-Reply-To: <4aaf39cc.0c58560a.7202.5ca9@mx.google.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 17 Sep 2009 12:55:58.0104 (UTC) FILETIME=[336F6180:01CA3796] X-Brightmail-Tracker: AAAAAA== Cc: schulzrinne@cs.columbia.edu, mmusic@ietf.org Subject: Re: [MMUSIC] RFC2326bis-22, Section 16.19 need clarification. X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2009 12:55:09 -0000 Roni Even skrev: > Magnus, > I also agree that the intention is for number 1. > I thought that the proxy will have separate sessions for each client based > on > section 16.47: > "However, multiple "user" sessions for the same URI from the same client > will require use of different session identifiers. > The session identifier is needed to distinguish several delivery > requests for the same URI coming from the same client. > " > Do you think that we should try to make this text stronger RTSP sessions and TCP connections are not the same. I think this confusions comes from that the information is spread out in multiple places. For example the text in 10.2 is relevant: > A persistent connection is RECOMMENDED to be used for all > transactions between the server and client, including messages for > multiple RTSP sessions. However, a persistent connection MAY be > closed after a few message exchanges. For example, a client may use > a persistent connection for the initial SETUP and PLAY message > exchanges in a session and then close the connection. Later, when > the client wishes to send a new request, such as a PAUSE for the > session, a new connection would be opened. This connection may > either be transient or persistent. > > An RTSP agent SHOULD NOT have more than one connection to the server > at any given point. If a client or proxy handles multiple RTSP > sessions on the same server, it SHOULD use only one connection for > managing those sessions. > > This saves connection resources on the server. It also reduces > complexity by and enabling the server to maintain less state about > its sessions and connections. It might be that we should expand on the Proxies chapter to discuss aggregation of RTSP sessions from multiple client in that context. Cheers Magnus Westerlund IETF Transport Area Director ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From rjsparks@nostrum.com Thu Sep 17 11:32:46 2009 Return-Path: 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 BFA123A6877 for ; Thu, 17 Sep 2009 11:32:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_111=0.6, SPF_PASS=-0.001] 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 e5Aw+wMIgUab for ; Thu, 17 Sep 2009 11:32:46 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id AC5243A67B7 for ; Thu, 17 Sep 2009 11:32:45 -0700 (PDT) Received: from 132-177-253-133.ip.sipit.net (132-177-253-133.ip.sipit.net [132.177.253.133]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n8HIXVc8076853 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 17 Sep 2009 13:33:34 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-Id: <3675635B-CC5A-4801-B391-E29D196C01C6@nostrum.com> From: Robert Sparks To: mmusic@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 17 Sep 2009 14:33:31 -0400 X-Mailer: Apple Mail (2.936) Received-SPF: pass (nostrum.com: 132.177.253.133 is authenticated by a trusted mechanism) Subject: [MMUSIC] SDP offer/answer question from SIPit X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2009 18:32:46 -0000 Can somebody point quickly to some existing text that answers this question? (If none exists, perhaps we should think about creating some) When you reject an m-line that has something in it you've never heard of before, (say someone sent you m=application 50000 TCP/TLS/BFCP *) you return a corresponding m-line with a port of 0 as below, the question is, as you are building that response: m=application 0 ????what goes here???? One sane answer is to just copy the bits from the offer without trying to attribute any meaning to them: m=application 0 TCP/TLS/BFCP * But remember that the rejector probably doesn't know TCP/TLS/BFCP from NEVER/USE/THIS. Section 6 of 3264 has this language: "To reject an offered stream, the port number in the corresponding stream in the answer MUST be set to zero. Any media formats listed are ignored. At least one MUST be present, as specified by SDP." Now, media-field is this in SDP: media-field = %x6d "=" media SP port ["/" integer] SP proto 1*(SP fmt) CRLF So the text from 3264 could be read to be talking only the fmt field. Should the proto field also be ignored at this point? Would it be ok to return m=application 0 RTP/AVP 0 for example? If not, what text makes it clear? (It might exist, but the testing is furious today and I'm not spotting it quickly). RjS From jo@netlab.tkk.fi Sun Sep 20 09:19:32 2009 Return-Path: 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 C7D5B3A689E for ; Sun, 20 Sep 2009 09:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 p0uaXERdA9sz for ; Sun, 20 Sep 2009 09:19:32 -0700 (PDT) Received: from smtp-4.hut.fi (smtp-4.hut.fi [130.233.228.94]) by core3.amsl.com (Postfix) with ESMTP id BB1503A6869 for ; Sun, 20 Sep 2009 09:19:31 -0700 (PDT) Received: from localhost (katosiko.hut.fi [130.233.228.115]) by smtp-4.hut.fi (8.13.6/8.12.10) with ESMTP id n8KGKOBC012154; Sun, 20 Sep 2009 19:20:24 +0300 Received: from smtp-4.hut.fi ([130.233.228.94]) by localhost (katosiko.hut.fi [130.233.228.115]) (amavisd-new, port 10024) with LMTP id 10594-124-4; Sun, 20 Sep 2009 19:20:24 +0300 (EEST) Received: from smtp.netlab.hut.fi (luuri.netlab.hut.fi [130.233.154.177]) by smtp-4.hut.fi (8.13.6/8.12.10) with ESMTP id n8KGJavK011932; Sun, 20 Sep 2009 19:19:36 +0300 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.netlab.hut.fi (Postfix) with ESMTP id 2CE431E047; Sun, 20 Sep 2009 19:19:36 +0300 (EEST) X-Virus-Scanned: by amavisd-new at luuri.netlab.hut.fi Received: from smtp.netlab.hut.fi ([127.0.0.1]) by localhost (luuri.netlab.hut.fi [127.0.0.1]) (amavisd-new, port 10024) with LMTP id nh1IG7f1fOl8; Sun, 20 Sep 2009 19:19:32 +0300 (EEST) Received: from joerg-otts-macbook.local (a91-154-108-222.elisa-laajakaista.fi [91.154.108.222]) by smtp.netlab.hut.fi (Postfix) with ESMTPSA id 366E81E01D; Sun, 20 Sep 2009 19:19:32 +0300 (EEST) Message-ID: <4AB65606.4040905@netlab.tkk.fi> Date: Sun, 20 Sep 2009 19:19:18 +0300 From: Joerg Ott User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: mmusic@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at katosiko.hut.fi Cc: Magnus Westerlund , Jean-Francois Mule , Martin Stiemerling Subject: [MMUSIC] WGLC: draft-ietf-mmusic-rfc2326bis-22 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Sep 2009 16:19:32 -0000 Folks, as agreed in Stockholm, we are issuing working group last call on the revised RTSP spec, draft-ietf-mmusic-rfc2326bis-22 heading for Proposed Standard. (http://tools.ietf.org/html/draft-ietf-mmusic-rfc2326bis-22) The WGLC will expire in four weeks, on 19 Oct 2009. We know that this is a long spec, the more important is it to receive thorough review by the community. While we have three volunteer reviewers (thanks again!), we urge everyone who cares to provide detailed feedback. Please review the document and post your comments to the MMUSIC list and/or the authors. Thanks, Joerg MMUSIC co-chair From christer.holmberg@ericsson.com Sun Sep 20 10:24:37 2009 Return-Path: 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 5A8F83A696E for ; Sun, 20 Sep 2009 10:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.277 X-Spam-Level: X-Spam-Status: No, score=-4.277 tagged_above=-999 required=5 tests=[AWL=-0.487, BAYES_20=-0.74, HELO_EQ_SE=0.35, J_CHICKENPOX_111=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 JCKemgLoWsJw for ; Sun, 20 Sep 2009 10:24:36 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 08F3B3A6884 for ; Sun, 20 Sep 2009 10:24:35 -0700 (PDT) X-AuditID: c1b4fb3c-b7b6eae000003d08-74-4ab6658d7688 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id F0.26.15624.D8566BA4; Sun, 20 Sep 2009 19:25:33 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sun, 20 Sep 2009 19:25:04 +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: Sun, 20 Sep 2009 19:23:09 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] SDP offer/answer question from SIPit Thread-Index: Aco3xWTrwNVxjl01R96qPSDZilAjPwCUaE2f References: <3675635B-CC5A-4801-B391-E29D196C01C6@nostrum.com> From: "Christer Holmberg" To: "Robert Sparks" , X-OriginalArrivalTime: 20 Sep 2009 17:25:04.0247 (UTC) FILETIME=[4A868870:01CA3A17] X-Brightmail-Tracker: AAAAAA== Subject: Re: [MMUSIC] SDP offer/answer question from SIPit X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Sep 2009 17:24:37 -0000 Hi, =20 Since the port is zero, does it really matter? =20 As long as the transport types etc match for the non-zero port m- lines, = the offerer should be ok. =20 Regards, =20 Christer ________________________________ From: mmusic-bounces@ietf.org on behalf of Robert Sparks Sent: Thu 17/09/2009 20:33 To: mmusic@ietf.org Subject: [MMUSIC] SDP offer/answer question from SIPit Can somebody point quickly to some existing text that answers this=20 question? (If none exists, perhaps we should think about creating some) When you reject an m-line that has something in it you've never heard=20 of before, (say someone sent you m=3Dapplication 50000 TCP/TLS/BFCP *) you return a corresponding m-line with a port of 0 as below, the question is, as=20 you are building that response: m=3Dapplication 0 ????what goes here???? One sane answer is to just copy the bits from the offer without trying=20 to attribute any meaning to them: m=3Dapplication 0 TCP/TLS/BFCP * But remember that the rejector probably doesn't know TCP/TLS/BFCP from NEVER/USE/THIS. Section 6 of 3264 has this language: "To reject an offered stream, the port number in the corresponding stream in the answer MUST be set to zero. Any media formats listed are ignored. At=20 least one MUST be present, as specified by SDP." Now, media-field is this in SDP: media-field =3D %x6d "=3D" media SP port ["/" integer] SP proto 1*(SP fmt) CRLF So the text from 3264 could be read to be talking only the fmt field. Should the proto field also be ignored at this point? Would it be ok to return m=3Dapplication 0 RTP/AVP 0 for example? If not, what text makes it clear? (It might exist, but the testing is furious today and I'm not spotting=20 it quickly). RjS _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From pkyzivat@cisco.com Mon Sep 21 09:12:30 2009 Return-Path: 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 1DB5128C176 for ; Mon, 21 Sep 2009 09:12:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.963 X-Spam-Level: X-Spam-Status: No, score=-5.963 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, J_CHICKENPOX_111=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 29lw2JP4vibe for ; Mon, 21 Sep 2009 09:12:29 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id E741028C175 for ; Mon, 21 Sep 2009 09:12:28 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAOtCt0pAZnmf/2dsb2JhbAC7TYhQAY49BYQb X-IronPort-AV: E=Sophos;i="4.44,425,1249257600"; d="scan'208";a="59163696" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 21 Sep 2009 16:13:30 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n8LGDUGO015615; Mon, 21 Sep 2009 12:13:30 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n8LGDN3T024237; Mon, 21 Sep 2009 16:13:30 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Sep 2009 12:13:24 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Sep 2009 12:13:24 -0400 Message-ID: <4AB7A625.3020104@cisco.com> Date: Mon, 21 Sep 2009 12:13:25 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Robert Sparks References: <3675635B-CC5A-4801-B391-E29D196C01C6@nostrum.com> In-Reply-To: <3675635B-CC5A-4801-B391-E29D196C01C6@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Sep 2009 16:13:24.0380 (UTC) FILETIME=[7204A5C0:01CA3AD6] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2082; t=1253549610; x=1254413610; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[MMUSIC]=20SDP=20offer/answer=20questio n=20from=20SIPit |Sender:=20 |To:=20Robert=20Sparks=20; bh=ZIGbPIjfSsJMpZgbSX0rcLZ6kI2/sbA0bfvuZYAKx3I=; b=o1zP2KtKIIufys27qOR/box7nfYx5NnItGBW8JvvLJ2deMp5IqZ9GSmxXP 125PE+NQ0gyrSx+fmdSYmC4x9FWqmCRQq4XWg1nmXOxmMFk4r56uHI3HE4F8 zT0rJ0lbm7; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: mmusic@ietf.org Subject: Re: [MMUSIC] SDP offer/answer question from SIPit X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 16:12:30 -0000 Robert, I don't know of anything that is definitive about this. My inclination is that the line needs to be syntactically correct, but that the values of parameters beyond the port can be anything. So not only m=application 0 RTP/AVP 0 but also m=application 0 none 0 But probably the choice with the highest probability of interop is to copy the proto from the offer. Thanks, Paul Robert Sparks wrote: > Can somebody point quickly to some existing text that answers this > question? > (If none exists, perhaps we should think about creating some) > > When you reject an m-line that has something in it you've never heard of > before, > (say someone sent you m=application 50000 TCP/TLS/BFCP *) you return a > corresponding m-line with a port of 0 as below, the question is, as you > are building > that response: > > m=application 0 ????what goes here???? > > One sane answer is to just copy the bits from the offer without trying > to attribute any > meaning to them: > > m=application 0 TCP/TLS/BFCP * > > But remember that the rejector probably doesn't know TCP/TLS/BFCP > from NEVER/USE/THIS. Section 6 of 3264 has this language: > "To reject an offered > stream, the port number in the corresponding stream in the answer > MUST be set to zero. Any media formats listed are ignored. At least > one MUST be present, as specified by SDP." > > Now, media-field is this in SDP: > media-field = %x6d "=" media SP port ["/" integer] > SP proto 1*(SP fmt) CRLF > > So the text from 3264 could be read to be talking only the fmt field. > Should the proto field also be ignored at this point? > > Would it be ok to return > > m=application 0 RTP/AVP 0 > > for example? > > If not, what text makes it clear? > (It might exist, but the testing is furious today and I'm not spotting > it quickly). > > RjS > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From guyingjie@huawei.com Tue Sep 22 19:44:24 2009 Return-Path: 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 F37BB3A68FF for ; Tue, 22 Sep 2009 19:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.058 X-Spam-Level: X-Spam-Status: No, score=-0.058 tagged_above=-999 required=5 tests=[AWL=0.437, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=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 BgDxcmDJobc5 for ; Tue, 22 Sep 2009 19:44:22 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 6E6B23A682D for ; Tue, 22 Sep 2009 19:44:22 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQE000TEKZGRD@szxga04-in.huawei.com> for mmusic@ietf.org; Wed, 23 Sep 2009 10:45:17 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQE001LMKZG4J@szxga04-in.huawei.com> for mmusic@ietf.org; Wed, 23 Sep 2009 10:45:16 +0800 (CST) Received: from g00107907 ([10.164.12.64]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KQE00945KZFFA@szxml04-in.huawei.com> for mmusic@ietf.org; Wed, 23 Sep 2009 10:45:16 +0800 (CST) Date: Wed, 23 Sep 2009 10:45:16 +0800 From: "Y.J. Gu" In-reply-to: <4AB65606.4040905@netlab.tkk.fi> To: 'Joerg Ott' , mmusic@ietf.org Message-id: <001d01ca3bf7$e2554380$400ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Aco6DmdECvk5UUrkSD+ErazjkB4nOwB4IWxQ Cc: 'Magnus Westerlund' , 'Jean-Francois Mule' , 'Martin Stiemerling' Subject: Re: [MMUSIC] WGLC: draft-ietf-mmusic-rfc2326bis-22 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 02:44:24 -0000 Hi all, According to the discussion in the mailing list, there exist some confusions on proxy and CSeq. I conclude the confusions as below. Pls feel free to correct my understanding. 1. How Cseq series should be organized on proxy when the proxy aggregates several RTSP sessions. Magnus has answered this question and I suggest to make the text in Section 16.19 clearer. 2. Is Cseq a good way to matching responses to requests if the requests are pipelined? I have gave an implementation and explains that Cseq could work but relies on the TCP connection in some case. Pls refer to my post in 2009-9-10. I think, as a protocol, RTSP should not bind tightly to any transport protocol. So I suggest that we expand on the proxies charter. How about adding a subsection 17.2 to discuss Proxy aggregating multiple RTSP sessions and give another optional solution other than Cseq. Cseq is useful in some cases, but might there be an easier and clearer one that can also achieve the goal? My gut feeling is that a local identifier, generated by proxy and included without change in both request and response, may help proxy match requests&responses. Proxies assign a local identifier to each new session. Cseq can be used as well for any intention rather than matching R/r. Regards Yingjie Gu > -----Original Message----- > From: mmusic-bounces@ietf.org > [mailto:mmusic-bounces@ietf.org] On Behalf Of Joerg Ott > Sent: Monday, September 21, 2009 12:19 AM > To: mmusic@ietf.org > Cc: Magnus Westerlund; Jean-Francois Mule; Martin Stiemerling > Subject: [MMUSIC] WGLC: draft-ietf-mmusic-rfc2326bis-22 > > Folks, > > as agreed in Stockholm, we are issuing working group last > call on the revised RTSP spec, > draft-ietf-mmusic-rfc2326bis-22 heading for Proposed Standard. > (http://tools.ietf.org/html/draft-ietf-mmusic-rfc2326bis-22) > > The WGLC will expire in four weeks, on 19 Oct 2009. > > We know that this is a long spec, the more important is it to > receive thorough review by the community. While we have > three volunteer reviewers (thanks again!), we urge everyone > who cares to provide detailed feedback. > > Please review the document and post your comments to the > MMUSIC list and/or the authors. > > Thanks, > Joerg > > MMUSIC co-chair > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From magnus.westerlund@ericsson.com Wed Sep 23 04:36:20 2009 Return-Path: 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 7AE2E3A68C2 for ; Wed, 23 Sep 2009 04:36:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.639 X-Spam-Level: X-Spam-Status: No, score=-5.639 tagged_above=-999 required=5 tests=[AWL=0.610, 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 4a9bNQZwL+Vy for ; Wed, 23 Sep 2009 04:36:19 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 492303A6926 for ; Wed, 23 Sep 2009 04:36:19 -0700 (PDT) X-AuditID: c1b4fb24-b7ba0ae000005786-be-4aba0873469c Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id A1.E4.22406.3780ABA4; Wed, 23 Sep 2009 13:37:24 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Sep 2009 13:34:29 +0200 Received: from [147.214.183.250] ([147.214.183.250]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Sep 2009 13:34:29 +0200 Message-ID: <4ABA07C5.3040609@ericsson.com> Date: Wed, 23 Sep 2009 13:34:29 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: IANA X-Enigmail-Version: 0.96.0 Content-Type: multipart/mixed; boundary="------------080907060801060906050104" X-OriginalArrivalTime: 23 Sep 2009 11:34:29.0238 (UTC) FILETIME=[CFEC2160:01CA3C41] X-Brightmail-Tracker: AAAAAA== Cc: "mmusic \(E-mail\)" Subject: [MMUSIC] [Fwd: WGLC: draft-ietf-mmusic-rfc2326bis-22] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 11:36:20 -0000 This is a multi-part message in MIME format. --------------080907060801060906050104 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Hi, Michelle has earlier promised me a review of this documents IANA section. As it is now in WG last call in MMUSIC I would appreciate if it could happen by the end of the WG last call the 19th of October. The reason we want early review is that the document contains a quite extensive IANA section that is 17 pages long that creates a large number of registries. Thanks Magnus Westerlund IETF Transport Area Director ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --------------080907060801060906050104 Content-Type: message/rfc822; name="WGLC: draft-ietf-mmusic-rfc2326bis-22.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="WGLC: draft-ietf-mmusic-rfc2326bis-22.eml" Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw103.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sun, 20 Sep 2009 18:20:28 +0200 Received: from mailgw7.ericsson.se ([193.180.251.48]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sun, 20 Sep 2009 18:20:28 +0200 X-AuditID: c1b4fb30-b7b32ae000003690-a2-4ab6564c33f2 Received: from smtp-4.hut.fi (smtp-4.hut.fi [130.233.228.94]) (using TLS with cipher AES256-SHA (AES256-SHA/256 bits)) (Client did not present a certificate) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 2D.05.13968.C4656BA4; Sun, 20 Sep 2009 18:20:28 +0200 (CEST) Received: from localhost (katosiko.hut.fi [130.233.228.115]) by smtp-4.hut.fi (8.13.6/8.12.10) with ESMTP id n8KGKOBC012154; Sun, 20 Sep 2009 19:20:24 +0300 Received: from smtp-4.hut.fi ([130.233.228.94]) by localhost (katosiko.hut.fi [130.233.228.115]) (amavisd-new, port 10024) with LMTP id 10594-124-4; Sun, 20 Sep 2009 19:20:24 +0300 (EEST) Received: from smtp.netlab.hut.fi (luuri.netlab.hut.fi [130.233.154.177]) by smtp-4.hut.fi (8.13.6/8.12.10) with ESMTP id n8KGJavK011932; Sun, 20 Sep 2009 19:19:36 +0300 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.netlab.hut.fi (Postfix) with ESMTP id 2CE431E047; Sun, 20 Sep 2009 19:19:36 +0300 (EEST) X-Virus-Scanned: by amavisd-new at luuri.netlab.hut.fi Received: from smtp.netlab.hut.fi ([127.0.0.1]) by localhost (luuri.netlab.hut.fi [127.0.0.1]) (amavisd-new, port 10024) with LMTP id nh1IG7f1fOl8; Sun, 20 Sep 2009 19:19:32 +0300 (EEST) Received: from joerg-otts-macbook.local (a91-154-108-222.elisa-laajakaista.fi [91.154.108.222]) by smtp.netlab.hut.fi (Postfix) with ESMTPSA id 366E81E01D; Sun, 20 Sep 2009 19:19:32 +0300 (EEST) Message-ID: <4AB65606.4040905@netlab.tkk.fi> Date: Sun, 20 Sep 2009 19:19:18 +0300 From: Joerg Ott User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: mmusic@ietf.org CC: Jean-Francois Mule , Magnus Westerlund , Martin Stiemerling Subject: WGLC: draft-ietf-mmusic-rfc2326bis-22 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at katosiko.hut.fi X-Brightmail-Tracker: AAAAARDQNYg= Return-Path: jo@netlab.tkk.fi X-OriginalArrivalTime: 20 Sep 2009 16:20:28.0744 (UTC) FILETIME=[448BB480:01CA3A0E] Folks, as agreed in Stockholm, we are issuing working group last call on the revised RTSP spec, draft-ietf-mmusic-rfc2326bis-22 heading for Proposed Standard. (http://tools.ietf.org/html/draft-ietf-mmusic-rfc2326bis-22) The WGLC will expire in four weeks, on 19 Oct 2009. We know that this is a long spec, the more important is it to receive thorough review by the community. While we have three volunteer reviewers (thanks again!), we urge everyone who cares to provide detailed feedback. Please review the document and post your comments to the MMUSIC list and/or the authors. Thanks, Joerg MMUSIC co-chair --------------080907060801060906050104-- From abegen@cisco.com Wed Sep 23 09:51:38 2009 Return-Path: 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 7D3153A6911; Wed, 23 Sep 2009 09:51:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.465 X-Spam-Level: X-Spam-Status: No, score=-6.465 tagged_above=-999 required=5 tests=[AWL=0.134, 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 CdAhvtof-m9J; Wed, 23 Sep 2009 09:51:37 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 7A2833A6906; Wed, 23 Sep 2009 09:51:37 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEABDvuUqrR7PE/2dsb2JhbACZS6VbiE8BkBUFhBs X-IronPort-AV: E=Sophos;i="4.44,439,1249257600"; d="scan'208";a="245851348" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 23 Sep 2009 16:52:44 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n8NGqiNo006377; Wed, 23 Sep 2009 09:52:44 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n8NGqh8Q001008; Wed, 23 Sep 2009 16:52:44 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 23 Sep 2009 09:52:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Wed, 23 Sep 2009 09:52:36 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540A3935F9@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-ietf-mmusic-rfc4756bis-03 Thread-Index: Aco8bf7PWFOmmuErRbuKRfBYZMZt4AAAAoJg From: "Ali C. Begen (abegen)" To: , X-OriginalArrivalTime: 23 Sep 2009 16:52:41.0260 (UTC) FILETIME=[43A77EC0:01CA3C6E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2304; t=1253724764; x=1254588764; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=abegen@cisco.com; z=From:=20=22Ali=20C.=20Begen=20(abegen)=22=20 |Subject:=20FW=3A=20New=20Version=20Notification=20for=20dr aft-ietf-mmusic-rfc4756bis-03=20 |Sender:=20; bh=8rF2s4ZwKF/eTwchH/wFh9/hR1i+54qoextX9gKbrvo=; b=WAkAavzqCOugshG+E+7XkXsaLeBZcFsUtuGqeSMh64eCanzJDQd9vLGFI1 E88gdPhZsskGmIWwsPgInWZr21IQbZXabzYcwxKweZvmPJuCOdjDH4n/hKRi vdilTrkryL; Authentication-Results: sj-dkim-4; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: [MMUSIC] FW: New Version Notification for draft-ietf-mmusic-rfc4756bis-03 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 16:51:38 -0000 QSByZXZpc2lvbiBoYXMgYmVlbiBqdXN0IHBvc3RlZCB0byBhZGRyZXNzIHRoZSBjb21tZW50IGZy b20gQ29saW4uIEkgYWxzbyBmaXhlZCBhIGZldyBvbGRlciByZWZlcmVuY2VzLiBJIGJlbGlldmUg d2UgYXJlIHJlYWR5IGZvciBsYXN0IGNhbGwuDQoNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvaWQvZHJh ZnQtaWV0Zi1tbXVzaWMtcmZjNDc1NmJpcy0wMy50eHQNCg0KDQpDaGVlcnMsIGFjYmVnZW4uDQoN Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBJRVRGIEktRCBTdWJtaXNzaW9uIFRv b2wgW21haWx0bzppZHN1Ym1pc3Npb25AaWV0Zi5vcmddIA0KU2VudDogV2VkbmVzZGF5LCBTZXB0 ZW1iZXIgMjMsIDIwMDkgMTI6NTAgUE0NClRvOiBBbGkgQy4gQmVnZW4gKGFiZWdlbikNClN1Ympl Y3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi1tbXVzaWMtcmZjNDc1 NmJpcy0wMyANCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaWV0Zi1tbXVzaWMtcmZj NDc1NmJpcy0wMy50eHQgaGFzIGJlZW4gc3VjY2Vzc2Z1bHkgc3VibWl0dGVkIGJ5IEFsaSBCZWdl biBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQt aWV0Zi1tbXVzaWMtcmZjNDc1NmJpcw0KUmV2aXNpb246CSAwMw0KVGl0bGU6CQkgRm9yd2FyZCBF cnJvciBDb3JyZWN0aW9uIEdyb3VwaW5nIFNlbWFudGljcyBpbiBTZXNzaW9uIERlc2NyaXB0aW9u IFByb3RvY29sDQpDcmVhdGlvbl9kYXRlOgkgMjAwOS0wOS0yMw0KV0cgSUQ6CQkgbW11c2ljDQpO dW1iZXJfb2ZfcGFnZXM6IDEyDQoNCkFic3RyYWN0Og0KVGhlIFNlc3Npb24gRGVzY3JpcHRpb24g UHJvdG9jb2wgKFNEUCkgc3VwcG9ydHMgZ3JvdXBpbmcgbWVkaWEgbGluZXMuDQpTRFAgYWxzbyBo YXMgc2VtYW50aWNzIGRlZmluZWQgZm9yIGdyb3VwaW5nIHRoZSBhc3NvY2lhdGVkIHNvdXJjZSBh bmQNCkZvcndhcmQgRXJyb3IgQ29ycmVjdGlvbiAoRkVDKS1iYXNlZCByZXBhaXIgZmxvd3MuICBI b3dldmVyLCB0aGUNCnNlbWFudGljcyB0aGF0IHdhcyBkZWZpbmVkIGluIFJGQyA0NzU2IGdlbmVy YWxseSBmYWlsIHRvIHByb3ZpZGUgdGhlDQpzcGVjaWZpYyBncm91cGluZyByZWxhdGlvbnNoaXBz IGJldHdlZW4gdGhlIHNvdXJjZSBhbmQgcmVwYWlyIGZsb3dzDQp3aGVuIHRoZXJlIGFyZSBtb3Jl IHRoYW4gb25lIHNvdXJjZSBhbmQvb3IgcmVwYWlyIGZsb3dzIGluIHRoZSBzYW1lDQpncm91cC4g IEZ1cnRoZXJtb3JlLCB0aGUgZXhpc3Rpbmcgc2VtYW50aWNzIGRvZXMgbm90IHN1cHBvcnQNCmRl c2NyaWJpbmcgYWRkaXRpdmUgcmVwYWlyIGZsb3dzLiAgVGhpcyBkb2N1bWVudCBhZGRyZXNzZXMg dGhlc2UNCmlzc3VlcyBieSBpbnRyb2R1Y2luZyBuZXcgRkVDIGdyb3VwaW5nIHNlbWFudGljcy4g IFNTUkMtbGV2ZWwNCmdyb3VwaW5nIHNlbWFudGljcyBpcyBhbHNvIGludHJvZHVjZWQgaW4gdGhp cyBkb2N1bWVudCBmb3IgUmVhbC10aW1lDQpUcmFuc3BvcnQgUHJvdG9jb2wgKFJUUCkgc3RyZWFt cyB1c2luZyBTU1JDIG11bHRpcGxleGluZy4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0K DQpUaGUgSUVURiBTZWNyZXRhcmlhdC4NCg0KDQo= From root@core3.amsl.com Wed Sep 23 10:00:01 2009 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 9B7353A67EB; Wed, 23 Sep 2009 10:00: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: <20090923170001.9B7353A67EB@core3.amsl.com> Date: Wed, 23 Sep 2009 10:00:01 -0700 (PDT) Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action:draft-ietf-mmusic-rfc4756bis-03.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Sep 2009 17:00: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 : Forward Error Correction Grouping Semantics in Session Description Protocol Author(s) : A. Begen Filename : draft-ietf-mmusic-rfc4756bis-03.txt Pages : 12 Date : 2009-09-23 The Session Description Protocol (SDP) supports grouping media lines. SDP also has semantics defined for grouping the associated source and Forward Error Correction (FEC)-based repair flows. However, the semantics that was defined in RFC 4756 generally fail to provide the specific grouping relationships between the source and repair flows when there are more than one source and/or repair flows in the same group. Furthermore, the existing semantics does not support describing additive repair flows. This document addresses these issues by introducing new FEC grouping semantics. SSRC-level grouping semantics is also introduced in this document for Real-time Transport Protocol (RTP) streams using SSRC multiplexing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rfc4756bis-03.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-rfc4756bis-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-09-23094938.I-D@ietf.org> --NextPart-- From csp@csperkins.org Thu Sep 24 15:32:27 2009 Return-Path: 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 F300C3A68AD; Thu, 24 Sep 2009 15:32:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.425 X-Spam-Level: X-Spam-Status: No, score=-3.425 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 zJv68T+67nqU; Thu, 24 Sep 2009 15:32:25 -0700 (PDT) Received: from lon1-msapost-1.mail.demon.net (lon1-msapost-1.mail.demon.net [195.173.77.180]) by core3.amsl.com (Postfix) with ESMTP id C19873A683A; Thu, 24 Sep 2009 15:32:25 -0700 (PDT) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.12]) by lon1-post-1.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1MqwsY-0006Fu-Yt; Thu, 24 Sep 2009 22:33:34 +0000 Message-Id: <5226612F-7151-45EE-8438-830E4F16BC4A@csperkins.org> From: Colin Perkins To: Ali C. Begen (abegen) In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540A3935F9@xmb-sjc-215.amer.cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 24 Sep 2009 23:33:33 +0100 References: <04CAD96D4C5A3D48B1919248A8FE0D540A3935F9@xmb-sjc-215.amer.cisco.com> X-Mailer: Apple Mail (2.936) Cc: mmusic@ietf.org, fecframe@ietf.org Subject: Re: [MMUSIC] FW: New Version Notification for draft-ietf-mmusic-rfc4756bis-03 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 22:32:27 -0000 The changes look good to me. Thanks, Colin On 23 Sep 2009, at 17:52, Ali C. Begen (abegen) wrote: > A revision has been just posted to address the comment from Colin. I > also fixed a few older references. I believe we are ready for last > call. > > http://www.ietf.org/id/draft-ietf-mmusic-rfc4756bis-03.txt > > > Cheers, acbegen. > > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: Wednesday, September 23, 2009 12:50 PM > To: Ali C. Begen (abegen) > Subject: New Version Notification for draft-ietf-mmusic-rfc4756bis-03 > > > A new version of I-D, draft-ietf-mmusic-rfc4756bis-03.txt has been > successfuly submitted by Ali Begen and posted to the IETF repository. > > Filename: draft-ietf-mmusic-rfc4756bis > Revision: 03 > Title: Forward Error Correction Grouping Semantics in Session > Description Protocol > Creation_date: 2009-09-23 > WG ID: mmusic > Number_of_pages: 12 > > Abstract: > The Session Description Protocol (SDP) supports grouping media lines. > SDP also has semantics defined for grouping the associated source and > Forward Error Correction (FEC)-based repair flows. However, the > semantics that was defined in RFC 4756 generally fail to provide the > specific grouping relationships between the source and repair flows > when there are more than one source and/or repair flows in the same > group. Furthermore, the existing semantics does not support > describing additive repair flows. This document addresses these > issues by introducing new FEC grouping semantics. SSRC-level > grouping semantics is also introduced in this document for Real-time > Transport Protocol (RTP) streams using SSRC multiplexing. > > > > The IETF Secretariat. > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic -- Colin Perkins http://csperkins.org/ From Christian.Haas@frequentis.com Thu Sep 24 22:23:00 2009 Return-Path: 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 4CF393A698E for ; Thu, 24 Sep 2009 22:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] 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 1Js8el6vNqrb for ; Thu, 24 Sep 2009 22:22:48 -0700 (PDT) Received: from mail1.frequentis.com (mail1.frequentis.com [212.186.194.131]) by core3.amsl.com (Postfix) with ESMTP id AAE6A3A67FF for ; Thu, 24 Sep 2009 22:22:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,449,1249250400"; d="scan'208";a="590376" Received: from unknown (HELO webmail.frequentis.com) ([192.168.253.10]) by mail1.frequentis.com with ESMTP; 25 Sep 2009 07:23:48 +0200 Received: from VIECLEX01.frequentis.frq ([192.168.253.1]) by webmail.frequentis.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 25 Sep 2009 07:23:48 +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: Fri, 25 Sep 2009 07:23:47 +0200 Message-ID: <70FB7A734037F44399441D45A72DE90D04B8298B@VIECLEX01.frequentis.frq> In-Reply-To: <4AB65606.4040905@netlab.tkk.fi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] WGLC: draft-ietf-mmusic-rfc2326bis-22 Thread-Index: Aco6DnDOJU+iBP/DQhGHuV19VgdmvQDkPE6w References: <4AB65606.4040905@netlab.tkk.fi> From: "HAAS Christian" To: X-OriginalArrivalTime: 25 Sep 2009 05:23:48.0354 (UTC) FILETIME=[5C260E20:01CA3DA0] Subject: Re: [MMUSIC] WGLC: draft-ietf-mmusic-rfc2326bis-22 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2009 05:23:02 -0000 Hello all! I've read through the draft (skipping the syntax definitions) and found = only minor issues regarding wording, typos and consistency so far, which I = already sent to Magnus directly. I will try to find some time during the upcoming days for a dedicated = check of the syntax. Regards, ch ____________________________________________________ Christian Haas Team DIVOS, Software Engineer FREQUENTIS=A0AG Innovationsstra=DFe 1,=A01100 Vienna,=A0Austria Phone=A0=A0 +43-1-811 50 -=A08353 Mobile =A0=A0+43-664-60 850=A0- 8353 Fax=A0=A0=A0=A0=A0=A0=A0+43-1-811 50 - 77 8353 Web=A0=A0=A0=A0=A0 www.frequentis.com E-Mail=A0=A0=A0=A0christian.haas@frequentis.com =A0 Handelsgericht Wien (Vienna Commercial Court): FN 72115 b DVR 0364797, ATU 14715600 ____________________________________________________ Diese=A0E-Mail k=F6nnte vertrauliche und/oder rechtlich gesch=FCtzte = Informationen enthalten. Wenn Sie nicht der richtige Adressat sind oder diese=A0E-Mail irrt=FCmlich erhalten haben, informieren Sie bitte sofort den Absender = und vernichten Sie diese=A0E-Mail. Das unerlaubte Kopieren sowie die = unbefugte Weitergabe dieser=A0E-Mail sind nicht gestattet. This e-mail may contain confidential and/or privileged information. If = you are not the intended recipient (or have received this e-mail in error) = please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.=20 -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf = Of Joerg Ott Sent: Sonntag, 20. September 2009 18:19 To: mmusic@ietf.org Cc: Magnus Westerlund; Jean-Francois Mule; Martin Stiemerling Subject: [MMUSIC] WGLC: draft-ietf-mmusic-rfc2326bis-22 Folks, as agreed in Stockholm, we are issuing working group last call on the = revised RTSP spec, draft-ietf-mmusic-rfc2326bis-22 heading for Proposed = Standard. (http://tools.ietf.org/html/draft-ietf-mmusic-rfc2326bis-22) The WGLC will expire in four weeks, on 19 Oct 2009. We know that this is a long spec, the more important is it to receive thorough review by the community. While we have three volunteer = reviewers (thanks again!), we urge everyone who cares to provide detailed = feedback. Please review the document and post your comments to the MMUSIC list = and/or the authors. Thanks, Joerg MMUSIC co-chair _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From jo@netlab.tkk.fi Mon Sep 28 06:22:07 2009 Return-Path: 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 08C6E3A6818 for ; Mon, 28 Sep 2009 06:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.67 X-Spam-Level: X-Spam-Status: No, score=-3.67 tagged_above=-999 required=5 tests=[AWL=1.071, BAYES_20=-0.74, 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 Zy3Sd99D4r1W for ; Mon, 28 Sep 2009 06:22:06 -0700 (PDT) Received: from smtp-3.hut.fi (smtp-3.hut.fi [130.233.228.93]) by core3.amsl.com (Postfix) with ESMTP id 164C03A67BE for ; Mon, 28 Sep 2009 06:22:05 -0700 (PDT) Received: from localhost (katosiko.hut.fi [130.233.228.115]) by smtp-3.hut.fi (8.13.6/8.12.10) with ESMTP id n8SDNIk8026397; Mon, 28 Sep 2009 16:23:18 +0300 Received: from smtp-3.hut.fi ([130.233.228.93]) by localhost (katosiko.hut.fi [130.233.228.115]) (amavisd-new, port 10024) with LMTP id 17026-57; Mon, 28 Sep 2009 16:23:18 +0300 (EEST) Received: from smtp.netlab.hut.fi (luuri.netlab.hut.fi [130.233.154.177]) by smtp-3.hut.fi (8.13.6/8.12.10) with ESMTP id n8SDMkIq026173; Mon, 28 Sep 2009 16:22:46 +0300 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.netlab.hut.fi (Postfix) with ESMTP id 66D001E15A; Mon, 28 Sep 2009 16:22:46 +0300 (EEST) X-Virus-Scanned: by amavisd-new at luuri.netlab.hut.fi Received: from smtp.netlab.hut.fi ([127.0.0.1]) by localhost (luuri.netlab.hut.fi [127.0.0.1]) (amavisd-new, port 10024) with LMTP id x9fYLSnL52KX; Mon, 28 Sep 2009 16:22:42 +0300 (EEST) Received: from pc89.netlab.hut.fi (pc89.netlab.hut.fi [130.233.154.89]) by smtp.netlab.hut.fi (Postfix) with ESMTPSA id 77F511E156; Mon, 28 Sep 2009 16:22:42 +0300 (EEST) Message-ID: <4AC0B88F.9000609@netlab.tkk.fi> Date: Mon, 28 Sep 2009 16:22:23 +0300 From: Joerg Ott User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: mmusic@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at katosiko.hut.fi Cc: Jean-Francois Mule Subject: [MMUSIC] Agenda items for Hiroshima X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2009 13:22:07 -0000 Folks, we should have one meeting slot for MMUSIC to meet in Hiroshima. We'd like to poll you for agenda items. Please indicate in your agenda item request -- about which published Internet draft (and version) it is -- which specific issues you would like to talk about (and, of course, please note the 'note well' statement before sending in requests) WG items will have priority over individual drafts. Please send requests just to Jean-François and myself. Thanks, Joerg From iana-shared@icann.org Mon Sep 28 06:57:32 2009 Return-Path: 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 DB50A3A696D for ; Mon, 28 Sep 2009 06:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.818 X-Spam-Level: X-Spam-Status: No, score=-7.818 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_HI=-8] 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 mvQVPUiUXnBo for ; Mon, 28 Sep 2009 06:57:31 -0700 (PDT) Received: from request.iana.org (request.iana.org [208.77.188.221]) by core3.amsl.com (Postfix) with ESMTP id E72BC3A6945 for ; Mon, 28 Sep 2009 06:57:30 -0700 (PDT) Received: from request.iana.org (localhost.localdomain [127.0.0.1]) by request.iana.org (8.13.8/8.13.8) with ESMTP id n8SDvn3G011099 for ; Mon, 28 Sep 2009 06:57:49 -0700 Received: (from apache@localhost) by request.iana.org (8.13.8/8.13.8/Submit) id n8SDvnLG011098; Mon, 28 Sep 2009 06:57:49 -0700 From: "Michelle Cotton via RT" In-Reply-To: <4ABA07C5.3040609@ericsson.com> References: <4ABA07C5.3040609@ericsson.com> Message-ID: Precedence: bulk X-RT-Loop-Prevention: IANA RT-Ticket: IANA #267864 Managed-by: RT 3.8.3pre1 (http://www.bestpractical.com/rt/) RT-Originator: michelle.cotton@icann.org Cc: mmusic@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Date: Mon, 28 Sep 2009 13:57:49 +0000 X-Mailman-Approved-At: Mon, 28 Sep 2009 08:04:13 -0700 Subject: [MMUSIC] [IANA #267864] [Fwd: WGLC: draft-ietf-mmusic-rfc2326bis-22] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Reply-To: iana-issues@iana.org List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2009 13:57:32 -0000 Magnus, I hope this review helps.. We will officially review this document in IETF Last Call. Hopefully these comments will assist in getting the document's IANA section close to perfect. Best regards, Michelle IANA IANA COMMENTS: IANA has examined draft-ietf-mmusic-rfc2326bis-22. While the IANA Considerations in Section 22 are very helpful and quite detailed, IANA has some comments and questions about the draft. General questions for the authors: IANA notes that four registries for RTSP v1.0 are located at: http://www.iana.org/assignments/rtsp-parameters/rtsp-parameters.xhtml. IANA would like to confirm that these registries (Headers, Methods, Option Tags and Status Codes) are to remain in place for compatibility purposes. Is this correct? The structure of the RTSPv1.0 registry was to provide a single repository for all RTSP parameter registries. One possibility for the new RTSP v2.0 registry is to simply create a new file/repository for the v2.0 parameters. Another possibility is to simply extend the existing repository to contain both v1.0 and v2.0 parameters. Which of these options is preferred by the authors? Upon approval of this document, IANA understands that there are to be four major actions completed by the IANA: 1] the creation of 18 new registries (see below) in a registry location to be determined; 2] the registration of three new, permanent URI schemes (in http://www.iana.org/assignments/uri-schemes.html); and, 3] the registration of three new SDP attributes (in http://www.iana.org/assignments/sdp-parameters) 4] the registration of a Media Type for text/parameters (in MIME Media Types registry located at: http://www.iana.org/assignments/media-types/index.html. Part 1: ======= IANA understands that eighteen new registries are to be created. 1.1 A new registry called RTSP v2.0 feature-tags. The description of the contents of the registry is in section 22.1.1 of the draft document. IANA understands that future registrations are to be done on a first come, first served basis. IANA also understands that there are four initial values to be initially registered and that these are documented in section 22.1.3 of the draft. For each item in the RTSP v2.0 feature-tags registry, IANA understands that four fields will be registered: - the name of the feature tag (with rules for the creation of the name documented in section 22.1.2); - a description of the feature tag (a simple text string); - a indication of whether or not the feature tag applies to clients, servers or proxies (non-exclusively). and, - a reference for the source of the registry value (e.g. RFC, etc.) QUESTION TO AUTHORS: Is there a limit on the length of the description? Should the indication of whether or not the feature tag applies to clients, servers or proxies be provided as a matrix, or simply text? 1.2 A new registry called RTSP v2.0 Methods. The description of the meaning of RTSP Methods, the content of the registry, is in section 13 of the draft document. IANA understands that future registrations are to be done IETF Standards Action only. IANA also understands that there are ten initial values to be initially registered and that these are documented in section 13 of the draft. QUESTION TO AUTHORS: Should this registry mimic the presentation of Table 7 in Section 13 of the draft document? If so, could the authors ensure that the table column headings have full descriptions and provide any advice about which fields should be in the registry and which are simply guidance for the reader of the draft? 1.3 A new registry called RTSP v2.0 Status Codes. IANA understands the description of RTSP v2.0 Status Codes to be "A status code is the three digit number used to convey information in RTSP response messages." IANA also understands that future registrations are to be done through IETF Standards Action only. IANA also understands that there are 46 initial values to be initially registered and that these are to be extracted from the ABNF documentation for "Status-Code" in section 20.2.2 of the draft. For each item in the RTSP v2.0 Status Codes registry, IANA understands that three fields will be registered: - the three digit status code; - the meaning of the status code; and, - a reference for the source of the registry value. QUESTION TO AUTHORS: IANA is unsure how to handle the value "extension-code." Is a separate registration for "setension-code" required? 1.4 A new registry called RTSP v2.0 Headers. IANA intends to use the description provided in section 22.4.1 of the document for this registry. IANA understands that future registrations are to be done using Expert Review. IANA also understands that there are 68 initial values to be initially registered and that these are to be extracted from Section 16 (57 values) and Section 22.4.3 (11 values) of the draft. QUESTION TO AUTHORS: For each item in the RTSP V2.0 Headers registry, what values are recorded? The name, descirption, and reference sufficient, or should there be other fields for each entry in the registry? 1.5 A new registry called RTSP v2.0 Accept-Credentials policies. IANA understands the description of RTSP v2.0 Accept-Credentials policies to be defined in Section 22.5.1 of the document. IANA also understands that future registrations are to be done through IETF Standards Action only. IANA also understands that there are three initial values to be initially registered and that these are "Any" "Proxy" and "User" QUESTION TO AUTHORS: Beside the name of the Accept-Credentials value and a reference to where it is defined, are there any other fields that should be in this registry based on the definitions in Section 19.3.1 of the document? 1.6 A new registry called RTSP v2.0 Accept-Credentials hash algorithms. IANA understands the description of RTSP v2.0 Accept-Credentials hash algorithms to be the first sentence of text in Section 22.5.2 of the document. IANA also understands that future registrations are to be done through IETF Standards Action only. IANA also understands that there are no initial values to be registered upon approval of the document. QUESTION TO AUTHORS: If there were items in this registry, what fields would be registered for each item (name, reference, etc.)? 1.7 A new registry called RTSP v2.0 Cache Directive Extensions. IANA understands the description of RTSP v2.0 Cache Directive Extensions to be the first paragraph of the text in section 22.6 of the document. IANA also understands that future registrations are to be done through IETF Standards Action only. IANA also understands that there are 10 initial values to be registered upon approval of the document and that these are identified in section 22.6 of the document. For each item in the RTSP v2.0 Cache Directive Extensions registry, IANA understands that four fields will be registered: - the name of the directive; - the definition of the value; - specification if it is a request or response directive; and, - a reference for the source of the registry value. 1.8 A new registry called RTSP v2.0 Media Properties. IANA understands the description of RTSP v2.0 Media Propoerties to be the text in section 22.7.1 of the document. IANA also understands that future registrations are to be done using a designated expert. IANA also understands that there are ten initial values to be registered upon approval of the document and that these are identified in section 16.28 of the document. For each item in the RTSP v2.0 Media Properties registry, IANA understands that three fields will be registered: - the name of the media property; - a contact name for the property; - the description of the media property; and, - a reference for the source of the registry value. QUESTION TO AUTHORS: IANA understands that the property values identified in Section 16.28 are to be registered but not the property groups. Is this correct? 1.9 A new registry called RTSP v2.0 Notify Reason Values. IANA understands the description of RTSP v2.0 Status Codes to be the first two sentences of the text in section 22.8.1 of the document. IANA also understands that future registrations are to be done using a designated expert. IANA also understands that there are three initial values to be registered upon approval of the document and that these are to be extracted from the values defined in the Notify-Reas-val ABNF in Section 20.2.3. For each item in the RTSP v2.0 Notify Reason Values registry, IANA understands that four fields will be registered: - the Notify Reason Value; - the definition of the value; - a contact name; and, - a reference for the source of the registry value. 1.11 A new registry called RTSP v2.0 Range Header formats. IANA understands the description of RTSP v2.0 Range Header formats to be the first sentence of text in Section 22.9 of the document. IANA also understands that future registrations are to be done through IETF Standards Action only. IANA also understands that there are no initial values to be registered upon approval of the document. QUESTION TO AUTHORS: If there were items in this registry, what fields would be registered for each item (name, description, reference, etc.)? 1.12 A new registry called RTSP v2.0 Terminate-Reason Header Redirection Reasons. IANA understands the description of RTSP v2.0 Terminate-Reason Header Redirection Reasons to be the first two sentences of the text in section 16.50 of the document. IANA also understands that future registrations are to be done using a designated expert. IANA further understands that there are two initial values to be registered upon approval of the document and that these are in section 22.10.1 of the document. For each item in the RTSP v2.0 Terminate-Reason Header Redirection Reasons registry, IANA understands that three fields will be registered: - the Terminate-Reason Header Redirection Reason; - the description of the reason; and, - a reference for the source of the registry value. 1.13 A new registry called RTSP v2.0 Terminate-Reason Header Parameters. IANA understands the description of RTSP v2.0 Terminate-Reason Header Parameters to be the first two sentences of the text in section 16.50 of the document. IANA also understands that future registrations are to be done through IETF Standards Action only. IANA further understands that there are two initial values to be registered upon approval of the document and that these are in section 22.10.2 of the document. For each item in the RTSP v2.0 Terminate- Reason Header Parameters registry, IANA understands that four fields will be registered: - the Terminate-Reason Header Parameter; - the description of the parameter; - a contact name; and, - a reference for the source of the registry value. 1.14 A new registry called RTSP v2.0 RTP-Info header parameters. IANA understands the description of RTSP v2.0 RTP-Info header parameters to be extracted from section 16,43 of the document IANA also understands that future registrations are to be done using a designated expert. IANA further understands that there are two initial values to be registered upon approval of the document and that these are in section 22.11.3 of the document. For each item in the RTSP v2.0 RTP-Info header parameters registry, IANA understands that four fields will be registered: - the RTP-Info header parameter value; - the description of the value; - a contact name; and, - a reference for the source of the registry value. 1.15 A new registry called RTSP v2.0 Seek-Style Policies. IANA understands the description of RTSP v2.0 Seek-Style Policies to be extracted from section 16.45 of the document New registry values require specification and a designated expert. IANA further understands that there are three initial values to be registered upon approval of the document and that these are in section 22.12.3 of the document. For each item in the RTSP v2.0 Seek-Style Policy registry, IANA understands that four fields will be registered: - the Seek-Style Policy value; - the description of the value; - a contact name; and, - a reference for the source of the registry value. 1.16 A new registry called RTSP v2.0 Transport Protocol Specification. New registry values require speficiation and a designated expert. IANA also understands that there are 12 initial values to be registered upon approval of the document and that these are in section 22.13.1 of the document. For each item in the RTSP v2.0 Transport Protocol Specification, IANA understands that four fields will be registered: - the RTSP v2.0 Transport Protocol Specification value; - the description of the value; - a contact name; and, - a reference for the source of the registry value QUESTION TO AUTHORS: Is there a description for the RTSP v2.0 Transport Protocol Specification available? 1.17 A new registry called RTSP v2.0 Transport Modes. New registry values require IETF Standards Action. IANA also understands that there a single initial value to be registered upon approval of the document and that this is in section 22.13.2 of the document. For each item in the RTSP v2.0 Transport Modes, IANA understands that four fields will be registered: - the RTSP v2.0 Transport Mode value; - the description of the value; - a contact name; and, - a reference for the source of the registry value QUESTION TO AUTHORS: Is there a description for the RTSP v2.0 Transport Modes available? 1.18 A new registry called RTSP v2.0 Transport Parameters. New registry values require Specification and a Designated Expert. IANA also understands that there are no initial values to be registered upon approval of the document. QUESTION TO AUTHORS: Is there a description for the RTSP v2.0 Transport Parameters available? If there were items in this registry, what fields would be registered for each item (name, description, reference, etc.)? Part 2: ======= IANA understands that, upon approval of this document, three new URI schemes would be registered in the Permanent URI scheme registry located at: http://www.iana.org/assignments/uri-schemes.html -- these three URIs are: 2.1 URI Scheme Name: rtsp URI Scheme Description: Real-time Streaming Protocol (RTSP) Reference: TBD 2.2 URI Scheme Name: rtsps URI Scheme Description: RTSP over TLS Reference: TBD 2.3 URI Scheme Name: rtspu URI Scheme Description: RTSP over unreliable datagram transport Part 3: ======= IANA understands that, upon approval of this document, three new SDP attributes would be registered in the Session Description Protocol (SDP) Parameters regristry located at http://www.iana.org/assignments/sdp-parameters. These three entries would be placed in the "- att-field (both session and media level)" registry. The attributes are: 3.1 SDP name: range Reference: TBD 3.2 SDP name: control Reference: TBD 3.3 SDP name: mtag Reference: TBD Part 4: ======= IANA understands that, upon approval of this document, a single entry is to be added to the MIME Media Types registry located at: http://www.iana.org/assignments/media-types/index.html. This entry would be added to the "text" Media Type and would add a new Subtype of "parameters" The reference would be TBD. IANA understands that the creation of eighteen new registries and these three other actions are all the IANA actions required upon approval of this document. On Wed Sep 23 11:53:07 2009, magnus.westerlund@ericsson.com wrote: > Hi, > > Michelle has earlier promised me a review of this documents IANA > section. As it is now in WG last call in MMUSIC I would appreciate if it > could happen by the end of the WG last call the 19th of October. > > The reason we want early review is that the document contains a quite > extensive IANA section that is 17 pages long that creates a large number > of registries. > > Thanks > > Magnus Westerlund > > IETF Transport Area Director > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- From wwwrun@core3.amsl.com Wed Sep 30 09:25:19 2009 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 543B13A6992; Wed, 30 Sep 2009 09:25:19 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20090930162519.543B13A6992@core3.amsl.com> Date: Wed, 30 Sep 2009 09:25:19 -0700 (PDT) Cc: mmusic@ietf.org Subject: [MMUSIC] Last Call: draft-ietf-mmusic-connectivity-precon (Connectivity Preconditions for Session Description Protocol Media Streams) to Proposed Standard X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2009 16:25:19 -0000 The IESG has received a request from the Multiparty Multimedia Session Control WG (mmusic) to consider the following document: - 'Connectivity Preconditions for Session Description Protocol Media Streams ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-10-14. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mmusic-connectivity-precon-06.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=13114&rfc_flag=0 From wwwrun@core3.amsl.com Wed Sep 30 09:26:00 2009 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 2A0813A6963; Wed, 30 Sep 2009 09:25:59 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20090930162600.2A0813A6963@core3.amsl.com> Date: Wed, 30 Sep 2009 09:26:00 -0700 (PDT) Cc: mmusic@ietf.org Subject: [MMUSIC] Last Call: draft-ietf-mmusic-rfc3388bis (The SDP (Session Description Protocol) Grouping Framework) to Proposed Standard X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2009 16:26:00 -0000 The IESG has received a request from the Multiparty Multimedia Session Control WG (mmusic) to consider the following document: - 'The SDP (Session Description Protocol) Grouping Framework ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-10-14. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rfc3388bis-03.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17318&rfc_flag=0