From wwwrun@core3.amsl.com Wed Apr 1 14:22:40 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 61EB13A6A8C; Wed, 1 Apr 2009 14:22:39 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20090401212240.61EB13A6A8C@core3.amsl.com> Date: Wed, 1 Apr 2009 14:22:40 -0700 (PDT) Cc: mmusic chair , Internet Architecture Board , mmusic mailing list , RFC Editor Subject: [MMUSIC] Protocol Action: 'A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer' to Proposed Standard 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, 01 Apr 2009 21:22:40 -0000 The IESG has approved the following document: - 'A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer ' as a Proposed Standard This document is the product of the Multiparty Multimedia Session Control Working Group. The IESG contact persons are Cullen Jennings and Jon Peterson. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-file-transfer-mech-11.txt Technical summary: The document defines extensions to the SDP offer/answer model to enable file transfer as part of SDP-negotiated multimedia sessions. It also specifies using MSRP for the actual file transmission. Working Group summary: The MMUSIC WG has firm consenses on publishing this document as Proposed Standard. Document quality: The document is considered ready for publication. An early interoperability test of independent implementations from various major vendors on an image sharing specification (which uses the file transfer I-D as a basis) took place already in 2007 under the auspices of the GSM Association. The interop event provided useful input for this and other specifications. Personnel: The document shepherd is Joerg Ott, the responsible AD is Cullen Jennings. From root@core3.amsl.com Thu Apr 2 03:45: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 298333A6953; Thu, 2 Apr 2009 03:45:00 -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: <20090402104501.298333A6953@core3.amsl.com> Date: Thu, 2 Apr 2009 03:45:01 -0700 (PDT) Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action:draft-ietf-mmusic-decoding-dependency-07.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: Thu, 02 Apr 2009 10:45: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 : Signaling media decoding dependency in Session Description Protocol (SDP) Author(s) : T. Schierl, S. Wenger Filename : draft-ietf-mmusic-decoding-dependency-07.txt Pages : 18 Date : 2009-04-02 This memo defines semantics that allow for signaling the decoding dependency of different media descriptions with the same media type in the Session Description Protocol (SDP). This is required, for example, if media data is separated and transported in different network streams as a result of the use of a layered or multiple descriptive media coding process. A new grouping type "DDP" -- decoding dependency -- is defined, to be used in conjunction with RFC 3388 entitled "Grouping of Media Lines in the Session Description Protocol". In addition, an attribute is specified describing the relationship of the media streams in a "DDP" group indicated by media identification attribute(s) and media format description(s). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-decoding-dependency-07.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-decoding-dependency-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-04-02033634.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Fri Apr 3 01:30:02 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 0BC7A3A68E3; Fri, 3 Apr 2009 01:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090403083002.0BC7A3A68E3@core3.amsl.com> Date: Fri, 3 Apr 2009 01:30:02 -0700 (PDT) Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action:draft-ietf-mmusic-decoding-dependency-08.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: Fri, 03 Apr 2009 08:30:02 -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 : Signaling media decoding dependency in Session Description Protocol (SDP) Author(s) : T. Schierl, S. Wenger Filename : draft-ietf-mmusic-decoding-dependency-08.txt Pages : 18 Date : 2009-04-03 This memo defines semantics that allow for signaling the decoding dependency of different media descriptions with the same media type in the Session Description Protocol (SDP). This is required, for example, if media data is separated and transported in different network streams as a result of the use of a layered or multiple descriptive media coding process. A new grouping type "DDP" -- decoding dependency -- is defined, to be used in conjunction with RFC 3388 entitled "Grouping of Media Lines in the Session Description Protocol". In addition, an attribute is specified describing the relationship of the media streams in a "DDP" group indicated by media identification attribute(s) and media format description(s). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-decoding-dependency-08.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-decoding-dependency-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-04-03011541.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Thu Apr 16 07: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 537B53A6D2A; Thu, 16 Apr 2009 07:00:00 -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: <20090416140001.537B53A6D2A@core3.amsl.com> Date: Thu, 16 Apr 2009 07:00:01 -0700 (PDT) Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action:draft-ietf-mmusic-image-attributes-02.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: Thu, 16 Apr 2009 14: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 : Negotiation of Generic Image Attributes in SDP Author(s) : I. Johansson, K. Jung Filename : draft-ietf-mmusic-image-attributes-02.txt Pages : 20 Date : 2009-04-16 This document proposes a new generic session setup attribute to make it possible to negotiate different image attributes such as image size. A possible use case is to make it possible for a e.g a low-end hand-held terminal to display video without the need to rescale the image, something that may consume large amounts of memory and processing power. The draft also helps to maintain an optimal bitrate for video as only the image size that is desired by the receiver is transmitted. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-image-attributes-02.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-image-attributes-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-04-16065959.I-D@ietf.org> --NextPart-- From abegen@cisco.com Thu Apr 16 07:11:13 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 CA38E3A693F for ; Thu, 16 Apr 2009 07:11:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.163 X-Spam-Level: X-Spam-Status: No, score=-6.163 tagged_above=-999 required=5 tests=[AWL=-0.164, BAYES_00=-2.599, J_CHICKENPOX_42=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 vV-X6gVsROF3 for ; Thu, 16 Apr 2009 07:11:13 -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 EB1143A684F for ; Thu, 16 Apr 2009 07:11:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,198,1238976000"; d="scan'208";a="172471608" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 16 Apr 2009 14:12:11 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n3GECBhS008531 for ; Thu, 16 Apr 2009 07:12:11 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3GECBNH005801 for ; Thu, 16 Apr 2009 14:12:11 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Apr 2009 07:12:11 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 16 Apr 2009 07:10:25 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D54091BA169@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft 3388bis Thread-Index: Acm+nRaFy1gyPUxJR5W/b0gig5Vs+g== From: "Ali C. Begen (abegen)" To: X-OriginalArrivalTime: 16 Apr 2009 14:12:11.0607 (UTC) FILETIME=[55D70E70:01C9BE9D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=245; t=1239891131; x=1240755131; c=relaxed/simple; s=sjdkim3002; 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:=20Draft=203388bis |Sender:=20; bh=9Rq7WTGrsQ8eXefu6T94DUKXxl8oX1Zi5m9G3npIKNs=; b=g2OIAJazq7gPq54zKoDLTsatO4f9gQwJWlWxe2XLiYBc6mcOd+/UQ2D71g ktfP1mZxA9do/QKiHE0fRrJ5SQ9FUiPa1qIE5hKoScpBLW5akdsJN3jCF/uf 2cCDRw3PYe; Authentication-Results: sj-dkim-3; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [MMUSIC] Draft 3388bis 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, 16 Apr 2009 14:11:13 -0000 Is 3388bis ready for last call? I am planning to submit the updated = 4756bis soon and ask for a WGLC as agreed in the last IETF.=20 Since 4756bis normatively depends on 3388bis, I suppose it needs to be = wglc'ed before. BR, -acbegen From Mike.Severa@alcatel-lucent.com Thu Apr 16 15:52:04 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 BB88B3A6DDF for ; Thu, 16 Apr 2009 15:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 xP5UQuaHw7Wj for ; Thu, 16 Apr 2009 15:51:59 -0700 (PDT) Received: from audl951.usa.alcatel.com (audl951.usa.alcatel.com [143.209.238.161]) by core3.amsl.com (Postfix) with ESMTP id E44D93A6DA8 for ; Thu, 16 Apr 2009 15:51:58 -0700 (PDT) Received: from srsdmail01.PVNS.COM (mail.pvnetsolutions.com [128.251.100.16]) by audl951.usa.alcatel.com (ALCANET) with ESMTP id n3GMrBcn004188 for ; Thu, 16 Apr 2009 17:53:11 -0500 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_01C9BEE6.1DE44941" Date: Thu, 16 Apr 2009 15:52:49 -0700 Message-ID: <758B5A159B385447B4F950DE72D7D7AD01F24709@srsdmail01.PVNS.COM> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 3GPP/IMTC and Pipelining Thread-Index: Acm+5hE3mZFmqGb4Qq+hqwM7yFKEWg== From: "Mike Severa" To: X-Scanned-By: MIMEDefang 2.64 on 143.209.238.34 Subject: [MMUSIC] 3GPP/IMTC and Pipelining 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, 16 Apr 2009 22:52:04 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9BEE6.1DE44941 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi. Earlier this year IMTC held a F2F interop and had two issues arise related to pipelining that 3GPP felt this group should be aware of. These are not issues with the design of the feature but simply limitations on the environments in which it may apply, and as such may already be understood. Note that 3GPP PSS Rel7 has defined the same Pipelined-Requests header as is found in RTSP 2.0 because it still references 1.0. 3GPP was made aware of these issues and suggested raising them with this group. The first issue was an incorrect port mapping by an RTSP-aware NAT that was between the client and the server. The client pipelined two SETUPs and a PLAY request. The NAT remapped the client_port (RTSP 1.0 client) in the SETUPs to the ports exposed by the NAT to the server, which of course meant that the server's SETUP responses contained these remapped values. However, when forwarding these responses to the client, the NAT correctly unmapped the client_port value in the first SETUP response, but left the server's response value in the second SETUP response. This only happened when the requests were pipelined. There appeared to be a broken or no binding on the NAT for the second RTP channel as the media for that track never arrived at the client. No extensive investigation was done.=20 While this is clearly a NAT implementation issue, it is useful to understand that such issues may arise as a result of using the pipelining mechanism. The second issue was the inability to rely on so-called firewall packets in conjunction with pipelining. These packets are used by many 3GPP clients to open holes in a firewall by sending empty RTP packets to the server's ports. The value of these ports, however, is only found in the SETUP responses. If a PLAY has been pipelined with the SETUPs, the server may process the PLAY and begin sending packets before the client receives the SETUP responses (before which it cannot issue firewall packets). The result being that the initial RTP packets may be blocked by the firewall until the client has a chance to issue its firewall packets.=20 On one hand, it should be clear that not all features are always useful in every environment, however NATs are very prevalent, and 3GPP obviously has some stake in the pipelined feature and is concerned about the impact of this. It does not appear there is a solution using the existing design that doesn't sacrifice some of the potential gain, e.g., simply not pipelining the PLAY. However, there may be ways to expand the meaning of "RTSP-awareness" in one of the NAT related RFCs. Alternatively there may be ways to extend the existing design to address this limitation. However, this email was only intended to make the group aware of the issues.=20 Thanks, Mike ------_=_NextPart_001_01C9BEE6.1DE44941 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable 3GPP/IMTC and Pipelining

Hi. Earlier this year IMTC held a F2F = interop and had two issues arise related to pipelining that 3GPP felt = this group should be aware of. These are not issues with the design of = the feature but simply limitations on the environments in which it may = apply, and as such may already be understood. Note that 3GPP PSS Rel7 = has defined the same Pipelined-Requests header as is found in RTSP 2.0 = because it still references 1.0. 3GPP was made aware of these issues and = suggested raising them with this group.

The first issue was an incorrect port = mapping by an RTSP-aware NAT that was between the client and the server. = The client pipelined two SETUPs and a PLAY request. The NAT remapped the = client_port (RTSP 1.0 client) in the SETUPs to the ports exposed by the = NAT to the server, which of course meant that the server's SETUP = responses contained these remapped values. However, when forwarding = these responses to the client, the NAT correctly unmapped the = client_port value in the first SETUP response, but left the server's = response value in the second SETUP response. This only happened when the = requests were pipelined. There appeared to be a broken or no binding on = the NAT for the second RTP channel as the media for that track never = arrived at the client. No extensive investigation was done.

While this is clearly a NAT = implementation issue, it is useful to understand that such issues may = arise as a result of using the pipelining mechanism.

The second issue was the inability to = rely on so-called firewall packets in conjunction with pipelining. These = packets are used by many 3GPP clients to open holes in a firewall by = sending empty RTP packets to the server's ports. The value of these = ports, however, is only found in the SETUP responses. If a PLAY has been = pipelined with the SETUPs, the server may process the PLAY and begin = sending packets before the client receives the SETUP responses (before = which it cannot issue firewall packets). The result being that the = initial RTP packets may be blocked by the firewall until the client has = a chance to issue its firewall packets.

On one hand, it should be clear that = not all features are always useful in every environment, however NATs = are very prevalent, and 3GPP obviously has some stake in the pipelined = feature and is concerned about the impact of this.


It does not appear there is a solution = using the existing design that doesn’t sacrifice some of the = potential gain, e.g., simply not pipelining the PLAY. However, there may = be ways to expand the meaning of "RTSP-awareness" in one of = the NAT related RFCs. Alternatively there may be ways to extend the = existing design to address this limitation. However, this email was only = intended to make the group aware of the issues.

Thanks,

Mike

------_=_NextPart_001_01C9BEE6.1DE44941-- From ingemar.s.johansson@ericsson.com Mon Apr 20 03:55:25 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 5164A28C285 for ; Mon, 20 Apr 2009 03:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.893 X-Spam-Level: X-Spam-Status: No, score=-5.893 tagged_above=-999 required=5 tests=[AWL=0.356, 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 B7Z0TQIP3hKF for ; Mon, 20 Apr 2009 03:55:24 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 34DD128C11E for ; Mon, 20 Apr 2009 03:55:23 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6CE2920FC9; Mon, 20 Apr 2009 12:56:38 +0200 (CEST) X-AuditID: c1b4fb3e-af78cbb000005486-3f-49ec54e6f352 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5C58A203A8; Mon, 20 Apr 2009 12:56:38 +0200 (CEST) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Apr 2009 12:56:38 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Apr 2009 12:56:37 +0200 Message-ID: <130EBB38279E9847BAAAE0B8F9905F8CE1D957@esealmw109.eemea.ericsson.se> In-Reply-To: <20090416135959.4EB143A6D2A@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-ietf-mmusic-image-attributes-02.txt Thread-Index: Acm+m849UACNs8oaTLen3WnjUrXvHADCkWmQ References: <20090416135959.4EB143A6D2A@core3.amsl.com> From: "Ingemar Johansson S" To: X-OriginalArrivalTime: 20 Apr 2009 10:56:38.0230 (UTC) FILETIME=[ADDACF60:01C9C1A6] X-Brightmail-Tracker: AAAAAA== Subject: Re: [MMUSIC] I-D Action:draft-ietf-mmusic-image-attributes-02.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: Mon, 20 Apr 2009 10:55:25 -0000 Hi As you can see below, a new version of draft-ietf-mmusic-image-attributes has been submitted. With this I would say that the open issues that was existing before are resolved and that the document is ready for WGLC. Regards /Ingemar =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 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 : Negotiation of Generic Image Attributes in SDP Author(s) : I. Johansson, K. Jung Filename : draft-ietf-mmusic-image-attributes-02.txt Pages : 20 Date : 2009-04-16 This document proposes a new generic session setup attribute to make it possible to negotiate different image attributes such as image size. A possible use case is to make it possible for a e.g a low-end hand-held terminal to display video without the need to rescale the image, something that may consume large amounts of memory and processing power. The draft also helps to maintain an optimal bitrate for video as only the image size that is desired by the receiver is transmitted. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-image-attributes-0 2.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. From abegen@cisco.com Tue Apr 21 14:51:13 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 6DE5D3A6909; Tue, 21 Apr 2009 14:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.457 X-Spam-Level: X-Spam-Status: No, score=-6.457 tagged_above=-999 required=5 tests=[AWL=0.142, 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 IhRJXDewYtKq; Tue, 21 Apr 2009 14:51:12 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 6B2BA3A6D19; Tue, 21 Apr 2009 14:51:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,226,1238976000"; d="scan'208";a="290373109" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 21 Apr 2009 21:52:20 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n3LLqK66012433; Tue, 21 Apr 2009 14:52:20 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3LLqKZH025683; Tue, 21 Apr 2009 21:52:20 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Apr 2009 14:52:20 -0700 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: Tue, 21 Apr 2009 14:52:17 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D5409250056@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Additive FEC flows Thread-Index: AcnCy3A8L5fVyraVRjiT9EUqpNg1Lg== From: "Ali C. Begen (abegen)" To: X-OriginalArrivalTime: 21 Apr 2009 21:52:20.0072 (UTC) FILETIME=[71D53E80:01C9C2CB] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1157; t=1240350740; x=1241214740; 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:=20Additive=20FEC=20flows |Sender:=20; bh=GDDnLXZwl7zJiN6YGUOkj39fU+/4emNdMcAIIhvRah0=; b=ZQEUjWeLw9VUxuo9i/IyG/AyfZ69FW+mQvHFNTWNghZBSdqLJTkRaexbwB UCyo5o9zx2fF1zAUmaLbwAdDf+4C+0kZFqW1VfkFGVVetT5VM0tdok7wkGNN AuWD5WiYNC; Authentication-Results: sj-dkim-4; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: mmusic@ietf.org Subject: [MMUSIC] Additive FEC flows 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, 21 Apr 2009 21:51:13 -0000 This question is related to draft 4756bis, which is an MMUSIC draft but = the question probably belongs to FECFRAME. Comments are welcome from = both WGs. In the new semantics we are proposing (FEC-XR), which supports = describing additive repair flows in the SDP (Additivity is signaled if = the repair flows are in the same group). There is a "language" question = and I would like to hear your opinions. Suppose that we have a source flow (S1) and two repair flows (R1, R2). = If the repair flows are not additive with each other, we MUST have in = the SDP: a=3Dgroup:FEC-XR S1 R1 a=3Dgroup:FEC-XR S1 R2 However, if the repair flows are additive, MUST or SHOULD we write the = following? a=3Dgroup:FEC-XR S1 R1 R2 Because writing a=3Dgroup:FEC-XR S1 R1 a=3Dgroup:FEC-XR S1 R2 would not be strictly wrong, either. In other words, we must state = explicitly when the repair flows are not additive, but are we also = required to state explicitly when they are additive? My personal view is = that we "must" do so to avoid any confusion and fully benefit from this = new semantics. -acbegen From tme@multicasttech.com Tue Apr 21 16:11:36 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 2EED23A7057; Tue, 21 Apr 2009 16:11:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.956 X-Spam-Level: X-Spam-Status: No, score=-102.956 tagged_above=-999 required=5 tests=[AWL=-0.357, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 rwTIAy8RL1L3; Tue, 21 Apr 2009 16:11:35 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 32A8C3A6B07; Tue, 21 Apr 2009 16:11:35 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id ADDEF3A3A6AF; Tue, 21 Apr 2009 19:12:50 -0400 (EDT) Message-Id: <0DDC662C-C82B-4BDA-9FA4-6295617EBDF6@multicasttech.com> From: Marshall Eubanks To: "Ali C. Begen (abegen)" In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D5409250056@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 v930.3) Date: Tue, 21 Apr 2009 19:12:45 -0400 References: <04CAD96D4C5A3D48B1919248A8FE0D5409250056@xmb-sjc-215.amer.cisco.com> X-Mailer: Apple Mail (2.930.3) Cc: mmusic@ietf.org, fecframe@ietf.org Subject: Re: [MMUSIC] [Fecframe] Additive FEC flows 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, 21 Apr 2009 23:11:36 -0000 I would say that this is a MUST. Of course, most repair flows will be additive. Marshall On Apr 21, 2009, at 5:52 PM, Ali C. Begen (abegen) wrote: > This question is related to draft 4756bis, which is an MMUSIC draft > but the question probably belongs to FECFRAME. Comments are welcome > from both WGs. > > In the new semantics we are proposing (FEC-XR), which supports > describing additive repair flows in the SDP (Additivity is signaled > if the repair flows are in the same group). There is a "language" > question and I would like to hear your opinions. > > Suppose that we have a source flow (S1) and two repair flows (R1, > R2). If the repair flows are not additive with each other, we MUST > have in the SDP: > > a=group:FEC-XR S1 R1 > a=group:FEC-XR S1 R2 > > However, if the repair flows are additive, MUST or SHOULD we write > the following? > > a=group:FEC-XR S1 R1 R2 > > Because writing > > a=group:FEC-XR S1 R1 > a=group:FEC-XR S1 R2 > > would not be strictly wrong, either. In other words, we must state > explicitly when the repair flows are not additive, but are we also > required to state explicitly when they are additive? My personal > view is that we "must" do so to avoid any confusion and fully > benefit from this new semantics. > > -acbegen > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe > Regards Marshall Eubanks CEO / AmericaFree.TV From Albrecht.Schwarz@alcatel-lucent.de Wed Apr 22 01:46: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 9A7B23A6ACE for ; Wed, 22 Apr 2009 01:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=-3.600, BAYES_50=0.001, HELO_EQ_FR=0.35, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f5i+zGws4Dup for ; Wed, 22 Apr 2009 01:46:33 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 7655A3A6B40 for ; Wed, 22 Apr 2009 01:46:19 -0700 (PDT) Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.dc-m.alcatel-lucent.com [155.132.6.77]) by smail2.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n3M8lPkG011472; Wed, 22 Apr 2009 10:47:26 +0200 Received: from FRVELSMBS23.ad2.ad.alcatel.com ([155.132.6.56]) by FRVELSBHS05.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Apr 2009 10:47:25 +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: Wed, 22 Apr 2009 10:47:25 +0200 Message-ID: In-Reply-To: <49077079.2010409@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: some editorials in draft-ietf-mmusic-sdp-media-capabilities-07 Thread-Index: Ack5OIXTGmHjZfxjRFeM0GvdjJMQRiJ7SWeQ References: <49077079.2010409@ericsson.com> From: "Schwarz Albrecht" To: , , X-OriginalArrivalTime: 22 Apr 2009 08:47:25.0624 (UTC) FILETIME=[F5C48380:01C9C326] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.80 Cc: "mmusic \(E-mail\)" Subject: [MMUSIC] some editorials in draft-ietf-mmusic-sdp-media-capabilities-07 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, 22 Apr 2009 08:46:33 -0000 Bob, Roni, hope it's not to late for review comments, found two nits: 1) =A7 3.3.1 For example: v=3D0 a=3Dmcap:1 L16/8000/1 a=3Dmcap:2 L16/16000/2 a=3Dmcap:3,4 H263-1998/90000 m=3Daudio 54320 RTP/AVP 0 > pcfg:1 m=3D1|2, pt=3D1:99,2:98 m=3Dvideo 66544 RTP/AVP 100 a=3Drtpmap:100 H264/90000 a=3Dpcfg:10 m=3D3 pt=3D3:101 should be: For example: v=3D0 a=3Dmcap:1 L16/8000/1 a=3Dmcap:2 L16/16000/2 a=3Dmcap:3,4 H263-1998/90000 m=3Daudio 54320 RTP/AVP 0 a=3Dpcfg:1 m=3D1|2, pt=3D1:99,2:98 m=3Dvideo 66544 RTP/AVP 100 a=3Drtpmap:100 H264/90000 a=3Dpcfg:10 m=3D3 pt=3D3:101 2) =A7 4.1 ... > 10. a=3Dmacp:1,3,5 audio AMR-WB/16000/1 11. a=3Dmcap:2,4,6 audio AMR/8000/1 should be 10. a=3Dmcap:1,3,5 audio AMR-WB/16000/1 11. a=3Dmcap:2,4,6 audio AMR/8000/1 Best regards, Albrecht From Albrecht.Schwarz@alcatel-lucent.de Wed Apr 22 02:07: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 CB38D3A6EA1 for ; Wed, 22 Apr 2009 02:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.449 X-Spam-Level: X-Spam-Status: No, score=-4.449 tagged_above=-999 required=5 tests=[AWL=1.800, BAYES_00=-2.599, HELO_EQ_FR=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 EjFMYaFJplOV for ; Wed, 22 Apr 2009 02:07:06 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 7E2513A6B7A for ; Wed, 22 Apr 2009 02:07:06 -0700 (PDT) Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.dc-m.alcatel-lucent.com [155.132.6.76]) by smail3.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n3M97bGm031328; Wed, 22 Apr 2009 11:07:37 +0200 Received: from FRVELSMBS23.ad2.ad.alcatel.com ([155.132.6.56]) by FRVELSBHS04.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Apr 2009 11:07:36 +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: Wed, 22 Apr 2009 11:07:35 +0200 Message-ID: In-Reply-To: <49EECE91.7050301@angband.za.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip-implementors] media line (m line) is mandatory in SDP? Thread-Index: AcnDIH7iFocV93IATlu1hdxi2In5vgACMVNw References: <719164.17265.qm@web8806.mail.in.yahoo.com><49EDDAAC.7020402@lumisoft.ee> <49EECE91.7050301@angband.za.org> From: "Schwarz Albrecht" To: "Frank Shearar" , "sip fourm" X-OriginalArrivalTime: 22 Apr 2009 09:07:36.0806 (UTC) FILETIME=[C7B03860:01C9C329] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.83 Cc: "mmusic \(E-mail\)" Subject: Re: [MMUSIC] [Sip-implementors] media line (m line) is mandatory in SDP? 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, 22 Apr 2009 09:07:07 -0000 Independent of the syntax discussion ("allows present ABNF grammar an = omitted "m=3D" line"), there's a semantic mentioned in revised SDP Offer/Answer. See =A7 3.2 in = http://tools.ietf.org/html/draft-ietf-mmusic-sdp-media-capabilities-07 ... o A new attribute ("a=3Dlcfg") specifies latent media stream configurations when no corresponding media line ("m=3D") is = offered. An example is the offer of a latent configuration for video even though no video is currently offered. If both parties indicate support for one or more latent configurations, the corresponding media stream(s) may be added via a new offer/answer exchange. There seems to be thus use cases behind initially omitted "m=3D" lines. -Albrecht > -----Original Message----- > From: sip-implementors-bounces@lists.cs.columbia.edu=20 > [mailto:sip-implementors-bounces@lists.cs.columbia.edu] On=20 > Behalf Of Frank Shearar > Sent: Mittwoch, 22. April 2009 10:00 > To: sip fourm > Subject: Re: [Sip-implementors] media line (m line) is=20 > mandatory in SDP? >=20 > Ivar Lumi wrote: > > Hi, > > > > According RFC 4566. > > > > media-descriptions =3D *( media-field information-field=20 > > *connection-field bandwidth-fields key-field attribute-fields ) > > > > And if remember right in RFC text too: There may be zero=20 > media lines. > > With 0 lines just session created and new offer can add=20 > stream to it. > > =20 > Bearing in mind that RFC 4566 obsoletes RFC 2327, RFC 2327=20 > still says this in its ABNF: >=20 > media-descriptions =3D *( media-field > information-field > *(connection-field) > bandwidth-fields > key-field > attribute-fields ) >=20 > (just like RFC 4566's, in other words). >=20 > Friend friend's snippet covers the first field of a media=20 > description, not the media description in its entirety. >=20 > In other words, this is an illegal media-field because it has=20 > no media: >=20 > m=3D 0 RTP/AVP 0 >=20 > frank > > > > friend friend wrote: > > =20 > >> Hi,=20 > >> Thanks for your response. > >> =20 > >> but RFC 2327 Grammar says like > >> =20 > >> media-field =3D "m=3D" media space port ["/" integer] > >> space proto 1*(space fmt) CRLF > >> > >> > >> media =3D 1*(alpha-numeric) > >> ;typically "audio", "video", "application" > >> ;or "data" > >> > >> =20 > >> Which means, one or more m line is mandatory rite. > >> =20 > >> please correct me, if i am wrong. > >> =20 > >> Regards, > >> vijay > >> =20 > >> =20 > >> =20 > >> > >> > >> --- On Tue, 21/4/09, karthik karthik=20 > wrote: > >> > >> > >> From: karthik karthik > >> Subject: Re: [Sip-implementors] media line (m line) is=20 > mandatory in SDP? > >> To: sip_quest@yahoo.co.in > >> Cc: "sip fourm" > >> Date: Tuesday, 21 April, 2009, 7:36 PM > >> > >> > >> Hi, > >> Hope this thread has more info about this topic=20 > >>=20 > https://lists.cs.columbia.edu/pipermail/sip-implementors/2008-October > >> /020798.html > >> > >> Karthik > >> > >> > >> On Tue, Apr 21, 2009 at 7:31 PM, Frank Shearar=20 > wrote: > >> > >> > >> friend friend wrote: > >> =20 > >> =20 > >>> Dear Friends, > >>> In SDP, media (m line) is mandatory? if so, if=20 > the UAC doesnt support video, audio, can the UAC send SDP=20 > like m: 0(zero)? > >>> > >>> Please clarify. > >>> > >>> =20 > >>> =20 > >> The m header is not mandatory. RFC 4566 section 5 says > >> > >> An SDP session description consists of a session-level section > >> followed by zero or more media-level sections. > >> > >> If the UAC supports no kinds of media it'll send no media-level=20 > >> sections. Not very _useful_, since the UAS must respond=20 > with the same=20 > >> number of media-level sections! > >> > >> frank > >> =20 > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors >=20 From bob_gilman@comcast.net Wed Apr 22 12:07:50 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 2B5E23A6BC7 for ; Wed, 22 Apr 2009 12:07:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.092 X-Spam-Level: X-Spam-Status: No, score=-1.092 tagged_above=-999 required=5 tests=[AWL=-0.907, 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 LeOd2asYTuVz for ; Wed, 22 Apr 2009 12:07:49 -0700 (PDT) Received: from QMTA10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by core3.amsl.com (Postfix) with ESMTP id 5F5AA3A6B57 for ; Wed, 22 Apr 2009 12:07:49 -0700 (PDT) Received: from OMTA05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by QMTA10.emeryville.ca.mail.comcast.net with comcast id ibjS1b0020vp7WLAAj97P5; Wed, 22 Apr 2009 19:09:07 +0000 Received: from [192.168.1.101] ([67.176.84.91]) by OMTA05.emeryville.ca.mail.comcast.net with comcast id ij961b0031yDsSj8Rj964h; Wed, 22 Apr 2009 19:09:07 +0000 Message-ID: <49EF6B50.6040401@comcast.net> Date: Wed, 22 Apr 2009 13:09:04 -0600 From: Bob Gilman User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Schwarz Albrecht References: <49077079.2010409@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: fandreas@cisco.com, "mmusic \(E-mail\)" Subject: Re: [MMUSIC] some editorials in draft-ietf-mmusic-sdp-media-capabilities-07 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, 22 Apr 2009 19:07:50 -0000 Albrecht- Thanks for the corrections. I admit I read right past my errors. -Bob ------------------------------------------------------------- Bob Gilman bob_gilman@comcast.net +1 303 898 9780 From abegen@cisco.com Fri Apr 24 11:12: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 40CCF3A68A6; Fri, 24 Apr 2009 11:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.482 X-Spam-Level: X-Spam-Status: No, score=-6.482 tagged_above=-999 required=5 tests=[AWL=0.117, 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 nnq76bbcyVph; Fri, 24 Apr 2009 11:12:38 -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 424F828C290; Fri, 24 Apr 2009 11:11:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,243,1238976000"; d="scan'208";a="176513428" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 24 Apr 2009 18:13:13 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3OIDDTg015973; Fri, 24 Apr 2009 11:13:13 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n3OIDDTP008176; Fri, 24 Apr 2009 18:13:13 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Apr 2009 11:13:13 -0700 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, 24 Apr 2009 11:13:08 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D54092C817F@xmb-sjc-215.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RTP stream multiplexing in the fec framework Thread-Index: AcnFBZvmuqXE5ODwSgqb8A8kdmxCRwAASOYcAAAKG9A= References: <04CAD96D4C5A3D48B1919248A8FE0D54092C815D@xmb-sjc-215.amer.cisco.com> From: "Ali C. Begen (abegen)" To: "Watson, Mark" , X-OriginalArrivalTime: 24 Apr 2009 18:13:13.0050 (UTC) FILETIME=[54D623A0:01C9C508] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4277; t=1240596793; x=1241460793; c=relaxed/simple; s=sjdkim2002; 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:=20RE=3A=20RTP=20stream=20multiplexing=20in=20the= 20fec=20framework |Sender:=20; bh=n1qvAUkvNllGXqId83LII4hvaWZZm7DWmpoGMdZ5PsM=; b=J3ZYzHgjdhY8y1Kxx3RxMnztxqbPCi3bNJ0T+3p/r8q1feogw9GP2qEdHO anAHhABwluxaMYtcgWbs4Whu9ttIbWquLJU/zdlQn08iLbrrYMn6rOdoYEPP Mr8qFIHLwf; Authentication-Results: sj-dkim-2; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: mmusic@ietf.org Subject: Re: [MMUSIC] RTP stream multiplexing in the fec framework 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, 24 Apr 2009 18:12:39 -0000 Copying MMUSIC as this is relevant to: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-source-attribut= es-02.txt http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rfc4756bis-01.txt=20 > -----Original Message----- > From: Watson, Mark [mailto:watson@qualcomm.com]=20 > Sent: Friday, April 24, 2009 11:02 AM > To: Ali C. Begen (abegen); fecframe@ietf.org > Subject: Re: RTP stream multiplexing in the fec framework >=20 > Ali, >=20 > What do you think the Framework should do ? IMO, we should not restrict FEC to work only for session multiplexing = (although I agree with you that doing so has many advantages). I see a few key reasons why people would use SSRC multiplexing, one = being to simplify the port operations on NAT traversal. One session = means one hole on NAT for the RTP transport (rtcp port can be the same = or different). So, some apps may use ssrc multiplexing. I am about to finalize the 4756bis draft and so far my assumption has = been that we would only do session multiplexing and use "a=3Dgroup" for = associations. This would not work for SSRC multiplexed streams, though. = For that, we can use the "a=3Dssrc-group" attribute from Jonathan's = draft. > SSRC multiplexing of source and repair is possible and the=20 > intention was to support this in the Framework, but if it is=20 > not required we could simplify by supporting only port=20 > multiplexing. Port multiplexing is more straightforwardly=20 > backwards-compatible (I'm not sure what an RTP receiver does=20 > if it is expecting just one SSRC and it sees two). If it has a payload that it does not understand, it will discard it. If = it understands and knows what the stream is for, it would just use it as = if the stream was received from a different port. Are there any comments/suggestions from MMUSIC? -acbegen =20 > ...Mark >=20 >=20 > On 4/24/09 10:53 AM, "Ali C. Begen (abegen)" wrote: >=20 >=20 >=20 > Mark, All, > =09 > I have a question about multiplexing the source and=20 > repair streams when they are both RTP. Currently, we have the=20 > following text: > =09 > (Start of section 4) > =09 > The FEC Framework is described in terms of an=20 > additional layer > between the transport layer (e.g. UDP or DCCP) and=20 > protocols running > over this transport layer. Examples of such=20 > protocols are RTP, RTCP, > etc. As such, the data path interface between the=20 > FEC Framework and > both underlying and overlying layers can be thought=20 > of as being the > same as the standard interface to the transport=20 > layer - i.e. the data > exchanged consists of datagram payloads each=20 > associated with a single > transport flow identified (in the case of UDP) by=20 > the standard > 5-tuple { Source IP Address, Source Transport Port,=20 > Destination IP > Address, Destination Transport Port, Transport=20 > Protocol }. In the > case that RTP is used for the repair flows, the=20 > source and repair > data may be multiplexed using RTP onto a single UDP=20 > flow and must > consequently be demultiplexed at the receiver. =20 > There are various > ways in which this multiplexing can be done, for=20 > example as described > in [RFC4588]. > =09 > =09 > RFC 4588 mentions two ways of multiplexing RTP streams.=20 > One is session multiplexing, where source and repair RTP=20 > streams are in different RTP sessions (different dest=20 > address/port). In this case, I don't have any issues, this=20 > works beautifully with the framework. > =09 > The other one is SSRC multiplexing where the source and=20 > repair RTP streams have different SSRCs but are transmitted=20 > in the same RTP session (which is a single UDP flow). Is the=20 > text above saying that the framework also support this kind=20 > of multiplexing? In other words, is using a single UDP flow=20 > to carry source + FEC data acceptable when they have separate SSRCs? > =09 > Not that FEC could not be used in this scenario, but as=20 > I recall the framework required different UDP flows for=20 > source and repair flows... > =09 > BR, > -acbegen > =09 > =09 >=20 >=20 From csp@csperkins.org Mon Apr 27 11:54: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 3158928C1A6; Mon, 27 Apr 2009 11:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.557 X-Spam-Level: X-Spam-Status: No, score=-3.557 tagged_above=-999 required=5 tests=[AWL=0.042, 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 HmAtvghcH9yt; Mon, 27 Apr 2009 11:54:53 -0700 (PDT) Received: from lon1-msapost-2.mail.demon.net (lon1-msapost-2.mail.demon.net [195.173.77.181]) by core3.amsl.com (Postfix) with ESMTP id C2FE228C1A1; Mon, 27 Apr 2009 11:54:52 -0700 (PDT) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=mangole.lan) by lon1-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1LyVzw-0000xf-bO; Mon, 27 Apr 2009 18:56:13 +0000 Message-Id: <8F9DD728-5AE9-4394-9BDD-4EDBFB92E4A5@csperkins.org> From: Colin Perkins To: Ali C. Begen (abegen) In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D54092C817F@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 v930.3) Date: Mon, 27 Apr 2009 18:53:58 +0100 References: <04CAD96D4C5A3D48B1919248A8FE0D54092C815D@xmb-sjc-215.amer.cisco.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C817F@xmb-sjc-215.amer.cisco.com> X-Mailer: Apple Mail (2.930.3) Cc: "Watson, Mark" , mmusic@ietf.org, fecframe@ietf.org Subject: Re: [MMUSIC] [Fecframe] RTP stream multiplexing in the fec framework 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, 27 Apr 2009 18:54:54 -0000 On 24 Apr 2009, at 19:13, Ali C. Begen (abegen) wrote: > Copying MMUSIC as this is relevant to: > > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-source-attributes-02.txt > http://www.ietf.org/internet-drafts/draft-ietf-mmusic- > rfc4756bis-01.txt > >> -----Original Message----- >> From: Watson, Mark [mailto:watson@qualcomm.com] >> Sent: Friday, April 24, 2009 11:02 AM >> To: Ali C. Begen (abegen); fecframe@ietf.org >> Subject: Re: RTP stream multiplexing in the fec framework >> >> Ali, >> >> What do you think the Framework should do ? > > IMO, we should not restrict FEC to work only for session > multiplexing (although I agree with you that doing so has many > advantages). > > I see a few key reasons why people would use SSRC multiplexing, one > being to simplify the port operations on NAT traversal. One session > means one hole on NAT for the RTP transport (rtcp port can be the > same or different). So, some apps may use ssrc multiplexing. The trend is clearly towards allowing multiplexing by RTP SSRC, to ease NAT traversal by reducing the number of UDP ports. By that argument, sending FEC data on the same port as the media it's protecting doesn't seem problematic. (I wouldn't want to see different media types on one port, but this is close enough related that I don't see a big issue). > I am about to finalize the 4756bis draft and so far my assumption > has been that we would only do session multiplexing and use > "a=group" for associations. This would not work for SSRC multiplexed > streams, though. For that, we can use the "a=ssrc-group" attribute > from Jonathan's draft. > >> SSRC multiplexing of source and repair is possible and the >> intention was to support this in the Framework, but if it is >> not required we could simplify by supporting only port >> multiplexing. Port multiplexing is more straightforwardly >> backwards-compatible (I'm not sure what an RTP receiver does >> if it is expecting just one SSRC and it sees two). > > If it has a payload that it does not understand, it will discard it. > If it understands and knows what the stream is for, it would just > use it as if the stream was received from a different port. > > Are there any comments/suggestions from MMUSIC? > > -acbegen > >> ...Mark >> >> >> On 4/24/09 10:53 AM, "Ali C. Begen (abegen)" >> wrote: >> >> >> >> Mark, All, >> >> I have a question about multiplexing the source and >> repair streams when they are both RTP. Currently, we have the >> following text: >> >> (Start of section 4) >> >> The FEC Framework is described in terms of an >> additional layer >> between the transport layer (e.g. UDP or DCCP) and >> protocols running >> over this transport layer. Examples of such >> protocols are RTP, RTCP, >> etc. As such, the data path interface between the >> FEC Framework and >> both underlying and overlying layers can be thought >> of as being the >> same as the standard interface to the transport >> layer - i.e. the data >> exchanged consists of datagram payloads each >> associated with a single >> transport flow identified (in the case of UDP) by >> the standard >> 5-tuple { Source IP Address, Source Transport Port, >> Destination IP >> Address, Destination Transport Port, Transport >> Protocol }. In the >> case that RTP is used for the repair flows, the >> source and repair >> data may be multiplexed using RTP onto a single UDP >> flow and must >> consequently be demultiplexed at the receiver. >> There are various >> ways in which this multiplexing can be done, for >> example as described >> in [RFC4588]. >> >> >> RFC 4588 mentions two ways of multiplexing RTP streams. >> One is session multiplexing, where source and repair RTP >> streams are in different RTP sessions (different dest >> address/port). In this case, I don't have any issues, this >> works beautifully with the framework. >> >> The other one is SSRC multiplexing where the source and >> repair RTP streams have different SSRCs but are transmitted >> in the same RTP session (which is a single UDP flow). Is the >> text above saying that the framework also support this kind >> of multiplexing? In other words, is using a single UDP flow >> to carry source + FEC data acceptable when they have separate SSRCs? >> >> Not that FEC could not be used in this scenario, but as >> I recall the framework required different UDP flows for >> source and repair flows... >> >> BR, >> -acbegen >> >> >> >> > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe -- Colin Perkins http://csperkins.org/ From abegen@cisco.com Mon Apr 27 12:03: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 51EA93A6FD4; Mon, 27 Apr 2009 12:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.329 X-Spam-Level: X-Spam-Status: No, score=-6.329 tagged_above=-999 required=5 tests=[AWL=0.270, 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 XPWim09W7AOG; Mon, 27 Apr 2009 12:03:10 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id CA88D3A6FD6; Mon, 27 Apr 2009 12:00:41 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,256,1238976000"; d="scan'208";a="293820178" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 27 Apr 2009 19:01:19 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n3RJ1JSG002934; Mon, 27 Apr 2009 12:01:19 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3RJ1Jur001156; Mon, 27 Apr 2009 19:01:19 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Apr 2009 12:01:19 -0700 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: Mon, 27 Apr 2009 12:00:49 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D54092C86BE@xmb-sjc-215.amer.cisco.com> In-Reply-To: <8F9DD728-5AE9-4394-9BDD-4EDBFB92E4A5@csperkins.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] RTP stream multiplexing in the fec framework Thread-Index: AcnHadz22guj5TBhSs6bHzEE811o3wAAIUqw References: <04CAD96D4C5A3D48B1919248A8FE0D54092C815D@xmb-sjc-215.amer.cisco.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C817F@xmb-sjc-215.amer.cisco.com> <8F9DD728-5AE9-4394-9BDD-4EDBFB92E4A5@csperkins.org> From: "Ali C. Begen (abegen)" To: "Colin Perkins" X-OriginalArrivalTime: 27 Apr 2009 19:01:19.0349 (UTC) FILETIME=[8C71AA50:01C9C76A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5658; t=1240858879; x=1241722879; c=relaxed/simple; s=sjdkim3002; 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:=20RE=3A=20[Fecframe]=20RTP=20stream=20multiplexin g=20in=20the=20fec=20framework |Sender:=20; bh=4vHm0tNhP1kp7Uqu9/Ag5YzalRvLM6yQ7qDhtkYzRvM=; b=SAukOms7ONEpOOxEXu1Gwm2mfQ70r9f8KdA18X+1yBkrUXbm1BiQKpPM/y RZhI6rkmJZaqv8YuHX10ucxol1UWftwI8jZRMUNwnYz2CLvZaiDY0xnwXGMO b4Vub47piW; Authentication-Results: sj-dkim-3; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: "Watson, Mark" , mmusic@ietf.org, fecframe@ietf.org Subject: Re: [MMUSIC] [Fecframe] RTP stream multiplexing in the fec framework 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, 27 Apr 2009 19:03:12 -0000 Is that a "yes" for ssrc-level grouping for FEC? -acbegen=20 > -----Original Message----- > From: Colin Perkins [mailto:csp@csperkins.org]=20 > Sent: Monday, April 27, 2009 10:54 AM > To: Ali C. Begen (abegen) > Cc: Watson, Mark; fecframe@ietf.org; mmusic@ietf.org > Subject: Re: [Fecframe] RTP stream multiplexing in the fec framework >=20 > On 24 Apr 2009, at 19:13, Ali C. Begen (abegen) wrote: > > Copying MMUSIC as this is relevant to: > > > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-sour ce-attributes-02.txt > > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-=20 > > rfc4756bis-01.txt > > > >> -----Original Message----- > >> From: Watson, Mark [mailto:watson@qualcomm.com] > >> Sent: Friday, April 24, 2009 11:02 AM > >> To: Ali C. Begen (abegen); fecframe@ietf.org > >> Subject: Re: RTP stream multiplexing in the fec framework > >> > >> Ali, > >> > >> What do you think the Framework should do ? > > > > IMO, we should not restrict FEC to work only for session =20 > > multiplexing (although I agree with you that doing so has many =20 > > advantages). > > > > I see a few key reasons why people would use SSRC=20 > multiplexing, one =20 > > being to simplify the port operations on NAT traversal. One=20 > session =20 > > means one hole on NAT for the RTP transport (rtcp port can be the =20 > > same or different). So, some apps may use ssrc multiplexing. >=20 > The trend is clearly towards allowing multiplexing by RTP SSRC, to =20 > ease NAT traversal by reducing the number of UDP ports. By that =20 > argument, sending FEC data on the same port as the media it's =20 > protecting doesn't seem problematic. (I wouldn't want to see=20 > different =20 > media types on one port, but this is close enough related=20 > that I don't =20 > see a big issue). >=20 > > I am about to finalize the 4756bis draft and so far my assumption =20 > > has been that we would only do session multiplexing and use =20 > > "a=3Dgroup" for associations. This would not work for SSRC=20 > multiplexed =20 > > streams, though. For that, we can use the "a=3Dssrc-group" attribute = =20 > > from Jonathan's draft. > > > >> SSRC multiplexing of source and repair is possible and the > >> intention was to support this in the Framework, but if it is > >> not required we could simplify by supporting only port > >> multiplexing. Port multiplexing is more straightforwardly > >> backwards-compatible (I'm not sure what an RTP receiver does > >> if it is expecting just one SSRC and it sees two). > > > > If it has a payload that it does not understand, it will=20 > discard it. =20 > > If it understands and knows what the stream is for, it would just =20 > > use it as if the stream was received from a different port. > > > > Are there any comments/suggestions from MMUSIC? > > > > -acbegen > > > >> ...Mark > >> > >> > >> On 4/24/09 10:53 AM, "Ali C. Begen (abegen)" =20 > >> wrote: > >> > >> > >> > >> Mark, All, > >> =09 > >> I have a question about multiplexing the source and > >> repair streams when they are both RTP. Currently, we have the > >> following text: > >> =09 > >> (Start of section 4) > >> =09 > >> The FEC Framework is described in terms of an > >> additional layer > >> between the transport layer (e.g. UDP or DCCP) and > >> protocols running > >> over this transport layer. Examples of such > >> protocols are RTP, RTCP, > >> etc. As such, the data path interface between the > >> FEC Framework and > >> both underlying and overlying layers can be thought > >> of as being the > >> same as the standard interface to the transport > >> layer - i.e. the data > >> exchanged consists of datagram payloads each > >> associated with a single > >> transport flow identified (in the case of UDP) by > >> the standard > >> 5-tuple { Source IP Address, Source Transport Port, > >> Destination IP > >> Address, Destination Transport Port, Transport > >> Protocol }. In the > >> case that RTP is used for the repair flows, the > >> source and repair > >> data may be multiplexed using RTP onto a single UDP > >> flow and must > >> consequently be demultiplexed at the receiver. > >> There are various > >> ways in which this multiplexing can be done, for > >> example as described > >> in [RFC4588]. > >> =09 > >> =09 > >> RFC 4588 mentions two ways of multiplexing RTP streams. > >> One is session multiplexing, where source and repair RTP > >> streams are in different RTP sessions (different dest > >> address/port). In this case, I don't have any issues, this > >> works beautifully with the framework. > >> =09 > >> The other one is SSRC multiplexing where the source and > >> repair RTP streams have different SSRCs but are transmitted > >> in the same RTP session (which is a single UDP flow). Is the > >> text above saying that the framework also support this kind > >> of multiplexing? In other words, is using a single UDP flow > >> to carry source + FEC data acceptable when they have=20 > separate SSRCs? > >> =09 > >> Not that FEC could not be used in this scenario, but as > >> I recall the framework required different UDP flows for > >> source and repair flows... > >> =09 > >> BR, > >> -acbegen > >> =09 > >> =09 > >> > >> > > _______________________________________________ > > Fecframe mailing list > > Fecframe@ietf.org > > https://www.ietf.org/mailman/listinfo/fecframe >=20 >=20 >=20 > --=20 > Colin Perkins > http://csperkins.org/ >=20 >=20 >=20 >=20 From rem@videolan.org Mon Apr 27 12:13:35 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 98AFE3A7007; Mon, 27 Apr 2009 12:13:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.125 X-Spam-Level: X-Spam-Status: No, score=-1.125 tagged_above=-999 required=5 tests=[AWL=1.174, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 qVE4vz4gDQ6o; Mon, 27 Apr 2009 12:13:34 -0700 (PDT) Received: from yop.chewa.net (yop.chewa.net [91.121.105.214]) by core3.amsl.com (Postfix) with ESMTP id 5E8BE3A6ACB; Mon, 27 Apr 2009 12:13:34 -0700 (PDT) Received: from basile.remlab.net (unknown [IPv6:2002:591b:3e37:0:211:11ff:fe25:e6b4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: remi) by yop.chewa.net (Postfix) with ESMTPSA id 11949382; Mon, 27 Apr 2009 21:14:53 +0200 (CEST) From: "=?iso-8859-1?q?R=E9mi?= Denis-Courmont" Organization: VideoLAN project - www.videolan.org To: mmusic@ietf.org Date: Mon, 27 Apr 2009 22:14:46 +0300 User-Agent: KMail/1.11.2 (Linux/2.6.29-1-686; KDE/4.2.2; i686; ; ) References: <04CAD96D4C5A3D48B1919248A8FE0D54092C815D@xmb-sjc-215.amer.cisco.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C817F@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D54092C817F@xmb-sjc-215.amer.cisco.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200904272214.47982.rem@videolan.org> Cc: "Watson, Mark" , fecframe@ietf.org Subject: Re: [MMUSIC] RTP stream multiplexing in the fec framework X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: remi@remlab.net List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 19:13:35 -0000 Le vendredi 24 avril 2009 21:13:08 Ali C. Begen (abegen), vous avez =E9crit= : > > What do you think the Framework should do ? > > IMO, we should not restrict FEC to work only for session multiplexing > (although I agree with you that doing so has many advantages). > > I see a few key reasons why people would use SSRC multiplexing, one being > to simplify the port operations on NAT traversal. One session means one > hole on NAT for the RTP transport (rtcp port can be the same or different= ). > So, some apps may use ssrc multiplexing. I actually do not see the point of SSRC multiplexing at all. If you want to= =20 include FEC infos on the same transport tuple as the protected media data, = why=20 don't you use a separate payload type? Using a separate SSRC on the same transport tuple will break compatiblity w= ith=20 receivers that only accept one session per socket at a time. Worse, it coul= d=20 break those pseudo-randomly, which would be hell from customer support=20 perspective. > I am about to finalize the 4756bis draft and so far my assumption has been > that we would only do session multiplexing and use "a=3Dgroup" for > associations. This would not work for SSRC multiplexed streams, though. F= or > that, we can use the "a=3Dssrc-group" attribute from Jonathan's draft. > > > SSRC multiplexing of source and repair is possible and the > > intention was to support this in the Framework, but if it is > > not required we could simplify by supporting only port > > multiplexing. Port multiplexing is more straightforwardly > > backwards-compatible (I'm not sure what an RTP receiver does > > if it is expecting just one SSRC and it sees two). > > If it has a payload that it does not understand, it will discard it. If it > understands and knows what the stream is for, it would just use it as if > the stream was received from a different port. That looks like the sanest (most backward compatible and NAT-friendly) opti= on=20 to me. =2D-=20 R=E9mi Denis-Courmont http://git.remlab.net/cgi-bin/gitweb.cgi?p=3Dvlc-courmisch.git;a=3Dsummary From abegen@cisco.com Mon Apr 27 12:32: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 1B4A03A692F; Mon, 27 Apr 2009 12:32:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.334 X-Spam-Level: X-Spam-Status: No, score=-6.334 tagged_above=-999 required=5 tests=[AWL=0.265, 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 VGiq+axfuIUB; Mon, 27 Apr 2009 12:32:32 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 4E2A728C1EE; Mon, 27 Apr 2009 12:32:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,256,1238976000"; d="scan'208";a="293842813" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 27 Apr 2009 19:33:41 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3RJXf1j027819; Mon, 27 Apr 2009 12:33:41 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n3RJXfCj027875; Mon, 27 Apr 2009 19:33:41 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Apr 2009 12:33: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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 27 Apr 2009 12:33:35 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D54092C86F2@xmb-sjc-215.amer.cisco.com> In-Reply-To: <200904272214.47982.rem@videolan.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] RTP stream multiplexing in the fec framework Thread-Index: AcnHbHdaPqprgUXsS7ynhruR8YqB5gAAeYFw References: <04CAD96D4C5A3D48B1919248A8FE0D54092C815D@xmb-sjc-215.amer.cisco.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C817F@xmb-sjc-215.amer.cisco.com> <200904272214.47982.rem@videolan.org> From: "Ali C. Begen (abegen)" To: , X-OriginalArrivalTime: 27 Apr 2009 19:33:41.0265 (UTC) FILETIME=[11EA8810:01C9C76F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2863; t=1240860821; x=1241724821; c=relaxed/simple; s=sjdkim2002; 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:=20RE=3A=20[MMUSIC]=20RTP=20stream=20multiplexing= 20in=20the=20fec=20framework |Sender:=20; bh=kGm6Razji0hFd0mIcGykwdRVIld9HGM7eb8rpvqS0y4=; b=HtEaMGfyOUIxTSznRm7Qt/QbYeZ5jmFIjaOWnXuaca10k8fRiI/oH/wWPn QkKqXpk6AEzQnG9g2opUmIIuYNXH8LDnS7UGg8y+kh8NeSqwopmOCfyJWK1c vcIqqC7/ln; Authentication-Results: sj-dkim-2; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: "Watson, Mark" , fecframe@ietf.org Subject: Re: [MMUSIC] RTP stream multiplexing in the fec framework 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, 27 Apr 2009 19:32:33 -0000 =20 > -----Original Message----- > From: R=E9mi Denis-Courmont [mailto:rem@videolan.org]=20 > Sent: Monday, April 27, 2009 12:15 PM > To: mmusic@ietf.org > Cc: Ali C. Begen (abegen); Watson, Mark; fecframe@ietf.org > Subject: Re: [MMUSIC] RTP stream multiplexing in the fec framework >=20 > Le vendredi 24 avril 2009 21:13:08 Ali C. Begen (abegen),=20 > vous avez =E9crit : > > > What do you think the Framework should do ? > > > > IMO, we should not restrict FEC to work only for session=20 > multiplexing > > (although I agree with you that doing so has many advantages). > > > > I see a few key reasons why people would use SSRC=20 > multiplexing, one being > > to simplify the port operations on NAT traversal. One=20 > session means one > > hole on NAT for the RTP transport (rtcp port can be the=20 > same or different). > > So, some apps may use ssrc multiplexing. >=20 > I actually do not see the point of SSRC multiplexing at all.=20 > If you want to=20 > include FEC infos on the same transport tuple as the=20 > protected media data, why=20 > don't you use a separate payload type? You mean payload-type multiplexing? Then, they will share the same SSRC = and seqnum space. The RTCP feedback including receiver reports or NACKS = will be shared, too. I guess section 5.2 of RFC 3550 provides good reasons for not doing = this. -acbegen =20 > Using a separate SSRC on the same transport tuple will break=20 > compatiblity with=20 > receivers that only accept one session per socket at a time.=20 > Worse, it could=20 > break those pseudo-randomly, which would be hell from=20 > customer support=20 > perspective. >=20 > > I am about to finalize the 4756bis draft and so far my=20 > assumption has been > > that we would only do session multiplexing and use "a=3Dgroup" for > > associations. This would not work for SSRC multiplexed=20 > streams, though. For > > that, we can use the "a=3Dssrc-group" attribute from Jonathan's = draft. > > > > > SSRC multiplexing of source and repair is possible and the > > > intention was to support this in the Framework, but if it is > > > not required we could simplify by supporting only port > > > multiplexing. Port multiplexing is more straightforwardly > > > backwards-compatible (I'm not sure what an RTP receiver does > > > if it is expecting just one SSRC and it sees two). > > > > If it has a payload that it does not understand, it will=20 > discard it. If it > > understands and knows what the stream is for, it would just=20 > use it as if > > the stream was received from a different port. >=20 > That looks like the sanest (most backward compatible and=20 > NAT-friendly) option=20 > to me. >=20 > --=20 > R=E9mi Denis-Courmont > = http://git.remlab.net/cgi-bin/gitweb.cgi?p=3Dvlc-courmisch.git;a=3Dsummar= y >=20 From csp@csperkins.org Mon Apr 27 13:52:25 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 8EAB528C1C5; Mon, 27 Apr 2009 13:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.563 X-Spam-Level: X-Spam-Status: No, score=-3.563 tagged_above=-999 required=5 tests=[AWL=0.036, 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 NPGEd4TTdDOy; Mon, 27 Apr 2009 13:52:24 -0700 (PDT) Received: from anchor-msapost-2.mail.demon.net (anchor-msapost-2.mail.demon.net [195.173.77.165]) by core3.amsl.com (Postfix) with ESMTP id 23EA428C1C7; Mon, 27 Apr 2009 13:51:23 -0700 (PDT) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=mangole.lan) by anchor-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1LyXoh-0005ti-kd; Mon, 27 Apr 2009 20:52:43 +0000 Message-Id: From: Colin Perkins To: Marshall Eubanks In-Reply-To: <2FA6A311-8B9F-41FF-B9A3-04EB1E399732@americafree.tv> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 27 Apr 2009 21:52:35 +0100 References: <04CAD96D4C5A3D48B1919248A8FE0D54092C815D@xmb-sjc-215.amer.cisco.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C817F@xmb-sjc-215.amer.cisco.com> <8F9DD728-5AE9-4394-9BDD-4EDBFB92E4A5@csperkins.org> <2FA6A311-8B9F-41FF-B9A3-04EB1E399732@americafree.tv> X-Mailer: Apple Mail (2.930.3) Cc: mmusic@ietf.org, fecframe@ietf.org Subject: Re: [MMUSIC] [Fecframe] RTP stream multiplexing in the fec framework 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, 27 Apr 2009 20:52:25 -0000 On 27 Apr 2009, at 20:02, Marshall Eubanks wrote: > On Apr 27, 2009, at 1:53 PM, Colin Perkins wrote: >> On 24 Apr 2009, at 19:13, Ali C. Begen (abegen) wrote: ... > >>> IMO, we should not restrict FEC to work only for session >>> multiplexing (although I agree with you that doing so has many >>> advantages). >>> >>> I see a few key reasons why people would use SSRC multiplexing, >>> one being to simplify the port operations on NAT traversal. One >>> session means one hole on NAT for the RTP transport (rtcp port can >>> be the same or different). So, some apps may use ssrc multiplexing. >> >> The trend is clearly towards allowing multiplexing by RTP SSRC, to >> ease NAT traversal by reducing the number of UDP ports. By that >> argument, sending FEC data on the same port as the media it's >> protecting doesn't seem problematic. (I wouldn't want to see >> different media types on one port, but this is close enough related >> that I don't see a big issue). > > If someone wanted to use SSRC multiplexing in a audio or video > conference with multiplexing (audio) or multiple displays (video), > and then wanted to apply SSRC multiplexed FEC to that (say for > sources on lossy wireless links), isn't there a danger that non-FEC > aware receivers would not do the right thing with the FEC ? I don't think so. Non-FEC aware receivers would see an unknown payload type, which they should ignore. What's your specific concern with that scenario? -- Colin Perkins http://csperkins.org/ From csp@csperkins.org Mon Apr 27 14:01: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 CB54A3A680D; Mon, 27 Apr 2009 14:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.568 X-Spam-Level: X-Spam-Status: No, score=-3.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 uqipFyW8g+TV; Mon, 27 Apr 2009 14:01:08 -0700 (PDT) Received: from lon1-msapost-2.mail.demon.net (lon1-msapost-2.mail.demon.net [195.173.77.181]) by core3.amsl.com (Postfix) with ESMTP id 26A543A6A02; Mon, 27 Apr 2009 14:00:43 -0700 (PDT) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=mangole.lan) by lon1-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1LyXxj-0004c0-ap; Mon, 27 Apr 2009 21:02:03 +0000 Message-Id: <7D1B0D8B-BCFE-463B-B2F4-E627729A198D@csperkins.org> From: Colin Perkins To: Ali C. Begen (abegen) In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D54092C86BE@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 v930.3) Date: Mon, 27 Apr 2009 22:01:47 +0100 References: <04CAD96D4C5A3D48B1919248A8FE0D54092C815D@xmb-sjc-215.amer.cisco.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C817F@xmb-sjc-215.amer.cisco.com> <8F9DD728-5AE9-4394-9BDD-4EDBFB92E4A5@csperkins.org> <04CAD96D4C5A3D48B1919248A8FE0D54092C86BE@xmb-sjc-215.amer.cisco.com> X-Mailer: Apple Mail (2.930.3) Cc: "Watson, Mark" , mmusic@ietf.org, fecframe@ietf.org Subject: Re: [MMUSIC] [Fecframe] RTP stream multiplexing in the fec framework 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, 27 Apr 2009 21:01:09 -0000 Yes, for the purposes for grouping FEC and the original media, in cases where you're trying to reduce port usage. Colin On 27 Apr 2009, at 20:00, Ali C. Begen (abegen) wrote: > Is that a "yes" for ssrc-level grouping for FEC? > > -acbegen > >> -----Original Message----- >> From: Colin Perkins [mailto:csp@csperkins.org] >> Sent: Monday, April 27, 2009 10:54 AM >> To: Ali C. Begen (abegen) >> Cc: Watson, Mark; fecframe@ietf.org; mmusic@ietf.org >> Subject: Re: [Fecframe] RTP stream multiplexing in the fec framework >> >> On 24 Apr 2009, at 19:13, Ali C. Begen (abegen) wrote: >>> Copying MMUSIC as this is relevant to: >>> >>> >> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-sour > ce-attributes-02.txt >>> http://www.ietf.org/internet-drafts/draft-ietf-mmusic- >>> rfc4756bis-01.txt >>> >>>> -----Original Message----- >>>> From: Watson, Mark [mailto:watson@qualcomm.com] >>>> Sent: Friday, April 24, 2009 11:02 AM >>>> To: Ali C. Begen (abegen); fecframe@ietf.org >>>> Subject: Re: RTP stream multiplexing in the fec framework >>>> >>>> Ali, >>>> >>>> What do you think the Framework should do ? >>> >>> IMO, we should not restrict FEC to work only for session >>> multiplexing (although I agree with you that doing so has many >>> advantages). >>> >>> I see a few key reasons why people would use SSRC >> multiplexing, one >>> being to simplify the port operations on NAT traversal. One >> session >>> means one hole on NAT for the RTP transport (rtcp port can be the >>> same or different). So, some apps may use ssrc multiplexing. >> >> The trend is clearly towards allowing multiplexing by RTP SSRC, to >> ease NAT traversal by reducing the number of UDP ports. By that >> argument, sending FEC data on the same port as the media it's >> protecting doesn't seem problematic. (I wouldn't want to see >> different >> media types on one port, but this is close enough related >> that I don't >> see a big issue). >> >>> I am about to finalize the 4756bis draft and so far my assumption >>> has been that we would only do session multiplexing and use >>> "a=group" for associations. This would not work for SSRC >> multiplexed >>> streams, though. For that, we can use the "a=ssrc-group" attribute >>> from Jonathan's draft. >>> >>>> SSRC multiplexing of source and repair is possible and the >>>> intention was to support this in the Framework, but if it is >>>> not required we could simplify by supporting only port >>>> multiplexing. Port multiplexing is more straightforwardly >>>> backwards-compatible (I'm not sure what an RTP receiver does >>>> if it is expecting just one SSRC and it sees two). >>> >>> If it has a payload that it does not understand, it will >> discard it. >>> If it understands and knows what the stream is for, it would just >>> use it as if the stream was received from a different port. >>> >>> Are there any comments/suggestions from MMUSIC? >>> >>> -acbegen >>> >>>> ...Mark >>>> >>>> >>>> On 4/24/09 10:53 AM, "Ali C. Begen (abegen)" >>>> wrote: >>>> >>>> >>>> >>>> Mark, All, >>>> >>>> I have a question about multiplexing the source and >>>> repair streams when they are both RTP. Currently, we have the >>>> following text: >>>> >>>> (Start of section 4) >>>> >>>> The FEC Framework is described in terms of an >>>> additional layer >>>> between the transport layer (e.g. UDP or DCCP) and >>>> protocols running >>>> over this transport layer. Examples of such >>>> protocols are RTP, RTCP, >>>> etc. As such, the data path interface between the >>>> FEC Framework and >>>> both underlying and overlying layers can be thought >>>> of as being the >>>> same as the standard interface to the transport >>>> layer - i.e. the data >>>> exchanged consists of datagram payloads each >>>> associated with a single >>>> transport flow identified (in the case of UDP) by >>>> the standard >>>> 5-tuple { Source IP Address, Source Transport Port, >>>> Destination IP >>>> Address, Destination Transport Port, Transport >>>> Protocol }. In the >>>> case that RTP is used for the repair flows, the >>>> source and repair >>>> data may be multiplexed using RTP onto a single UDP >>>> flow and must >>>> consequently be demultiplexed at the receiver. >>>> There are various >>>> ways in which this multiplexing can be done, for >>>> example as described >>>> in [RFC4588]. >>>> >>>> >>>> RFC 4588 mentions two ways of multiplexing RTP streams. >>>> One is session multiplexing, where source and repair RTP >>>> streams are in different RTP sessions (different dest >>>> address/port). In this case, I don't have any issues, this >>>> works beautifully with the framework. >>>> >>>> The other one is SSRC multiplexing where the source and >>>> repair RTP streams have different SSRCs but are transmitted >>>> in the same RTP session (which is a single UDP flow). Is the >>>> text above saying that the framework also support this kind >>>> of multiplexing? In other words, is using a single UDP flow >>>> to carry source + FEC data acceptable when they have >> separate SSRCs? >>>> >>>> Not that FEC could not be used in this scenario, but as >>>> I recall the framework required different UDP flows for >>>> source and repair flows... >>>> >>>> BR, >>>> -acbegen >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> Fecframe mailing list >>> Fecframe@ietf.org >>> https://www.ietf.org/mailman/listinfo/fecframe >> >> >> >> -- >> Colin Perkins >> http://csperkins.org/ >> >> >> >> > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic -- Colin Perkins http://csperkins.org/ From ron.even.tlv@gmail.com Mon Apr 27 14:02: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 59BCE3A680D; Mon, 27 Apr 2009 14:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.209 X-Spam-Level: X-Spam-Status: No, score=-2.209 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SUB_6CONS_WORD=0.356] 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 QonYcct4vdnV; Mon, 27 Apr 2009 14:02:24 -0700 (PDT) Received: from mail-bw0-f163.google.com (mail-bw0-f163.google.com [209.85.218.163]) by core3.amsl.com (Postfix) with ESMTP id 128E23A6863; Mon, 27 Apr 2009 14:02:22 -0700 (PDT) Received: by bwz7 with SMTP id 7so164724bwz.37 for ; Mon, 27 Apr 2009 14:03:43 -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 :x-mailer:thread-index:content-language; bh=Dnn2rjdV2CcSj5KfHeahfgAYaVzSSgVjqz0bBO34L/c=; b=PYjUDWrPi4hfXGkgtHSo06PvWrx8colFkyJBNTwMTNGV4Zo2wL+h+N1ql3L2Q9Q4YE KFyGwxry14PNOH44mB5+36ngfLFHG/7TxZvUUs7bPi1zJoDWe5s3mOmRz1YqDFQx5b4c 54v8QxNvqcSRbzPSC+8StEXCyrY8azKbjjJJE= 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:x-mailer:thread-index:content-language; b=L4TURdzomQ5QhbKYp5lwf89B+7kOBN3V9H3sOVLr1075mmyPjoPNlbg833JCOuSCd7 lvr9+PrvtP6i6sysfdTZ6Dc1hrLJQ0A2REekGjapyH1DUX/c0eBfgz2OES5557mQLCu5 AijyJpbD8NZsFzz1eFf+9JpIPDE4yife1vOaU= Received: by 10.86.74.4 with SMTP id w4mr620578fga.11.1240866223273; Mon, 27 Apr 2009 14:03:43 -0700 (PDT) Received: from windows8d787f9 (bzq-79-182-99-139.red.bezeqint.net [79.182.99.139]) by mx.google.com with ESMTPS id 12sm448281fgg.0.2009.04.27.14.03.38 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 27 Apr 2009 14:03:42 -0700 (PDT) From: "Roni Even" To: "'VAN CAENEGEM Tom'" , References: <238382595265324EA50F6134BB42DCAF03B18B96@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <238382595265324EA50F6134BB42DCAF03B18B96@FRVELSMBS22.ad2.ad.alcatel.com> Date: Tue, 28 Apr 2009 00:01:48 +0300 Message-ID: <49f61dae.0c07560a.64b2.ffffb27d@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0077_01C9C794.8B94ECD0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnEyIV3JVxE1pVAQlWyD4mzx47lUgCsVa3A Content-Language: en-us Cc: mmusic@ietf.org Subject: Re: [MMUSIC] [AVT] Multiple Feedback Targets in " http://tools.ietf.org/html/draft-ietf-avt-rtcpssm-18" 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, 27 Apr 2009 21:02:33 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0077_01C9C794.8B94ECD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Tom, I think this question should go to mmusic. What you are trying to do here is to define semantics for the content of a RTCP flow pointing to different devices. The m-line or the RTCP line in SDP does not address what is the content of the stream that will go in the RTP session. RFC 4796 addresses the media content issue but you are looking for something similar to the RTCP attribute. This may require a new parameter to the rtcp attribute. You will also need to look at backward interoperability where the receiver will not understand this semantics and may change the RTCP message to the wrong address. The example for the content attribute was to specify to video m-lines one with screen capture as a video stream and the other from a camera. SDP does not define the behavior of the receiver if it receives two m-lines of the same media type and can only support one. It is not clear which one he will chose (first or second). The work on capability negotiation tries to address this issue. Roni Even From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of VAN CAENEGEM Tom Sent: Friday, April 24, 2009 1:36 PM To: avt@ietf.org Subject: [AVT] Multiple Feedback Targets in " http://tools.ietf.org/html/draft-ietf-avt-rtcpssm-18" Hi, I have two questions/comments mostly regarding the RTCP-SSM draft ( http://tools.ietf.org/html/draft-ietf-avt-rtcpssm-18). The background of my questions is the use case of "broadcast channels" in an IPTV context, where the channels are distributed over IP multicast (SSM). In this context, the concept of feedback target(s) is obviously very useful, and actually necessary given today's restrictions with multicast in upstream in the "WAN". For the IPTV use case, it also makes sense to have multiple feedback targets, each responsible for a subset of RTP receivers, because of the large number of RTP receivers involved (100.000s is possible). The way to signal this by means of SDP is that each local subset of RTP receivers sees a different IP address in the "a=rtcp: "portnumber" IN IP4 "IP address" line. So, multiple "localised" FT is covered by the draft IMO. However, in that case, the maximum bandwidth that can be used for RTCP reporting by RTP receivers only needs to be determined by the size of the local group of RTP receivers (sending RTCP to the same localised Feedback Target), especially in the summary FB model. But in my interpretation of the architecture, the actual RTCP bandwith limit information can only be retrieved by the RTP receivers from the information sent by the distribution source in the ssm session. Either by refected RTCP reports from RTP receivers (not a feasible solution for the given use case) or from a RSI message -in the summary FB model- indicating the session size or explicitly the RTCP reporting bandwidth limit. The fact is that this information is sent to ALL RTP receivers, which may be reporting to different Feedback targets where each Feedback target is collecting RTCP messages from a different number of RTP receivers, and hence may have different "requirements" for total RTCP reporting bandwidth limit. My question is whether local Feedback targets have been considered with respect to this issue? My second question again has to do with multiple feedback targets for the same use case. In the IPTV use case for rtcpssm, Feedback Targets can also be used as retransmission sources (RFC 4588) and in http://tools.ietf.org/html/draft-versteeg-avt-rapid-synchronization-for-rtp- 03, the feedback target architecture is used to allow fast acquisition of SSM RTP sessions. The draft proposes that a "burst source" is co-located with the FT which transmits unicast data (starting with a random access point of the video channel) from a cache that holds the most recent data distributed over the RTP SSM. It does transmit the RTP packets at an accelerated speed, allowing the RTP receiver to join the SSM after some time. The idea I would like to bring forward is to allow separate Feedback Targets for the same RTP receiver (population): one Feedback target acts as RTP retransmission server (see http://tools.ietf.org/html/draft-versteeg-avt-rapid-synchronization-for-rtp- 03) and collects RTCP FB messages, while the other Feedback Target is solely "responsible" for the non RTCP-FB messages, such as RTCP XR messages. I realise this idea is not necessarily linked with the rtcp-ssm draft, but IMO only for a massive scale application that makes use of RTP and leverages rtcp ssm such a separation is justified. The possibility for separation of the monitoring service -associated with a server function basically responsible for collecting RTCP receiver reports for the purpose of monitoring- and the retransmission service requiring a server function that is responsible for processing and responding to RTCP FB messages, is driven from the point of view of server function optimisation (different requirements on the server platform). In terms of signaling two Feedback Targets, we could make use of the following lines: a=rtcp:40001 IN IP4 192.0.2.1 (This is for retransmission) a=rtcp-fb:96 nack a=rtcp:40001 IN IP4 192.0.2.2 (This is for XR collection) However, that is probably quite ambiguous..? Furthermore I also realise such a solution introduces other questions than just signaling syntax including the fact that we may need guiding rules on how RTCP reports are issued by the RTP receiver with two RTCP targets in place, as in the example above. The new RFC 5506 is certainly helpful here, but this is probably not sufficient. Comments appreciated on this idea. Kind regards, Tom Van Caenegem ------=_NextPart_000_0077_01C9C794.8B94ECD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Multiple Feedback Targets in " http://tools.ietf.org/html/draft-ietf-avt-rtcpssm-18"

Tom,

I think this question should go to mmusic. What you are = trying to do here is to define semantics for the content of a RTCP flow = pointing to different devices. The m-line or the RTCP line in SDP does not address = what is the content of the stream that will go in the RTP session.  RFC = 4796 addresses the media content issue but you are looking for something = similar to the RTCP attribute. This may require a new parameter to the rtcp = attribute.

You will also need to look at backward interoperability = where the receiver will not understand this semantics and may change the RTCP = message to the wrong address.

 

The example for the content attribute was to specify to = video m-lines one with screen capture as a video stream and the other from a = camera. SDP does not define the behavior of the receiver if it receives two = m-lines of the same media type and can only support one. It is not clear which one = he will chose (first or second). The work on capability negotiation tries to = address this issue.

 

Roni Even

 

From:= avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of = VAN CAENEGEM Tom
Sent: Friday, April 24, 2009 1:36 PM
To: avt@ietf.org
Subject: [AVT] Multiple Feedback Targets in " http://tools.ietf.org/html/draft-ietf-avt-rtcpssm-18"

 

 

Hi, =

I = have two questions/comments mostly regarding the RTCP-SSM draft (http://tools.= ietf.org/html/draft-ietf-avt-rtcpssm-18). The = background of my questions is the use case of "broadcast channels" in an = IPTV context, where the channels are distributed over IP multicast (SSM). In = this context, the concept of feedback target(s) is obviously very useful, and actually necessary given today's restrictions with multicast in upstream = in the "WAN".

For = the IPTV use case, it also makes sense to have multiple feedback targets, each responsible for a subset of RTP receivers, because of the large number = of RTP receivers involved (100.000s is possible). The way to signal this by = means of SDP is that each local subset of RTP receivers sees a different IP = address in the "a=3Drtcp: "portnumber" IN IP4 "IP address"  line.  So, multiple "localised" FT  is covered by the draft = IMO.

However, in that case, the maximum bandwidth that can be used for RTCP reporting by = RTP receivers only needs to be determined by the size of the local group of RTP = receivers (sending RTCP to the same localised Feedback Target), especially in the = summary FB model. But in my interpretation of the architecture, the actual RTCP bandwith limit information can only be retrieved by the RTP receivers = from the information sent by the distribution source in the ssm session. Either = by refected RTCP reports from RTP receivers (not a feasible solution for = the given use case) or from a RSI message -in the summary FB model- indicating the session size or explicitly the RTCP reporting bandwidth limit. The fact = is that this information is sent to ALL RTP receivers, which may be reporting to different Feedback targets where each Feedback target is collecting RTCP = messages from a different number of RTP receivers, and hence may have different "requirements" for total RTCP reporting bandwidth limit.  = My question is whether local Feedback targets have been considered with = respect to this issue?

My = second question again has to do with multiple feedback targets for the same use = case.

In = the IPTV use case for rtcpssm, Feedback Targets can also be used as = retransmission sources (RFC 4588) and in http://tools.= ietf.org/html/draft-versteeg-avt-rapid-synchronization-for-rtp-03<= /a>, the = feedback target architecture is used to allow fast acquisition of SSM RTP sessions. The = draft proposes that  a "burst source" is co-located with the FT = which transmits unicast data (starting with a random access point of the video channel) from a cache that holds the most recent data distributed over = the RTP SSM. It does transmit the RTP packets at an accelerated speed, allowing = the RTP receiver to join the SSM after some time.

The = idea I would like to bring forward is to allow separate Feedback Targets  = for the same RTP receiver (population): one Feedback target acts as RTP = retransmission server (see http://tools.= ietf.org/html/draft-versteeg-avt-rapid-synchronization-for-rtp-03<= /a>) and = collects RTCP FB messages, while the other Feedback Target is solely = "responsible" for the non RTCP-FB messages, such as RTCP XR messages. I realise this = idea is not necessarily linked with  the rtcp-ssm draft, but IMO only for a massive scale application that makes use of RTP and leverages rtcp ssm = such a separation is justified. The possibility for separation of the = monitoring service –associ= ated with a server function basically responsible for collecting RTCP = receiver reports for the purpose of monitoring- and the retransmission service = requiring a server function that is responsible for processing and responding to = RTCP FB messages, is driven from the point of view of server function = optimisation (different requirements on the server platform).

In = terms of signaling two Feedback Targets, we could make use of the following = lines:

a=3Drtcp:40001 IN IP4 192.0.2.1 (This is for retransmission)
a=3Drtcp-fb:96 nack
a=3Drtcp:40001 IN IP4 192.0.2.2 (This is for XR collection) =

 

However, that is probably quite ambiguous..?
Furthermore = I also realise such a solution introduces other questions than just = signaling syntax including the fact that we may need guiding rules on how RTCP = reports are issued by the RTP receiver with two RTCP targets in place, as in the example above. The new RFC 5506 is certainly helpful here, but this is = probably not sufficient.

Comments appreciated on this idea.

Kind regards,
Tom = Van Caenegem

 

 =

------=_NextPart_000_0077_01C9C794.8B94ECD0-- From ron.even.tlv@gmail.com Mon Apr 27 14:21: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 4CB2928C1DD; Mon, 27 Apr 2009 14:21:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.389 X-Spam-Level: X-Spam-Status: No, score=-2.389 tagged_above=-999 required=5 tests=[AWL=0.210, 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 oKwQRwejq1sY; Mon, 27 Apr 2009 14:21:17 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by core3.amsl.com (Postfix) with ESMTP id 6698A3A6960; Mon, 27 Apr 2009 14:21:15 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id l26so1189171fgb.18 for ; Mon, 27 Apr 2009 14:22:35 -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=oMxqr0jp/WNFj5exXRhaCsAnqtH+G5Kqjikoi5bq/Ao=; b=c08vO+TbrA17Ve/G30r6k8DJFu96nT1KzuI26HomWgUfLDLbVUeIELjoz5tKZ/5HSS QzeyLPNIF1yXrhLF8kYjr9XX0P3O0ant1qeuwcr2TgNf+VIzXvwMmhLGVNJuvhKSTGsb 3YdH4tfGpeeabZCsJI+mVoi2RDL8RALOLTSKE= 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=qgGbk3jQGbLnofZyJLh6yfjGBcEZYM73mSd+6IBnKQ6NLnsYHWkkS7xGLmrip7MlQl N8/Vcy1wii/IdJS4ri0UEdbr2slNZ1FVq7aEYh+xnlinc/dqpZXWGnNtm0wOXaEA6TgU wAQkKlrojyeWGY1Q3lfBjoIlXo30JFDGwbPVA= Received: by 10.86.26.11 with SMTP id 11mr3726735fgz.45.1240867355450; Mon, 27 Apr 2009 14:22:35 -0700 (PDT) Received: from windows8d787f9 (bzq-79-182-99-139.red.bezeqint.net [79.182.99.139]) by mx.google.com with ESMTPS id l19sm1889311fgb.7.2009.04.27.14.22.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 27 Apr 2009 14:22:34 -0700 (PDT) From: "Roni Even" To: "'Colin Perkins'" , "'Ali C. Begen \(abegen\)'" References: <04CAD96D4C5A3D48B1919248A8FE0D54092C815D@xmb-sjc-215.amer.cisco.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C817F@xmb-sjc-215.amer.cisco.com> <8F9DD728-5AE9-4394-9BDD-4EDBFB92E4A5@csperkins.org> <04CAD96D4C5A3D48B1919248A8FE0D54092C86BE@xmb-sjc-215.amer.cisco.com> <7D1B0D8B-BCFE-463B-B2F4-E627729A198D@csperkins.org> In-Reply-To: <7D1B0D8B-BCFE-463B-B2F4-E627729A198D@csperkins.org> Date: Tue, 28 Apr 2009 00:20:46 +0300 Message-ID: <49f6221a.1358560a.5aa1.ffff8e46@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnHe5MfvPcJVLxoQt2no+euUsGaogAAgopg Content-Language: en-us Cc: "'Watson, Mark'" , mmusic@ietf.org, fecframe@ietf.org Subject: Re: [MMUSIC] [Fecframe] RTP stream multiplexing in the fec framework 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, 27 Apr 2009 21:21:24 -0000 Hi, I support Colin's view and I think this is why you also specify media of type audio, video and text for the fec stream enabling the multiplexing. I think that maybe there will be a need for a parameter that defines the relation between the original stream and the fec stream similar to the grouping or to the red in RFC 2198 Roni Even -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Colin Perkins Sent: Tuesday, April 28, 2009 12:02 AM To: Ali C. Begen (abegen) Cc: Watson, Mark; mmusic@ietf.org; fecframe@ietf.org Subject: Re: [MMUSIC] [Fecframe] RTP stream multiplexing in the fec framework Yes, for the purposes for grouping FEC and the original media, in cases where you're trying to reduce port usage. Colin On 27 Apr 2009, at 20:00, Ali C. Begen (abegen) wrote: > Is that a "yes" for ssrc-level grouping for FEC? > > -acbegen > >> -----Original Message----- >> From: Colin Perkins [mailto:csp@csperkins.org] >> Sent: Monday, April 27, 2009 10:54 AM >> To: Ali C. Begen (abegen) >> Cc: Watson, Mark; fecframe@ietf.org; mmusic@ietf.org >> Subject: Re: [Fecframe] RTP stream multiplexing in the fec framework >> >> On 24 Apr 2009, at 19:13, Ali C. Begen (abegen) wrote: >>> Copying MMUSIC as this is relevant to: >>> >>> >> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-sour > ce-attributes-02.txt >>> http://www.ietf.org/internet-drafts/draft-ietf-mmusic- >>> rfc4756bis-01.txt >>> >>>> -----Original Message----- >>>> From: Watson, Mark [mailto:watson@qualcomm.com] >>>> Sent: Friday, April 24, 2009 11:02 AM >>>> To: Ali C. Begen (abegen); fecframe@ietf.org >>>> Subject: Re: RTP stream multiplexing in the fec framework >>>> >>>> Ali, >>>> >>>> What do you think the Framework should do ? >>> >>> IMO, we should not restrict FEC to work only for session >>> multiplexing (although I agree with you that doing so has many >>> advantages). >>> >>> I see a few key reasons why people would use SSRC >> multiplexing, one >>> being to simplify the port operations on NAT traversal. One >> session >>> means one hole on NAT for the RTP transport (rtcp port can be the >>> same or different). So, some apps may use ssrc multiplexing. >> >> The trend is clearly towards allowing multiplexing by RTP SSRC, to >> ease NAT traversal by reducing the number of UDP ports. By that >> argument, sending FEC data on the same port as the media it's >> protecting doesn't seem problematic. (I wouldn't want to see >> different >> media types on one port, but this is close enough related >> that I don't >> see a big issue). >> >>> I am about to finalize the 4756bis draft and so far my assumption >>> has been that we would only do session multiplexing and use >>> "a=group" for associations. This would not work for SSRC >> multiplexed >>> streams, though. For that, we can use the "a=ssrc-group" attribute >>> from Jonathan's draft. >>> >>>> SSRC multiplexing of source and repair is possible and the >>>> intention was to support this in the Framework, but if it is >>>> not required we could simplify by supporting only port >>>> multiplexing. Port multiplexing is more straightforwardly >>>> backwards-compatible (I'm not sure what an RTP receiver does >>>> if it is expecting just one SSRC and it sees two). >>> >>> If it has a payload that it does not understand, it will >> discard it. >>> If it understands and knows what the stream is for, it would just >>> use it as if the stream was received from a different port. >>> >>> Are there any comments/suggestions from MMUSIC? >>> >>> -acbegen >>> >>>> ...Mark >>>> >>>> >>>> On 4/24/09 10:53 AM, "Ali C. Begen (abegen)" >>>> wrote: >>>> >>>> >>>> >>>> Mark, All, >>>> >>>> I have a question about multiplexing the source and >>>> repair streams when they are both RTP. Currently, we have the >>>> following text: >>>> >>>> (Start of section 4) >>>> >>>> The FEC Framework is described in terms of an >>>> additional layer >>>> between the transport layer (e.g. UDP or DCCP) and >>>> protocols running >>>> over this transport layer. Examples of such >>>> protocols are RTP, RTCP, >>>> etc. As such, the data path interface between the >>>> FEC Framework and >>>> both underlying and overlying layers can be thought >>>> of as being the >>>> same as the standard interface to the transport >>>> layer - i.e. the data >>>> exchanged consists of datagram payloads each >>>> associated with a single >>>> transport flow identified (in the case of UDP) by >>>> the standard >>>> 5-tuple { Source IP Address, Source Transport Port, >>>> Destination IP >>>> Address, Destination Transport Port, Transport >>>> Protocol }. In the >>>> case that RTP is used for the repair flows, the >>>> source and repair >>>> data may be multiplexed using RTP onto a single UDP >>>> flow and must >>>> consequently be demultiplexed at the receiver. >>>> There are various >>>> ways in which this multiplexing can be done, for >>>> example as described >>>> in [RFC4588]. >>>> >>>> >>>> RFC 4588 mentions two ways of multiplexing RTP streams. >>>> One is session multiplexing, where source and repair RTP >>>> streams are in different RTP sessions (different dest >>>> address/port). In this case, I don't have any issues, this >>>> works beautifully with the framework. >>>> >>>> The other one is SSRC multiplexing where the source and >>>> repair RTP streams have different SSRCs but are transmitted >>>> in the same RTP session (which is a single UDP flow). Is the >>>> text above saying that the framework also support this kind >>>> of multiplexing? In other words, is using a single UDP flow >>>> to carry source + FEC data acceptable when they have >> separate SSRCs? >>>> >>>> Not that FEC could not be used in this scenario, but as >>>> I recall the framework required different UDP flows for >>>> source and repair flows... >>>> >>>> BR, >>>> -acbegen >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> Fecframe mailing list >>> Fecframe@ietf.org >>> https://www.ietf.org/mailman/listinfo/fecframe >> >> >> >> -- >> Colin Perkins >> http://csperkins.org/ >> >> >> >> > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic -- Colin Perkins http://csperkins.org/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From csp@csperkins.org Mon Apr 27 15:08: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 4D04C28C19C; Mon, 27 Apr 2009 15:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.571 X-Spam-Level: X-Spam-Status: No, score=-3.571 tagged_above=-999 required=5 tests=[AWL=0.028, 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 cYrDUmv2zuIS; Mon, 27 Apr 2009 15:08:37 -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 4500528C168; Mon, 27 Apr 2009 15:08:37 -0700 (PDT) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=mangole.lan) by lon1-post-1.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1LyZ1R-00072j-XC; Mon, 27 Apr 2009 22:09:58 +0000 Message-Id: From: Colin Perkins To: Marshall Eubanks In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 27 Apr 2009 23:09:48 +0100 References: <04CAD96D4C5A3D48B1919248A8FE0D54092C815D@xmb-sjc-215.amer.cisco.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C817F@xmb-sjc-215.amer.cisco.com> <8F9DD728-5AE9-4394-9BDD-4EDBFB92E4A5@csperkins.org> <2FA6A311-8B9F-41FF-B9A3-04EB1E399732@americafree.tv> X-Mailer: Apple Mail (2.930.3) Cc: mmusic@ietf.org, fecframe@ietf.org Subject: Re: [MMUSIC] [Fecframe] RTP stream multiplexing in the fec framework 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, 27 Apr 2009 22:08:38 -0000 On 27 Apr 2009, at 22:23, Marshall Eubanks wrote: > On Apr 27, 2009, at 4:52 PM, Colin Perkins wrote: >> On 27 Apr 2009, at 20:02, Marshall Eubanks wrote: >>> On Apr 27, 2009, at 1:53 PM, Colin Perkins wrote: >>>> On 24 Apr 2009, at 19:13, Ali C. Begen (abegen) wrote: >> ... >>> >>>>> IMO, we should not restrict FEC to work only for session >>>>> multiplexing (although I agree with you that doing so has many >>>>> advantages). >>>>> >>>>> I see a few key reasons why people would use SSRC multiplexing, >>>>> one being to simplify the port operations on NAT traversal. One >>>>> session means one hole on NAT for the RTP transport (rtcp port >>>>> can be the same or different). So, some apps may use ssrc >>>>> multiplexing. >>>> >>>> The trend is clearly towards allowing multiplexing by RTP SSRC, >>>> to ease NAT traversal by reducing the number of UDP ports. By >>>> that argument, sending FEC data on the same port as the media >>>> it's protecting doesn't seem problematic. (I wouldn't want to see >>>> different media types on one port, but this is close enough >>>> related that I don't see a big issue). >>> >>> If someone wanted to use SSRC multiplexing in a audio or video >>> conference with multiplexing (audio) or multiple displays (video), >>> and then wanted to apply SSRC multiplexed FEC to that (say for >>> sources on lossy wireless links), isn't there a danger that non- >>> FEC aware receivers would not do the right thing with the FEC ? >> >> >> I don't think so. Non-FEC aware receivers would see an unknown >> payload type, which they should ignore. What's your specific >> concern with that scenario? > > I am trying to understand all of the worries expressed here > > > Separate audio and video streams SHOULD NOT be carried in a single > RTP session and demultiplexed based on the payload type or SSRC > fields. Interleaving packets with different RTP media types but > using the same SSRC would introduce several problems: > > Using a different SSRC for each medium but sending them in the same > RTP session would avoid the first three problems but not the last two > > > So, to be clear, what is proposed is to send the FEC repair stream > with one source address and port, but a different SSRC and payload > type (from the original stream) ? As I understand it, this is being proposed as one option for sending FEC data (with the ability to send the FEC on a separate port as the other option). In terms of the last two points in section 5.2 of RFC 3550, an RTP mixer that understands FEC can make use of the FEC data when mixing (and if it doesn't understand the FEC, the quality is degraded, but the mixer still works); and the only reason to use SSRC multiplexing here is specifically to use the same network path for the FEC and media, making the last point moot. -- Colin Perkins http://csperkins.org/ From abegen@cisco.com Mon Apr 27 15:58:36 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 704433A6F4D; Mon, 27 Apr 2009 15:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.339 X-Spam-Level: X-Spam-Status: No, score=-6.339 tagged_above=-999 required=5 tests=[AWL=0.260, 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 PXRiNG5bHMIB; Mon, 27 Apr 2009 15:58:35 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 348EB3A6DFF; Mon, 27 Apr 2009 15:58:35 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,257,1238976000"; d="scan'208";a="157115723" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 27 Apr 2009 22:59:56 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3RMxuFT026672; Mon, 27 Apr 2009 15:59:56 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3RMxumL021790; Mon, 27 Apr 2009 22:59:56 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Apr 2009 15:59:56 -0700 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: Mon, 27 Apr 2009 15:59:48 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D54092C88A0@xmb-sjc-215.amer.cisco.com> In-Reply-To: <7D1B0D8B-BCFE-463B-B2F4-E627729A198D@csperkins.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] [Fecframe] RTP stream multiplexing in the fec framework Thread-Index: AcnHe3o2t9udAcKdTMOM0tgu2HypagAD0Deg References: <04CAD96D4C5A3D48B1919248A8FE0D54092C815D@xmb-sjc-215.amer.cisco.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C817F@xmb-sjc-215.amer.cisco.com> <8F9DD728-5AE9-4394-9BDD-4EDBFB92E4A5@csperkins.org> <04CAD96D4C5A3D48B1919248A8FE0D54092C86BE@xmb-sjc-215.amer.cisco.com> <7D1B0D8B-BCFE-463B-B2F4-E627729A198D@csperkins.org> From: "Ali C. Begen (abegen)" To: "Colin Perkins" X-OriginalArrivalTime: 27 Apr 2009 22:59:56.0340 (UTC) FILETIME=[E2091F40:01C9C78B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7197; t=1240873196; x=1241737196; c=relaxed/simple; s=sjdkim2002; 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:=20RE=3A=20[MMUSIC]=20[Fecframe]=20RTP=20stream=20 multiplexing=20in=20the=20fec=20framework |Sender:=20; bh=qYn9oNHMYjXT7k6npO/B+WY36g6fGxAgq6Ezsirs8gg=; b=VKvXNPXB1Sp9YDIhXxpbzyDz47nZLqDlzfAiO9ynyzxzbNX0uZYLV+4Ytz 6cZq3UkPgF1SIqm9nOEnEAHC+jV+GLJzNBMPmifLMpdP0HAq3/rCkNjvGb/4 +Z9FsYZRxh; Authentication-Results: sj-dkim-2; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: "Watson, Mark" , mmusic@ietf.org, fecframe@ietf.org Subject: Re: [MMUSIC] [Fecframe] RTP stream multiplexing in the fec framework 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, 27 Apr 2009 22:58:36 -0000 Alright, looks like we need to have SSRC multiplexing for FEC, and thus, = we need grouping support for it (a=3Dssrc-group). I'll revise the = 4756bis and submit a new version for review. One more question, though. Should we allow for "a=3Dssrc-group:FEC-XR" = semantics only if SSRC multiplexing is used and mandate = "a=3Dgroup:FEC-XR" semantics for everything else (for non-RTP flows and = when session multiplexing is used)? Or, should we also allow = "a=3Dssrc-group:FEC-XR" semantics for session multiplexing as well? -acbegen > -----Original Message----- > From: Colin Perkins [mailto:csp@csperkins.org]=20 > Sent: Monday, April 27, 2009 2:02 PM > To: Ali C. Begen (abegen) > Cc: Watson, Mark; mmusic@ietf.org; fecframe@ietf.org > Subject: Re: [MMUSIC] [Fecframe] RTP stream multiplexing in=20 > the fec framework >=20 > Yes, for the purposes for grouping FEC and the original media, in =20 > cases where you're trying to reduce port usage. >=20 > Colin >=20 >=20 >=20 > On 27 Apr 2009, at 20:00, Ali C. Begen (abegen) wrote: > > Is that a "yes" for ssrc-level grouping for FEC? > > > > -acbegen > > > >> -----Original Message----- > >> From: Colin Perkins [mailto:csp@csperkins.org] > >> Sent: Monday, April 27, 2009 10:54 AM > >> To: Ali C. Begen (abegen) > >> Cc: Watson, Mark; fecframe@ietf.org; mmusic@ietf.org > >> Subject: Re: [Fecframe] RTP stream multiplexing in the fec=20 > framework > >> > >> On 24 Apr 2009, at 19:13, Ali C. Begen (abegen) wrote: > >>> Copying MMUSIC as this is relevant to: > >>> > >>> > >> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-sour > > ce-attributes-02.txt > >>> http://www.ietf.org/internet-drafts/draft-ietf-mmusic- > >>> rfc4756bis-01.txt > >>> > >>>> -----Original Message----- > >>>> From: Watson, Mark [mailto:watson@qualcomm.com] > >>>> Sent: Friday, April 24, 2009 11:02 AM > >>>> To: Ali C. Begen (abegen); fecframe@ietf.org > >>>> Subject: Re: RTP stream multiplexing in the fec framework > >>>> > >>>> Ali, > >>>> > >>>> What do you think the Framework should do ? > >>> > >>> IMO, we should not restrict FEC to work only for session > >>> multiplexing (although I agree with you that doing so has many > >>> advantages). > >>> > >>> I see a few key reasons why people would use SSRC > >> multiplexing, one > >>> being to simplify the port operations on NAT traversal. One > >> session > >>> means one hole on NAT for the RTP transport (rtcp port can be the > >>> same or different). So, some apps may use ssrc multiplexing. > >> > >> The trend is clearly towards allowing multiplexing by RTP SSRC, to > >> ease NAT traversal by reducing the number of UDP ports. By that > >> argument, sending FEC data on the same port as the media it's > >> protecting doesn't seem problematic. (I wouldn't want to see > >> different > >> media types on one port, but this is close enough related > >> that I don't > >> see a big issue). > >> > >>> I am about to finalize the 4756bis draft and so far my assumption > >>> has been that we would only do session multiplexing and use > >>> "a=3Dgroup" for associations. This would not work for SSRC > >> multiplexed > >>> streams, though. For that, we can use the "a=3Dssrc-group" = attribute > >>> from Jonathan's draft. > >>> > >>>> SSRC multiplexing of source and repair is possible and the > >>>> intention was to support this in the Framework, but if it is > >>>> not required we could simplify by supporting only port > >>>> multiplexing. Port multiplexing is more straightforwardly > >>>> backwards-compatible (I'm not sure what an RTP receiver does > >>>> if it is expecting just one SSRC and it sees two). > >>> > >>> If it has a payload that it does not understand, it will > >> discard it. > >>> If it understands and knows what the stream is for, it would just > >>> use it as if the stream was received from a different port. > >>> > >>> Are there any comments/suggestions from MMUSIC? > >>> > >>> -acbegen > >>> > >>>> ...Mark > >>>> > >>>> > >>>> On 4/24/09 10:53 AM, "Ali C. Begen (abegen)" > >>>> wrote: > >>>> > >>>> > >>>> > >>>> Mark, All, > >>>> =09 > >>>> I have a question about multiplexing the source and > >>>> repair streams when they are both RTP. Currently, we have the > >>>> following text: > >>>> =09 > >>>> (Start of section 4) > >>>> =09 > >>>> The FEC Framework is described in terms of an > >>>> additional layer > >>>> between the transport layer (e.g. UDP or DCCP) and > >>>> protocols running > >>>> over this transport layer. Examples of such > >>>> protocols are RTP, RTCP, > >>>> etc. As such, the data path interface between the > >>>> FEC Framework and > >>>> both underlying and overlying layers can be thought > >>>> of as being the > >>>> same as the standard interface to the transport > >>>> layer - i.e. the data > >>>> exchanged consists of datagram payloads each > >>>> associated with a single > >>>> transport flow identified (in the case of UDP) by > >>>> the standard > >>>> 5-tuple { Source IP Address, Source Transport Port, > >>>> Destination IP > >>>> Address, Destination Transport Port, Transport > >>>> Protocol }. In the > >>>> case that RTP is used for the repair flows, the > >>>> source and repair > >>>> data may be multiplexed using RTP onto a single UDP > >>>> flow and must > >>>> consequently be demultiplexed at the receiver. > >>>> There are various > >>>> ways in which this multiplexing can be done, for > >>>> example as described > >>>> in [RFC4588]. > >>>> =09 > >>>> =09 > >>>> RFC 4588 mentions two ways of multiplexing RTP streams. > >>>> One is session multiplexing, where source and repair RTP > >>>> streams are in different RTP sessions (different dest > >>>> address/port). In this case, I don't have any issues, this > >>>> works beautifully with the framework. > >>>> =09 > >>>> The other one is SSRC multiplexing where the source and > >>>> repair RTP streams have different SSRCs but are transmitted > >>>> in the same RTP session (which is a single UDP flow). Is the > >>>> text above saying that the framework also support this kind > >>>> of multiplexing? In other words, is using a single UDP flow > >>>> to carry source + FEC data acceptable when they have > >> separate SSRCs? > >>>> =09 > >>>> Not that FEC could not be used in this scenario, but as > >>>> I recall the framework required different UDP flows for > >>>> source and repair flows... > >>>> =09 > >>>> BR, > >>>> -acbegen > >>>> =09 > >>>> =09 > >>>> > >>>> > >>> _______________________________________________ > >>> Fecframe mailing list > >>> Fecframe@ietf.org > >>> https://www.ietf.org/mailman/listinfo/fecframe > >> > >> > >> > >> --=20 > >> Colin Perkins > >> http://csperkins.org/ > >> > >> > >> > >> > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic >=20 >=20 >=20 > --=20 > Colin Perkins > http://csperkins.org/ >=20 >=20 >=20 >=20 From princearimpur@huawei.com Mon Apr 27 22:36:08 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 5A0923A7047 for ; Mon, 27 Apr 2009 22:36:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.364 X-Spam-Level: * X-Spam-Status: No, score=1.364 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 6GuhobxGqWID for ; Mon, 27 Apr 2009 22:36:07 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id CF6CB3A7044 for ; Mon, 27 Apr 2009 22:35:51 -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 <0KIS00IQZQ9QYF@szxga04-in.huawei.com> for mmusic@ietf.org; Tue, 28 Apr 2009 13:37:02 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIS00990Q9QCA@szxga04-in.huawei.com> for mmusic@ietf.org; Tue, 28 Apr 2009 13:37:02 +0800 (CST) Received: from BLRNSHTIPL8NC ([10.18.1.38]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KIS00DUNQ9O3I@szxml06-in.huawei.com> for mmusic@ietf.org; Tue, 28 Apr 2009 13:37:02 +0800 (CST) Date: Tue, 28 Apr 2009 11:07:00 +0530 From: Prince A P In-reply-to: To: 'sip fourm' Message-id: <004301c9c7c3$5b5dbdb0$2601120a@china.huawei.com> Organization: Htipl MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.3168 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcnDIH7iFocV93IATlu1hdxi2In5vgACMVNwASZpKCA= Cc: "'mmusic \(E-mail\)'" Subject: [MMUSIC] Sigcomp X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: princearimpur@huawei.com List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 05:36:08 -0000 Hi, Any idea about currently how many live deployments are happening for Sigcomp? Does the Importance of it really going down with high bandwidth availability? rgds, Prince From ron.even.tlv@gmail.com Tue Apr 28 00:06:15 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 A93C83A6947; Tue, 28 Apr 2009 00:06:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.685 X-Spam-Level: X-Spam-Status: No, score=-1.685 tagged_above=-999 required=5 tests=[AWL=0.314, BAYES_00=-2.599, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0BGUiZwR6FP; Tue, 28 Apr 2009 00:06:14 -0700 (PDT) Received: from mail-bw0-f163.google.com (mail-bw0-f163.google.com [209.85.218.163]) by core3.amsl.com (Postfix) with ESMTP id 1EA613A705B; Tue, 28 Apr 2009 00:05:42 -0700 (PDT) Received: by bwz7 with SMTP id 7so346274bwz.37 for ; Tue, 28 Apr 2009 00:07:03 -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=Gty0zKak7NF+GCouhQEFjadSL2TPpju1IP7WXqQqtig=; b=EySf1898y3qIBe5WcqQ3iY030TzfMZUJsnIYsvGZaJZeQ2JkgpL8vnotVT4CsGEvY6 DEmxIgnxBcFMmJ79b7To5s4qg3NzzdnEqv9x/KEjSyYVG6CPQLTeaZoo8tCJqZfPx0BJ xYBLlcUNh4V5p34IMXMnesfxzBrIaZYQT1+CQ= 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=sAOGqwArG9gMAkFgeQ2BPoJMvoJVxRmsnto6wBRWwQ3q/pgvWO/YzNc+M0qKvgXGMj sttBMPFi75iQHt0y4K7j5K0auqlvBzwHOttTy/TikuKxtKrmMeJ3XNNgbpaksYgu5ghb HwpT+CafuaG7x69bLRYvFDqjpnVTWgWVvk/n0= Received: by 10.103.227.10 with SMTP id e10mr3704527mur.67.1240902423283; Tue, 28 Apr 2009 00:07:03 -0700 (PDT) Received: from windows8d787f9 (bzq-79-177-61-236.red.bezeqint.net [79.177.61.236]) by mx.google.com with ESMTPS id s10sm5203094muh.58.2009.04.28.00.07.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 28 Apr 2009 00:07:02 -0700 (PDT) From: "Roni Even" To: "'Ali C. Begen \(abegen\)'" , "'Colin Perkins'" References: <04CAD96D4C5A3D48B1919248A8FE0D54092C815D@xmb-sjc-215.amer.cisco.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C817F@xmb-sjc-215.amer.cisco.com> <8F9DD728-5AE9-4394-9BDD-4EDBFB92E4A5@csperkins.org> <04CAD96D4C5A3D48B1919248A8FE0D54092C86BE@xmb-sjc-215.amer.cisco.com> <7D1B0D8B-BCFE-463B-B2F4-E627729A198D@csperkins.org> <04CAD96D4C5A3D48B1919248A8FE0D54092C88A0@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D54092C88A0@xmb-sjc-215.amer.cisco.com> Date: Tue, 28 Apr 2009 10:05:04 +0300 Message-ID: <49f6ab16.0af5660a.1039.5418@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnHe3o2t9udAcKdTMOM0tgu2HypagAD0DegABEeFuA= Content-Language: en-us Cc: "'Watson, Mark'" , mmusic@ietf.org, fecframe@ietf.org Subject: Re: [MMUSIC] [Fecframe] RTP stream multiplexing in the fec framework 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, 28 Apr 2009 07:06:15 -0000 Ali, I think that if you would want to use a=ssrc-group:fec-xr also for session multiplexing it will be a session level attribute duplicating the a=group and having problem with SSRC number uniqueness across RTP sessions. I think it will be best to have the a=ssrc-group as a media level attribute only Roni -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Ali C. Begen (abegen) Sent: Tuesday, April 28, 2009 2:00 AM To: Colin Perkins Cc: Watson, Mark; mmusic@ietf.org; fecframe@ietf.org Subject: Re: [MMUSIC] [Fecframe] RTP stream multiplexing in the fec framework Alright, looks like we need to have SSRC multiplexing for FEC, and thus, we need grouping support for it (a=ssrc-group). I'll revise the 4756bis and submit a new version for review. One more question, though. Should we allow for "a=ssrc-group:FEC-XR" semantics only if SSRC multiplexing is used and mandate "a=group:FEC-XR" semantics for everything else (for non-RTP flows and when session multiplexing is used)? Or, should we also allow "a=ssrc-group:FEC-XR" semantics for session multiplexing as well? -acbegen > -----Original Message----- > From: Colin Perkins [mailto:csp@csperkins.org] > Sent: Monday, April 27, 2009 2:02 PM > To: Ali C. Begen (abegen) > Cc: Watson, Mark; mmusic@ietf.org; fecframe@ietf.org > Subject: Re: [MMUSIC] [Fecframe] RTP stream multiplexing in > the fec framework > > Yes, for the purposes for grouping FEC and the original media, in > cases where you're trying to reduce port usage. > > Colin > > > > On 27 Apr 2009, at 20:00, Ali C. Begen (abegen) wrote: > > Is that a "yes" for ssrc-level grouping for FEC? > > > > -acbegen > > > >> -----Original Message----- > >> From: Colin Perkins [mailto:csp@csperkins.org] > >> Sent: Monday, April 27, 2009 10:54 AM > >> To: Ali C. Begen (abegen) > >> Cc: Watson, Mark; fecframe@ietf.org; mmusic@ietf.org > >> Subject: Re: [Fecframe] RTP stream multiplexing in the fec > framework > >> > >> On 24 Apr 2009, at 19:13, Ali C. Begen (abegen) wrote: > >>> Copying MMUSIC as this is relevant to: > >>> > >>> > >> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-sour > > ce-attributes-02.txt > >>> http://www.ietf.org/internet-drafts/draft-ietf-mmusic- > >>> rfc4756bis-01.txt > >>> > >>>> -----Original Message----- > >>>> From: Watson, Mark [mailto:watson@qualcomm.com] > >>>> Sent: Friday, April 24, 2009 11:02 AM > >>>> To: Ali C. Begen (abegen); fecframe@ietf.org > >>>> Subject: Re: RTP stream multiplexing in the fec framework > >>>> > >>>> Ali, > >>>> > >>>> What do you think the Framework should do ? > >>> > >>> IMO, we should not restrict FEC to work only for session > >>> multiplexing (although I agree with you that doing so has many > >>> advantages). > >>> > >>> I see a few key reasons why people would use SSRC > >> multiplexing, one > >>> being to simplify the port operations on NAT traversal. One > >> session > >>> means one hole on NAT for the RTP transport (rtcp port can be the > >>> same or different). So, some apps may use ssrc multiplexing. > >> > >> The trend is clearly towards allowing multiplexing by RTP SSRC, to > >> ease NAT traversal by reducing the number of UDP ports. By that > >> argument, sending FEC data on the same port as the media it's > >> protecting doesn't seem problematic. (I wouldn't want to see > >> different > >> media types on one port, but this is close enough related > >> that I don't > >> see a big issue). > >> > >>> I am about to finalize the 4756bis draft and so far my assumption > >>> has been that we would only do session multiplexing and use > >>> "a=group" for associations. This would not work for SSRC > >> multiplexed > >>> streams, though. For that, we can use the "a=ssrc-group" attribute > >>> from Jonathan's draft. > >>> > >>>> SSRC multiplexing of source and repair is possible and the > >>>> intention was to support this in the Framework, but if it is > >>>> not required we could simplify by supporting only port > >>>> multiplexing. Port multiplexing is more straightforwardly > >>>> backwards-compatible (I'm not sure what an RTP receiver does > >>>> if it is expecting just one SSRC and it sees two). > >>> > >>> If it has a payload that it does not understand, it will > >> discard it. > >>> If it understands and knows what the stream is for, it would just > >>> use it as if the stream was received from a different port. > >>> > >>> Are there any comments/suggestions from MMUSIC? > >>> > >>> -acbegen > >>> > >>>> ...Mark > >>>> > >>>> > >>>> On 4/24/09 10:53 AM, "Ali C. Begen (abegen)" > >>>> wrote: > >>>> > >>>> > >>>> > >>>> Mark, All, > >>>> > >>>> I have a question about multiplexing the source and > >>>> repair streams when they are both RTP. Currently, we have the > >>>> following text: > >>>> > >>>> (Start of section 4) > >>>> > >>>> The FEC Framework is described in terms of an > >>>> additional layer > >>>> between the transport layer (e.g. UDP or DCCP) and > >>>> protocols running > >>>> over this transport layer. Examples of such > >>>> protocols are RTP, RTCP, > >>>> etc. As such, the data path interface between the > >>>> FEC Framework and > >>>> both underlying and overlying layers can be thought > >>>> of as being the > >>>> same as the standard interface to the transport > >>>> layer - i.e. the data > >>>> exchanged consists of datagram payloads each > >>>> associated with a single > >>>> transport flow identified (in the case of UDP) by > >>>> the standard > >>>> 5-tuple { Source IP Address, Source Transport Port, > >>>> Destination IP > >>>> Address, Destination Transport Port, Transport > >>>> Protocol }. In the > >>>> case that RTP is used for the repair flows, the > >>>> source and repair > >>>> data may be multiplexed using RTP onto a single UDP > >>>> flow and must > >>>> consequently be demultiplexed at the receiver. > >>>> There are various > >>>> ways in which this multiplexing can be done, for > >>>> example as described > >>>> in [RFC4588]. > >>>> > >>>> > >>>> RFC 4588 mentions two ways of multiplexing RTP streams. > >>>> One is session multiplexing, where source and repair RTP > >>>> streams are in different RTP sessions (different dest > >>>> address/port). In this case, I don't have any issues, this > >>>> works beautifully with the framework. > >>>> > >>>> The other one is SSRC multiplexing where the source and > >>>> repair RTP streams have different SSRCs but are transmitted > >>>> in the same RTP session (which is a single UDP flow). Is the > >>>> text above saying that the framework also support this kind > >>>> of multiplexing? In other words, is using a single UDP flow > >>>> to carry source + FEC data acceptable when they have > >> separate SSRCs? > >>>> > >>>> Not that FEC could not be used in this scenario, but as > >>>> I recall the framework required different UDP flows for > >>>> source and repair flows... > >>>> > >>>> BR, > >>>> -acbegen > >>>> > >>>> > >>>> > >>>> > >>> _______________________________________________ > >>> Fecframe mailing list > >>> Fecframe@ietf.org > >>> https://www.ietf.org/mailman/listinfo/fecframe > >> > >> > >> > >> -- > >> Colin Perkins > >> http://csperkins.org/ > >> > >> > >> > >> > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > > > -- > Colin Perkins > http://csperkins.org/ > > > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From abegen@cisco.com Tue Apr 28 00:57: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 7C0653A7091; Tue, 28 Apr 2009 00:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.052 X-Spam-Level: X-Spam-Status: No, score=-6.052 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=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 MaJrFIw8ANiL; Tue, 28 Apr 2009 00:57:54 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 8DE973A7088; Tue, 28 Apr 2009 00:57:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,259,1238976000"; d="scan'208,217";a="294179309" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 28 Apr 2009 07:59:14 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3S7xEdK024121; Tue, 28 Apr 2009 00:59:14 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n3S7xEUW017913; Tue, 28 Apr 2009 07:59:14 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Apr 2009 00:59:13 -0700 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_01C9C7D7.37D1C102" Date: Tue, 28 Apr 2009 00:59:12 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D54066184F9@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] [Fecframe] RTP stream multiplexing in the fec framework Thread-Index: AcnHe3o2t9udAcKdTMOM0tgu2HypagAD0DegABEeFuAAAgEQ2A== From: "Ali C. Begen (abegen)" To: , X-OriginalArrivalTime: 28 Apr 2009 07:59:13.0980 (UTC) FILETIME=[38B127C0:01C9C7D7] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=29207; t=1240905554; x=1241769554; c=relaxed/simple; s=sjdkim1004; 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:=20Re=3A=20[MMUSIC]=20[Fecframe]=20RTP=20stream=20 multiplexing=20in=20the=20fec=20framework |Sender:=20; bh=OAX+YNxAJlof6LJjSi5AvmiZnac+bkpfuZyed2yz4yc=; b=gz0hq3c9aIk1yBrlQwMrketSdoIFjoHWyEKZXx7uX97h2zxRFeLxRIBT7i zZjIFd+/8DhMvRzq7pVe3hf6WvJ3zsgK710Jydld5zmBbe7XzpcyflDXDtYp U+W9L9zUe6MmuWs0zeiyydQiqnpO7VAZ6jLw61ztaP4+c8ch/SHlw=; Authentication-Results: sj-dkim-1; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: watson@qualcomm.com, mmusic@ietf.org, fecframe@ietf.org Subject: Re: [MMUSIC] [Fecframe] RTP stream multiplexing in the fec framework 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, 28 Apr 2009 07:57:56 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9C7D7.37D1C102 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 R29vZCBwb2ludCwgSSBhZ3JlZSB3aXRoIHRoaXMgYXNzZXNzbWVudC4gDQoNCkJSLA0KDQoNCi1h Y2JlZ2VuIChCYmVycnkgY3JpcHBsZWQpDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0N CkZyb206IFJvbmkgRXZlbiA8cm9uLmV2ZW4udGx2QGdtYWlsLmNvbT4NClRvOiBBbGkgQy4gQmVn ZW4gKGFiZWdlbik7ICdDb2xpbiBQZXJraW5zJyA8Y3NwQGNzcGVya2lucy5vcmc+DQpDYzogJ1dh dHNvbiwgTWFyaycgPHdhdHNvbkBxdWFsY29tbS5jb20+OyBtbXVzaWNAaWV0Zi5vcmcgPG1tdXNp Y0BpZXRmLm9yZz47IGZlY2ZyYW1lQGlldGYub3JnIDxmZWNmcmFtZUBpZXRmLm9yZz4NClNlbnQ6 IFR1ZSBBcHIgMjggMDA6MDU6MDQgMjAwOQ0KU3ViamVjdDogUkU6IFtNTVVTSUNdIFtGZWNmcmFt ZV0gUlRQIHN0cmVhbSBtdWx0aXBsZXhpbmcgaW4gdGhlIGZlYyBmcmFtZXdvcmsNCg0KQWxpLA0K SSB0aGluayB0aGF0IGlmIHlvdSB3b3VsZCB3YW50IHRvIHVzZSBhPXNzcmMtZ3JvdXA6ZmVjLXhy IGFsc28gZm9yIHNlc3Npb24NCm11bHRpcGxleGluZyBpdCB3aWxsIGJlIGEgc2Vzc2lvbiBsZXZl bCBhdHRyaWJ1dGUgZHVwbGljYXRpbmcgdGhlIGE9Z3JvdXANCmFuZCBoYXZpbmcgcHJvYmxlbSB3 aXRoIFNTUkMgbnVtYmVyIHVuaXF1ZW5lc3MgYWNyb3NzIFJUUCBzZXNzaW9ucy4gSSB0aGluaw0K aXQgd2lsbCBiZSBiZXN0IHRvIGhhdmUgdGhlIGE9c3NyYy1ncm91cCBhcyBhIG1lZGlhIGxldmVs IGF0dHJpYnV0ZSBvbmx5DQpSb25pDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBtbXVzaWMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1tdXNpYy1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YNCkFsaSBDLiBCZWdlbiAoYWJlZ2VuKQ0KU2VudDogVHVlc2RheSwgQXBy aWwgMjgsIDIwMDkgMjowMCBBTQ0KVG86IENvbGluIFBlcmtpbnMNCkNjOiBXYXRzb24sIE1hcms7 IG1tdXNpY0BpZXRmLm9yZzsgZmVjZnJhbWVAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbTU1VU0lD XSBbRmVjZnJhbWVdIFJUUCBzdHJlYW0gbXVsdGlwbGV4aW5nIGluIHRoZSBmZWMNCmZyYW1ld29y aw0KDQpBbHJpZ2h0LCBsb29rcyBsaWtlIHdlIG5lZWQgdG8gaGF2ZSBTU1JDIG11bHRpcGxleGlu ZyBmb3IgRkVDLCBhbmQgdGh1cywgd2UNCm5lZWQgZ3JvdXBpbmcgc3VwcG9ydCBmb3IgaXQgKGE9 c3NyYy1ncm91cCkuIEknbGwgcmV2aXNlIHRoZSA0NzU2YmlzIGFuZA0Kc3VibWl0IGEgbmV3IHZl cnNpb24gZm9yIHJldmlldy4NCg0KT25lIG1vcmUgcXVlc3Rpb24sIHRob3VnaC4gU2hvdWxkIHdl IGFsbG93IGZvciAiYT1zc3JjLWdyb3VwOkZFQy1YUiINCnNlbWFudGljcyBvbmx5IGlmIFNTUkMg bXVsdGlwbGV4aW5nIGlzIHVzZWQgYW5kIG1hbmRhdGUgImE9Z3JvdXA6RkVDLVhSIg0Kc2VtYW50 aWNzIGZvciBldmVyeXRoaW5nIGVsc2UgKGZvciBub24tUlRQIGZsb3dzIGFuZCB3aGVuIHNlc3Np b24NCm11bHRpcGxleGluZyBpcyB1c2VkKT8gT3IsIHNob3VsZCB3ZSBhbHNvIGFsbG93ICJhPXNz cmMtZ3JvdXA6RkVDLVhSIg0Kc2VtYW50aWNzIGZvciBzZXNzaW9uIG11bHRpcGxleGluZyBhcyB3 ZWxsPw0KDQotYWNiZWdlbg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206 IENvbGluIFBlcmtpbnMgW21haWx0bzpjc3BAY3NwZXJraW5zLm9yZ10gDQo+IFNlbnQ6IE1vbmRh eSwgQXByaWwgMjcsIDIwMDkgMjowMiBQTQ0KPiBUbzogQWxpIEMuIEJlZ2VuIChhYmVnZW4pDQo+ IENjOiBXYXRzb24sIE1hcms7IG1tdXNpY0BpZXRmLm9yZzsgZmVjZnJhbWVAaWV0Zi5vcmcNCj4g U3ViamVjdDogUmU6IFtNTVVTSUNdIFtGZWNmcmFtZV0gUlRQIHN0cmVhbSBtdWx0aXBsZXhpbmcg aW4gDQo+IHRoZSBmZWMgZnJhbWV3b3JrDQo+IA0KPiBZZXMsIGZvciB0aGUgcHVycG9zZXMgZm9y IGdyb3VwaW5nIEZFQyBhbmQgdGhlIG9yaWdpbmFsIG1lZGlhLCBpbiAgDQo+IGNhc2VzIHdoZXJl IHlvdSdyZSB0cnlpbmcgdG8gcmVkdWNlIHBvcnQgdXNhZ2UuDQo+IA0KPiBDb2xpbg0KPiANCj4g DQo+IA0KPiBPbiAyNyBBcHIgMjAwOSwgYXQgMjA6MDAsIEFsaSBDLiBCZWdlbiAoYWJlZ2VuKSB3 cm90ZToNCj4gPiBJcyB0aGF0IGEgInllcyIgZm9yIHNzcmMtbGV2ZWwgZ3JvdXBpbmcgZm9yIEZF Qz8NCj4gPg0KPiA+IC1hY2JlZ2VuDQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gPj4gRnJvbTogQ29saW4gUGVya2lucyBbbWFpbHRvOmNzcEBjc3BlcmtpbnMub3JnXQ0K PiA+PiBTZW50OiBNb25kYXksIEFwcmlsIDI3LCAyMDA5IDEwOjU0IEFNDQo+ID4+IFRvOiBBbGkg Qy4gQmVnZW4gKGFiZWdlbikNCj4gPj4gQ2M6IFdhdHNvbiwgTWFyazsgZmVjZnJhbWVAaWV0Zi5v cmc7IG1tdXNpY0BpZXRmLm9yZw0KPiA+PiBTdWJqZWN0OiBSZTogW0ZlY2ZyYW1lXSBSVFAgc3Ry ZWFtIG11bHRpcGxleGluZyBpbiB0aGUgZmVjIA0KPiBmcmFtZXdvcmsNCj4gPj4NCj4gPj4gT24g MjQgQXByIDIwMDksIGF0IDE5OjEzLCBBbGkgQy4gQmVnZW4gKGFiZWdlbikgd3JvdGU6DQo+ID4+ PiBDb3B5aW5nIE1NVVNJQyBhcyB0aGlzIGlzIHJlbGV2YW50IHRvOg0KPiA+Pj4NCj4gPj4+DQo+ ID4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtbW11c2lj LXNkcC1zb3VyDQo+ID4gY2UtYXR0cmlidXRlcy0wMi50eHQNCj4gPj4+IGh0dHA6Ly93d3cuaWV0 Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtbW11c2ljLQ0KPiA+Pj4gcmZjNDc1NmJp cy0wMS50eHQNCj4gPj4+DQo+ID4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4+ PiBGcm9tOiBXYXRzb24sIE1hcmsgW21haWx0bzp3YXRzb25AcXVhbGNvbW0uY29tXQ0KPiA+Pj4+ IFNlbnQ6IEZyaWRheSwgQXByaWwgMjQsIDIwMDkgMTE6MDIgQU0NCj4gPj4+PiBUbzogQWxpIEMu IEJlZ2VuIChhYmVnZW4pOyBmZWNmcmFtZUBpZXRmLm9yZw0KPiA+Pj4+IFN1YmplY3Q6IFJlOiBS VFAgc3RyZWFtIG11bHRpcGxleGluZyBpbiB0aGUgZmVjIGZyYW1ld29yaw0KPiA+Pj4+DQo+ID4+ Pj4gQWxpLA0KPiA+Pj4+DQo+ID4+Pj4gV2hhdCBkbyB5b3UgdGhpbmsgdGhlIEZyYW1ld29yayBz aG91bGQgZG8gPw0KPiA+Pj4NCj4gPj4+IElNTywgd2Ugc2hvdWxkIG5vdCByZXN0cmljdCBGRUMg dG8gd29yayBvbmx5IGZvciBzZXNzaW9uDQo+ID4+PiBtdWx0aXBsZXhpbmcgKGFsdGhvdWdoIEkg YWdyZWUgd2l0aCB5b3UgdGhhdCBkb2luZyBzbyBoYXMgbWFueQ0KPiA+Pj4gYWR2YW50YWdlcyku DQo+ID4+Pg0KPiA+Pj4gSSBzZWUgYSBmZXcga2V5IHJlYXNvbnMgd2h5IHBlb3BsZSB3b3VsZCB1 c2UgU1NSQw0KPiA+PiBtdWx0aXBsZXhpbmcsIG9uZQ0KPiA+Pj4gYmVpbmcgdG8gc2ltcGxpZnkg dGhlIHBvcnQgb3BlcmF0aW9ucyBvbiBOQVQgdHJhdmVyc2FsLiBPbmUNCj4gPj4gc2Vzc2lvbg0K PiA+Pj4gbWVhbnMgb25lIGhvbGUgb24gTkFUIGZvciB0aGUgUlRQIHRyYW5zcG9ydCAocnRjcCBw b3J0IGNhbiBiZSB0aGUNCj4gPj4+IHNhbWUgb3IgZGlmZmVyZW50KS4gU28sIHNvbWUgYXBwcyBt YXkgdXNlIHNzcmMgbXVsdGlwbGV4aW5nLg0KPiA+Pg0KPiA+PiBUaGUgdHJlbmQgaXMgY2xlYXJs eSB0b3dhcmRzIGFsbG93aW5nIG11bHRpcGxleGluZyBieSBSVFAgU1NSQywgdG8NCj4gPj4gZWFz ZSBOQVQgdHJhdmVyc2FsIGJ5IHJlZHVjaW5nIHRoZSBudW1iZXIgb2YgVURQIHBvcnRzLiBCeSB0 aGF0DQo+ID4+IGFyZ3VtZW50LCBzZW5kaW5nIEZFQyBkYXRhIG9uIHRoZSBzYW1lIHBvcnQgYXMg dGhlIG1lZGlhIGl0J3MNCj4gPj4gcHJvdGVjdGluZyBkb2Vzbid0IHNlZW0gcHJvYmxlbWF0aWMu IChJIHdvdWxkbid0IHdhbnQgdG8gc2VlDQo+ID4+IGRpZmZlcmVudA0KPiA+PiBtZWRpYSB0eXBl cyBvbiBvbmUgcG9ydCwgYnV0IHRoaXMgaXMgY2xvc2UgZW5vdWdoIHJlbGF0ZWQNCj4gPj4gdGhh dCBJIGRvbid0DQo+ID4+IHNlZSBhIGJpZyBpc3N1ZSkuDQo+ID4+DQo+ID4+PiBJIGFtIGFib3V0 IHRvIGZpbmFsaXplIHRoZSA0NzU2YmlzIGRyYWZ0IGFuZCBzbyBmYXIgbXkgYXNzdW1wdGlvbg0K PiA+Pj4gaGFzIGJlZW4gdGhhdCB3ZSB3b3VsZCBvbmx5IGRvIHNlc3Npb24gbXVsdGlwbGV4aW5n IGFuZCB1c2UNCj4gPj4+ICJhPWdyb3VwIiBmb3IgYXNzb2NpYXRpb25zLiBUaGlzIHdvdWxkIG5v dCB3b3JrIGZvciBTU1JDDQo+ID4+IG11bHRpcGxleGVkDQo+ID4+PiBzdHJlYW1zLCB0aG91Z2gu IEZvciB0aGF0LCB3ZSBjYW4gdXNlIHRoZSAiYT1zc3JjLWdyb3VwIiBhdHRyaWJ1dGUNCj4gPj4+ IGZyb20gSm9uYXRoYW4ncyBkcmFmdC4NCj4gPj4+DQo+ID4+Pj4gU1NSQyBtdWx0aXBsZXhpbmcg b2Ygc291cmNlIGFuZCByZXBhaXIgaXMgcG9zc2libGUgYW5kIHRoZQ0KPiA+Pj4+IGludGVudGlv biB3YXMgdG8gc3VwcG9ydCB0aGlzIGluIHRoZSBGcmFtZXdvcmssIGJ1dCBpZiBpdCBpcw0KPiA+ Pj4+IG5vdCByZXF1aXJlZCB3ZSBjb3VsZCBzaW1wbGlmeSBieSBzdXBwb3J0aW5nIG9ubHkgcG9y dA0KPiA+Pj4+IG11bHRpcGxleGluZy4gUG9ydCBtdWx0aXBsZXhpbmcgaXMgbW9yZSBzdHJhaWdo dGZvcndhcmRseQ0KPiA+Pj4+IGJhY2t3YXJkcy1jb21wYXRpYmxlIChJJ20gbm90IHN1cmUgd2hh dCBhbiBSVFAgcmVjZWl2ZXIgZG9lcw0KPiA+Pj4+IGlmIGl0IGlzIGV4cGVjdGluZyBqdXN0IG9u ZSBTU1JDIGFuZCBpdCBzZWVzIHR3bykuDQo+ID4+Pg0KPiA+Pj4gSWYgaXQgaGFzIGEgcGF5bG9h ZCB0aGF0IGl0IGRvZXMgbm90IHVuZGVyc3RhbmQsIGl0IHdpbGwNCj4gPj4gZGlzY2FyZCBpdC4N Cj4gPj4+IElmIGl0IHVuZGVyc3RhbmRzIGFuZCBrbm93cyB3aGF0IHRoZSBzdHJlYW0gaXMgZm9y LCBpdCB3b3VsZCBqdXN0DQo+ID4+PiB1c2UgaXQgYXMgaWYgdGhlIHN0cmVhbSB3YXMgcmVjZWl2 ZWQgZnJvbSBhIGRpZmZlcmVudCBwb3J0Lg0KPiA+Pj4NCj4gPj4+IEFyZSB0aGVyZSBhbnkgY29t bWVudHMvc3VnZ2VzdGlvbnMgZnJvbSBNTVVTSUM/DQo+ID4+Pg0KPiA+Pj4gLWFjYmVnZW4NCj4g Pj4+DQo+ID4+Pj4gLi4uTWFyaw0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+PiBPbiA0LzI0LzA5IDEw OjUzIEFNLCAiQWxpIEMuIEJlZ2VuIChhYmVnZW4pIiA8YWJlZ2VuQGNpc2NvLmNvbT4NCj4gPj4+ PiB3cm90ZToNCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+PiAJTWFyaywgQWxsLA0KPiA+ Pj4+IAkNCj4gPj4+PiAJSSBoYXZlIGEgcXVlc3Rpb24gYWJvdXQgbXVsdGlwbGV4aW5nIHRoZSBz b3VyY2UgYW5kDQo+ID4+Pj4gcmVwYWlyIHN0cmVhbXMgd2hlbiB0aGV5IGFyZSBib3RoIFJUUC4g Q3VycmVudGx5LCB3ZSBoYXZlIHRoZQ0KPiA+Pj4+IGZvbGxvd2luZyB0ZXh0Og0KPiA+Pj4+IAkN Cj4gPj4+PiAJKFN0YXJ0IG9mIHNlY3Rpb24gNCkNCj4gPj4+PiAJDQo+ID4+Pj4gCSAgIFRoZSBG RUMgRnJhbWV3b3JrIGlzIGRlc2NyaWJlZCBpbiB0ZXJtcyBvZiBhbg0KPiA+Pj4+IGFkZGl0aW9u YWwgbGF5ZXINCj4gPj4+PiAJICAgYmV0d2VlbiB0aGUgdHJhbnNwb3J0IGxheWVyIChlLmcuICBV RFAgb3IgRENDUCkgYW5kDQo+ID4+Pj4gcHJvdG9jb2xzIHJ1bm5pbmcNCj4gPj4+PiAJICAgb3Zl ciB0aGlzIHRyYW5zcG9ydCBsYXllci4gIEV4YW1wbGVzIG9mIHN1Y2gNCj4gPj4+PiBwcm90b2Nv bHMgYXJlIFJUUCwgUlRDUCwNCj4gPj4+PiAJICAgZXRjLiAgQXMgc3VjaCwgdGhlIGRhdGEgcGF0 aCBpbnRlcmZhY2UgYmV0d2VlbiB0aGUNCj4gPj4+PiBGRUMgRnJhbWV3b3JrIGFuZA0KPiA+Pj4+ IAkgICBib3RoIHVuZGVybHlpbmcgYW5kIG92ZXJseWluZyBsYXllcnMgY2FuIGJlIHRob3VnaHQN Cj4gPj4+PiBvZiBhcyBiZWluZyB0aGUNCj4gPj4+PiAJICAgc2FtZSBhcyB0aGUgc3RhbmRhcmQg aW50ZXJmYWNlIHRvIHRoZSB0cmFuc3BvcnQNCj4gPj4+PiBsYXllciAtIGkuZS4gdGhlIGRhdGEN Cj4gPj4+PiAJICAgZXhjaGFuZ2VkIGNvbnNpc3RzIG9mIGRhdGFncmFtIHBheWxvYWRzIGVhY2gN Cj4gPj4+PiBhc3NvY2lhdGVkIHdpdGggYSBzaW5nbGUNCj4gPj4+PiAJICAgdHJhbnNwb3J0IGZs b3cgaWRlbnRpZmllZCAoaW4gdGhlIGNhc2Ugb2YgVURQKSBieQ0KPiA+Pj4+IHRoZSBzdGFuZGFy ZA0KPiA+Pj4+IAkgICA1LXR1cGxlIHsgU291cmNlIElQIEFkZHJlc3MsIFNvdXJjZSBUcmFuc3Bv cnQgUG9ydCwNCj4gPj4+PiBEZXN0aW5hdGlvbiBJUA0KPiA+Pj4+IAkgICBBZGRyZXNzLCBEZXN0 aW5hdGlvbiBUcmFuc3BvcnQgUG9ydCwgVHJhbnNwb3J0DQo+ID4+Pj4gUHJvdG9jb2wgfS4gIElu IHRoZQ0KPiA+Pj4+IAkgICBjYXNlIHRoYXQgUlRQIGlzIHVzZWQgZm9yIHRoZSByZXBhaXIgZmxv d3MsIHRoZQ0KPiA+Pj4+IHNvdXJjZSBhbmQgcmVwYWlyDQo+ID4+Pj4gCSAgIGRhdGEgbWF5IGJl IG11bHRpcGxleGVkIHVzaW5nIFJUUCBvbnRvIGEgc2luZ2xlIFVEUA0KPiA+Pj4+IGZsb3cgYW5k IG11c3QNCj4gPj4+PiAJICAgY29uc2VxdWVudGx5IGJlIGRlbXVsdGlwbGV4ZWQgYXQgdGhlIHJl Y2VpdmVyLg0KPiA+Pj4+IFRoZXJlIGFyZSB2YXJpb3VzDQo+ID4+Pj4gCSAgIHdheXMgaW4gd2hp Y2ggdGhpcyBtdWx0aXBsZXhpbmcgY2FuIGJlIGRvbmUsIGZvcg0KPiA+Pj4+IGV4YW1wbGUgYXMg ZGVzY3JpYmVkDQo+ID4+Pj4gCSAgIGluIFtSRkM0NTg4XS4NCj4gPj4+PiAJDQo+ID4+Pj4gCQ0K PiA+Pj4+IAlSRkMgNDU4OCBtZW50aW9ucyB0d28gd2F5cyBvZiBtdWx0aXBsZXhpbmcgUlRQIHN0 cmVhbXMuDQo+ID4+Pj4gT25lIGlzIHNlc3Npb24gbXVsdGlwbGV4aW5nLCB3aGVyZSBzb3VyY2Ug YW5kIHJlcGFpciBSVFANCj4gPj4+PiBzdHJlYW1zIGFyZSBpbiBkaWZmZXJlbnQgUlRQIHNlc3Np b25zIChkaWZmZXJlbnQgZGVzdA0KPiA+Pj4+IGFkZHJlc3MvcG9ydCkuIEluIHRoaXMgY2FzZSwg SSBkb24ndCBoYXZlIGFueSBpc3N1ZXMsIHRoaXMNCj4gPj4+PiB3b3JrcyBiZWF1dGlmdWxseSB3 aXRoIHRoZSBmcmFtZXdvcmsuDQo+ID4+Pj4gCQ0KPiA+Pj4+IAlUaGUgb3RoZXIgb25lIGlzIFNT UkMgbXVsdGlwbGV4aW5nIHdoZXJlIHRoZSBzb3VyY2UgYW5kDQo+ID4+Pj4gcmVwYWlyIFJUUCBz dHJlYW1zIGhhdmUgZGlmZmVyZW50IFNTUkNzIGJ1dCBhcmUgdHJhbnNtaXR0ZWQNCj4gPj4+PiBp biB0aGUgc2FtZSBSVFAgc2Vzc2lvbiAod2hpY2ggaXMgYSBzaW5nbGUgVURQIGZsb3cpLiBJcyB0 aGUNCj4gPj4+PiB0ZXh0IGFib3ZlIHNheWluZyB0aGF0IHRoZSBmcmFtZXdvcmsgYWxzbyBzdXBw b3J0IHRoaXMga2luZA0KPiA+Pj4+IG9mIG11bHRpcGxleGluZz8gSW4gb3RoZXIgd29yZHMsIGlz IHVzaW5nIGEgc2luZ2xlIFVEUCBmbG93DQo+ID4+Pj4gdG8gY2Fycnkgc291cmNlICsgRkVDIGRh dGEgYWNjZXB0YWJsZSB3aGVuIHRoZXkgaGF2ZQ0KPiA+PiBzZXBhcmF0ZSBTU1JDcz8NCj4gPj4+ PiAJDQo+ID4+Pj4gCU5vdCB0aGF0IEZFQyBjb3VsZCBub3QgYmUgdXNlZCBpbiB0aGlzIHNjZW5h cmlvLCBidXQgYXMNCj4gPj4+PiBJIHJlY2FsbCB0aGUgZnJhbWV3b3JrIHJlcXVpcmVkIGRpZmZl cmVudCBVRFAgZmxvd3MgZm9yDQo+ID4+Pj4gc291cmNlIGFuZCByZXBhaXIgZmxvd3MuLi4NCj4g Pj4+PiAJDQo+ID4+Pj4gCUJSLA0KPiA+Pj4+IAktYWNiZWdlbg0KPiA+Pj4+IAkNCj4gPj4+PiAJ DQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gPj4+IEZlY2ZyYW1lIG1haWxpbmcgbGlzdA0KPiA+Pj4gRmVjZnJh bWVAaWV0Zi5vcmcNCj4gPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v ZmVjZnJhbWUNCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4gLS0gDQo+ID4+IENvbGluIFBlcmtpbnMN Cj4gPj4gaHR0cDovL2NzcGVya2lucy5vcmcvDQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBtbXVz aWMgbWFpbGluZyBsaXN0DQo+ID4gbW11c2ljQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMNCj4gDQo+IA0KPiANCj4gLS0gDQo+IENvbGlu IFBlcmtpbnMNCj4gaHR0cDovL2NzcGVya2lucy5vcmcvDQo+IA0KPiANCj4gDQo+IA0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1tdXNpYyBtYWlsaW5n IGxpc3QNCm1tdXNpY0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9tbXVzaWMNCg0K ------_=_NextPart_001_01C9C7D7.37D1C102 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0iTVMg RXhjaGFuZ2UgU2VydmVyIHZlcnNpb24gNi41Ljc2NTQuMTIiPg0KPFRJVExFPlJlOiBbTU1VU0lD XSBbRmVjZnJhbWVdIFJUUCBzdHJlYW0gbXVsdGlwbGV4aW5nIGluIHRoZSBmZWMgZnJhbWV3b3Jr PC9USVRMRT4NCjwvSEVBRD4NCjxCT0RZPg0KPCEtLSBDb252ZXJ0ZWQgZnJvbSB0ZXh0L3BsYWlu IGZvcm1hdCAtLT4NCg0KPFA+PEZPTlQgU0laRT0yPkdvb2QgcG9pbnQsIEkgYWdyZWUgd2l0aCB0 aGlzIGFzc2Vzc21lbnQuPEJSPg0KPEJSPg0KQlIsPEJSPg0KPEJSPg0KPEJSPg0KLWFjYmVnZW4g KEJiZXJyeSBjcmlwcGxlZCk8QlI+DQo8QlI+DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0t PEJSPg0KRnJvbTogUm9uaSBFdmVuICZsdDtyb24uZXZlbi50bHZAZ21haWwuY29tJmd0OzxCUj4N ClRvOiBBbGkgQy4gQmVnZW4gKGFiZWdlbik7ICdDb2xpbiBQZXJraW5zJyAmbHQ7Y3NwQGNzcGVy a2lucy5vcmcmZ3Q7PEJSPg0KQ2M6ICdXYXRzb24sIE1hcmsnICZsdDt3YXRzb25AcXVhbGNvbW0u Y29tJmd0OzsgbW11c2ljQGlldGYub3JnICZsdDttbXVzaWNAaWV0Zi5vcmcmZ3Q7OyBmZWNmcmFt ZUBpZXRmLm9yZyAmbHQ7ZmVjZnJhbWVAaWV0Zi5vcmcmZ3Q7PEJSPg0KU2VudDogVHVlIEFwciAy OCAwMDowNTowNCAyMDA5PEJSPg0KU3ViamVjdDogUkU6IFtNTVVTSUNdIFtGZWNmcmFtZV0gUlRQ IHN0cmVhbSBtdWx0aXBsZXhpbmcgaW4gdGhlIGZlYyBmcmFtZXdvcms8QlI+DQo8QlI+DQpBbGks PEJSPg0KSSB0aGluayB0aGF0IGlmIHlvdSB3b3VsZCB3YW50IHRvIHVzZSBhPXNzcmMtZ3JvdXA6 ZmVjLXhyIGFsc28gZm9yIHNlc3Npb248QlI+DQptdWx0aXBsZXhpbmcgaXQgd2lsbCBiZSBhIHNl c3Npb24gbGV2ZWwgYXR0cmlidXRlIGR1cGxpY2F0aW5nIHRoZSBhPWdyb3VwPEJSPg0KYW5kIGhh dmluZyBwcm9ibGVtIHdpdGggU1NSQyBudW1iZXIgdW5pcXVlbmVzcyBhY3Jvc3MgUlRQIHNlc3Np b25zLiBJIHRoaW5rPEJSPg0KaXQgd2lsbCBiZSBiZXN0IHRvIGhhdmUgdGhlIGE9c3NyYy1ncm91 cCBhcyBhIG1lZGlhIGxldmVsIGF0dHJpYnV0ZSBvbmx5PEJSPg0KUm9uaTxCUj4NCjxCUj4NCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPEJSPg0KRnJvbTogbW11c2ljLWJvdW5jZXNAaWV0Zi5v cmcgWzxBIEhSRUY9Im1haWx0bzptbXVzaWMtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOm1tdXNp Yy1ib3VuY2VzQGlldGYub3JnPC9BPl0gT24gQmVoYWxmIE9mPEJSPg0KQWxpIEMuIEJlZ2VuIChh YmVnZW4pPEJSPg0KU2VudDogVHVlc2RheSwgQXByaWwgMjgsIDIwMDkgMjowMCBBTTxCUj4NClRv OiBDb2xpbiBQZXJraW5zPEJSPg0KQ2M6IFdhdHNvbiwgTWFyazsgbW11c2ljQGlldGYub3JnOyBm ZWNmcmFtZUBpZXRmLm9yZzxCUj4NClN1YmplY3Q6IFJlOiBbTU1VU0lDXSBbRmVjZnJhbWVdIFJU UCBzdHJlYW0gbXVsdGlwbGV4aW5nIGluIHRoZSBmZWM8QlI+DQpmcmFtZXdvcms8QlI+DQo8QlI+ DQpBbHJpZ2h0LCBsb29rcyBsaWtlIHdlIG5lZWQgdG8gaGF2ZSBTU1JDIG11bHRpcGxleGluZyBm b3IgRkVDLCBhbmQgdGh1cywgd2U8QlI+DQpuZWVkIGdyb3VwaW5nIHN1cHBvcnQgZm9yIGl0IChh PXNzcmMtZ3JvdXApLiBJJ2xsIHJldmlzZSB0aGUgNDc1NmJpcyBhbmQ8QlI+DQpzdWJtaXQgYSBu ZXcgdmVyc2lvbiBmb3IgcmV2aWV3LjxCUj4NCjxCUj4NCk9uZSBtb3JlIHF1ZXN0aW9uLCB0aG91 Z2guIFNob3VsZCB3ZSBhbGxvdyBmb3IgJnF1b3Q7YT1zc3JjLWdyb3VwOkZFQy1YUiZxdW90OzxC Uj4NCnNlbWFudGljcyBvbmx5IGlmIFNTUkMgbXVsdGlwbGV4aW5nIGlzIHVzZWQgYW5kIG1hbmRh dGUgJnF1b3Q7YT1ncm91cDpGRUMtWFImcXVvdDs8QlI+DQpzZW1hbnRpY3MgZm9yIGV2ZXJ5dGhp bmcgZWxzZSAoZm9yIG5vbi1SVFAgZmxvd3MgYW5kIHdoZW4gc2Vzc2lvbjxCUj4NCm11bHRpcGxl eGluZyBpcyB1c2VkKT8gT3IsIHNob3VsZCB3ZSBhbHNvIGFsbG93ICZxdW90O2E9c3NyYy1ncm91 cDpGRUMtWFImcXVvdDs8QlI+DQpzZW1hbnRpY3MgZm9yIHNlc3Npb24gbXVsdGlwbGV4aW5nIGFz IHdlbGw/PEJSPg0KPEJSPg0KLWFjYmVnZW48QlI+DQo8QlI+DQomZ3Q7IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tPEJSPg0KJmd0OyBGcm9tOiBDb2xpbiBQZXJraW5zIFs8QSBIUkVGPSJtYWls dG86Y3NwQGNzcGVya2lucy5vcmciPm1haWx0bzpjc3BAY3NwZXJraW5zLm9yZzwvQT5dPEJSPg0K Jmd0OyBTZW50OiBNb25kYXksIEFwcmlsIDI3LCAyMDA5IDI6MDIgUE08QlI+DQomZ3Q7IFRvOiBB bGkgQy4gQmVnZW4gKGFiZWdlbik8QlI+DQomZ3Q7IENjOiBXYXRzb24sIE1hcms7IG1tdXNpY0Bp ZXRmLm9yZzsgZmVjZnJhbWVAaWV0Zi5vcmc8QlI+DQomZ3Q7IFN1YmplY3Q6IFJlOiBbTU1VU0lD XSBbRmVjZnJhbWVdIFJUUCBzdHJlYW0gbXVsdGlwbGV4aW5nIGluPEJSPg0KJmd0OyB0aGUgZmVj IGZyYW1ld29yazxCUj4NCiZndDs8QlI+DQomZ3Q7IFllcywgZm9yIHRoZSBwdXJwb3NlcyBmb3Ig Z3JvdXBpbmcgRkVDIGFuZCB0aGUgb3JpZ2luYWwgbWVkaWEsIGluJm5ic3A7PEJSPg0KJmd0OyBj YXNlcyB3aGVyZSB5b3UncmUgdHJ5aW5nIHRvIHJlZHVjZSBwb3J0IHVzYWdlLjxCUj4NCiZndDs8 QlI+DQomZ3Q7IENvbGluPEJSPg0KJmd0OzxCUj4NCiZndDs8QlI+DQomZ3Q7PEJSPg0KJmd0OyBP biAyNyBBcHIgMjAwOSwgYXQgMjA6MDAsIEFsaSBDLiBCZWdlbiAoYWJlZ2VuKSB3cm90ZTo8QlI+ DQomZ3Q7ICZndDsgSXMgdGhhdCBhICZxdW90O3llcyZxdW90OyBmb3Igc3NyYy1sZXZlbCBncm91 cGluZyBmb3IgRkVDPzxCUj4NCiZndDsgJmd0OzxCUj4NCiZndDsgJmd0OyAtYWNiZWdlbjxCUj4N CiZndDsgJmd0OzxCUj4NCiZndDsgJmd0OyZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08 QlI+DQomZ3Q7ICZndDsmZ3Q7IEZyb206IENvbGluIFBlcmtpbnMgWzxBIEhSRUY9Im1haWx0bzpj c3BAY3NwZXJraW5zLm9yZyI+bWFpbHRvOmNzcEBjc3BlcmtpbnMub3JnPC9BPl08QlI+DQomZ3Q7 ICZndDsmZ3Q7IFNlbnQ6IE1vbmRheSwgQXByaWwgMjcsIDIwMDkgMTA6NTQgQU08QlI+DQomZ3Q7 ICZndDsmZ3Q7IFRvOiBBbGkgQy4gQmVnZW4gKGFiZWdlbik8QlI+DQomZ3Q7ICZndDsmZ3Q7IENj OiBXYXRzb24sIE1hcms7IGZlY2ZyYW1lQGlldGYub3JnOyBtbXVzaWNAaWV0Zi5vcmc8QlI+DQom Z3Q7ICZndDsmZ3Q7IFN1YmplY3Q6IFJlOiBbRmVjZnJhbWVdIFJUUCBzdHJlYW0gbXVsdGlwbGV4 aW5nIGluIHRoZSBmZWM8QlI+DQomZ3Q7IGZyYW1ld29yazxCUj4NCiZndDsgJmd0OyZndDs8QlI+ DQomZ3Q7ICZndDsmZ3Q7IE9uIDI0IEFwciAyMDA5LCBhdCAxOToxMywgQWxpIEMuIEJlZ2VuIChh YmVnZW4pIHdyb3RlOjxCUj4NCiZndDsgJmd0OyZndDsmZ3Q7IENvcHlpbmcgTU1VU0lDIGFzIHRo aXMgaXMgcmVsZXZhbnQgdG86PEJSPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8QlI+DQomZ3Q7ICZndDsm Z3Q7Jmd0OzxCUj4NCiZndDsgJmd0OyZndDsgPEEgSFJFRj0iaHR0cDovL3d3dy5pZXRmLm9yZy9p bnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1tbXVzaWMtc2RwLXNvdXIiPmh0dHA6Ly93d3cuaWV0 Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtbW11c2ljLXNkcC1zb3VyPC9BPjxCUj4N CiZndDsgJmd0OyBjZS1hdHRyaWJ1dGVzLTAyLnR4dDxCUj4NCiZndDsgJmd0OyZndDsmZ3Q7IDxB IEhSRUY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtbW11 c2ljLSI+aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1tbXVz aWMtPC9BPjxCUj4NCiZndDsgJmd0OyZndDsmZ3Q7IHJmYzQ3NTZiaXMtMDEudHh0PEJSPg0KJmd0 OyAmZ3Q7Jmd0OyZndDs8QlI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS08QlI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgRnJvbTogV2F0c29uLCBNYXJr IFs8QSBIUkVGPSJtYWlsdG86d2F0c29uQHF1YWxjb21tLmNvbSI+bWFpbHRvOndhdHNvbkBxdWFs Y29tbS5jb208L0E+XTxCUj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBTZW50OiBGcmlkYXksIEFw cmlsIDI0LCAyMDA5IDExOjAyIEFNPEJSPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IFRvOiBBbGkg Qy4gQmVnZW4gKGFiZWdlbik7IGZlY2ZyYW1lQGlldGYub3JnPEJSPg0KJmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7IFN1YmplY3Q6IFJlOiBSVFAgc3RyZWFtIG11bHRpcGxleGluZyBpbiB0aGUgZmVjIGZy YW1ld29yazxCUj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OzxCUj4NCiZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyBBbGksPEJSPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7PEJSPg0KJmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7IFdoYXQgZG8geW91IHRoaW5rIHRoZSBGcmFtZXdvcmsgc2hvdWxkIGRvID88QlI+DQom Z3Q7ICZndDsmZ3Q7Jmd0OzxCUj4NCiZndDsgJmd0OyZndDsmZ3Q7IElNTywgd2Ugc2hvdWxkIG5v dCByZXN0cmljdCBGRUMgdG8gd29yayBvbmx5IGZvciBzZXNzaW9uPEJSPg0KJmd0OyAmZ3Q7Jmd0 OyZndDsgbXVsdGlwbGV4aW5nIChhbHRob3VnaCBJIGFncmVlIHdpdGggeW91IHRoYXQgZG9pbmcg c28gaGFzIG1hbnk8QlI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBhZHZhbnRhZ2VzKS48QlI+DQomZ3Q7 ICZndDsmZ3Q7Jmd0OzxCUj4NCiZndDsgJmd0OyZndDsmZ3Q7IEkgc2VlIGEgZmV3IGtleSByZWFz b25zIHdoeSBwZW9wbGUgd291bGQgdXNlIFNTUkM8QlI+DQomZ3Q7ICZndDsmZ3Q7IG11bHRpcGxl eGluZywgb25lPEJSPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgYmVpbmcgdG8gc2ltcGxpZnkgdGhlIHBv cnQgb3BlcmF0aW9ucyBvbiBOQVQgdHJhdmVyc2FsLiBPbmU8QlI+DQomZ3Q7ICZndDsmZ3Q7IHNl c3Npb248QlI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBtZWFucyBvbmUgaG9sZSBvbiBOQVQgZm9yIHRo ZSBSVFAgdHJhbnNwb3J0IChydGNwIHBvcnQgY2FuIGJlIHRoZTxCUj4NCiZndDsgJmd0OyZndDsm Z3Q7IHNhbWUgb3IgZGlmZmVyZW50KS4gU28sIHNvbWUgYXBwcyBtYXkgdXNlIHNzcmMgbXVsdGlw bGV4aW5nLjxCUj4NCiZndDsgJmd0OyZndDs8QlI+DQomZ3Q7ICZndDsmZ3Q7IFRoZSB0cmVuZCBp cyBjbGVhcmx5IHRvd2FyZHMgYWxsb3dpbmcgbXVsdGlwbGV4aW5nIGJ5IFJUUCBTU1JDLCB0bzxC Uj4NCiZndDsgJmd0OyZndDsgZWFzZSBOQVQgdHJhdmVyc2FsIGJ5IHJlZHVjaW5nIHRoZSBudW1i ZXIgb2YgVURQIHBvcnRzLiBCeSB0aGF0PEJSPg0KJmd0OyAmZ3Q7Jmd0OyBhcmd1bWVudCwgc2Vu ZGluZyBGRUMgZGF0YSBvbiB0aGUgc2FtZSBwb3J0IGFzIHRoZSBtZWRpYSBpdCdzPEJSPg0KJmd0 OyAmZ3Q7Jmd0OyBwcm90ZWN0aW5nIGRvZXNuJ3Qgc2VlbSBwcm9ibGVtYXRpYy4gKEkgd291bGRu J3Qgd2FudCB0byBzZWU8QlI+DQomZ3Q7ICZndDsmZ3Q7IGRpZmZlcmVudDxCUj4NCiZndDsgJmd0 OyZndDsgbWVkaWEgdHlwZXMgb24gb25lIHBvcnQsIGJ1dCB0aGlzIGlzIGNsb3NlIGVub3VnaCBy ZWxhdGVkPEJSPg0KJmd0OyAmZ3Q7Jmd0OyB0aGF0IEkgZG9uJ3Q8QlI+DQomZ3Q7ICZndDsmZ3Q7 IHNlZSBhIGJpZyBpc3N1ZSkuPEJSPg0KJmd0OyAmZ3Q7Jmd0OzxCUj4NCiZndDsgJmd0OyZndDsm Z3Q7IEkgYW0gYWJvdXQgdG8gZmluYWxpemUgdGhlIDQ3NTZiaXMgZHJhZnQgYW5kIHNvIGZhciBt eSBhc3N1bXB0aW9uPEJSPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgaGFzIGJlZW4gdGhhdCB3ZSB3b3Vs ZCBvbmx5IGRvIHNlc3Npb24gbXVsdGlwbGV4aW5nIGFuZCB1c2U8QlI+DQomZ3Q7ICZndDsmZ3Q7 Jmd0OyAmcXVvdDthPWdyb3VwJnF1b3Q7IGZvciBhc3NvY2lhdGlvbnMuIFRoaXMgd291bGQgbm90 IHdvcmsgZm9yIFNTUkM8QlI+DQomZ3Q7ICZndDsmZ3Q7IG11bHRpcGxleGVkPEJSPg0KJmd0OyAm Z3Q7Jmd0OyZndDsgc3RyZWFtcywgdGhvdWdoLiBGb3IgdGhhdCwgd2UgY2FuIHVzZSB0aGUgJnF1 b3Q7YT1zc3JjLWdyb3VwJnF1b3Q7IGF0dHJpYnV0ZTxCUj4NCiZndDsgJmd0OyZndDsmZ3Q7IGZy b20gSm9uYXRoYW4ncyBkcmFmdC48QlI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OzxCUj4NCiZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyBTU1JDIG11bHRpcGxleGluZyBvZiBzb3VyY2UgYW5kIHJlcGFpciBpcyBw b3NzaWJsZSBhbmQgdGhlPEJSPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGludGVudGlvbiB3YXMg dG8gc3VwcG9ydCB0aGlzIGluIHRoZSBGcmFtZXdvcmssIGJ1dCBpZiBpdCBpczxCUj4NCiZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyBub3QgcmVxdWlyZWQgd2UgY291bGQgc2ltcGxpZnkgYnkgc3VwcG9y dGluZyBvbmx5IHBvcnQ8QlI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgbXVsdGlwbGV4aW5nLiBQ b3J0IG11bHRpcGxleGluZyBpcyBtb3JlIHN0cmFpZ2h0Zm9yd2FyZGx5PEJSPg0KJmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7IGJhY2t3YXJkcy1jb21wYXRpYmxlIChJJ20gbm90IHN1cmUgd2hhdCBhbiBS VFAgcmVjZWl2ZXIgZG9lczxCUj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBpZiBpdCBpcyBleHBl Y3RpbmcganVzdCBvbmUgU1NSQyBhbmQgaXQgc2VlcyB0d28pLjxCUj4NCiZndDsgJmd0OyZndDsm Z3Q7PEJSPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgSWYgaXQgaGFzIGEgcGF5bG9hZCB0aGF0IGl0IGRv ZXMgbm90IHVuZGVyc3RhbmQsIGl0IHdpbGw8QlI+DQomZ3Q7ICZndDsmZ3Q7IGRpc2NhcmQgaXQu PEJSPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgSWYgaXQgdW5kZXJzdGFuZHMgYW5kIGtub3dzIHdoYXQg dGhlIHN0cmVhbSBpcyBmb3IsIGl0IHdvdWxkIGp1c3Q8QlI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyB1 c2UgaXQgYXMgaWYgdGhlIHN0cmVhbSB3YXMgcmVjZWl2ZWQgZnJvbSBhIGRpZmZlcmVudCBwb3J0 LjxCUj4NCiZndDsgJmd0OyZndDsmZ3Q7PEJSPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgQXJlIHRoZXJl IGFueSBjb21tZW50cy9zdWdnZXN0aW9ucyBmcm9tIE1NVVNJQz88QlI+DQomZ3Q7ICZndDsmZ3Q7 Jmd0OzxCUj4NCiZndDsgJmd0OyZndDsmZ3Q7IC1hY2JlZ2VuPEJSPg0KJmd0OyAmZ3Q7Jmd0OyZn dDs8QlI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgLi4uTWFyazxCUj4NCiZndDsgJmd0OyZndDsm Z3Q7Jmd0OzxCUj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OzxCUj4NCiZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyBPbiA0LzI0LzA5IDEwOjUzIEFNLCAmcXVvdDtBbGkgQy4gQmVnZW4gKGFiZWdlbikmcXVv dDsgJmx0O2FiZWdlbkBjaXNjby5jb20mZ3Q7PEJSPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IHdy b3RlOjxCUj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OzxCUj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0 OzxCUj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OzxCUj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZu YnNwOyBNYXJrLCBBbGwsPEJSPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7PEJSPg0KJmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7IEkgaGF2ZSBhIHF1ZXN0aW9uIGFib3V0IG11bHRpcGxl eGluZyB0aGUgc291cmNlIGFuZDxCUj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyByZXBhaXIgc3Ry ZWFtcyB3aGVuIHRoZXkgYXJlIGJvdGggUlRQLiBDdXJyZW50bHksIHdlIGhhdmUgdGhlPEJSPg0K Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGZvbGxvd2luZyB0ZXh0OjxCUj4NCiZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZuYnNwOzxCUj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyAoU3RhcnQgb2Yg c2VjdGlvbiA0KTxCUj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOzxCUj4NCiZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsmbmJzcDsgVGhlIEZFQyBGcmFtZXdvcmsgaXMgZGVz Y3JpYmVkIGluIHRlcm1zIG9mIGFuPEJSPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGFkZGl0aW9u YWwgbGF5ZXI8QlI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsgJm5ic3A7Jm5ic3A7IGJl dHdlZW4gdGhlIHRyYW5zcG9ydCBsYXllciAoZS5nLiZuYnNwOyBVRFAgb3IgRENDUCkgYW5kPEJS Pg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IHByb3RvY29scyBydW5uaW5nPEJSPg0KJmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyZuYnNwOyBvdmVyIHRoaXMgdHJhbnNwb3J0IGxheWVy LiZuYnNwOyBFeGFtcGxlcyBvZiBzdWNoPEJSPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IHByb3Rv Y29scyBhcmUgUlRQLCBSVENQLDxCUj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJz cDsmbmJzcDsgZXRjLiZuYnNwOyBBcyBzdWNoLCB0aGUgZGF0YSBwYXRoIGludGVyZmFjZSBiZXR3 ZWVuIHRoZTxCUj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBGRUMgRnJhbWV3b3JrIGFuZDxCUj4N CiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsmbmJzcDsgYm90aCB1bmRlcmx5aW5n IGFuZCBvdmVybHlpbmcgbGF5ZXJzIGNhbiBiZSB0aG91Z2h0PEJSPg0KJmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7IG9mIGFzIGJlaW5nIHRoZTxCUj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyAm bmJzcDsmbmJzcDsgc2FtZSBhcyB0aGUgc3RhbmRhcmQgaW50ZXJmYWNlIHRvIHRoZSB0cmFuc3Bv cnQ8QlI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgbGF5ZXIgLSBpLmUuIHRoZSBkYXRhPEJSPg0K Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyZuYnNwOyBleGNoYW5nZWQgY29uc2lz dHMgb2YgZGF0YWdyYW0gcGF5bG9hZHMgZWFjaDxCUj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBh c3NvY2lhdGVkIHdpdGggYSBzaW5nbGU8QlI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsg Jm5ic3A7Jm5ic3A7IHRyYW5zcG9ydCBmbG93IGlkZW50aWZpZWQgKGluIHRoZSBjYXNlIG9mIFVE UCkgYnk8QlI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgdGhlIHN0YW5kYXJkPEJSPg0KJmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyZuYnNwOyA1LXR1cGxlIHsgU291cmNlIElQIEFk ZHJlc3MsIFNvdXJjZSBUcmFuc3BvcnQgUG9ydCw8QlI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsg RGVzdGluYXRpb24gSVA8QlI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsgJm5ic3A7Jm5i c3A7IEFkZHJlc3MsIERlc3RpbmF0aW9uIFRyYW5zcG9ydCBQb3J0LCBUcmFuc3BvcnQ8QlI+DQom Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsgUHJvdG9jb2wgfS4mbmJzcDsgSW4gdGhlPEJSPg0KJmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyZuYnNwOyBjYXNlIHRoYXQgUlRQIGlzIHVzZWQg Zm9yIHRoZSByZXBhaXIgZmxvd3MsIHRoZTxCUj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBzb3Vy Y2UgYW5kIHJlcGFpcjxCUj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsmbmJz cDsgZGF0YSBtYXkgYmUgbXVsdGlwbGV4ZWQgdXNpbmcgUlRQIG9udG8gYSBzaW5nbGUgVURQPEJS Pg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGZsb3cgYW5kIG11c3Q8QlI+DQomZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmbmJzcDsgJm5ic3A7Jm5ic3A7IGNvbnNlcXVlbnRseSBiZSBkZW11bHRpcGxleGVk IGF0IHRoZSByZWNlaXZlci48QlI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgVGhlcmUgYXJlIHZh cmlvdXM8QlI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsgJm5ic3A7Jm5ic3A7IHdheXMg aW4gd2hpY2ggdGhpcyBtdWx0aXBsZXhpbmcgY2FuIGJlIGRvbmUsIGZvcjxCUj4NCiZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyBleGFtcGxlIGFzIGRlc2NyaWJlZDxCUj4NCiZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZuYnNwOyAmbmJzcDsmbmJzcDsgaW4gW1JGQzQ1ODhdLjxCUj4NCiZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZuYnNwOzxCUj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOzxCUj4NCiZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyBSRkMgNDU4OCBtZW50aW9ucyB0d28gd2F5cyBvZiBtdWx0 aXBsZXhpbmcgUlRQIHN0cmVhbXMuPEJSPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IE9uZSBpcyBz ZXNzaW9uIG11bHRpcGxleGluZywgd2hlcmUgc291cmNlIGFuZCByZXBhaXIgUlRQPEJSPg0KJmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7IHN0cmVhbXMgYXJlIGluIGRpZmZlcmVudCBSVFAgc2Vzc2lvbnMg KGRpZmZlcmVudCBkZXN0PEJSPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGFkZHJlc3MvcG9ydCku IEluIHRoaXMgY2FzZSwgSSBkb24ndCBoYXZlIGFueSBpc3N1ZXMsIHRoaXM8QlI+DQomZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsgd29ya3MgYmVhdXRpZnVsbHkgd2l0aCB0aGUgZnJhbWV3b3JrLjxCUj4N CiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOzxCUj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZu YnNwOyBUaGUgb3RoZXIgb25lIGlzIFNTUkMgbXVsdGlwbGV4aW5nIHdoZXJlIHRoZSBzb3VyY2Ug YW5kPEJSPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IHJlcGFpciBSVFAgc3RyZWFtcyBoYXZlIGRp ZmZlcmVudCBTU1JDcyBidXQgYXJlIHRyYW5zbWl0dGVkPEJSPg0KJmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7IGluIHRoZSBzYW1lIFJUUCBzZXNzaW9uICh3aGljaCBpcyBhIHNpbmdsZSBVRFAgZmxvdyku IElzIHRoZTxCUj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyB0ZXh0IGFib3ZlIHNheWluZyB0aGF0 IHRoZSBmcmFtZXdvcmsgYWxzbyBzdXBwb3J0IHRoaXMga2luZDxCUj4NCiZndDsgJmd0OyZndDsm Z3Q7Jmd0OyBvZiBtdWx0aXBsZXhpbmc/IEluIG90aGVyIHdvcmRzLCBpcyB1c2luZyBhIHNpbmds ZSBVRFAgZmxvdzxCUj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyB0byBjYXJyeSBzb3VyY2UgKyBG RUMgZGF0YSBhY2NlcHRhYmxlIHdoZW4gdGhleSBoYXZlPEJSPg0KJmd0OyAmZ3Q7Jmd0OyBzZXBh cmF0ZSBTU1JDcz88QlI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmbmJzcDs8QlI+DQomZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsmbmJzcDsgTm90IHRoYXQgRkVDIGNvdWxkIG5vdCBiZSB1c2VkIGluIHRo aXMgc2NlbmFyaW8sIGJ1dCBhczxCUj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBJIHJlY2FsbCB0 aGUgZnJhbWV3b3JrIHJlcXVpcmVkIGRpZmZlcmVudCBVRFAgZmxvd3MgZm9yPEJSPg0KJmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7IHNvdXJjZSBhbmQgcmVwYWlyIGZsb3dzLi4uPEJSPg0KJmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jm5ic3A7PEJSPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7IEJSLDxC Uj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyAtYWNiZWdlbjxCUj4NCiZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZuYnNwOzxCUj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOzxCUj4NCiZn dDsgJmd0OyZndDsmZ3Q7Jmd0OzxCUj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OzxCUj4NCiZndDsg Jmd0OyZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPEJSPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgRmVjZnJhbWUgbWFpbGluZyBsaXN0PEJSPg0KJmd0 OyAmZ3Q7Jmd0OyZndDsgRmVjZnJhbWVAaWV0Zi5vcmc8QlI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyA8 QSBIUkVGPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ZlY2ZyYW1lIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ZlY2ZyYW1lPC9BPjxCUj4NCiZn dDsgJmd0OyZndDs8QlI+DQomZ3Q7ICZndDsmZ3Q7PEJSPg0KJmd0OyAmZ3Q7Jmd0OzxCUj4NCiZn dDsgJmd0OyZndDsgLS08QlI+DQomZ3Q7ICZndDsmZ3Q7IENvbGluIFBlcmtpbnM8QlI+DQomZ3Q7 ICZndDsmZ3Q7IDxBIEhSRUY9Imh0dHA6Ly9jc3BlcmtpbnMub3JnLyI+aHR0cDovL2NzcGVya2lu cy5vcmcvPC9BPjxCUj4NCiZndDsgJmd0OyZndDs8QlI+DQomZ3Q7ICZndDsmZ3Q7PEJSPg0KJmd0 OyAmZ3Q7Jmd0OzxCUj4NCiZndDsgJmd0OyZndDs8QlI+DQomZ3Q7ICZndDsgX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188QlI+DQomZ3Q7ICZndDsgbW11c2lj IG1haWxpbmcgbGlzdDxCUj4NCiZndDsgJmd0OyBtbXVzaWNAaWV0Zi5vcmc8QlI+DQomZ3Q7ICZn dDsgPEEgSFJFRj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMi Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljPC9BPjxCUj4NCiZn dDs8QlI+DQomZ3Q7PEJSPg0KJmd0OzxCUj4NCiZndDsgLS08QlI+DQomZ3Q7IENvbGluIFBlcmtp bnM8QlI+DQomZ3Q7IDxBIEhSRUY9Imh0dHA6Ly9jc3BlcmtpbnMub3JnLyI+aHR0cDovL2NzcGVy a2lucy5vcmcvPC9BPjxCUj4NCiZndDs8QlI+DQomZ3Q7PEJSPg0KJmd0OzxCUj4NCiZndDs8QlI+ DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxCUj4NCm1t dXNpYyBtYWlsaW5nIGxpc3Q8QlI+DQptbXVzaWNAaWV0Zi5vcmc8QlI+DQo8QSBIUkVGPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYyI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWM8L0E+PEJSPg0KPEJSPg0KPC9GT05UPg0KPC9Q Pg0KDQo8L0JPRFk+DQo8L0hUTUw+ ------_=_NextPart_001_01C9C7D7.37D1C102-- From tme@multicasttech.com Tue Apr 28 02:11: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 0AAD63A6924; Tue, 28 Apr 2009 02:11:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.942 X-Spam-Level: X-Spam-Status: No, score=-102.942 tagged_above=-999 required=5 tests=[AWL=-0.343, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 xBZRsCYRALEW; Tue, 28 Apr 2009 02:11:55 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 00BE63A6910; Tue, 28 Apr 2009 02:11:55 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 170FE3AFAB2D; Tue, 28 Apr 2009 05:13:14 -0400 (EDT) Message-Id: From: Marshall Eubanks To: Colin Perkins In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 28 Apr 2009 05:13:13 -0400 References: <04CAD96D4C5A3D48B1919248A8FE0D54092C815D@xmb-sjc-215.amer.cisco.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C817F@xmb-sjc-215.amer.cisco.com> <8F9DD728-5AE9-4394-9BDD-4EDBFB92E4A5@csperkins.org> <2FA6A311-8B9F-41FF-B9A3-04EB1E399732@americafree.tv> X-Mailer: Apple Mail (2.930.3) Cc: mmusic@ietf.org, fecframe@ietf.org Subject: Re: [MMUSIC] [Fecframe] RTP stream multiplexing in the fec framework 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, 28 Apr 2009 09:11:56 -0000 On Apr 27, 2009, at 6:09 PM, Colin Perkins wrote: > On 27 Apr 2009, at 22:23, Marshall Eubanks wrote: >> On Apr 27, 2009, at 4:52 PM, Colin Perkins wrote: >>> On 27 Apr 2009, at 20:02, Marshall Eubanks wrote: >>>> On Apr 27, 2009, at 1:53 PM, Colin Perkins wrote: >>>>> On 24 Apr 2009, at 19:13, Ali C. Begen (abegen) wrote: >>> ... >>>> >>>>>> IMO, we should not restrict FEC to work only for session >>>>>> multiplexing (although I agree with you that doing so has many >>>>>> advantages). >>>>>> >>>>>> I see a few key reasons why people would use SSRC multiplexing, >>>>>> one being to simplify the port operations on NAT traversal. One >>>>>> session means one hole on NAT for the RTP transport (rtcp port >>>>>> can be the same or different). So, some apps may use ssrc >>>>>> multiplexing. >>>>> >>>>> The trend is clearly towards allowing multiplexing by RTP SSRC, >>>>> to ease NAT traversal by reducing the number of UDP ports. By >>>>> that argument, sending FEC data on the same port as the media >>>>> it's protecting doesn't seem problematic. (I wouldn't want to >>>>> see different media types on one port, but this is close enough >>>>> related that I don't see a big issue). >>>> >>>> If someone wanted to use SSRC multiplexing in a audio or video >>>> conference with multiplexing (audio) or multiple displays >>>> (video), and then wanted to apply SSRC multiplexed FEC to that >>>> (say for sources on lossy wireless links), isn't there a danger >>>> that non-FEC aware receivers would not do the right thing with >>>> the FEC ? >>> >>> >>> I don't think so. Non-FEC aware receivers would see an unknown >>> payload type, which they should ignore. What's your specific >>> concern with that scenario? >> >> I am trying to understand all of the worries expressed here >> >> >> Separate audio and video streams SHOULD NOT be carried in a single >> RTP session and demultiplexed based on the payload type or SSRC >> fields. Interleaving packets with different RTP media types but >> using the same SSRC would introduce several problems: >> >> Using a different SSRC for each medium but sending them in the same >> RTP session would avoid the first three problems but not the last two >> >> >> So, to be clear, what is proposed is to send the FEC repair stream >> with one source address and port, but a different SSRC and payload >> type (from the original stream) ? > > As I understand it, this is being proposed as one option for sending > FEC data (with the ability to send the FEC on a separate port as the > other option). In terms of the last two points in section 5.2 of RFC > 3550, an RTP mixer that understands FEC can make use of the FEC data > when mixing (and if it doesn't understand the FEC, the quality is > degraded, but the mixer still works); and the only reason to use > SSRC multiplexing here is specifically to use the same network path > for the FEC and media, making the last point moot. > OK, this works for me if this aligns with Ali's thinking. Marshall > -- > Colin Perkins > http://csperkins.org/ > > > > From jonathan@vidyo.com Tue Apr 28 07:19: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 E2F773A70C8; Tue, 28 Apr 2009 07:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[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 v1F4-nAIWF87; Tue, 28 Apr 2009 07:19:26 -0700 (PDT) Received: from mx1.myoutlookonline.com (mx1.myoutlookonline.com [64.95.72.238]) by core3.amsl.com (Postfix) with ESMTP id 748E23A684E; Tue, 28 Apr 2009 07:19:26 -0700 (PDT) Received: from be150.mail.lan ([10.110.20.150]) by mx1.myoutlookonline.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Apr 2009 10:20:47 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 28 Apr 2009 10:19:35 -0400 Message-ID: <6B55710E7F51AD4B93F336052113B85F8C7899@be150.mail.lan> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D54092C88A0@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] [Fecframe] RTP stream multiplexing in the fec framework Thread-Index: AcnHe3o2t9udAcKdTMOM0tgu2HypagAD0DegACBgO0A= References: <04CAD96D4C5A3D48B1919248A8FE0D54092C815D@xmb-sjc-215.amer.cisco.com><04CAD96D4C5A3D48B1919248A8FE0D54092C817F@xmb-sjc-215.amer.cisco.com><8F9DD728-5AE9-4394-9BDD-4EDBFB92E4A5@csperkins.org><04CAD96D4C5A3D48B1919248A8FE0D54092C86BE@xmb-sjc-215.amer.cisco.com><7D1B0D8B-BCFE-463B-B2F4-E627729A198D@csperkins.org> <04CAD96D4C5A3D48B1919248A8FE0D54092C88A0@xmb-sjc-215.amer.cisco.com> From: "Jonathan Lennox" To: "Ali C. Begen (abegen)" , "Colin Perkins" X-OriginalArrivalTime: 28 Apr 2009 14:20:47.0277 (UTC) FILETIME=[86290DD0:01C9C80C] Cc: "Watson, Mark" , mmusic@ietf.org, fecframe@ietf.org Subject: Re: [MMUSIC] [Fecframe] RTP stream multiplexing in the fec framework 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, 28 Apr 2009 14:19:28 -0000 In the source-attributes draft, ssrc-group: semantics are only defined within a given RTP session. To associate multiple RTP sessions sessions you need to use group: semantics instead. So, yes, the former. --=20 Jonathan Lennox Vidyo, Inc jonathan@vidyo.com > -----Original Message----- > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > Sent: Monday, April 27, 2009 7:00 PM > To: Colin Perkins > Cc: Watson, Mark; mmusic@ietf.org; fecframe@ietf.org > Subject: Re: [MMUSIC] [Fecframe] RTP stream multiplexing in the fec > framework >=20 > Alright, looks like we need to have SSRC multiplexing for FEC, and > thus, we need grouping support for it (a=3Dssrc-group). I'll revise = the > 4756bis and submit a new version for review. >=20 > One more question, though. Should we allow for "a=3Dssrc-group:FEC-XR" > semantics only if SSRC multiplexing is used and mandate = "a=3Dgroup:FEC- > XR" semantics for everything else (for non-RTP flows and when session > multiplexing is used)? Or, should we also allow = "a=3Dssrc-group:FEC-XR" > semantics for session multiplexing as well? >=20 > -acbegen >=20 > > -----Original Message----- > > From: Colin Perkins [mailto:csp@csperkins.org] > > Sent: Monday, April 27, 2009 2:02 PM > > To: Ali C. Begen (abegen) > > Cc: Watson, Mark; mmusic@ietf.org; fecframe@ietf.org > > Subject: Re: [MMUSIC] [Fecframe] RTP stream multiplexing in > > the fec framework > > > > Yes, for the purposes for grouping FEC and the original media, in > > cases where you're trying to reduce port usage. > > > > Colin > > > > > > > > On 27 Apr 2009, at 20:00, Ali C. Begen (abegen) wrote: > > > Is that a "yes" for ssrc-level grouping for FEC? > > > > > > -acbegen > > > > > >> -----Original Message----- > > >> From: Colin Perkins [mailto:csp@csperkins.org] > > >> Sent: Monday, April 27, 2009 10:54 AM > > >> To: Ali C. Begen (abegen) > > >> Cc: Watson, Mark; fecframe@ietf.org; mmusic@ietf.org > > >> Subject: Re: [Fecframe] RTP stream multiplexing in the fec > > framework > > >> > > >> On 24 Apr 2009, at 19:13, Ali C. Begen (abegen) wrote: > > >>> Copying MMUSIC as this is relevant to: > > >>> > > >>> > > >> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-sour > > > ce-attributes-02.txt > > >>> http://www.ietf.org/internet-drafts/draft-ietf-mmusic- > > >>> rfc4756bis-01.txt > > >>> > > >>>> -----Original Message----- > > >>>> From: Watson, Mark [mailto:watson@qualcomm.com] > > >>>> Sent: Friday, April 24, 2009 11:02 AM > > >>>> To: Ali C. Begen (abegen); fecframe@ietf.org > > >>>> Subject: Re: RTP stream multiplexing in the fec framework > > >>>> > > >>>> Ali, > > >>>> > > >>>> What do you think the Framework should do ? > > >>> > > >>> IMO, we should not restrict FEC to work only for session > > >>> multiplexing (although I agree with you that doing so has many > > >>> advantages). > > >>> > > >>> I see a few key reasons why people would use SSRC > > >> multiplexing, one > > >>> being to simplify the port operations on NAT traversal. One > > >> session > > >>> means one hole on NAT for the RTP transport (rtcp port can be the > > >>> same or different). So, some apps may use ssrc multiplexing. > > >> > > >> The trend is clearly towards allowing multiplexing by RTP SSRC, to > > >> ease NAT traversal by reducing the number of UDP ports. By that > > >> argument, sending FEC data on the same port as the media it's > > >> protecting doesn't seem problematic. (I wouldn't want to see > > >> different > > >> media types on one port, but this is close enough related > > >> that I don't > > >> see a big issue). > > >> > > >>> I am about to finalize the 4756bis draft and so far my assumption > > >>> has been that we would only do session multiplexing and use > > >>> "a=3Dgroup" for associations. This would not work for SSRC > > >> multiplexed > > >>> streams, though. For that, we can use the "a=3Dssrc-group" > attribute > > >>> from Jonathan's draft. > > >>> > > >>>> SSRC multiplexing of source and repair is possible and the > > >>>> intention was to support this in the Framework, but if it is > > >>>> not required we could simplify by supporting only port > > >>>> multiplexing. Port multiplexing is more straightforwardly > > >>>> backwards-compatible (I'm not sure what an RTP receiver does > > >>>> if it is expecting just one SSRC and it sees two). > > >>> > > >>> If it has a payload that it does not understand, it will > > >> discard it. > > >>> If it understands and knows what the stream is for, it would just > > >>> use it as if the stream was received from a different port. > > >>> > > >>> Are there any comments/suggestions from MMUSIC? > > >>> > > >>> -acbegen > > >>> > > >>>> ...Mark > > >>>> > > >>>> > > >>>> On 4/24/09 10:53 AM, "Ali C. Begen (abegen)" > > >>>> wrote: > > >>>> > > >>>> > > >>>> > > >>>> Mark, All, > > >>>> > > >>>> I have a question about multiplexing the source and > > >>>> repair streams when they are both RTP. Currently, we have the > > >>>> following text: > > >>>> > > >>>> (Start of section 4) > > >>>> > > >>>> The FEC Framework is described in terms of an > > >>>> additional layer > > >>>> between the transport layer (e.g. UDP or DCCP) and > > >>>> protocols running > > >>>> over this transport layer. Examples of such > > >>>> protocols are RTP, RTCP, > > >>>> etc. As such, the data path interface between the > > >>>> FEC Framework and > > >>>> both underlying and overlying layers can be thought > > >>>> of as being the > > >>>> same as the standard interface to the transport > > >>>> layer - i.e. the data > > >>>> exchanged consists of datagram payloads each > > >>>> associated with a single > > >>>> transport flow identified (in the case of UDP) by > > >>>> the standard > > >>>> 5-tuple { Source IP Address, Source Transport Port, > > >>>> Destination IP > > >>>> Address, Destination Transport Port, Transport > > >>>> Protocol }. In the > > >>>> case that RTP is used for the repair flows, the > > >>>> source and repair > > >>>> data may be multiplexed using RTP onto a single UDP > > >>>> flow and must > > >>>> consequently be demultiplexed at the receiver. > > >>>> There are various > > >>>> ways in which this multiplexing can be done, for > > >>>> example as described > > >>>> in [RFC4588]. > > >>>> > > >>>> > > >>>> RFC 4588 mentions two ways of multiplexing RTP streams. > > >>>> One is session multiplexing, where source and repair RTP > > >>>> streams are in different RTP sessions (different dest > > >>>> address/port). In this case, I don't have any issues, this > > >>>> works beautifully with the framework. > > >>>> > > >>>> The other one is SSRC multiplexing where the source and > > >>>> repair RTP streams have different SSRCs but are transmitted > > >>>> in the same RTP session (which is a single UDP flow). Is the > > >>>> text above saying that the framework also support this kind > > >>>> of multiplexing? In other words, is using a single UDP flow > > >>>> to carry source + FEC data acceptable when they have > > >> separate SSRCs? > > >>>> > > >>>> Not that FEC could not be used in this scenario, but as > > >>>> I recall the framework required different UDP flows for > > >>>> source and repair flows... > > >>>> > > >>>> BR, > > >>>> -acbegen > > >>>> > > >>>> > > >>>> > > >>>> > > >>> _______________________________________________ > > >>> Fecframe mailing list > > >>> Fecframe@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/fecframe > > >> > > >> > > >> > > >> -- > > >> Colin Perkins > > >> http://csperkins.org/ > > >> > > >> > > >> > > >> > > > _______________________________________________ > > > mmusic mailing list > > > mmusic@ietf.org > > > https://www.ietf.org/mailman/listinfo/mmusic > > > > > > > > -- > > Colin Perkins > > http://csperkins.org/ > > > > > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From csp@csperkins.org Wed Apr 29 10:44:26 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 404EC28C159; Wed, 29 Apr 2009 10:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=-0.717, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_6CONS_WORD=0.356] 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 tyZ1W4H9XuUr; Wed, 29 Apr 2009 10:44:24 -0700 (PDT) Received: from anchor-msapost-2.mail.demon.net (anchor-msapost-2.mail.demon.net [195.173.77.165]) by core3.amsl.com (Postfix) with ESMTP id 318C13A7187; Wed, 29 Apr 2009 10:44:24 -0700 (PDT) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=mangole.lan) by anchor-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1LzDqr-0005K4-kQ; Wed, 29 Apr 2009 17:45:46 +0000 Message-Id: From: Colin Perkins To: Roni Even In-Reply-To: <49f61dae.0c07560a.64b2.ffffb27d@mx.google.com> Content-Type: multipart/alternative; boundary=Apple-Mail-6-726930915 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 29 Apr 2009 18:45:35 +0100 References: <238382595265324EA50F6134BB42DCAF03B18B96@FRVELSMBS22.ad2.ad.alcatel.com> <49f61dae.0c07560a.64b2.ffffb27d@mx.google.com> X-Mailer: Apple Mail (2.930.3) Cc: avt@ietf.org, mmusic@ietf.org Subject: Re: [MMUSIC] [AVT] Multiple Feedback Targets in " http://tools.ietf.org/html/draft-ietf-avt-rtcpssm-18" 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, 29 Apr 2009 17:44:26 -0000 --Apple-Mail-6-726930915 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Roni, The signalling aspects could certainly go to MMUSIC, and are probably =20= not too difficult to address. The proposal also involves some =20 potentially significant changes to the RTCP architecture, which should =20= be considered in AVT (although hopefully as additional documents =20 rather than being folded into the - already long overdue - rtcpssm =20 draft). Cheers, Colin On 27 Apr 2009, at 22:01, Roni Even wrote: > Tom, > I think this question should go to mmusic. What you are trying to do =20= > here is to define semantics for the content of a RTCP flow pointing =20= > to different devices. The m-line or the RTCP line in SDP does not =20 > address what is the content of the stream that will go in the RTP =20 > session. RFC 4796 addresses the media content issue but you are =20 > looking for something similar to the RTCP attribute. This may =20 > require a new parameter to the rtcp attribute. > You will also need to look at backward interoperability where the =20 > receiver will not understand this semantics and may change the RTCP =20= > message to the wrong address. > > The example for the content attribute was to specify to video m-=20 > lines one with screen capture as a video stream and the other from a =20= > camera. SDP does not define the behavior of the receiver if it =20 > receives two m-lines of the same media type and can only support =20 > one. It is not clear which one he will chose (first or second). The =20= > work on capability negotiation tries to address this issue. > > Roni Even > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf =20 > Of VAN CAENEGEM Tom > Sent: Friday, April 24, 2009 1:36 PM > To: avt@ietf.org > Subject: [AVT] Multiple Feedback Targets in " = http://tools.ietf.org/html/draft-ietf-avt-rtcpssm-18=20 > " > > > Hi, > > I have two questions/comments mostly regarding the RTCP-SSM draft = (http://tools.ietf.org/html/draft-ietf-avt-rtcpssm-18=20 > ). The background of my questions is the use case of "broadcast =20 > channels" in an IPTV context, where the channels are distributed =20 > over IP multicast (SSM). In this context, the concept of feedback =20 > target(s) is obviously very useful, and actually necessary given =20 > today's restrictions with multicast in upstream in the "WAN". > > For the IPTV use case, it also makes sense to have multiple feedback =20= > targets, each responsible for a subset of RTP receivers, because of =20= > the large number of RTP receivers involved (100.000s is possible). =20 > The way to signal this by means of SDP is that each local subset of =20= > RTP receivers sees a different IP address in the "a=3Drtcp: =20 > "portnumber" IN IP4 "IP address" line. So, multiple "localised" =20 > FT is covered by the draft IMO. > > However, in that case, the maximum bandwidth that can be used for =20 > RTCP reporting by RTP receivers only needs to be determined by the =20 > size of the local group of RTP receivers (sending RTCP to the same =20 > localised Feedback Target), especially in the summary FB model. But =20= > in my interpretation of the architecture, the actual RTCP bandwith =20 > limit information can only be retrieved by the RTP receivers from =20 > the information sent by the distribution source in the ssm session. =20= > Either by refected RTCP reports from RTP receivers (not a feasible =20 > solution for the given use case) or from a RSI message -in the =20 > summary FB model- indicating the session size or explicitly the RTCP =20= > reporting bandwidth limit. The fact is that this information is sent =20= > to ALL RTP receivers, which may be reporting to different Feedback =20 > targets where each Feedback target is collecting RTCP messages from =20= > a different number of RTP receivers, and hence may have different =20 > "requirements" for total RTCP reporting bandwidth limit. My =20 > question is whether local Feedback targets have been considered with =20= > respect to this issue? > > My second question again has to do with multiple feedback targets =20 > for the same use case. > > In the IPTV use case for rtcpssm, Feedback Targets can also be used =20= > as retransmission sources (RFC 4588) and in = http://tools.ietf.org/html/draft-versteeg-avt-rapid-synchronization-for-rt= p-03=20 > , the feedback target architecture is used to allow fast acquisition =20= > of SSM RTP sessions. The draft proposes that a "burst source" is co-=20= > located with the FT which transmits unicast data (starting with a =20 > random access point of the video channel) from a cache that holds =20 > the most recent data distributed over the RTP SSM. It does transmit =20= > the RTP packets at an accelerated speed, allowing the RTP receiver =20 > to join the SSM after some time. > > The idea I would like to bring forward is to allow separate Feedback =20= > Targets for the same RTP receiver (population): one Feedback target =20= > acts as RTP retransmission server = (seehttp://tools.ietf.org/html/draft-versteeg-avt-rapid-synchronization-fo= r-rtp-03)=20 > and collects RTCP FB messages, while the other Feedback Target is =20 > solely "responsible" for the non RTCP-FB messages, such as RTCP XR =20 > messages. I realise this idea is not necessarily linked with the =20 > rtcp-ssm draft, but IMO only for a massive scale application that =20 > makes use of RTP and leverages rtcp ssm such a separation is =20 > justified. The possibility for separation of the monitoring service =96=20= > associated with a server function basically responsible for =20 > collecting RTCP receiver reports for the purpose of monitoring- and =20= > the retransmission service requiring a server function that is =20 > responsible for processing and responding to RTCP FB messages, is =20 > driven from the point of view of server function optimisation =20 > (different requirements on the server platform). > > In terms of signaling two Feedback Targets, we could make use of the =20= > following lines: > > a=3Drtcp:40001 IN IP4 192.0.2.1 (This is for retransmission) > a=3Drtcp-fb:96 nack > a=3Drtcp:40001 IN IP4 192.0.2.2 (This is for XR collection) > > > However, that is probably quite ambiguous..? > Furthermore I also realise such a solution introduces other =20 > questions than just signaling syntax including the fact that we may =20= > need guiding rules on how RTCP reports are issued by the RTP =20 > receiver with two RTCP targets in place, as in the example above. =20 > The new RFC 5506 is certainly helpful here, but this is probably not =20= > sufficient. > > Comments appreciated on this idea. > > Kind regards, > Tom Van Caenegem > > > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt --=20 Colin Perkins http://csperkins.org/ --Apple-Mail-6-726930915 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Roni,

The = signalling aspects could certainly go to MMUSIC, and are probably not = too difficult to address. The proposal also involves some potentially = significant changes to the RTCP architecture, which should be considered = in AVT (although hopefully as additional documents rather than being = folded into the - already long overdue - rtcpssm draft). 

Cheers,
Colin



On = 27 Apr 2009, at 22:01, Roni Even wrote:
I = think this question should go to mmusic. What you are trying to do here = is to define semantics for the content of a RTCP flow pointing to = different devices. The m-line or the RTCP line in SDP does not address = what is the content of the stream that will go in the RTP session. =  RFC 4796 addresses the media content issue but you are looking for = something similar to the RTCP attribute. This may require a new = parameter to the rtcp attribute.
You will also need to look at = backward interoperability where the receiver will not understand this = semantics and may change the RTCP message to the wrong = address.
 
The example for the content = attribute was to specify to video m-lines one with screen capture as a = video stream and the other from a camera. SDP does not define the = behavior of the receiver if it receives two m-lines of the same media = type and can only support one. It is not clear which one he will chose = (first or second). The work on capability negotiation tries to address = this issue.
 
Roni = Even
From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of VAN CAENEGEM Tom
Sent: Friday, April 24, 2009 1:36 = PM
To: avt@ietf.org
Subject: [AVT] Multiple Feedback = Targets in " 
 

). The = background of my questions is the use case of "broadcast channels" in an = IPTV context, where the channels are distributed over IP multicast = (SSM). In this context, the concept of feedback target(s) is obviously = very useful, and actually necessary given today's restrictions with = multicast in upstream in the "WAN".

For the IPTV use case, it also = makes sense to have multiple feedback targets, each responsible for a = subset of RTP receivers, because of the large number of RTP receivers = involved (100.000s is possible). The way to signal this by means of SDP = is that each local subset of RTP receivers sees a different IP address = in the "a=3Drtcp: "portnumber" IN IP4 "IP = address"  line.  = So, multiple "localised" FT  is covered by the draft = IMO.

My second question again has to do = with multiple feedback targets for the same use = case.

 , the feedback target architecture is used to allow fast = acquisition of SSM RTP sessions. The draft proposes that  a "burst = source" is co-located with the FT which transmits unicast data (starting = with a random access point of the video channel) from a cache that holds = the most recent data distributed over the RTP SSM. It does transmit the = RTP packets at an accelerated speed, allowing the RTP receiver to join = the SSM after some time.

The idea I would like to bring forward = is to allow separate Feedback Targets  for the same RTP receiver = (population): one Feedback target acts as RTP retransmission server = (see) and collects RTCP FB messages, while the other Feedback = Target is solely "responsible" for the non RTCP-FB messages, such as = RTCP XR messages. I realise this idea is not necessarily linked = with  the rtcp-ssm draft, but IMO only for a massive scale = application that makes use of RTP and leverages rtcp ssm such a = separation is justified. The possibility for separation of the = monitoring service =96associated with a server = function basically responsible for collecting RTCP receiver reports for = the purpose of monitoring- and the retransmission service requiring a = server function that is responsible for processing and responding to = RTCP FB messages, is driven from the point of view of server function = optimisation (different requirements on the server = platform).

In terms of signaling two Feedback = Targets, we could make use of the following = lines:

a=3Drtcp:40001 = IN IP4 192.0.2.1 (This is for retransmission) 
a=3Drtcp-fb:96 nack 
a=3Drtcp:40001 IN IP4 192.0.2.2 (This is for XR = collection)

 

However, that is probably quite = ambiguous..? 
Furthermore I also realise such a solution = introduces other questions than just signaling syntax including the fact = that we may need guiding rules on how RTCP reports are issued by the RTP = receiver with two RTCP targets in place, as in the example above. The = new RFC 5506 is certainly helpful here, but this is probably not = sufficient.

Comments appreciated on this = idea.

 
Tom Van Caenegem

 

Audio/Video Transport Working = Group
avt@ietf.org




-- 
Colin Perkins
http://csperkins.org/



= --Apple-Mail-6-726930915-- From root@core3.amsl.com Thu Apr 30 10:30:02 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 E15783A6F66; Thu, 30 Apr 2009 10:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090430173001.E15783A6F66@core3.amsl.com> Date: Thu, 30 Apr 2009 10:30:01 -0700 (PDT) Cc: mmusic@ietf.org Subject: [MMUSIC] I-D Action:draft-ietf-mmusic-rfc4756bis-02.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: Thu, 30 Apr 2009 17:30:02 -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-02.txt Pages : 12 Date : 2009-04-30 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-02.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-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-04-30101955.I-D@ietf.org> --NextPart-- From abegen@cisco.com Thu Apr 30 10:33:59 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 3900C3A720B for ; Thu, 30 Apr 2009 10:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.367 X-Spam-Level: X-Spam-Status: No, score=-6.367 tagged_above=-999 required=5 tests=[AWL=0.232, 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 QiIHvKx4HroR for ; Thu, 30 Apr 2009 10:33:58 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 3B3A228C328 for ; Thu, 30 Apr 2009 10:32:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,274,1238976000"; d="scan'208";a="295983777" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 30 Apr 2009 17:33:55 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3UHXtcF022861 for ; Thu, 30 Apr 2009 10:33:55 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3UHXtsu018852 for ; Thu, 30 Apr 2009 17:33:55 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Apr 2009 10:33:55 -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: Thu, 30 Apr 2009 10:32:57 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D5409349084@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-ietf-mmusic-rfc4756bis-02 Thread-Index: AcnJuBO2kYzpSjNIQL6Z9SBIdJX+6QAAQGLQ From: "Ali C. Begen (abegen)" To: X-OriginalArrivalTime: 30 Apr 2009 17:33:55.0395 (UTC) FILETIME=[D60B0930:01C9C9B9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2624; t=1241112835; x=1241976835; c=relaxed/simple; s=sjdkim1004; 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-02=20 |Sender:=20; bh=dsBktEchWQcgWl3OuI/ZQuMRWy+A6PeMzovZSMiZqKI=; b=cYmom5UIdTXry0hYwnjy7fYnt2bru6Es2p3C98uwHyQfTbY2TmOsbHx99p J1fDyplVVj8i2bNLG3vxKbUdQgxyDVdD/e/V5KGYIa1wLA1JzDAkbXEvMQFO zRsL42XDBXKdnLuo650aXTH5+fDsaQ1qoxyd/SBdpp7P6lbxX/Eiw=; Authentication-Results: sj-dkim-1; header.From=abegen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: [MMUSIC] FW: New Version Notification for draft-ietf-mmusic-rfc4756bis-02 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, 30 Apr 2009 17:33:59 -0000 VGhlIG91dGNvbWUgYWZ0ZXIgdGhlIGxhc3QgSUVURiBNTVVTSUMgc2Vzc2lvbiB3YXMgdG8gV0dM QyB0aGlzIGRvY3VtZW50LiBIb3dldmVyLCBzaW5jZSB0aGVuIHdlIGFsc28gZGVjaWRlZCB0byBz dXBwb3J0IGdyb3VwaW5nIG9mIFNTUkMtbXVsdGlwbGV4ZWQgUlRQIHN0cmVhbXMuIFRoaXMgZG9j dW1lbnQgYWRkcyBzdXBwb3J0IGZvciB0aGlzLiBJIGFsc28gdXBkYXRlZCB0aGUgb2ZmZXIvYW5z d2VyIG1vZGVsIHNlY3Rpb24gdG8gZGVhbCB3aXRoIDQ3NTYtY29tcGF0aWJsZSBlbmRwb2ludHMg bW9yZSBzbW9vdGhseS4NCmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0 LWlldGYtbW11c2ljLXJmYzQ3NTZiaXMtMDIudHh0DQoNCk5vdGUgdGhhdCB0aGlzIGRvY3VtZW50 IGludGVuZHMgdG8gb2Jzb2xldGUgNDc1Ni4NCg0KQ29tbWVudHMgYXJlIHdlbGNvbWUuIA0KDQot YWNiZWdlbg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSUVURiBJLUQgU3Vi bWlzc2lvbiBUb29sIFttYWlsdG86aWRzdWJtaXNzaW9uQGlldGYub3JnXSANClNlbnQ6IFRodXJz ZGF5LCBBcHJpbCAzMCwgMjAwOSAxMDoyMCBBTQ0KVG86IEFsaSBDLiBCZWdlbiAoYWJlZ2VuKQ0K U3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRmLW1tdXNpYy1y ZmM0NzU2YmlzLTAyIA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1pZXRmLW1tdXNp Yy1yZmM0NzU2YmlzLTAyLnR4dCBoYXMgYmVlbiBzdWNjZXNzZnVseSBzdWJtaXR0ZWQgYnkgQWxp IEJlZ2VuIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBk cmFmdC1pZXRmLW1tdXNpYy1yZmM0NzU2YmlzDQpSZXZpc2lvbjoJIDAyDQpUaXRsZToJCSBGb3J3 YXJkIEVycm9yIENvcnJlY3Rpb24gR3JvdXBpbmcgU2VtYW50aWNzIGluIFNlc3Npb24gRGVzY3Jp cHRpb24gUHJvdG9jb2wNCkNyZWF0aW9uX2RhdGU6CSAyMDA5LTA0LTMwDQpXRyBJRDoJCSBtbXVz aWMNCk51bWJlcl9vZl9wYWdlczogMTINCg0KQWJzdHJhY3Q6DQpUaGUgU2Vzc2lvbiBEZXNjcmlw dGlvbiBQcm90b2NvbCAoU0RQKSBzdXBwb3J0cyBncm91cGluZyBtZWRpYSBsaW5lcy4NClNEUCBh bHNvIGhhcyBzZW1hbnRpY3MgZGVmaW5lZCBmb3IgZ3JvdXBpbmcgdGhlIGFzc29jaWF0ZWQgc291 cmNlIGFuZA0KRm9yd2FyZCBFcnJvciBDb3JyZWN0aW9uIChGRUMpLWJhc2VkIHJlcGFpciBmbG93 cy4gIEhvd2V2ZXIsIHRoZQ0Kc2VtYW50aWNzIHRoYXQgd2FzIGRlZmluZWQgaW4gUkZDIDQ3NTYg Z2VuZXJhbGx5IGZhaWwgdG8gcHJvdmlkZSB0aGUNCnNwZWNpZmljIGdyb3VwaW5nIHJlbGF0aW9u c2hpcHMgYmV0d2VlbiB0aGUgc291cmNlIGFuZCByZXBhaXIgZmxvd3MNCndoZW4gdGhlcmUgYXJl IG1vcmUgdGhhbiBvbmUgc291cmNlIGFuZC9vciByZXBhaXIgZmxvd3MgaW4gdGhlIHNhbWUNCmdy b3VwLiAgRnVydGhlcm1vcmUsIHRoZSBleGlzdGluZyBzZW1hbnRpY3MgZG9lcyBub3Qgc3VwcG9y dA0KZGVzY3JpYmluZyBhZGRpdGl2ZSByZXBhaXIgZmxvd3MuICBUaGlzIGRvY3VtZW50IGFkZHJl c3NlcyB0aGVzZQ0KaXNzdWVzIGJ5IGludHJvZHVjaW5nIG5ldyBGRUMgZ3JvdXBpbmcgc2VtYW50 aWNzLiAgU1NSQy1sZXZlbA0KZ3JvdXBpbmcgc2VtYW50aWNzIGlzIGFsc28gaW50cm9kdWNlZCBp biB0aGlzIGRvY3VtZW50IGZvciBSZWFsLXRpbWUNClRyYW5zcG9ydCBQcm90b2NvbCAoUlRQKSBz dHJlYW1zIHVzaW5nIFNTUkMgbXVsdGlwbGV4aW5nLg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IA0KDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0Lg0KDQoNCg==