From csp@csperkins.org Sat Jul 2 05:25:16 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96FCD11E8281 for ; Sat, 2 Jul 2011 05:25:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3aAEpjMTLybo for ; Sat, 2 Jul 2011 05:25:15 -0700 (PDT) Received: from lon1-msapost-2.mail.demon.net (lon1-msapost-2.mail.demon.net [195.173.77.181]) by ietfa.amsl.com (Postfix) with ESMTP id 3A35F11E827F for ; Sat, 2 Jul 2011 05:25:15 -0700 (PDT) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.26]) by lon1-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1QczG6-0000HE-ZY; Sat, 02 Jul 2011 12:25:14 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: Date: Sat, 2 Jul 2011 13:25:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9B818D56-DF88-45F4-B761-70698123510C@csperkins.org> References: <7C8D947749B24396AA011FB286CC69E1@china.huawei.com> <489F755BBD284D18AE9AD47F17317B6F@china.huawei.com> To: "Van Caenegem, Tom (Tom)" X-Mailer: Apple Mail (2.1084) Cc: 'IETF AVTCore WG' Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-rtp-04 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2011 12:25:16 -0000 On 30 Jun 2011, at 10:47, Van Caenegem, Tom (Tom) wrote: > Qin, > See below > Tom > -----Original Message----- > From: Qin Wu [mailto:bill.wu@huawei.com]=20 > Sent: donderdag 30 juni 2011 11:36 > To: Van Caenegem, Tom (Tom); Colin Perkins > Cc: 'IETF AVTCore WG'; Roni Even; Qin Wu > Subject: Re: [AVTCORE] Comments on = draft-ietf-avtcore-feedback-supression-rtp-04 >=20 > Hi, > ----- Original Message ----- > From: "Van Caenegem, Tom (Tom)" > To: "Qin Wu" ; "Colin Perkins" > Cc: "'IETF AVTCore WG'" ; "Roni Even" = > Sent: Thursday, June 30, 2011 5:07 PM > Subject: RE: [AVTCORE] Comments on = draft-ietf-avtcore-feedback-supression-rtp-04 >=20 >=20 > Qin, > See below, >=20 >=20 > [Qin]: Okay, maybe there is some ambiguity on describing media source = behavior. I will add some texts to get consistent with=20 > Intermediary behavior of suppressing feedback described in the = previous paragraph. > The proposed text may look like: > " > Alternatively, the media source may directly monitor the amount of > feedback reports it receives from downstream. If the media source = notices the loss itself, then it > may send a NACK downstream towards the receivers to suppress = feedback. If the media source > receives a NACK from another system, it should redistribute that = NACK > to all other systems that would not otherwise receive it. An = example > of this is RTCP-SSM in simple feedback model [RFC5760], where the > distribution source reflects NACKs to other systems. If the media = source > receives a NACK from another system, but, for some > reason, cannot redistribute that NACK, then it may send a = third-party > loss report to the systems that were unable to receive the NACK, and > won't receive the NACK via other means. An example would be a > distribution source using RTCP-SSM in Distribution Source Feedback > Summary model [RFC5760]. > " >=20 >=20 > Tom: the "for some reason" will have to be clarified. I also do not = understand: "may send a third-party loss report to the systems that = were unable to receive the NACK" Based on the rationale provided by = Colin why one may not always simply forward/redistribute NACKs, this is = not a matter of systems being "UNABLE" to receive the NACK. They are = always able, it is just a decision from the intermediate to not FW the = received NACKs. >=20 > [Qin]: No, basic rationale is prevent the receivers know who send = NACK.=20 > In SSM case, the rationale is Distribution Source Feedback Summary = model does not allow the NACK to be forwarded downstream. >=20 > Tom: In RFC 5760 for SSM in FB summary mode, the DS might also forward = RTCP feedback messages and transmit them in the SSM session, when this = is explicitly signaled. It is a service/deployment decision whether = NACKs are hence FW-ed or not, and there may be good reasons to not do = so, but saying that such systems(i..e RTP Rx) are unable to receive the = NACK is not justified IMO. It might be clearer to say that the receivers don't get the NACKs, since = they're not forwarded by the distribution source. Colin > [Qin]: I agree we should follow RFC5760 architecture. But I am not = sure the example I give in the section 6.1.1 conflict with RFC5760 = architecture. > The architecture I bulild looks like this: > Suppose there are 100 RTP receivers, in these receivers, 50 RTP = receivers belong to DS A, 50 RTP receivers belong to DS B, DS A may be = placed at the upstream > of DS B or DS A is adjacent to DS B at the same level, Do this kind = architecture conflict with RFC5760? If yes, please point out. >=20 > Tom: a DS represents the source/RTP sender of the SSM RTP session. = Receivers send out NACKs related to packet loss in a particular SSM RTP = session. If a receiver is not "belonging" to a DS X (I guess you mean = ..is not receiving packets from that DS X), then why would you implement = some kind of FB suppression for such receiver(s) within the SSM RTP = session that is sourced by that DS X ??? >=20 > [Qin]: What I am saying here each DS has its own coverage for = receivers. You can implement FB suppression for each DS. But you are not = necessary to prevent interaction between DS. > Anyway since you or other folks may think this multiple DS case = introduce ambiguity and complexity, I will remove this case from the = draft, Is that okay with you? >=20 > Tom: Fine!=20 >=20 > Regards! > -Qin > ----- Original Message ----- > From: "Colin Perkins" > To: "Van Caenegem, Tom (Tom)" > Cc: "Qin Wu" ; "'IETF AVTCore WG'" = ; "Roni Even" > Sent: Tuesday, June 21, 2011 10:07 PM > Subject: Re: [AVTCORE] Comments on = draft-ietf-avtcore-feedback-supression-rtp-04 >=20 >=20 > On 21 Jun 2011, at 10:29, Van Caenegem, Tom (Tom) wrote: >> Hi, >>=20 >> as promised, these are comments I have on the draft " RTCP Extension = for Third-party Loss Report" >>=20 >> -IMO the draft does not provide a good rationale on the use case for = sending this new report. The section 3 (protocol overview) says: >>=20 >> "If an intermediary receives a NACK from another system, it should = redistribute that NACK to all other systems that would not otherwise = receive it. An example of this is RTCP-SSM in simple feedback model = [RFC5760], where the distribution source reflects NACKs to other = systems. =20 >> If an intermediary receives a NACK from another system, but, for some = reason, cannot redistribute that NACK, then it may send a third-party = loss report to the systems that were unable to receive the NACK, and = won't receive the NACK via other means. An example would be a = distribution source using RTCP-SSM in Distribution Source Feedback = Summary model [RFC5760]." >>=20 >> My questions:=20 >>=20 >> -why would the intermediary not be able or capable to send the = received NACK to the "systems" that were unable to receive the NACK, = whereas it would be able or capable to send the 3rd party loss report to = those same "systems"?=20 >=20 > Because the intermediary is trying to hide the identity or existence = of those systems, and cannot forward the NACK from them without = revealing that information >=20 >> -The DS in RTCP-SSM operating in FB summary mode is mentioned as an = example for a case where a NACK cannnot be forwarded. Why is this? = RFC5760 does not prevent a DS to foward the NACK (see the RFC 5760 and = my quote from that RFC in = "draft-vancaenegem-avtcore-retransmission-for-ssm-00" >=20 > RFC 5760 allows the NACK to be forwarded, but this would cause the = other receivers to become aware of, and keep state for, the participant = that sent the NACK. If a third-party loss report is used, the other = receivers don't become aware of the participant that signalled the loss, = they just know that the loss occurred.=20 >=20 >> -This section 3 makes a distinction between an intermediate that does = check the RTP stream for missing packets itself, and an intermediate = that does not, but still the behaviour in terms of FW-ing the NACKs = received from other "systems" is exactly the same. Why make this = distinction then? >>=20 >> I still have an outstanding comment which has not been resolved yet. = The section 6.1. and 6.1.1. take RFC 5760 as use case architectures, but = section 6.1.1. talks about two distribution sources, whereas RFC 5760 = only defined ONE SINGLE DS. Please clarify this. >=20 > [Qin]: two distribution sources means we have two levels of SSM = communication, one distribution souce is placed at the upstream of the = other distribution source. > two distribution sources case is just one exmaple to discuss how to = use new report when there are multiple middleboxs or intermediaries = between media source and the receivers.=20 > The middlebox can be distribution source and can be other = intermediary. >=20 >>=20 >> Regards >> Tom >> _______________________________________________ >> Audio/Video Transport Core Maintenance >> avt@ietf.org >> https://www.ietf.org/mailman/listinfo/avt >=20 >=20 >=20 > --=20 > Colin Perkins > http://csperkins.org/ >=20 >=20 > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt --=20 Colin Perkins http://csperkins.org/ From Even.roni@huawei.com Sun Jul 3 09:54:44 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3361521F8735 for ; Sun, 3 Jul 2011 09:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LmVn-ADWDh8m for ; Sun, 3 Jul 2011 09:54:43 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id CA9BF21F85A4 for ; Sun, 3 Jul 2011 09:54:42 -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 <0LNR00F1MOB4UF@szxga04-in.huawei.com> for avt@ietf.org; Mon, 04 Jul 2011 00:54:40 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LNR0083EOB4MI@szxga04-in.huawei.com> for avt@ietf.org; Mon, 04 Jul 2011 00:54:40 +0800 (CST) Received: from windows8d787f9 (bzq-79-176-43-124.red.bezeqint.net [79.176.43.124]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LNR009QDOASZ5@szxml12-in.huawei.com>; Mon, 04 Jul 2011 00:54:40 +0800 (CST) Date: Sun, 03 Jul 2011 19:51:54 +0300 From: Roni Even In-reply-to: To: 'Qin Wu' , "'Van Caenegem, Tom (Tom)'" , 'Colin Perkins' Message-id: <00a201cc39a1$92ec2850$b8c478f0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: Acw3CRX8/+IkGX4QRhCkQgqHuTZXWQCmGlfg References: <7C8D947749B24396AA011FB286CC69E1@china.huawei.com> <489F755BBD284D18AE9AD47F17317B6F@china.huawei.com> Cc: 'IETF AVTCore WG' Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-rtp-04 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 16:54:44 -0000 Hi, I think that we can look at the following use cases. 1. The single DS /FT in a Distribution Source Feedback Summary Model. The case mentioned by Collin using 3rd party report to hide the topology. 2. A single DS with multiple FT. See RFC 5760 section 3 in the FT definition. In this case I am not sure if there is a DS without any FT with multiple FTs or one DS with a FT and multiple FTs sending unicast RTCP feedback to the FT co-located with the DS. Maybe we need to look at both cases. 3. RFC 5760 talks about single DS. Is there a use case for multiple DSs where each DS is in a different SSRC space with one media source transmitting to all. Is there such a case, maybe if there is some hierarchy which may look like a DS which is also an RTP mixer or translator. Does these use cases make sense? Are there others Regards Roni > -----Original Message----- > From: Qin Wu [mailto:bill.wu@huawei.com] > Sent: Thursday, June 30, 2011 12:36 PM > To: Van Caenegem, Tom (Tom); Colin Perkins > Cc: 'IETF AVTCore WG'; Roni Even; Qin Wu > Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-feedback- > supression-rtp-04 > > Hi, > ----- Original Message ----- > From: "Van Caenegem, Tom (Tom)" > To: "Qin Wu" ; "Colin Perkins" > Cc: "'IETF AVTCore WG'" ; "Roni Even" > > Sent: Thursday, June 30, 2011 5:07 PM > Subject: RE: [AVTCORE] Comments on draft-ietf-avtcore-feedback- > supression-rtp-04 > > > Qin, > See below, > > > [Qin]: Okay, maybe there is some ambiguity on describing media source > behavior. I will add some texts to get consistent with > Intermediary behavior of suppressing feedback described in the previous > paragraph. > The proposed text may look like: > " > Alternatively, the media source may directly monitor the amount of > feedback reports it receives from downstream. If the media source > notices the loss itself, then it > may send a NACK downstream towards the receivers to suppress > feedback. If the media source > receives a NACK from another system, it should redistribute that > NACK > to all other systems that would not otherwise receive it. An > example > of this is RTCP-SSM in simple feedback model [RFC5760], where the > distribution source reflects NACKs to other systems. If the media > source > receives a NACK from another system, but, for some > reason, cannot redistribute that NACK, then it may send a third- > party > loss report to the systems that were unable to receive the NACK, and > won't receive the NACK via other means. An example would be a > distribution source using RTCP-SSM in Distribution Source Feedback > Summary model [RFC5760]. > " > > > Tom: the "for some reason" will have to be clarified. I also do not > understand: "may send a third-party loss report to the systems that > were unable to receive the NACK" Based on the rationale provided by > Colin why one may not always simply forward/redistribute NACKs, this is > not a matter of systems being "UNABLE" to receive the NACK. They are > always able, it is just a decision from the intermediate to not FW the > received NACKs. > > [Qin]: No, basic rationale is prevent the receivers know who send > NACK. > In SSM case, the rationale is Distribution Source Feedback Summary > model does not allow the NACK to be forwarded downstream. > > [Qin]: I agree we should follow RFC5760 architecture. But I am not sure > the example I give in the section 6.1.1 conflict with RFC5760 > architecture. > The architecture I bulild looks like this: > Suppose there are 100 RTP receivers, in these receivers, 50 RTP > receivers belong to DS A, 50 RTP receivers belong to DS B, DS A may be > placed at the upstream > of DS B or DS A is adjacent to DS B at the same level, Do this kind > architecture conflict with RFC5760? If yes, please point out. > > Tom: a DS represents the source/RTP sender of the SSM RTP session. > Receivers send out NACKs related to packet loss in a particular SSM RTP > session. If a receiver is not "belonging" to a DS X (I guess you mean > ..is not receiving packets from that DS X), then why would you > implement some kind of FB suppression for such receiver(s) within the > SSM RTP session that is sourced by that DS X ??? > > [Qin]: What I am saying here each DS has its own coverage for > receivers. You can implement FB suppression for each DS. But you are > not necessary to prevent interaction between DS. > Anyway since you or other folks may think this multiple DS case > introduce ambiguity and complexity, I will remove this case from the > draft, Is that okay with you? > > > Regards! > -Qin > ----- Original Message ----- > From: "Colin Perkins" > To: "Van Caenegem, Tom (Tom)" > Cc: "Qin Wu" ; "'IETF AVTCore WG'" ; > "Roni Even" > Sent: Tuesday, June 21, 2011 10:07 PM > Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-feedback- > supression-rtp-04 > > > On 21 Jun 2011, at 10:29, Van Caenegem, Tom (Tom) wrote: > > Hi, > > > > as promised, these are comments I have on the draft " RTCP Extension > for Third-party Loss Report" > > > > -IMO the draft does not provide a good rationale on the use case for > sending this new report. The section 3 (protocol overview) says: > > > > "If an intermediary receives a NACK from another system, it should > redistribute that NACK to all other systems that would not otherwise > receive it. An example of this is RTCP-SSM in simple feedback model > [RFC5760], where the distribution source reflects NACKs to other > systems. > > If an intermediary receives a NACK from another system, but, for some > reason, cannot redistribute that NACK, then it may send a third-party > loss report to the systems that were unable to receive the NACK, and > won't receive the NACK via other means. An example would be a > distribution source using RTCP-SSM in Distribution Source Feedback > Summary model [RFC5760]." > > > > My questions: > > > > -why would the intermediary not be able or capable to send the > received NACK to the "systems" that were unable to receive the NACK, > whereas it would be able or capable to send the 3rd party loss report > to those same "systems"? > > Because the intermediary is trying to hide the identity or existence of > those systems, and cannot forward the NACK from them without revealing > that information > > > -The DS in RTCP-SSM operating in FB summary mode is mentioned as an > example for a case where a NACK cannnot be forwarded. Why is this? > RFC5760 does not prevent a DS to foward the NACK (see the RFC 5760 and > my quote from that RFC in "draft-vancaenegem-avtcore-retransmission- > for-ssm-00" > > RFC 5760 allows the NACK to be forwarded, but this would cause the > other receivers to become aware of, and keep state for, the participant > that sent the NACK. If a third-party loss report is used, the other > receivers don't become aware of the participant that signalled the > loss, they just know that the loss occurred. > > > -This section 3 makes a distinction between an intermediate that does > check the RTP stream for missing packets itself, and an intermediate > that does not, but still the behaviour in terms of FW-ing the NACKs > received from other "systems" is exactly the same. Why make this > distinction then? > > > > I still have an outstanding comment which has not been resolved yet. > The section 6.1. and 6.1.1. take RFC 5760 as use case architectures, > but section 6.1.1. talks about two distribution sources, whereas RFC > 5760 only defined ONE SINGLE DS. Please clarify this. > > [Qin]: two distribution sources means we have two levels of SSM > communication, one distribution souce is placed at the upstream of the > other distribution source. > two distribution sources case is just one exmaple to discuss how to use > new report when there are multiple middleboxs or intermediaries between > media source and the receivers. > The middlebox can be distribution source and can be other intermediary. > > > > > Regards > > Tom > > _______________________________________________ > > Audio/Video Transport Core Maintenance > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt > > > > -- > Colin Perkins > http://csperkins.org/ > From magnus.westerlund@ericsson.com Tue Jul 5 03:54:21 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08B5321F8779 for ; Tue, 5 Jul 2011 03:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.497 X-Spam-Level: X-Spam-Status: No, score=-106.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vrh-L8+L0MD8 for ; Tue, 5 Jul 2011 03:54:20 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 10F3221F8776 for ; Tue, 5 Jul 2011 03:54:19 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-5d-4e12ed56b413 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 86.84.09774.65DE21E4; Tue, 5 Jul 2011 12:54:14 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Tue, 5 Jul 2011 12:54:14 +0200 Message-ID: <4E12ED55.2060301@ericsson.com> Date: Tue, 5 Jul 2011 12:54:13 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: IETF AVTCore WG X-Enigmail-Version: 1.1.1 Content-Type: multipart/mixed; boundary="------------000805030003080409000003" X-Brightmail-Tracker: AAAAAA== Subject: [AVTCORE] Fwd: I-D Action: draft-westerlund-avtcore-multistream-and-simulcast-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 10:54:21 -0000 --------------000805030003080409000003 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit WG, As an individual Bo Burman and I have written this internet draft that discusses multistream and simulcast issues and proposes a set of extensions to resolve the issues. Feedback is much appreciated. Cheers Magnus --------------000805030003080409000003 Content-Type: message/rfc822; name="I-D Action: draft-westerlund-avtcore-multistream-and-simulcast-00_txt.eml" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="I-D Action: draft-westerlund-avtcore-multistream-and-simulca"; filename*1="st-00_txt.eml" Received: from mailgw7.ericsson.se (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.95) with Microsoft SMTP Server id 8.3.137.0; Tue, 5 Jul 2011 01:00:04 +0200 Received: from mail.ietf.org (mail.ietf.org [64.170.98.30]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 06.D4.25859.3F5421E4; Tue, 5 Jul 2011 01:00:04 +0200 (CEST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 723B021F8795; Mon, 4 Jul 2011 15:59:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF13221F8790 for ; Mon, 4 Jul 2011 15:59:37 -0700 (PDT) Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CbA7HXQk3YE1 for ; Mon, 4 Jul 2011 15:59:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F11421F85BA for ; Mon, 4 Jul 2011 15:59:37 -0700 (PDT) From: "internet-drafts@ietf.org" To: "i-d-announce@ietf.org" Sender: "i-d-announce-bounces@ietf.org" Date: Tue, 5 Jul 2011 00:59:37 +0200 Subject: I-D Action: draft-westerlund-avtcore-multistream-and-simulcast-00.txt Thread-Topic: I-D Action: draft-westerlund-avtcore-multistream-and-simulcast-00.txt Thread-Index: Acw6niPdHWobMNCZTbCKE6pftHYosA== Message-ID: <20110704225937.11011.55431.idtracker@ietfa.amsl.com> List-Help: List-Subscribe: , List-Unsubscribe: , Reply-To: "internet-drafts@ietf.org" Accept-Language: en-US Content-Language: en-US X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AuthSource: esessmw0247.eemea.ericsson.se X-MS-Has-Attach: X-Auto-Response-Suppress: All X-MS-TNEF-Correlator: x-auditid: c1b4fb30-b7ba2ae000006503-ba-4e1245f33644 x-brightmail-tracker: AAAAAA== errors-to: i-d-announce-bounces@ietf.org x-virus-scanned: amavisd-new at amsl.com x-mailman-version: 2.1.12 list-post: list-archive: list-id: Internet Draft Announcements only x-beenthere: i-d-announce@ietf.org x-spam-level: x-spam-status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] x-spam-score: -102.59 x-spam-flag: NO delivered-to: i-d-announce@ietfa.amsl.com x-original-to: i-d-announce@ietfa.amsl.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : RTP Multiple Stream Sessions and Simulcast Author(s) : Magnus Westerlund Bo Burman Filename : draft-westerlund-avtcore-multistream-and-simulcast-00.tx= t Pages : 60 Date : 2011-07-04 RTP has always been a protocol that supports multiple participants each sending their own media streams in an RTP session. Unfortunately many implementations aimed only at point to point voice over IP with a single source in each end-point. Even client implementations aimed at video conferences have often been built with the assumption around central mixers that only deliver a single media stream per media type. Thus any application that wants to allow for more advance usage where multiple media streams are sent and received by an end-point has a problem with legacy. This issue is analyzed, and RTP clarifications and signalling extensions are proposed to handle this issue. A related issue is how to perform simulcast, in the meaning of sending multiple encodings or representations of the same media source, when using RTP for media transport. This is further analyzed and possible solutions discussed and we arrive at a conclusion for session multiplexing of simulcast versions. We also found a number of related issues when having multiple streams and simulcast. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-westerlund-avtcore-multistream-an= d-simulcast-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-westerlund-avtcore-multistream-and= -simulcast-00.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --------------000805030003080409000003-- From internet-drafts@ietf.org Wed Jul 6 05:05:05 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2AB721F86F7; Wed, 6 Jul 2011 05:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.599 X-Spam-Level: X-Spam-Status: No, score=-98.599 tagged_above=-999 required=5 tests=[AWL=-3.976, BAYES_00=-2.599, FRT_STOCK1=3.988, FRT_STOCK2=3.988, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w9xFbWToRH-O; Wed, 6 Jul 2011 05:05:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72FEA21F85EC; Wed, 6 Jul 2011 05:05:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110706120505.15053.98212.idtracker@ietfa.amsl.com> Date: Wed, 06 Jul 2011 05:05:05 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-idms-01.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 12:05:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenanc= e Working Group of the IETF. Title : RTCP for inter-destination media synchronization Author(s) : Ray van Brandenburg Hans M. Stokking M. Oskar van Deventer Omar A. Niamut Fabian A. Walraven Ishan Vaishnavi Fernando Boronat Mario Montagud Filename : draft-ietf-avtcore-idms-01.txt Pages : 24 Date : 2011-07-06 This document gives information on an RTCP Packet Type and RTCP XR Block Type including associated SDP parameters for inter-destination media synchronization (IDMS). The RTCP XR Block Type, registered with IANA based on an ETSI specification, is used to collect media play- out information from participants in a group playing-out (watching, listening, etc.) a specific RTP media stream. The RTCP packet type specified by this document is used to distribute a summary of the collected information so that the participants can synchronize play- out. Typical applications for IDMS are social TV, shared service control (i.e. applications where two or more geographically separated users are watching a media stream together), distance learning, network quiz shows, multi-playing online games, etc. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avtcore-idms-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtcore-idms-01.txt From wwwrun@rfc-editor.org Tue Jul 5 09:18:20 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C600011E8109 for ; Tue, 5 Jul 2011 09:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.257 X-Spam-Level: X-Spam-Status: No, score=-102.257 tagged_above=-999 required=5 tests=[AWL=0.343, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VJvHiJYGetRk for ; Tue, 5 Jul 2011 09:18:20 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id 32AE011E80B9 for ; Tue, 5 Jul 2011 09:18:20 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id E460F98C4EF; Tue, 5 Jul 2011 09:18:19 -0700 (PDT) To: jo@acm.org, stewe@stewe.org, sato652@oki.com, carsten.burmeister@eu.panasonic.com, jose.rey@eu.panasonic.com, gonzalo.camarillo@ericsson.com, rjsparks@nostrum.com, keith.drage@alcatel-lucent.com, even.roni@huawei.com From: RFC Errata System Message-Id: <20110705161819.E460F98C4EF@rfc-editor.org> Date: Tue, 5 Jul 2011 09:18:19 -0700 (PDT) X-Mailman-Approved-At: Wed, 06 Jul 2011 13:48:09 -0700 Cc: avt@ietf.org, rfc-editor@rfc-editor.org Subject: [AVTCORE] [Technical Errata Reported] RFC4585 (2853) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 16:18:20 -0000 The following errata report has been submitted for RFC4585, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4585&eid=2853 -------------------------------------- Type: Technical Reported by: Ali Begen Section: 4.2 Original Text ------------- OLD: rtcp-fb-param = SP "app" [SP byte-string] / SP token [SP byte-string] / ; empty NEW: rtcp-fb-param = [ SP "app" [SP byte-string] / SP token [SP byte-string] ] OLD: rtcp-fb-ack-param = SP "rpsi" / SP "app" [SP byte-string] / SP token [SP byte-string] / ; empty NEW: rtcp-fb-ack-param = [ SP "rpsi" / SP "app" [SP byte-string] / SP token [SP byte-string] ] OLD: rtcp-fb-nack-param = SP "pli" / SP "sli" / SP "rpsi" / SP "app" [SP byte-string] / SP token [SP byte-string] / ; empty NEW: rtcp-fb-nack-param = [ SP "pli" / SP "sli" / SP "rpsi" / SP "app" [SP byte-string] / SP token [SP byte-string] ] Corrected Text -------------- Notes ----- During the AUTH48 of RFC 6285, we discovered a bug with the ABNF syntax in RFC 4585. The original ABNF in Section 4.2 (as noted above) is incorrect ("/ ;empty" is not a valid ABNF - RFC 5234 does not allow empty alternates). The NEW text intends to fix it. There are 3 places where the same change should be applied (changes are identical). Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4585 (draft-ietf-avt-rtcp-feedback-11) -------------------------------------- Title : Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF) Publication Date : July 2006 Author(s) : J. Ott, S. Wenger, N. Sato, C. Burmeister, J. Rey Category : PROPOSED STANDARD Source : Audio/Video Transport Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG From bill.wu@huawei.com Wed Jul 6 23:10:44 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A35521F88CD for ; Wed, 6 Jul 2011 23:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.786 X-Spam-Level: X-Spam-Status: No, score=-3.786 tagged_above=-999 required=5 tests=[AWL=-1.187, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XjTb2KyyuN63 for ; Wed, 6 Jul 2011 23:10:43 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 9877721F88C8 for ; Wed, 6 Jul 2011 23:10:42 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LNY00J7992UOM@szxga05-in.huawei.com> for avt@ietf.org; Thu, 07 Jul 2011 14:08:54 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LNY0023Z92UKA@szxga05-in.huawei.com> for avt@ietf.org; Thu, 07 Jul 2011 14:08:54 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml207-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ABU53113; Thu, 07 Jul 2011 14:08:53 +0800 (CST) Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 07 Jul 2011 14:08:47 +0800 Received: from w53375q (10.138.41.76) by smtpscn.huawei.com (10.82.67.31) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 07 Jul 2011 14:08:52 +0800 Date: Thu, 07 Jul 2011 14:08:52 +0800 From: Qin Wu X-Originating-IP: [10.138.41.76] To: Colin Perkins , "Van Caenegem, Tom (Tom)" Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6090 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-CFilter-Loop: Reflected References: <7C8D947749B24396AA011FB286CC69E1@china.huawei.com> <489F755BBD284D18AE9AD47F17317B6F@china.huawei.com> <9B818D56-DF88-45F4-B761-70698123510C@csperkins.org> Cc: 'IETF AVTCore WG' Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-rtp-04 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 06:10:44 -0000 Hi, ----- Original Message ----- From: "Colin Perkins" To: "Van Caenegem, Tom (Tom)" Cc: "Qin Wu" ; "'IETF AVTCore WG'" Sent: Saturday, July 02, 2011 8:25 PM Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-rtp-04 On 30 Jun 2011, at 10:47, Van Caenegem, Tom (Tom) wrote: > Qin, > See below > Tom > -----Original Message----- > From: Qin Wu [mailto:bill.wu@huawei.com] > Sent: donderdag 30 juni 2011 11:36 > To: Van Caenegem, Tom (Tom); Colin Perkins > Cc: 'IETF AVTCore WG'; Roni Even; Qin Wu > Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-rtp-04 > > Hi, > ----- Original Message ----- > From: "Van Caenegem, Tom (Tom)" > To: "Qin Wu" ; "Colin Perkins" > Cc: "'IETF AVTCore WG'" ; "Roni Even" > Sent: Thursday, June 30, 2011 5:07 PM > Subject: RE: [AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-rtp-04 > > > Qin, > See below, > > > [Qin]: Okay, maybe there is some ambiguity on describing media source behavior. I will add some texts to get consistent with > Intermediary behavior of suppressing feedback described in the previous paragraph. > The proposed text may look like: > " > Alternatively, the media source may directly monitor the amount of > feedback reports it receives from downstream. If the media source notices the loss itself, then it > may send a NACK downstream towards the receivers to suppress feedback. If the media source > receives a NACK from another system, it should redistribute that NACK > to all other systems that would not otherwise receive it. An example > of this is RTCP-SSM in simple feedback model [RFC5760], where the > distribution source reflects NACKs to other systems. If the media source > receives a NACK from another system, but, for some > reason, cannot redistribute that NACK, then it may send a third-party > loss report to the systems that were unable to receive the NACK, and > won't receive the NACK via other means. An example would be a > distribution source using RTCP-SSM in Distribution Source Feedback > Summary model [RFC5760]. > " > > > Tom: the "for some reason" will have to be clarified. I also do not understand: "may send a third-party loss report to the systems that were unable to receive the NACK" Based on the rationale provided by Colin why one may not always simply forward/redistribute NACKs, this is not a matter of systems being "UNABLE" to receive the NACK. They are always able, it is just a decision from the intermediate to not FW the received NACKs. > > [Qin]: No, basic rationale is prevent the receivers know who send NACK. > In SSM case, the rationale is Distribution Source Feedback Summary model does not allow the NACK to be forwarded downstream. > > Tom: In RFC 5760 for SSM in FB summary mode, the DS might also forward RTCP feedback messages and transmit them in the SSM session, when this is explicitly signaled. It is a service/deployment decision whether NACKs are hence FW-ed or not, and there may be good reasons to not do so, but saying that such systems(i..e RTP Rx) are unable to receive the NACK is not justified IMO. It might be clearer to say that the receivers don't get the NACKs, since they're not forwarded by the distribution source. [Qin]: Okay. I agree. Colin > [Qin]: I agree we should follow RFC5760 architecture. But I am not sure the example I give in the section 6.1.1 conflict with RFC5760 architecture. > The architecture I bulild looks like this: > Suppose there are 100 RTP receivers, in these receivers, 50 RTP receivers belong to DS A, 50 RTP receivers belong to DS B, DS A may be placed at the upstream > of DS B or DS A is adjacent to DS B at the same level, Do this kind architecture conflict with RFC5760? If yes, please point out. > > Tom: a DS represents the source/RTP sender of the SSM RTP session. Receivers send out NACKs related to packet loss in a particular SSM RTP session. If a receiver is not "belonging" to a DS X (I guess you mean ..is not receiving packets from that DS X), then why would you implement some kind of FB suppression for such receiver(s) within the SSM RTP session that is sourced by that DS X ??? > > [Qin]: What I am saying here each DS has its own coverage for receivers. You can implement FB suppression for each DS. But you are not necessary to prevent interaction between DS. > Anyway since you or other folks may think this multiple DS case introduce ambiguity and complexity, I will remove this case from the draft, Is that okay with you? > > Tom: Fine! > > Regards! > -Qin > ----- Original Message ----- > From: "Colin Perkins" > To: "Van Caenegem, Tom (Tom)" > Cc: "Qin Wu" ; "'IETF AVTCore WG'" ; "Roni Even" > Sent: Tuesday, June 21, 2011 10:07 PM > Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-rtp-04 > > > On 21 Jun 2011, at 10:29, Van Caenegem, Tom (Tom) wrote: >> Hi, >> >> as promised, these are comments I have on the draft " RTCP Extension for Third-party Loss Report" >> >> -IMO the draft does not provide a good rationale on the use case for sending this new report. The section 3 (protocol overview) says: >> >> "If an intermediary receives a NACK from another system, it should redistribute that NACK to all other systems that would not otherwise receive it. An example of this is RTCP-SSM in simple feedback model [RFC5760], where the distribution source reflects NACKs to other systems. >> If an intermediary receives a NACK from another system, but, for some reason, cannot redistribute that NACK, then it may send a third-party loss report to the systems that were unable to receive the NACK, and won't receive the NACK via other means. An example would be a distribution source using RTCP-SSM in Distribution Source Feedback Summary model [RFC5760]." >> >> My questions: >> >> -why would the intermediary not be able or capable to send the received NACK to the "systems" that were unable to receive the NACK, whereas it would be able or capable to send the 3rd party loss report to those same "systems"? > > Because the intermediary is trying to hide the identity or existence of those systems, and cannot forward the NACK from them without revealing that information > >> -The DS in RTCP-SSM operating in FB summary mode is mentioned as an example for a case where a NACK cannnot be forwarded. Why is this? RFC5760 does not prevent a DS to foward the NACK (see the RFC 5760 and my quote from that RFC in "draft-vancaenegem-avtcore-retransmission-for-ssm-00" > > RFC 5760 allows the NACK to be forwarded, but this would cause the other receivers to become aware of, and keep state for, the participant that sent the NACK. If a third-party loss report is used, the other receivers don't become aware of the participant that signalled the loss, they just know that the loss occurred. > >> -This section 3 makes a distinction between an intermediate that does check the RTP stream for missing packets itself, and an intermediate that does not, but still the behaviour in terms of FW-ing the NACKs received from other "systems" is exactly the same. Why make this distinction then? >> >> I still have an outstanding comment which has not been resolved yet. The section 6.1. and 6.1.1. take RFC 5760 as use case architectures, but section 6.1.1. talks about two distribution sources, whereas RFC 5760 only defined ONE SINGLE DS. Please clarify this. > > [Qin]: two distribution sources means we have two levels of SSM communication, one distribution souce is placed at the upstream of the other distribution source. > two distribution sources case is just one exmaple to discuss how to use new report when there are multiple middleboxs or intermediaries between media source and the receivers. > The middlebox can be distribution source and can be other intermediary. > >> >> Regards >> Tom >> _______________________________________________ >> Audio/Video Transport Core Maintenance >> avt@ietf.org >> https://www.ietf.org/mailman/listinfo/avt > > > > -- > Colin Perkins > http://csperkins.org/ > > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt -- Colin Perkins http://csperkins.org/ From bill.wu@huawei.com Wed Jul 6 23:27:14 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3B7B21F88DB for ; Wed, 6 Jul 2011 23:27:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.617 X-Spam-Level: X-Spam-Status: No, score=-3.617 tagged_above=-999 required=5 tests=[AWL=-1.018, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TlHYA4trhnVP for ; Wed, 6 Jul 2011 23:27:13 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 37BA221F88CE for ; Wed, 6 Jul 2011 23:27:13 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LNY002O29TG5F@szxga05-in.huawei.com> for avt@ietf.org; Thu, 07 Jul 2011 14:24:53 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LNY00K7T9TFRB@szxga05-in.huawei.com> for avt@ietf.org; Thu, 07 Jul 2011 14:24:52 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml205-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ABU54326; Thu, 07 Jul 2011 14:24:51 +0800 (CST) Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 07 Jul 2011 14:24:46 +0800 Received: from w53375q (10.138.41.76) by smtpscn.huawei.com (10.82.67.60) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 07 Jul 2011 14:24:47 +0800 Date: Thu, 07 Jul 2011 14:24:47 +0800 From: Qin Wu X-Originating-IP: [10.138.41.76] To: Roni Even , "'Van Caenegem, Tom (Tom)'" , 'Colin Perkins' Message-id: <4F7EA83A12D24A42A4129D0516780648@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6090 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-CFilter-Loop: Reflected References: <7C8D947749B24396AA011FB286CC69E1@china.huawei.com> <489F755BBD284D18AE9AD47F17317B6F@china.huawei.com> <00a201cc39a1$92ec2850$b8c478f0$%roni@huawei.com> Cc: 'IETF AVTCore WG' Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-rtp-04 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 06:27:14 -0000 Hi, ----- Original Message ----- From: "Roni Even" To: "'Qin Wu'" ; "'Van Caenegem, Tom (Tom)'" ; "'Colin Perkins'" Cc: "'IETF AVTCore WG'" Sent: Monday, July 04, 2011 12:51 AM Subject: RE: [AVTCORE] Comments on draft-ietf-avtcore-feedback-supression-rtp-04 > Hi, > I think that we can look at the following use cases. > > 1. The single DS /FT in a Distribution Source Feedback Summary Model. The > case mentioned by Collin using 3rd party report to hide the topology. > 2. A single DS with multiple FT. See RFC 5760 section 3 in the FT > definition. In this case I am not sure if there is a DS without any FT with > multiple FTs or one DS with a FT and multiple FTs sending unicast RTCP > feedback to the FT co-located with the DS. Maybe we need to look at both > cases. > > 3. RFC 5760 talks about single DS. Is there a use case for multiple DSs > where each DS is in a different SSRC space with one media source > transmitting to all. Is there such a case, maybe if there is some hierarchy > which may look like a DS which is also an RTP mixer or translator. > > Does these use cases make sense? [Qin]: I think These three cases are all SSM use case. Current draft covers case 1 and case 3. But according to Tom's comments, case 3 may introduce too much confusion and complexity. I am going to leave this case out since the focus of this draft is on usage of new message in the SSM general use case. As for case 2, draft-vancaenegem-avtcore-retransmission-for-ssm-00 discusses a lot about how to extend protocol to provide better retransmission. some part is relevant to this draft. But I guess updating RFC5760 or rule changing of RFC5760 is required. > Are there others > > Regards > Roni > >> -----Original Message----- >> From: Qin Wu [mailto:bill.wu@huawei.com] >> Sent: Thursday, June 30, 2011 12:36 PM >> To: Van Caenegem, Tom (Tom); Colin Perkins >> Cc: 'IETF AVTCore WG'; Roni Even; Qin Wu >> Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-feedback- >> supression-rtp-04 >> >> Hi, >> ----- Original Message ----- >> From: "Van Caenegem, Tom (Tom)" >> To: "Qin Wu" ; "Colin Perkins" >> Cc: "'IETF AVTCore WG'" ; "Roni Even" >> >> Sent: Thursday, June 30, 2011 5:07 PM >> Subject: RE: [AVTCORE] Comments on draft-ietf-avtcore-feedback- >> supression-rtp-04 >> >> >> Qin, >> See below, >> >> >> [Qin]: Okay, maybe there is some ambiguity on describing media source >> behavior. I will add some texts to get consistent with >> Intermediary behavior of suppressing feedback described in the previous >> paragraph. >> The proposed text may look like: >> " >> Alternatively, the media source may directly monitor the amount of >> feedback reports it receives from downstream. If the media source >> notices the loss itself, then it >> may send a NACK downstream towards the receivers to suppress >> feedback. If the media source >> receives a NACK from another system, it should redistribute that >> NACK >> to all other systems that would not otherwise receive it. An >> example >> of this is RTCP-SSM in simple feedback model [RFC5760], where the >> distribution source reflects NACKs to other systems. If the media >> source >> receives a NACK from another system, but, for some >> reason, cannot redistribute that NACK, then it may send a third- >> party >> loss report to the systems that were unable to receive the NACK, and >> won't receive the NACK via other means. An example would be a >> distribution source using RTCP-SSM in Distribution Source Feedback >> Summary model [RFC5760]. >> " >> >> >> Tom: the "for some reason" will have to be clarified. I also do not >> understand: "may send a third-party loss report to the systems that >> were unable to receive the NACK" Based on the rationale provided by >> Colin why one may not always simply forward/redistribute NACKs, this is >> not a matter of systems being "UNABLE" to receive the NACK. They are >> always able, it is just a decision from the intermediate to not FW the >> received NACKs. >> >> [Qin]: No, basic rationale is prevent the receivers know who send >> NACK. >> In SSM case, the rationale is Distribution Source Feedback Summary >> model does not allow the NACK to be forwarded downstream. >> >> [Qin]: I agree we should follow RFC5760 architecture. But I am not sure >> the example I give in the section 6.1.1 conflict with RFC5760 >> architecture. >> The architecture I bulild looks like this: >> Suppose there are 100 RTP receivers, in these receivers, 50 RTP >> receivers belong to DS A, 50 RTP receivers belong to DS B, DS A may be >> placed at the upstream >> of DS B or DS A is adjacent to DS B at the same level, Do this kind >> architecture conflict with RFC5760? If yes, please point out. >> >> Tom: a DS represents the source/RTP sender of the SSM RTP session. >> Receivers send out NACKs related to packet loss in a particular SSM RTP >> session. If a receiver is not "belonging" to a DS X (I guess you mean >> ..is not receiving packets from that DS X), then why would you >> implement some kind of FB suppression for such receiver(s) within the >> SSM RTP session that is sourced by that DS X ??? >> >> [Qin]: What I am saying here each DS has its own coverage for >> receivers. You can implement FB suppression for each DS. But you are >> not necessary to prevent interaction between DS. >> Anyway since you or other folks may think this multiple DS case >> introduce ambiguity and complexity, I will remove this case from the >> draft, Is that okay with you? >> >> >> Regards! >> -Qin >> ----- Original Message ----- >> From: "Colin Perkins" >> To: "Van Caenegem, Tom (Tom)" >> Cc: "Qin Wu" ; "'IETF AVTCore WG'" ; >> "Roni Even" >> Sent: Tuesday, June 21, 2011 10:07 PM >> Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-feedback- >> supression-rtp-04 >> >> >> On 21 Jun 2011, at 10:29, Van Caenegem, Tom (Tom) wrote: >> > Hi, >> > >> > as promised, these are comments I have on the draft " RTCP Extension >> for Third-party Loss Report" >> > >> > -IMO the draft does not provide a good rationale on the use case for >> sending this new report. The section 3 (protocol overview) says: >> > >> > "If an intermediary receives a NACK from another system, it should >> redistribute that NACK to all other systems that would not otherwise >> receive it. An example of this is RTCP-SSM in simple feedback model >> [RFC5760], where the distribution source reflects NACKs to other >> systems. >> > If an intermediary receives a NACK from another system, but, for some >> reason, cannot redistribute that NACK, then it may send a third-party >> loss report to the systems that were unable to receive the NACK, and >> won't receive the NACK via other means. An example would be a >> distribution source using RTCP-SSM in Distribution Source Feedback >> Summary model [RFC5760]." >> > >> > My questions: >> > >> > -why would the intermediary not be able or capable to send the >> received NACK to the "systems" that were unable to receive the NACK, >> whereas it would be able or capable to send the 3rd party loss report >> to those same "systems"? >> >> Because the intermediary is trying to hide the identity or existence of >> those systems, and cannot forward the NACK from them without revealing >> that information >> >> > -The DS in RTCP-SSM operating in FB summary mode is mentioned as an >> example for a case where a NACK cannnot be forwarded. Why is this? >> RFC5760 does not prevent a DS to foward the NACK (see the RFC 5760 and >> my quote from that RFC in "draft-vancaenegem-avtcore-retransmission- >> for-ssm-00" >> >> RFC 5760 allows the NACK to be forwarded, but this would cause the >> other receivers to become aware of, and keep state for, the participant >> that sent the NACK. If a third-party loss report is used, the other >> receivers don't become aware of the participant that signalled the >> loss, they just know that the loss occurred. >> >> > -This section 3 makes a distinction between an intermediate that does >> check the RTP stream for missing packets itself, and an intermediate >> that does not, but still the behaviour in terms of FW-ing the NACKs >> received from other "systems" is exactly the same. Why make this >> distinction then? >> > >> > I still have an outstanding comment which has not been resolved yet. >> The section 6.1. and 6.1.1. take RFC 5760 as use case architectures, >> but section 6.1.1. talks about two distribution sources, whereas RFC >> 5760 only defined ONE SINGLE DS. Please clarify this. >> >> [Qin]: two distribution sources means we have two levels of SSM >> communication, one distribution souce is placed at the upstream of the >> other distribution source. >> two distribution sources case is just one exmaple to discuss how to use >> new report when there are multiple middleboxs or intermediaries between >> media source and the receivers. >> The middlebox can be distribution source and can be other intermediary. >> >> > >> > Regards >> > Tom >> > _______________________________________________ >> > Audio/Video Transport Core Maintenance >> > avt@ietf.org >> > https://www.ietf.org/mailman/listinfo/avt >> >> >> >> -- >> Colin Perkins >> http://csperkins.org/ >> > > From internet-drafts@ietf.org Thu Jul 7 02:05:24 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B3B421F87BB; Thu, 7 Jul 2011 02:05:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rg+HsODQtYWY; Thu, 7 Jul 2011 02:05:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC4FC21F87A3; Thu, 7 Jul 2011 02:05:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110707090523.29363.20732.idtracker@ietfa.amsl.com> Date: Thu, 07 Jul 2011 02:05:23 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-srtp-vbr-audio-03.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 09:05:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenanc= e Working Group of the IETF. Title : Guidelines for the use of Variable Bit Rate Audio with S= ecure RTP Author(s) : Colin Perkins Jean-Marc Valin Filename : draft-ietf-avtcore-srtp-vbr-audio-03.txt Pages : 7 Date : 2011-07-07 This memo discusses potential security issues that arise when using variable bit rate audio with the secure RTP profile. Guidelines to mitigate these issues are suggested. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avtcore-srtp-vbr-audio-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtcore-srtp-vbr-audio-03.txt From csp@csperkins.org Thu Jul 7 02:13:15 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B7D221F87B0 for ; Thu, 7 Jul 2011 02:13:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fk-clQ3DeX8L for ; Thu, 7 Jul 2011 02:13:14 -0700 (PDT) Received: from lon1-msapost-3.mail.demon.net (lon1-msapost-3.mail.demon.net [195.173.77.182]) by ietfa.amsl.com (Postfix) with ESMTP id 2D6EA21F8789 for ; Thu, 7 Jul 2011 02:13:14 -0700 (PDT) Received: from vpn17.dcs.gla.ac.uk ([130.209.254.17]) by lon1-post-3.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1Qeke1-00074h-cn for avt@ietf.org; Thu, 07 Jul 2011 09:13:13 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Colin Perkins In-Reply-To: <20110707090523.29363.20732.idtracker@ietfa.amsl.com> Date: Thu, 7 Jul 2011 10:13:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110707090523.29363.20732.idtracker@ietfa.amsl.com> To: IETF AVTCore WG X-Mailer: Apple Mail (2.1084) Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-srtp-vbr-audio-03.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 09:13:15 -0000 On 7 Jul 2011, at 10:05, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Audio/Video Transport Core = Maintenance Working Group of the IETF. >=20 > Title : Guidelines for the use of Variable Bit Rate = Audio with Secure RTP > Author(s) : Colin Perkins > Jean-Marc Valin > Filename : draft-ietf-avtcore-srtp-vbr-audio-03.txt > Pages : 7 > Date : 2011-07-07 >=20 > This memo discusses potential security issues that arise when using > variable bit rate audio with the secure RTP profile. Guidelines to > mitigate these issues are suggested. >=20 >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-ietf-avtcore-srtp-vbr-audio-03.t= xt This addresses some nits that came up at a result of WG last call.=20 --=20 Colin Perkins http://csperkins.org/ From rayvbr@gmail.com Thu Jul 7 08:06:48 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B35D111E8079 for ; Thu, 7 Jul 2011 08:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.443 X-Spam-Level: X-Spam-Status: No, score=-3.443 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hvJNGxx7q+gK for ; Thu, 7 Jul 2011 08:06:48 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id BED6711E8078 for ; Thu, 7 Jul 2011 08:06:47 -0700 (PDT) Received: by qwc23 with SMTP id 23so816685qwc.31 for ; Thu, 07 Jul 2011 08:06:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=PIJHmgzHhGhWiminKinEl6UiLfvD4AsiBIt37VEBIDU=; b=XUrcc3BQdQjCspZmwE3UMPEG1evlHNrkUyMEmxcIWi40HtDyhCRYHUz5PMKQ35DTL3 v61d9XrRadM12DfxdJyKDq5WhuEojycpOGAj2b5BWbClf635ryKt9EF0A1Lm4QOu0bkG WQyidpMdJmup4QXCjSMrkbt5Wh3QZYKrQpE/M= MIME-Version: 1.0 Received: by 10.229.1.230 with SMTP id 38mr712966qcg.19.1310051207143; Thu, 07 Jul 2011 08:06:47 -0700 (PDT) Received: by 10.229.228.8 with HTTP; Thu, 7 Jul 2011 08:06:47 -0700 (PDT) In-Reply-To: References: Date: Thu, 7 Jul 2011 17:06:47 +0200 Message-ID: From: Ray van Brandenburg To: avt@ietf.org Content-Type: multipart/mixed; boundary=00148536e646d6e1ce04a77c10dc Subject: [AVTCORE] New version of IMDS draft X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 15:06:48 -0000 --00148536e646d6e1ce04a77c10dc Content-Type: multipart/alternative; boundary=00148536e646d6e1c804a77c10da --00148536e646d6e1c804a77c10da Content-Type: text/plain; charset=ISO-8859-1 Hi all, As you can see, I uploaded a new version of the IDMS draft. This version includes the changes as suggested by Kevin Gross earlier but that we could't include on time for the July 4th new document deadline. Included are amongst others a number of clarifications regarding: - Use of the presentation timestamp - How to deal with multiple RTP packets with the same RTP timestamp - Use of idms in high-accuracy applications - Dealing with ptp/gal/gps as a time source @Kevin: You mentioned that you would be willing to provide some additional use cases to include in section 4. If you could write some text for this, I can include it in the next version. Looking forward to your comments, Best regards, Ray van Brandenburg --00148536e646d6e1c804a77c10da Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,

As you can= see, I uploaded a new version of the IDMS draft. This version includes the= changes as suggested by Kevin Gross earlier but that we could't includ= e on time for the July 4th new document deadline.
=A0
Included are amongst others a number of clarifications r= egarding:
=A0 =A0 =A0 =A0 - Use of the presentation timestamp
=A0 =A0 =A0 =A0 - How to deal with multiple RTP packets with the sam= e RTP timestamp
=A0 =A0 =A0 =A0 - Use of idms in high-accuracy applications
= =A0 =A0 =A0 =A0 - Dealing with ptp/gal/gps as a time source
=A0
@Kevin: You mentioned that you would be willing to provide some ad= ditional use cases to include in section 4. If you could write some text fo= r this, I can include it in the next version.=A0
=A0
Looking forward to your comments,
=A0
Best regards,
=A0
Ray van Bra= ndenburg

--00148536e646d6e1c804a77c10da-- --00148536e646d6e1ce04a77c10dc Content-Type: application/octet-stream; name="AVTCORE I-D Action draft-ietf-avtcore-idms-01.txt.msg" Content-Disposition: attachment; filename="AVTCORE I-D Action draft-ietf-avtcore-idms-01.txt.msg" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gptufeit0 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAAQAAAAAAAAAA EAAAAgAAAAMAAAD+////AAAAAAAAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////9 ////BAAAACQAAAAFAAAABwAAAAYAAAAJAAAACAAAAAoAAAAMAAAACwAAAA0AAAAOAAAADwAAABAA AAARAAAAEwAAABIAAAAUAAAAIQAAACIAAAAWAAAAFwAAABgAAAAZAAAAGgAAABsAAAAcAAAAHQAA AB4AAAAfAAAAIAAAAP7///8lAAAAIwAAADAAAABTAAAAJgAAACcAAAAoAAAAKQAAACoAAAArAAAA LAAAAC0AAAAuAAAALwAAADsAAAA8AAAAMgAAADMAAAA0AAAANQAAADYAAAA3AAAAOAAAADkAAAA6 AAAA/v///z0AAAA+AAAAQAAAAD8AAABBAAAAQwAAAEIAAABEAAAARQAAAEYAAABHAAAASAAAAEkA AABKAAAASwAAAE8AAABMAAAATQAAAE4AAABRAAAAUAAAAFIAAABUAAAAVQAAAP7///9WAAAAVwAA AFgAAAD+/////v////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////////////1IA bwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAWAAUA//////////8yAAAACw0CAAAAAADAAAAAAAAARgAAAAAAAAAAAAAAAMAbmoe2PMwB AwAAAIBEAAAAAAAAXwBfAG4AYQBtAGUAaQBkAF8AdgBlAHIAcwBpAG8AbgAxAC4AMAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAACgAAQH//////////wkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANDR l4e2PMwB0NGXh7Y8zAEAAAAAAAAAAAAAAABfAF8AcwB1AGIAcwB0AGcAMQAuADAAXwAwADAAMAAy ADAAMQAwADIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKgACAf///////////////wAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAF8AXwBzAHUAYgBzAHQAZwAx AC4AMABfADAAMAAwADMAMAAxADAAMgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAqAAIBAgAAAAQA AAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAALAAAAAAAAAA/v// /wIAAAADAAAA/v///wUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAA EAAAAP7////+/////v////7////+/////v////7////+/////v////7////+/////v////7////+ /////v////7////+////IgAAAP7////+////JQAAAP7////+////KAAAACkAAAD+/////v///ywA AAD+/////v///y8AAAD+////MQAAAP7////+/////v///zUAAAD+/////v////7///85AAAA/v// //7///88AAAA/v///z4AAAD+/////v////7////+/////v////7////+////RgAAAP7///9IAAAA SQAAAEoAAABLAAAATAAAAE0AAABOAAAATwAAAFAAAABRAAAAUgAAAFMAAABUAAAAVQAAAFYAAABX AAAAWAAAAFkAAABaAAAAWwAAAFwAAABdAAAAXgAAAF8AAABgAAAAYQAAAGIAAABjAAAAZAAAAGUA AABmAAAAZwAAAGgAAABpAAAAagAAAGsAAABsAAAAbQAAAG4AAABvAAAAcAAAAHEAAAByAAAAcwAA AHQAAAB1AAAAdgAAAHcAAAB4AAAAeQAAAHoAAAB7AAAAfAAAAH0AAAB+AAAAfwAAAIAAAACGAwIA AAAAAMAAAAAAAABGH6TrM6h6LkK+e3nhqY5UsxOP8kH0gxRBpYTu21prC/8AAAAAAAAAAAAAAAAA AAAAAAAAAAcAAAAgAAAABwABADgAAAAHAAIAVAAAAAcAAwCQAAAABwAEANAAAAAHAAUA8AAAAAcA BgAMAQAABwAHADABAAAHAAgATAEAAAcACQB0AQAABwAKAIgBAAAHAAsAoAEAAAcADAC8AQAABwAN ANgBAAAHAA4A9AEAAAcADwAUAgAABwAQADACAAAJABEAbAIAAAcAEgC8AgAABwATAAQDAAALABQA GAMAAAsAFQAAAAAAAAAAAAAAAAAAAAAAGgAAAHgALQBpAHIAbwBuAHAAbwByAHQALQBhAHYAAAAS AAAAZQByAHIAbwByAHMALQB0AG8AAAAYAAAAeAAtAHMAcABhAG0ALQBzAGMAbwByAGUANgAAAHgA LQBpAHIAbwBuAHAAbwByAHQALQBhAG4AdABpAC0AcwBwAGEAbQAtAHIAZQBzAHUAbAB0AAAAOgAA AHgALQBpAHIAbwBuAHAAbwByAHQALQBhAG4AdABpAC0AcwBwAGEAbQAtAGYAaQBsAHQAZQByAGUA ZAAAABoAAAB4AC0AcwBwAGEAbQAtAHMAdABhAHQAdQBzAAAAGAAAAHgALQBzAHAAYQBtAF8AXwBz AHUAYgBzAHQAZwAxAC4AMABfADAAMAAwADQAMAAxADAAMgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAqAAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAA ADYDAAAAAAAAXwBfAHMAdQBiAHMAdABnADEALgAwAF8AMQAwADAAMAAwADEAMAAyAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAACoAAgEDAAAABwAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAARAAAACAAAAAAAAABfAF8AcwB1AGIAcwB0AGcAMQAuADAAXwAxADAAMAAxADAA MQAwADIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKgACAf///////////////wAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAAAIAAAAAAAAAF8AXwBzAHUAYgBzAHQAZwAxAC4A MABfADEAMAAwADMAMAAxADAAMgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAqAAIBBgAAAAgAAAD/ ////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEwAAABAAAAAAAAAALQBsAGUA dgBlAGwAHgAAAHgALQB2AGkAcgB1AHMALQBzAGMAYQBuAG4AZQBkAAAAFgAAAHgALQBiAGUAZQBu AHQAaABlAHIAZQAAACIAAAB4AC0AbQBhAGkAbABtAGEAbgAtAHYAZQByAHMAaQBvAG4AAAAOAAAA bABpAHMAdAAtAGkAZAAAABIAAABsAGkAcwB0AC0AcABvAHMAdAAAABgAAAByAGUAYwBlAGkAdgBl AGQALQBzAHAAZgAYAAAAbABpAHMAdAAtAGEAcgBjAGgAaQB2AGUAFgAAAHgALQBzAHAAYQBtAC0A ZgBsAGEAZwAAABoAAAB4AC0AbwByAGkAZwBpAG4AYQBsAC0AdABvAAAAGAAAAGQAZQBsAGkAdgBl AHIAZQBkAC0AdABvADYAAABDAG8AbgB2AGUAcgBzAGEAdABpAG8AbgBJAG4AZABlAHgAVAByAGEA YwBrAGkAbgBnAEUAeAAAAEoAAAB4AC0AbQBzAC0AZQB4AGMAaABhAG4AZwBlAC0AbwByAGcAYQBu AGkAegBhAHQAaQBvAG4ALQBhAHUAdABoAHMAbwB1AHIAYwBlAAAAQgAAAHgALQBtAHMALQBlAHgA YwBoAGEAbgBnAGUALQBvAHIAZwBhAG4AaQB6AGEAdABpAG8AbgAtAGEAdQB0AGgAYQBzAAAAEAAA AEkAcwBTAGkAZwBuAGUAZAAaAAAASQBzAFIAZQBhAGQAUgBlAGMAZQBpAHAAdAAAAAAAAAAAAAAA tM9rVwcABQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAOA4sccHAAYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAADz0jPJBwAQAOanpeYLABQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAIb5ATQcACQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMEuWWcHAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADb+jjXBwAPAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAijct4AcABAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAF8AXwBzAHUA YgBzAHQAZwAxAC4AMABfADEAMAAwADQAMAAxADAAMgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAq AAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFAAAAAgA AAAAAAAAXwBfAHMAdQBiAHMAdABnADEALgAwAF8AMQAwADAANQAwADEAMAAyAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAACoAAgEFAAAADQAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAVAAAACAAAAAAAAABfAF8AcwB1AGIAcwB0AGcAMQAuADAAXwAxADAAMAA2ADAAMQAw ADIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKgACAf///////////////wAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAABYAAAAIAAAAAAAAAF8AXwBzAHUAYgBzAHQAZwAxAC4AMABf ADEAMAAwADgAMAAxADAAMgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAqAAIBCgAAAAwAAAD///// AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFwAAAAgAAAAAAAAAXwBfAHMAdQBi AHMAdABnADEALgAwAF8AMQAwADAAOQAwADEAMAAyAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACoA AgH///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAAAAEAAA AAAAAABfAF8AcwB1AGIAcwB0AGcAMQAuADAAXwAxADAAMABGADAAMQAwADIAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAKgACAQsAAAAPAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAABkAAAAIAAAAAAAAAF8AXwBzAHUAYgBzAHQAZwAxAC4AMABfADEAMAAxADEAMAAxADAA MgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAqAAIB////////////////AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAGgAAABgAAAAAAAAAXwBfAHMAdQBiAHMAdABnADEALgAwAF8A MQAwADEANAAwADEAMAAyAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACoAAgEOAAAAEQAAAP////8A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAbAAAAGAAAAAAAAACDg4+6BwAAAD5s ru8HAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC3I9 qgcADQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAJcZ5MkHAAcAA9H76wcACAC0RandBwAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAS8VjfBwAOAOlhpykHABMAH0bH/gsAFQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAA/Zt+AwcAAwB5eu+pCQARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAK7pOtoHAAoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADpCcJzBwALAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADPNkNwcAEgAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAF8AXwBzAHUAYgBz AHQAZwAxAC4AMABfADEAMAAxADcAMAAxADAAMgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAqAAIB ////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAABAAAAAA AAAAXwBfAHMAdQBiAHMAdABnADEALgAwAF8AMQAwADEAQQAwADEAMAAyAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAACoAAgAQAAAAEgAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAdAAAACAAAAAAAAABfAF8AcwB1AGIAcwB0AGcAMQAuADAAXwAxADAAMQBCADAAMQAwADIA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKgACAf////8TAAAA/////wAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAB4AAAAIAAAAAAAAAF8AXwBzAHUAYgBzAHQAZwAxAC4AMABfADEA MAAxAEMAMAAxADAAMgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAqAAIA////////////////AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHwAAAAgAAAAAAAAAXwBfAHMAdQBiAHMA dABnADEALgAwAF8AMAAwADEAQQAwADAAMQBGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACoAAgEB AAAAFQAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAEAAAAAAA AABfAF8AcwB1AGIAcwB0AGcAMQAuADAAXwAwADAAMwA3ADAAMAAxAEYAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAKgACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAACEAAABoAAAAAAAAAF8AXwBzAHUAYgBzAHQAZwAxAC4AMABfADAAMAAzAEIAMAAxADAAMgAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAqAAIBFAAAABgAAAD/////AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAIwAAAB4AAAAAAAAAXwBfAHMAdQBiAHMAdABnADEALgAwAF8AMAAw ADMARAAwADAAMQBGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACoAAgH///////////////8AAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+////AAAAAAAAAABJAFAATQAuAE4AbwB0 AGUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWwBBAFYA VABDAE8AUgBFAF0AIABJAC0ARAAgAEEAYwB0AGkAbwBuADoAIABkAHIAYQBmAHQALQBpAGUAdABm AC0AYQB2AHQAYwBvAHIAZQAtAGkAZABtAHMALQAwADEALgB0AHgAdAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAABTTVRQOklOVEVSTkVULURSQUZUU0BJRVRGLk9SRwAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAANynQMjAQhAatLkIACsv4YIBAAAAAAAAAC9PPVNFUlZJQ0VORVQg REVMRlQvT1U9VFNOIERFTEZUL0NOPVJFQ0lQSUVOVFMvQ049QlJBTkRFTkJVUkdSVgAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABCAHIAYQBuAGQAZQBuAGIAdQByAGcALAAgAFIA LgAgACgAUgBhAHkAKQAgAHYAYQBuAAAAAAAAAAAAAAAAAAAAAAAAAIErH6S+oxAZnW4A3QEPVAIA AAGAaQBuAHQAZQByAG4AZQB0AC0AZAByAGEAZgB0AHMAQABpAGUAdABmAF8AXwBzAHUAYgBzAHQA ZwAxAC4AMABfADAAMAAzAEYAMAAxADAAMgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAqAAIBFwAA ABkAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJAAAAFwAAAAAAAAA XwBfAHMAdQBiAHMAdABnADEALgAwAF8AMAAwADQAMAAwADAAMQBGAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAACoAAgH///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAmAAAAMgAAAAAAAABfAF8AcwB1AGIAcwB0AGcAMQAuADAAXwAwADAANAAxADAAMQAwADIAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAKgACARYAAAAeAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAACcAAACGAAAAAAAAAF8AXwBzAHUAYgBzAHQAZwAxAC4AMABfADAAMAA0 ADIAMAAwADEARgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAqAAIB////////////////AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKgAAADAAAAAAAAAALgBvAHIAZwAAAFMATQBU AFAAAABpAG4AdABlAHIAbgBlAHQALQBkAHIAYQBmAHQAcwBAAGkAZQB0AGYALgBvAHIAZwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABp AG4AdABlAHIAbgBlAHQALQBkAHIAYQBmAHQAcwBAAGkAZQB0AGYALgBvAHIAZwAAAAAAAAAAAAAA AAAAAAAAAAAAANynQMjAQhAatLkIACsv4YIBAAAAAAAAAC9PPVNFUlZJQ0VORVQgREVMRlQvT1U9 VFNOIERFTEZUL0NOPVJFQ0lQSUVOVFMvQ049QlJBTkRFTkJVUkdSVgAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAABCAHIAYQBuAGQAZQBuAGIAdQByAGcALAAgAFIALgAgACgAUgBh AHkAKQAgAHYAYQBuAAAAAAAAAAAAAAAAAAAARVg6L089U0VSVklDRU5FVCBERUxGVC9PVT1UU04g REVMRlQvQ049UkVDSVBJRU5UUy9DTj1CUkFOREVOQlVSR1JWAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABfAF8AcwB1AGIAcwB0AGcA MQAuADAAXwAwADAANAAzADAAMQAwADIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKgACARsAAAAd AAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACsAAABcAAAAAAAAAF8A XwBzAHUAYgBzAHQAZwAxAC4AMABfADAAMAA0ADQAMAAwADEARgAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAqAAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA LQAAADIAAAAAAAAAXwBfAHMAdQBiAHMAdABnADEALgAwAF8AMAAwADUAMQAwADEAMAAyAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAACoAAgEcAAAAIAAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAuAAAAQwAAAAAAAABfAF8AcwB1AGIAcwB0AGcAMQAuADAAXwAwADAANQAy ADAAMQAwADIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKgACAf///////////////wAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAAAABDAAAAAAAAAEVYOi9PPVNFUlZJQ0VORVQg REVMRlQvT1U9VFNOIERFTEZUL0NOPVJFQ0lQSUVOVFMvQ049QlJBTkRFTkJVUkdSVgAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUwBN AFQAUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAGkAbgB0AGUAcgBuAGUAdAAtAGQAcgBhAGYAdABzAEAAaQBlAHQAZgAuAG8AcgBnAAAAAAAA AAAAAAAAAAAAAABbAEEAVgBUAEMATwBSAEUAXQAgAEkALQBEACAAQQBjAHQAaQBvAG4AOgAgAGQA cgBhAGYAdAAtAGkAZQB0AGYALQBhAHYAdABjAG8AcgBlAC0AaQBkAG0AcwAtADAAMQAuAHQAeAB0 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEBzDvVRHnJOXIVRbdKttFjNdyXkM8AAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABFAFgAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAXwBfAHMAdQBiAHMAdABnADEA LgAwAF8AMAAwADYANAAwADAAMQBGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACoAAgEfAAAAIQAA AP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAyAAAACAAAAAAAAABfAF8A cwB1AGIAcwB0AGcAMQAuADAAXwAwADAANgA1ADAAMAAxAEYAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAKgACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADMA AAAwAAAAAAAAAF8AXwBzAHUAYgBzAHQAZwAxAC4AMABfADAAMAA3ADAAMAAwADEARgAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAqAAIBGgAAACoAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAANAAAAGgAAAAAAAAAXwBfAHMAdQBiAHMAdABnADEALgAwAF8AMAAwADcAMQAw ADEAMAAyAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACoAAgH///////////////8AAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA2AAAAFgAAAAAAAABfAF8AcwB1AGIAcwB0AGcAMQAu ADAAXwAwADAANwA1ADAAMAAxAEYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKgACASMAAAAlAAAA /////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADcAAAAEAAAAAAAAAF8AXwBz AHUAYgBzAHQAZwAxAC4AMABfADAAMAA3ADYAMAAwADEARgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAqAAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOAAA AH4AAAAAAAAAXwBfAHMAdQBiAHMAdABnADEALgAwAF8AMAAwADcANwAwADAAMQBGAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAACoAAgEkAAAAKAAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAA6AAAABAAAAAAAAABfAF8AcwB1AGIAcwB0AGcAMQAuADAAXwAwADAANwA4ADAA MAAxAEYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKgACAf///////////////wAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADsAAAB+AAAAAAAAAC8ATwA9AFMARQBSAFYASQBDAEUA TgBFAFQAIABEAEUATABGAFQALwBPAFUAPQBUAFMATgAgAEQARQBMAEYAVAAvAEMATgA9AFIARQBD AEkAUABJAEUATgBUAFMALwBDAE4APQBCAFIAQQBOAEQARQBOAEIAVQBSAEcAUgBWAAAARQBYAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AC8ATwA9AFMARQBSAFYASQBDAEUATgBFAFQAIABEAEUATABGAFQALwBPAFUAPQBUAFMATgAgAEQA RQBMAEYAVAAvAEMATgA9AFIARQBDAEkAUABJAEUATgBUAFMALwBDAE4APQBCAFIAQQBOAEQARQBO AEIAVQBSAEcAUgBWAAAAAAAAAIErH6S+oxAZnW4A3QEPVAIAAAGAYQB2AHQALQBiAG8AdQBuAGMA ZQBzAEAAaQBlAHQAZgAuAG8AcgBnAAAAUwBNAFQAUAAAAGEAdgB0AC0AYgBvAHUAbgBjAGUAcwBA AGkAZQB0AGYALgBvAHIAZwAAAAAAAAAAAAAAAABhAHYAdAAtAGIAbwB1AG4AYwBlAHMAQABpAGUA dABmAC4AbwByAGcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAXwBfAHMAdQBiAHMAdABnADEALgAw AF8AMAAwADcARAAwADAAMQBGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACoAAgEnAAAAKQAAAP// //8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAVAAAA6hYAAAAAAABfAF8AcwB1 AGIAcwB0AGcAMQAuADAAXwAwAEMAMQA5ADAAMQAwADIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA KgACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD0AAAB2 AAAAAAAAAF8AXwBzAHUAYgBzAHQAZwAxAC4AMABfADAAQwAxAEEAMAAwADEARgAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAqAAIBJgAAAC4AAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAPwAAACgAAAAAAAAAXwBfAHMAdQBiAHMAdABnADEALgAwAF8AMABDADEARAAwADEA MAAyAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACoAAgH///////////////8AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAGgAAAAAAAABSAGUAYwBlAGkAdgBlAGQAOgAgAGYA cgBvAG0AIABtAGEAaQBsAG8AdQB0AGEALgB0AG4AbwAuAG4AbAAgACgAMQAzADQALgAyADIAMQAu ADEALgAxADYAKQAgAGIAeQAgAEUAWABDAC0AQwBBAFMASABVAEIAMAAzAC4AdABzAG4ALgB0AG4A bwAuAG4AbAANAAoAIAAoADEAMwA0AC4AMgAyADEALgAyADIANQAuADIAMgAyACkAIAB3AGkAdABo ACAATQBpAGMAcgBvAHMAbwBmAHQAIABTAE0AVABQACAAUwBlAHIAdgBlAHIAIABpAGQAIAAxADQA LgAxAC4AMgA4ADkALgAxADsAIABXAGUAZAAsACAANgAgAEoAdQBsACAAMgAwADEAMQANAAoAIAAx ADQAOgAwADcAOgAyADUAIAArADAAMgAwADAADQAKAFgALQBJAHIAbwBuAFAAbwByAHQALQBBAG4A dABpAC0AUwBwAGEAbQAtAEYAaQBsAHQAZQByAGUAZAA6ACAAdAByAHUAZQANAAoAWAAtAEkAcgBv AG4AUABvAHIAdAAtAEEAbgB0AGkALQBTAHAAYQBtAC0AUgBlAHMAdQBsAHQAOgAgAEEAaAAwAEQA QQBCAHQAUABGAEUANQBBAHEAbQBJAGUAawBtAGQAcwBiADIASgBoAGIAQQBCAFQAbQBSAGkATwBh AHgAUQBCAEEAUQBFAEIAQwBRAHMATABCAHgASQBuAHoARwBhAEcATgBnAFMASABSAG8AcAA3AGsA RgB3AA0ACgBYAC0ASQByAG8AbgBQAG8AcgB0AC0AQQBWADoAIABFAD0AUwBvAHAAaABvAHMAOwBp AD0AIgA0AC4ANgA1ACwANAA4ADYALAAxADMAMAA0ADIAOAA3ADIAMAAwACIAOwAgAA0ACgAgACAA IABkAD0AIgBzAGMAYQBuACcAMgAwADgAIgA7AGEAPQAiADUANAAzADkAMwA0ADYANQAiAA0ACgBS AGUAYwBlAGkAdgBlAGQAOgAgAGYAcgBvAG0AIABtAGEAaQBsAC4AaQBlAHQAZgAuAG8AcgBnACAA KABbADYANAAuADEANwAwAC4AOQA4AC4AMwAwAF0AKQAgACAAYgB5ACAAbQBhAGkAbAAxAGEALgB0 AG4AbwAuAG4AbAAgAHcAaQB0AGgAIABFAFMATQBUAFAAOwAgADAANgANAAoAIABKAHUAbAAgADIA MAAxADEAIAAxADQAOgAwADcAOgAyADMAIAArADAAMgAwADAADQAKAFIAZQBjAGUAaQB2AGUAZAA6 ACAAZgByAG8AbQAgAGkAZQB0AGYAYQAuAGEAbQBzAGwALgBjAG8AbQAgACgAbABvAGMAYQBsAGgA bwBzAHQAIABbADEAMgA3AC4AMAAuADAALgAxAF0AKQAJAGIAeQAgAGkAZQB0AGYAYQAuAGEAbQBz AGwALgBjAG8AbQANAAoAIAAoAFAAbwBzAHQAZgBpAHgAKQAgAHcAaQB0AGgAIABFAFMATQBUAFAA IABpAGQAIAA5ADgAOQBBAEYAMgAxAEYAOAA3ADMAOQA7AAkAVwBlAGQALAAgACAANgAgAEoAdQBs ACAAMgAwADEAMQAgADAANQA6ADAANQA6ADAAOAAgAC0AMAA3ADAAMAAgACgAUABEAFQAKQANAAoA WAAtAE8AcgBpAGcAaQBuAGEAbAAtAFQAbwA6ACAAYQB2AHQAQABpAGUAdABmAGEALgBhAG0AcwBs AC4AYwBvAG0ADQAKAEQAZQBsAGkAdgBlAHIAZQBkAC0AVABvADoAIABhAHYAdABAAGkAZQB0AGYA YQAuAGEAbQBzAGwALgBjAG8AbQANAAoAUgBlAGMAZQBpAHYAZQBkADoAIABmAHIAbwBtACAAbABv AGMAYQBsAGgAbwBzAHQAIAAoAGwAbwBjAGEAbABoAG8AcwB0ACAAWwAxADIANwAuADAALgAwAC4A MQBdACkACQBiAHkAIABpAGUAdABmAGEALgBhAG0AcwBsAC4AYwBvAG0AIAAoAFAAbwBzAHQAZgBp AHgAKQANAAoAIAB3AGkAdABoACAARQBTAE0AVABQACAAaQBkACAARAAyAEEAQgA3ADIAMQBGADgA NgBGADcAOwAJAFcAZQBkACwAIAAgADYAIABKAHUAbAAgADIAMAAxADEAIAAwADUAOgAwADUAOgAw ADUAIAAtADAANwAwADAAIAAoAFAARABUACkADQAKAFgALQBWAGkAcgB1AHMALQBTAGMAYQBuAG4A ZQBkADoAIABhAG0AYQB2AGkAcwBkAC0AbgBlAHcAIABhAHQAIABhAG0AcwBsAC4AYwBvAG0ADQAK AFgALQBTAHAAYQBtAC0ARgBsAGEAZwA6ACAATgBPAA0ACgBYAC0AUwBwAGEAbQAtAFMAYwBvAHIA ZQA6ACAALQA5ADgALgA1ADkAOQANAAoAWAAtAFMAcABhAG0ALQBMAGUAdgBlAGwAOgANAAoAWAAt AFMAcABhAG0ALQBTAHQAYQB0AHUAcwA6ACAATgBvACwAIABzAGMAbwByAGUAPQAtADkAOAAuADUA OQA5ACAAdABhAGcAZwBlAGQAXwBhAGIAbwB2AGUAPQAtADkAOQA5ACAAcgBlAHEAdQBpAHIAZQBk AD0ANQANAAoACQB0AGUAcwB0AHMAPQBbAEEAVwBMAD0ALQAzAC4AOQA3ADYALAAgAEIAQQBZAEUA UwBfADAAMAA9AC0AMgAuADUAOQA5ACwAIABGAFIAVABfAFMAVABPAEMASwAxAD0AMwAuADkAOAA4 ACwADQAKAAkARgBSAFQAXwBTAFQATwBDAEsAMgA9ADMALgA5ADgAOAAsACAAVQBTAEUAUgBfAEkA TgBfAFcASABJAFQARQBMAEkAUwBUAD0ALQAxADAAMABdAA0ACgBSAGUAYwBlAGkAdgBlAGQAOgAg AGYAcgBvAG0AIABtAGEAaQBsAC4AaQBlAHQAZgAuAG8AcgBnACAAKABbADYANAAuADEANwAwAC4A OQA4AC4AMwAwAF0AKQAJAGIAeQAgAGwAbwBjAGEAbABoAG8AcwB0ACAAKABpAGUAdABmAGEALgBh AG0AcwBsAC4AYwBvAG0ADQAKACAAWwAxADIANwAuADAALgAwAC4AMQBdACkAIAAoAGEAbQBhAHYA aQBzAGQALQBuAGUAdwAsACAAcABvAHIAdAAgADEAMAAwADIANAApAAkAdwBpAHQAaAAgAEUAUwBN AFQAUAAgAGkAZAAgAHcAOQB4AEYAYgBXAFQAbwBSAEgALQBPADsAIABXAGUAZAAsACAAIAA2AA0A CgAgAEoAdQBsACAAMgAwADEAMQAgADAANQA6ADAANQA6ADAANQAgAC0AMAA3ADAAMAAgACgAUABE AFQAKQANAAoAUgBlAGMAZQBpAHYAZQBkADoAIABmAHIAbwBtACAAaQBlAHQAZgBhAC4AYQBtAHMA bAAuAGMAbwBtACAAKABsAG8AYwBhAGwAaABvAHMAdAAgAFsAMQAyADcALgAwAC4AMAAuADEAXQAp AAkAYgB5ACAAaQBlAHQAZgBhAC4AYQBtAHMAbAAuAGMAbwBtAA0ACgAgACgAUABvAHMAdABmAGkA eAApACAAdwBpAHQAaAAgAEUAUwBNAFQAUAAgAGkAZAAgADcAMgBGAEUAQQAyADEARgA4ADUARQBD ADsACQBXAGUAZAAsACAAIAA2ACAASgB1AGwAIAAyADAAMQAxACAAMAA1ADoAMAA1ADoAMAA1ACAA LQAwADcAMAAwACAAKABQAEQAVAApAA0ACgBNAEkATQBFAC0AVgBlAHIAcwBpAG8AbgA6ACAAMQAu ADAADQAKAEYAcgBvAG0AOgAgADwAaQBuAHQAZQByAG4AZQB0AC0AZAByAGEAZgB0AHMAQABpAGUA dABmAC4AbwByAGcAPgANAAoAVABvADoAIAA8AGkALQBkAC0AYQBuAG4AbwB1AG4AYwBlAEAAaQBl AHQAZgAuAG8AcgBnAD4ADQAKAFgALQBUAGUAcwB0AC0ASQBEAFQAcgBhAGMAawBlAHIAOgAgAG4A bwANAAoAWAAtAEkARQBUAEYALQBJAEQAVAByAGEAYwBrAGUAcgA6ACAAMwAuADUANQANAAoATQBl AHMAcwBhAGcAZQAtAEkARAA6ACAAPAAyADAAMQAxADAANwAwADYAMQAyADAANQAwADUALgAxADUA MAA1ADMALgA5ADgAMgAxADIALgBpAGQAdAByAGEAYwBrAGUAcgBAAGkAZQB0AGYAYQAuAGEAbQBz AGwALgBjAG8AbQA+AA0ACgBEAGEAdABlADoAIABXAGUAZAAsACAANgAgAEoAdQBsACAAMgAwADEA MQAgADAANQA6ADAANQA6ADAANQAgAC0AMAA3ADAAMAANAAoAQwBDADoAIAA8AGEAdgB0AEAAaQBl AHQAZgAuAG8AcgBnAD4ADQAKAFMAdQBiAGoAZQBjAHQAOgAgAFsAQQBWAFQAQwBPAFIARQBdACAA SQAtAEQAIABBAGMAdABpAG8AbgA6ACAAZAByAGEAZgB0AC0AaQBlAHQAZgAtAGEAdgB0AGMAbwBy AGUALQBpAGQAbQBzAC0AMAAxAC4AdAB4AHQADQAKAFgALQBCAGUAZQBuAFQAaABlAHIAZQA6ACAA YQB2AHQAQABpAGUAdABmAC4AbwByAGcADQAKAFgALQBNAGEAaQBsAG0AYQBuAC0AVgBlAHIAcwBp AG8AbgA6ACAAMgAuADEALgAxADIADQAKAFAAcgBlAGMAZQBkAGUAbgBjAGUAOgAgAGwAaQBzAHQA DQAKAEwAaQBzAHQALQBJAGQAOgAgAEEAdQBkAGkAbwAvAFYAaQBkAGUAbwAgAFQAcgBhAG4AcwBw AG8AcgB0ACAAQwBvAHIAZQAgAE0AYQBpAG4AdABlAG4AYQBuAGMAZQAgADwAYQB2AHQALgBpAGUA dABmAC4AbwByAGcAPgANAAoATABpAHMAdAAtAFUAbgBzAHUAYgBzAGMAcgBpAGIAZQA6ACAAPABo AHQAdABwAHMAOgAvAC8AdwB3AHcALgBpAGUAdABmAC4AbwByAGcALwBtAGEAaQBsAG0AYQBuAC8A bwBwAHQAaQBvAG4AcwAvAGEAdgB0AD4ALAANAAoACQA8AG0AYQBpAGwAdABvADoAYQB2AHQALQBy AGUAcQB1AGUAcwB0AEAAaQBlAHQAZgAuAG8AcgBnAD8AcwB1AGIAagBlAGMAdAA9AHUAbgBzAHUA YgBzAGMAcgBpAGIAZQA+AA0ACgBMAGkAcwB0AC0AQQByAGMAaABpAHYAZQA6ACAAPABoAHQAdABw ADoALwAvAHcAdwB3AC4AaQBlAHQAZgAuAG8AcgBnAC8AbQBhAGkAbAAtAGEAcgBjAGgAaQB2AGUA LwB3AGUAYgAvAGEAdgB0AD4ADQAKAEwAaQBzAHQALQBQAG8AcwB0ADoAIAA8AG0AYQBpAGwAdABv ADoAYQB2AHQAQABpAGUAdABmAC4AbwByAGcAPgANAAoATABpAHMAdAAtAEgAZQBsAHAAOgAgADwA bQBhAGkAbAB0AG8AOgBhAHYAdAAtAHIAZQBxAHUAZQBzAHQAQABpAGUAdABmAC4AbwByAGcAPwBz AHUAYgBqAGUAYwB0AD0AaABlAGwAcAA+AA0ACgBMAGkAcwB0AC0AUwB1AGIAcwBjAHIAaQBiAGUA OgAgADwAaAB0AHQAcABzADoALwAvAHcAdwB3AC4AaQBlAHQAZgAuAG8AcgBnAC8AbQBhAGkAbABt AGEAbgAvAGwAaQBzAHQAaQBuAGYAbwAvAGEAdgB0AD4ALAANAAoACQA8AG0AYQBpAGwAdABvADoA YQB2AHQALQByAGUAcQB1AGUAcwB0AEAAaQBlAHQAZgAuAG8AcgBnAD8AcwB1AGIAagBlAGMAdAA9 AHMAdQBiAHMAYwByAGkAYgBlAD4ADQAKAEMAbwBuAHQAZQBuAHQALQBUAHkAcABlADoAIAB0AGUA eAB0AC8AcABsAGEAaQBuADsAIABjAGgAYQByAHMAZQB0AD0AIgB1AHMALQBhAHMAYwBpAGkAIgAN AAoAQwBvAG4AdABlAG4AdAAtAFQAcgBhAG4AcwBmAGUAcgAtAEUAbgBjAG8AZABpAG4AZwA6ACAA NwBiAGkAdAANAAoAUwBlAG4AZABlAHIAOgAgADwAYQB2AHQALQBiAG8AdQBuAGMAZQBzAEAAaQBl AHQAZgAuAG8AcgBnAD4ADQAKAEUAcgByAG8AcgBzAC0AVABvADoAIABhAHYAdAAtAGIAbwB1AG4A YwBlAHMAQABpAGUAdABmAC4AbwByAGcADQAKAFIAZQB0AHUAcgBuAC0AUABhAHQAaAA6ACAAYQB2 AHQALQBiAG8AdQBuAGMAZQBzAEAAaQBlAHQAZgAuAG8AcgBnAA0ACgBYAC0ATQBTAC0ARQB4AGMA aABhAG4AZwBlAC0ATwByAGcAYQBuAGkAegBhAHQAaQBvAG4ALQBBAHUAdABoAFMAbwB1AHIAYwBl ADoAIABFAFgAQwAtAEMAQQBTAEgAVQBCADAAMwAuAHQAcwBuAC4AdABuAG8ALgBuAGwADQAKAFgA LQBNAFMALQBFAHgAYwBoAGEAbgBnAGUALQBPAHIAZwBhAG4AaQB6AGEAdABpAG8AbgAtAEEAdQB0 AGgAQQBzADoAIABBAG4AbwBuAHkAbQBvAHUAcwANAAoAWAAtAE0AUwAtAEUAeABjAGgAYQBuAGcA ZQAtAE8AcgBnAGEAbgBpAHoAYQB0AGkAbwBuAC0AUABSAEQAOgAgAGkAZQB0AGYALgBvAHIAZwAN AAoAWAAtAE0AUwAtAEUAeABjAGgAYQBuAGcAZQAtAE8AcgBnAGEAbgBpAHoAYQB0AGkAbwBuAC0A UwBlAG4AZABlAHIASQBkAFIAZQBzAHUAbAB0ADoAIABGAGEAaQBsAA0ACgBSAGUAYwBlAGkAdgBl AGQALQBTAFAARgA6ACAARgBhAGkAbAAgACgARQBYAEMALQBDAEEAUwBIAFUAQgAwADMALgB0AHMA bgAuAHQAbgBvAC4AbgBsADoAIABkAG8AbQBhAGkAbgAgAG8AZgAgAGEAdgB0AC0AYgBvAHUAbgBj AGUAcwBAAGkAZQB0AGYALgBvAHIAZwANAAoAIABkAG8AZQBzACAAbgBvAHQAIABkAGUAcwBpAGcA bgBhAHQAZQAgADEAMwA0AC4AMgAyADEALgAxAC4AMQA2ACAAYQBzACAAcABlAHIAbQBpAHQAdABl AGQAIABzAGUAbgBkAGUAcgApAA0ACgAgAHIAZQBjAGUAaQB2AGUAcgA9AEUAWABDAC0AQwBBAFMA SABVAEIAMAAzAC4AdABzAG4ALgB0AG4AbwAuAG4AbAA7ACAAYwBsAGkAZQBuAHQALQBpAHAAPQAx ADMANAAuADIAMgAxAC4AMQAuADEANgA7AA0ACgAgAGgAZQBsAG8APQBtAGEAaQBsAG8AdQB0AGEA LgB0AG4AbwAuAG4AbAA7AA0ACgBYAC0ATQBTAC0ARQB4AGMAaABhAG4AZwBlAC0ATwByAGcAYQBu AGkAegBhAHQAaQBvAG4ALQBBAFYAUwB0AGEAbQBwAC0ATQBhAGkAbABiAG8AeAA6ACAATQBTAEYA VABGAEYAOwAxADsAMAA7ADAAIAAwACAAMAANAAoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAABTTVRQOkFWVC1CT1VOQ0VTQElFVEYuT1JHAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUwBNAFQAUAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGEAdgB0AC0AYgBvAHUAbgBjAGUA cwBAAGkAZQB0AGYALgBvAHIAZwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABhAHYAdABAAGkAZQB0 AGYALgBvAHIAZwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaQAtAGQA LQBhAG4AbgBvAHUAbgBjAGUAQABpAGUAdABmAC4AbwByAGcAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AFsAQQBWAFQAQwBPAFIARQBdACAASQAtAEQAIABBAGMAdABpAG8AbgA6ACAAZAByAGEAZgB0AC0A aQBlAHQAZgAtAGEAdgB0AGMAbwByAGUALQBpAGQAbQBzAC0AMAAxAC4AdAB4AHQAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAQQAgAE4AZQB3ACAASQBuAHQAZQByAG4AZQB0AC0ARAByAGEAZgB0ACAA aQBzACAAYQB2AGEAaQBsAGEAYgBsAF8AXwBzAHUAYgBzAHQAZwAxAC4AMABfADAAQwAxAEUAMAAw ADEARgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAqAAIBKwAAAC0AAAD/////AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQQAAAAgAAAAAAAAAXwBfAHMAdQBiAHMAdABnADEALgAw AF8AMABDADEARgAwADAAMQBGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACoAAgH///////////// //8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABCAAAAKAAAAAAAAABfAF8AcwB1 AGIAcwB0AGcAMQAuADAAXwAwAEUAMAAyADAAMAAxAEYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA KgACASwAAAAwAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7///8A AAAAAAAAAF8AXwBzAHUAYgBzAHQAZwAxAC4AMABfADAARQAwADMAMAAwADEARgAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAqAAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAQwAAABoAAAAAAAAAXwBfAHMAdQBiAHMAdABnADEALgAwAF8AMABFADAANAAwADAA MQBGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACoAAgEvAAAAMQAAAP////8AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAABEAAAALAAAAAAAAABfAF8AcwB1AGIAcwB0AGcAMQAuADAA XwAwAEUAMQBEADAAMAAxAEYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKgACAf////////////// /wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEUAAABoAAAAAAAAAF8AXwBzAHUA YgBzAHQAZwAxAC4AMABfADEAMAAwADAAMAAwADEARgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAq AAIBIgAAAEIAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARwAAAMgP AAAAAAAAXwBfAHMAdQBiAHMAdABnADEALgAwAF8AMQAwADAAOQAwADEAMAAyAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAACoAAgH///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAACHAAAAFgUAAAAAAACBAAAAggAAAIMAAACEAAAAhQAAAIYAAAD+////iAAAAIkAAACK AAAAiwAAAIwAAACNAAAAjgAAAI8AAACQAAAAkQAAAJIAAACTAAAAlAAAAJUAAACWAAAAlwAAAJgA AACZAAAAmgAAAJsAAAD+////nQAAAP7///+fAAAA/v///6EAAAD+////owAAAKQAAAD+////pgAA AKcAAAD+/////v////7////+////rAAAAP7////+////rwAAAP7////+/////v////7////+//// tQAAAP7////+/////v///7kAAAD+/////v///7wAAAC9AAAAvgAAAL8AAAD+/////v////7////+ ////xAAAAP7////+////xwAAAMgAAADJAAAAygAAAMsAAADMAAAA/v///84AAAD+/////v////7/ ///+////0wAAANQAAAD+/////v////7////YAAAA2QAAANoAAADbAAAA3AAAAN0AAADeAAAA3wAA AOAAAADhAAAA4gAAAOMAAADkAAAA5QAAAOYAAADnAAAA6AAAAOkAAADqAAAA6wAAAOwAAADtAAAA 7gAAAO8AAADwAAAA8QAAAP7////+////9AAAAP7////+/////v////7////+/////v////7////8 AAAA/v////4AAAD/AAAAAAEAAGUAIABmAHIAbwBtACAAdABoAGUAIABvAG4ALQBsAGkAbgBlACAA SQBuAHQAZQByAG4AZQB0AC0ARAByAGEAZgB0AHMAIABkAGkAcgBlAGMAdABvAHIAaQBlAHMALgAg AFQAaABpAHMAIABkAHIAYQBmAHQAIABpAHMAIABhACAAdwBvAHIAawAgAGkAdABlAG0AIABvAGYA IAB0AGgAZQAgAEEAdQBkAGkAbwAvAFYAaQBkAGUAbwAgAFQAcgBhAG4AcwBwAG8AcgB0ACAAQwBv AHIAZQAgAE0AYQBpAG4AdABlAG4AYQBuAGMAZQAgAFcAbwByAGsAaQBuAGcAIABHAHIAbwB1AHAA IABvAGYAIAB0AGgAZQAgAEkARQBUAEYALgANAAoADQAKAAkAVABpAHQAbABlACAAIAAgACAAIAAg ACAAIAAgACAAIAA6ACAAUgBUAEMAUAAgAGYAbwByACAAaQBuAHQAZQByAC0AZABlAHMAdABpAG4A YQB0AGkAbwBuACAAbQBlAGQAaQBhACAAcwB5AG4AYwBoAHIAbwBuAGkAegBhAHQAaQBvAG4ADQAK AAkAQQB1AHQAaABvAHIAKABzACkAIAAgACAAIAAgACAAIAA6ACAAUgBhAHkAIAB2AGEAbgAgAEIA cgBhAG4AZABlAG4AYgB1AHIAZwANAAoAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAg ACAAIAAgACAAIAAgACAAIAAgAEgAYQBuAHMAIABNAC4AIABTAHQAbwBrAGsAaQBuAGcADQAKACAA IAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIABNAC4AIABP AHMAawBhAHIAIAB2AGEAbgAgAEQAZQB2AGUAbgB0AGUAcgANAAoAIAAgACAAIAAgACAAIAAgACAA IAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgAE8AbQBhAHIAIABBAC4AIABOAGkAYQBt AHUAdAANAAoAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAA IAAgAEYAYQBiAGkAYQBuACAAQQAuACAAVwBhAGwAcgBhAHYAZQBuAA0ACgAgACAAIAAgACAAIAAg ACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAASQBzAGgAYQBuACAAVgBhAGkA cwBoAG4AYQB2AGkADQAKACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAg ACAAIAAgACAAIABGAGUAcgBuAGEAbgBkAG8AIABCAG8AcgBvAG4AYQB0AA0ACgAgACAAIAAgACAA IAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAATQBhAHIAaQBvACAATQBv AG4AdABhAGcAdQBkAA0ACgAJAEYAaQBsAGUAbgBhAG0AZQAgACAAIAAgACAAIAAgACAAOgAgAGQA cgBhAGYAdAAtAGkAZQB0AGYALQBhAHYAdABjAG8AcgBlAC0AaQBkAG0AcwAtADAAMQAuAHQAeAB0 AA0ACgAJAFAAYQBnAGUAcwAgACAAIAAgACAAIAAgACAAIAAgACAAOgAgADIANAANAAoACQBEAGEA dABlACAAIAAgACAAIAAgACAAIAAgACAAIAAgADoAIAAyADAAMQAxAC0AMAA3AC0AMAA2AA0ACgAN AAoAIAAgACAAVABoAGkAcwAgAGQAbwBjAHUAbQBlAG4AdAAgAGcAaQB2AGUAcwAgAGkAbgBmAG8A cgBtAGEAdABpAG8AbgAgAG8AbgAgAGEAbgAgAFIAVABDAFAAIABQAGEAYwBrAGUAdAAgAFQAeQBw AGUAIABhAG4AZAAgAFIAVABDAFAAIABYAFIADQAKACAAIAAgAEIAbABvAGMAawAgAFQAeQBwAGUA IABpAG4AYwBsAHUAZABpAG4AZwAgAGEAcwBzAG8AYwBpAGEAdABlAGQAIABTAEQAUAAgAHAAYQBy AGEAbQBlAHQAZQByAHMAIABmAG8AcgAgAGkAbgB0AGUAcgAtAGQAZQBzAHQAaQBuAGEAdABpAG8A bgANAAoAIAAgACAAbQBlAGQAaQBhACAAcwB5AG4AYwBoAHIAbwBuAGkAegBhAHQAaQBvAG4AIAAo AEkARABNAFMAKQAuACAAVABoAGUAIABSAFQAQwBQACAAWABSACAAQgBsAG8AYwBrACAAVAB5AHAA ZQAsACAAcgBlAGcAaQBzAHQAZQByAGUAZAAgAHcAaQB0AGgADQAKACAAIAAgAEkAQQBOAEEAIABi AGEAcwBlAGQAIABvAG4AIABhAG4AIABFAFQAUwBJACAAcwBwAGUAYwBpAGYAaQBjAGEAdABpAG8A bgAsACAAaQBzACAAdQBzAGUAZAAgAHQAbwAgAGMAbwBsAGwAZQBjAHQAIABtAGUAZABpAGEAIABw AGwAYQB5AC0ADQAKACAAIAAgAG8AdQB0ACAAaQBuAGYAbwByAG0AYQB0AGkAbwBuACAAZgByAG8A bQAgAHAAYQByAHQAaQBjAGkAcABhAG4AdABzACAAaQBuACAAYQAgAGcAcgBvAHUAcAAgAHAAbABh AHkAaQBuAGcALQBvAHUAdAAgACgAdwBhAHQAYwBoAGkAbgBnACwADQAKACAAIAAgAGwAaQBzAHQA ZQBuAGkAbgBnACwAIABlAHQAYwAuACkAIABhACAAcwBwAGUAYwBpAGYAaQBjACAAUgBUAFAAIABt AGUAZABpAGEAIABzAHQAcgBlAGEAbQAuACAAVABoAGUAIABSAFQAQwBQACAAcABhAGMAawBlAHQA IAB0AHkAcABlAA0ACgAgACAAIABzAHAAZQBjAGkAZgBpAGUAZAAgAGIAeQAgAHQAaABpAHMAIABk AG8AYwB1AG0AZQBuAHQAIABpAHMAIAB1AHMAZQBkACAAdABvACAAZABpAHMAdAByAGkAYgB1AHQA ZQAgAGEAIABzAHUAbQBtAGEAcgB5ACAAbwBmACAAdABoAGUADQAKACAAIAAgAGMAbwBsAGwAZQBj AHQAZQBkACAAaQBuAGYAbwByAG0AYQB0AGkAbwBuACAAcwBvACAAdABoAGEAdAAgAHQAaABlACAA cABhAHIAdABpAGMAaQBwAGEAbgB0AHMAIABjAGEAbgAgAHMAeQBuAGMAaAByAG8AbgBpAHoAZQAg AHAAbABhAHkALQANAAoAIAAgACAAbwB1AHQALgANAAoADQAKACAAIAAgAFQAeQBwAGkAYwBhAGwA IABhAHAAcABsAGkAYwBhAHQAaQBvAG4AcwAgAGYAbwByACAASQBEAE0AUwAgAGEAcgBlACAAcwBv AGMAaQBhAGwAIABUAFYALAAgAHMAaABhAHIAZQBkACAAcwBlAHIAdgBpAGMAZQAgAGMAbwBuAHQA cgBvAGwADQAKACAAIAAgACgAaQAuAGUALgAgAGEAcABwAGwAaQBjAGEAdABpAG8AbgBzACAAdwBo AGUAcgBlACAAdAB3AG8AIABvAHIAIABtAG8AcgBlACAAZwBlAG8AZwByAGEAcABoAGkAYwBhAGwA bAB5ACAAcwBlAHAAYQByAGEAdABlAGQAIAB1AHMAZQByAHMADQAKACAAIAAgAGEAcgBlACAAdwBh AHQAYwBoAGkAbgBnACAAYQAgAG0AZQBkAGkAYQAgAHMAdAByAGUAYQBtACAAdABvAGcAZQB0AGgA ZQByACkALAAgAGQAaQBzAHQAYQBuAGMAZQAgAGwAZQBhAHIAbgBpAG4AZwAsACAAbgBlAHQAdwBv AHIAawANAAoAIAAgACAAcQB1AGkAegAgAHMAaABvAHcAcwAsACAAbQB1AGwAdABpAC0AcABsAGEA eQBpAG4AZwAgAG8AbgBsAGkAbgBlACAAZwBhAG0AZQBzACwAIABlAHQAYwAuAA0ACgANAAoADQAK AA0ACgBBACAAVQBSAEwAIABmAG8AcgAgAHQAaABpAHMAIABJAG4AdABlAHIAbgBlAHQALQBEAHIA YQBmAHQAIABpAHMAOgANAAoAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkAZQB0AGYALgBvAHIAZwAv AGkAbgB0AGUAcgBuAGUAdAAtAGQAcgBhAGYAdABzAC8AZAByAGEAZgB0AC0AaQBlAHQAZgAtAGEA dgB0AGMAbwByAGUALQBpAGQAbQBzAC0AMAAxAC4AdAB4AHQADQAKAA0ACgBJAG4AdABlAHIAbgBl AHQALQBEAHIAYQBmAHQAcwAgAGEAcgBlACAAYQBsAHMAbwAgAGEAdgBhAGkAbABhAGIAbABlACAA YgB5ACAAYQBuAG8AbgB5AG0AbwB1AHMAIABGAFQAUAAgAGEAdAA6AA0ACgBmAHQAcAA6AC8ALwBm AHQAcAAuAGkAZQB0AGYALgBvAHIAZwAvAGkAbgB0AGUAcgBuAGUAdAAtAGQAcgBhAGYAdABzAC8A DQAKAA0ACgBUAGgAaQBzACAASQBuAHQAZQByAG4AZQB0AC0ARAByAGEAZgB0ACAAYwBhAG4AIABi AGUAIAByAGUAdAByAGkAZQB2AGUAZAAgAGEAdAA6AA0ACgBmAHQAcAA6AC8ALwBmAHQAcAAuAGkA ZQB0AGYALgBvAHIAZwAvAGkAbgB0AGUAcgBuAGUAdAAtAGQAcgBhAGYAdABzAC8AZAByAGEAZgB0 AC0AaQBlAHQAZgAtAGEAdgB0AGMAbwByAGUALQBpAGQAbQBzAC0AMAAxAC4AdAB4AHQADQAKAF8A XwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBf AF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwANAAoAQQB1AGQAaQBvAC8AVgBpAGQA ZQBvACAAVAByAGEAbgBzAHAAbwByAHQAIABDAG8AcgBlACAATQBhAGkAbgB0AGUAbgBhAG4AYwBl AA0ACgBhAHYAdABAAGkAZQB0AGYALgBvAHIAZwANAAoAaAB0AHQAcABzADoALwAvAHcAdwB3AC4A aQBlAHQAZgAuAG8AcgBnAC8AbQBhAGkAbABtAGEAbgAvAGwAaQBzAHQAaQBuAGYAbwAvAGEAdgB0 AA0ACgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAABIFAACxCQAATFpGdb0TrFgDAAoAcmNwZzEyNSIyA0N0ZXgFQmJp/mQEAAMwAQMB9wqAAqQD 5P8HEwKAEHMAUARWCFUHshGlJw5RAwECAGNoCsBzZdx0MgYABsMRpTMERhQ33jASrBGzCO8J9zsY nw4wdjURogxgYwBQCwkBZDPeNhbQC6YRQAezSQIwBJGhFKAtRHJhAYAgD1GcYXYLcAtgAmBlIANS mCB0aB9wAiAtbAuAnx9wHdwEIA9AGKBjdAWwQQiQcy4gVGgPUWTpHncgdwWwax6wDrAfwCRvZh/T QXUPQG8vclYPMGVvImAecACAcL8YQRKhGKAF0AtxDrBuAHAaYx9wVyOBC4BnIEcJA2B1cCQGSUVU Rv4uCqIKhAqBAZEiYCPAH2HFKfg6B/BUQ1AfgAWxSSZSci0BAHN0C4BhOyvgAiAgB4APQCNQc3nt JrBoA2ADAHosEyj5JIAjH+AFsChzKSo4YXk2IB8AA6BCJVEBAG5iXQhwZyiUKfkxvUgGIk31IlBT IfBrJyIwzzS9MxEYT3NrCsEv0kRldm8J8B3xM884DU8AwAXAQXUiUE4HMG0ugDcfOu1G7wGgBzAD oDlhVwdAHnA2sbM5/z4NSXMUYAOgVgtw+z8gJpB2AKA9LzsdBJEwMf0lIEIFsAIgLBBADzTeCsBn JLAF0AIhYWckkCj5Rt8DECaBB4AqKCLDLQiQADAqLR7wdAWhZUgAZG3gcy0wMS4M0EL1KVNOUEWg B5EqCjI0KPlErywQKepLMkkwMUkgN0kgjjYominxInRvY3UHgPECMCBnaTawBCALgCsRPwDALCMs QQORKsNKQGNrcxSgImB5cB9wMDEqtFh6UkMHQhgwUbBR9AuAY/cKQA9AJ0FhBBBPQAcwDrD5UnBT RCrwCrFG4R3xBCAfKx8tiCnxLH8sIyhJRD0F4CkiUh9wUpVTiSwg/xigT8Ar0ASQVWED8B/gQwfo SUFOHXBiVOBVYVDkuShQU0kswFIgVSBmDeC3LBNboA9RdV2yIfAgGBHPH2Ah4FhVC1F5LUMHCGD/ HqFQOR+TCrEr4FUgCrACML9QAiNBCcAnkmEiJzEtYgLcKHcsEBRQJzEsQwcgUJdcAQMAZgEgFKBj Li7w31ihXrUqsSrwWGV0GKA5sPdaKQqwUbN0UhFDB16lVWF+Yi+wH+BPCl+ZD0FpMGn/MIBMUVih T2A5IS+wJBRDB/9gRVVhUCpVAB/RLBAf02Nb/18QcVEs53IRYT4oi06yUhDzXwEDIGFwC1BfBVZk WdLPHuAmAVUDAyBUVlugPyH7XDIUkHI/4CbBBaACMANgwxiAQxYoaS5lIlB2m/Z3H/AmAXQjcCAQ BcAEYHsmAUpgbwnAdpAigHZRbP8vsBSQVdJVUl/BFIBDB3fyP2WmI0FoymABSmAf4XIp/1ugbdIm ox9gCsBnFB4hI3IZQwdxdS1QeNFvd3PrW6A5wGwr4C1k1SARIFN+Z0bhhMFnciibKKkdcFVcUkxW c2xDHd86KJRoQQJAcDovL3eLUC7lSBIuBbBnL1bDHiIiw/xzL0e/SM8o1iCud/IHQP9xcR74bBEA cAIgBsAIYAQg/kZokSwQinUBgIsSk5GLj9+MlyiaInOJbXMCYh9wGKD/bgE2oVJwkw+UH4yPjZ9J Ov5fnd+e75+6iBUknyWvJrH7KJScQUCaBoqIimCLPQDA2wMQA4EvZsJQIi+cQSiUAn2oAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADcAMQA0ADkAQgBDADAARQA3ADUA RABGADYANwA0ADUAQQA5AEIARAA4AEYARAA4ADAAOQAwADQARgBGAEQARQBAAHQAbgBvAC4AbgBs AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAAyADAA MQAxADAANwAwADYAMQAyADAANQAwADUALgAxADUAMAA1ADMALgA5ADgAMgAxADIALgBpAGQAdABy AGEAYwBrAGUAcgBAAGkAZQB0AGYAYQAuAGEAbQBzAGwALgBjAG8AbQA+AAAAAAAAAAAAAAAAAAAA AAAAAAAAAABfAF8AcwB1AGIAcwB0AGcAMQAuADAAXwAxADAAMQAzADAAMQAwADIAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAKgACATMAAAA1AAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAADEAAAC6EwAAAAAAAF8AXwBzAHUAYgBzAHQAZwAxAC4AMABfADEAMAAxADUAMAAw ADEARgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAqAAIB////////////////AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnAAAAE4AAAAAAAAAXwBfAHMAdQBiAHMAdABnADEALgAw AF8AMQAwADMANQAwADAAMQBGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACoAAgE0AAAAOAAAAP// //8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACeAAAAagAAAAAAAABfAF8AcwB1 AGIAcwB0AGcAMQAuADAAXwAxADAANAAzADAAMAAxAEYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA KgACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAAAABU AAAAAAAAADwhRE9DVFlQRSBIVE1MIFBVQkxJQyAiLS8vVzNDLy9EVEQgSFRNTCAzLjIvL0VOIj4N CjxIVE1MPg0KPEhFQUQ+DQo8TUVUQSBIVFRQLUVRVUlWPSJDb250ZW50LVR5cGUiIENPTlRFTlQ9 InRleHQvaHRtbDsgY2hhcnNldD11cy1hc2NpaSI+DQo8TUVUQSBOQU1FPSJHZW5lcmF0b3IiIENP TlRFTlQ9Ik1TIEV4Y2hhbmdlIFNlcnZlciB2ZXJzaW9uIDE0LjAxLjAyNzkuMDAwIj4NCjxUSVRM RT5bQVZUQ09SRV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1hdnRjb3JlLWlkbXMtMDEudHh0PC9U SVRMRT4NCjwvSEVBRD4NCjxCT0RZPg0KPCEtLSBDb252ZXJ0ZWQgZnJvbSB0ZXh0L3BsYWluIGZv cm1hdCAtLT4NCg0KPFA+PEZPTlQgU0laRT0yPkEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWls YWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4gVGhpcyBk cmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgQXVkaW8vVmlkZW8gVHJhbnNwb3J0IENvcmUgTWFp bnRlbmFuY2UgV29ya2luZyBHcm91cCBvZiB0aGUgSUVURi48L0ZPTlQ+PC9QPg0KDQo8UD4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPEZPTlQgU0laRT0yPlRpdGxl Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IDogUlRDUCBmb3IgaW50ZXItZGVzdGluYXRpb24gbWVkaWEgc3luY2hyb25pemF0aW9uPC9G T05UPg0KDQo8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxG T05UIFNJWkU9Mj5BdXRob3IocykmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg OiBSYXkgdmFuIEJyYW5kZW5idXJnPC9GT05UPg0KDQo8QlI+PEZPTlQgU0laRT0yPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBIYW5zIE0uIFN0b2traW5nPC9GT05UPg0KDQo8 QlI+PEZPTlQgU0laRT0yPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBNLiBP c2thciB2YW4gRGV2ZW50ZXI8L0ZPTlQ+DQoNCjxCUj48Rk9OVCBTSVpFPTI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9tYXIgQS4gTmlhbXV0PC9GT05UPg0KDQo8QlI+PEZP TlQgU0laRT0yPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBGYWJpYW4gQS4g V2FscmF2ZW48L0ZPTlQ+DQoNCjxCUj48Rk9OVCBTSVpFPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IElzaGFuIFZhaXNobmF2aTwvRk9OVD4NCg0KPEJSPjxGT05UIFNJWkU9 Mj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRmVybmFuZG8gQm9yb25hdDwv Rk9OVD4NCg0KPEJSPjxGT05UIFNJWkU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgTWFyaW8gTW9udGFndWQ8L0ZPTlQ+DQoNCjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgPEZPTlQgU0laRT0yPkZpbGVuYW1lJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDogZHJhZnQtaWV0Zi1hdnRjb3JlLWlkbXMtMDEu dHh0PC9GT05UPg0KDQo8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IDxGT05UIFNJWkU9Mj5QYWdlcyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA6IDI0PC9GT05UPg0KDQo8QlI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxGT05UIFNJWkU9Mj5EYXRlJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IDogMjAxMS0wNy0wNjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPiZuYnNwOyZuYnNw OyBUaGlzIGRvY3VtZW50IGdpdmVzIGluZm9ybWF0aW9uIG9uIGFuIFJUQ1AgUGFja2V0IFR5cGUg YW5kIFJUQ1AgWFI8L0ZPTlQ+DQoNCjxCUj48Rk9OVCBTSVpFPTI+Jm5ic3A7Jm5ic3A7IEJsb2Nr IFR5cGUgaW5jbHVkaW5nIGFzc29jaWF0ZWQgU0RQIHBhcmFtZXRlcnMgZm9yIGludGVyLWRlc3Rp bmF0aW9uPC9GT05UPg0KDQo8QlI+PEZPTlQgU0laRT0yPiZuYnNwOyZuYnNwOyBtZWRpYSBzeW5j aHJvbml6YXRpb24gKElETVMpLiBUaGUgUlRDUCBYUiBCbG9jayBUeXBlLCByZWdpc3RlcmVkIHdp dGg8L0ZPTlQ+DQoNCjxCUj48Rk9OVCBTSVpFPTI+Jm5ic3A7Jm5ic3A7IElBTkEgYmFzZWQgb24g YW4gRVRTSSBzcGVjaWZpY2F0aW9uLCBpcyB1c2VkIHRvIGNvbGxlY3QgbWVkaWEgcGxheS08L0ZP TlQ+DQoNCjxCUj48Rk9OVCBTSVpFPTI+Jm5ic3A7Jm5ic3A7IG91dCBpbmZvcm1hdGlvbiBmcm9t IHBhcnRpY2lwYW50cyBpbiBhIGdyb3VwIHBsYXlpbmctb3V0ICh3YXRjaGluZyw8L0ZPTlQ+DQoN CjxCUj48Rk9OVCBTSVpFPTI+Jm5ic3A7Jm5ic3A7IGxpc3RlbmluZywgZXRjLikgYSBzcGVjaWZp YyBSVFAgbWVkaWEgc3RyZWFtLiBUaGUgUlRDUCBwYWNrZXQgdHlwZTwvRk9OVD4NCg0KPEJSPjxG T05UIFNJWkU9Mj4mbmJzcDsmbmJzcDsgc3BlY2lmaWVkIGJ5IHRoaXMgZG9jdW1lbnQgaXMgdXNl ZCB0byBkaXN0cmlidXRlIGEgc3VtbWFyeSBvZiB0aGU8L0ZPTlQ+DQoNCjxCUj48Rk9OVCBTSVpF PTI+Jm5ic3A7Jm5ic3A7IGNvbGxlY3RlZCBpbmZvcm1hdGlvbiBzbyB0aGF0IHRoZSBwYXJ0aWNp cGFudHMgY2FuIHN5bmNocm9uaXplIHBsYXktPC9GT05UPg0KDQo8QlI+PEZPTlQgU0laRT0yPiZu YnNwOyZuYnNwOyBvdXQuPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+Jm5ic3A7Jm5i c3A7IFR5cGljYWwgYXBwbGljYXRpb25zIGZvciBJRE1TIGFyZSBzb2NpYWwgVFYsIHNoYXJlZCBz ZXJ2aWNlIGNvbnRyb2w8L0ZPTlQ+DQoNCjxCUj48Rk9OVCBTSVpFPTI+Jm5ic3A7Jm5ic3A7IChp LmUuIGFwcGxpY2F0aW9ucyB3aGVyZSB0d28gb3IgbW9yZSBnZW9ncmFwaGljYWxseSBzZXBhcmF0 ZWQgdXNlcnM8L0ZPTlQ+DQoNCjxCUj48Rk9OVCBTSVpFPTI+Jm5ic3A7Jm5ic3A7IGFyZSB3YXRj aGluZyBhIG1lZGlhIHN0cmVhbSB0b2dldGhlciksIGRpc3RhbmNlIGxlYXJuaW5nLCBuZXR3b3Jr PC9GT05UPg0KDQo8QlI+PEZPTlQgU0laRT0yPiZuYnNwOyZuYnNwOyBxdWl6IHNob3dzLCBtdWx0 aS1wbGF5aW5nIG9ubGluZSBnYW1lcywgZXRjLjwvRk9OVD4NCjwvUD4NCjxCUj4NCjxCUj4NCg0K PFA+PEZPTlQgU0laRT0yPkEgVVJMIGZvciB0aGlzIEludGVybmV0LURyYWZ0IGlzOjwvRk9OVD4N Cg0KPEJSPjxGT05UIFNJWkU9Mj48QSBIUkVGPSJodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy9kcmFmdC1pZXRmLWF2dGNvcmUtaWRtcy0wMS50eHQiPmh0dHA6Ly93d3cuaWV0Zi5v cmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtYXZ0Y29yZS1pZG1zLTAxLnR4dDwvQT48L0ZP TlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5JbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZh aWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6PC9GT05UPg0KDQo8QlI+PEZPTlQgU0laRT0yPjxB IEhSRUY9ImZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvIj5mdHA6Ly9mdHAuaWV0 Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLzwvQT48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9 Mj5UaGlzIEludGVybmV0LURyYWZ0IGNhbiBiZSByZXRyaWV2ZWQgYXQ6PC9GT05UPg0KDQo8QlI+ PEZPTlQgU0laRT0yPjxBIEhSRUY9ImZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv ZHJhZnQtaWV0Zi1hdnRjb3JlLWlkbXMtMDEudHh0Ij5mdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzL2RyYWZ0LWlldGYtYXZ0Y29yZS1pZG1zLTAxLnR4dDwvQT48L0ZPTlQ+DQoNCjxC Uj48Rk9OVCBTSVpFPTI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188L0ZPTlQ+DQoNCjxCUj48Rk9OVCBTSVpFPTI+QXVkaW8vVmlkZW8gVHJhbnNwb3J0IENv cmUgTWFpbnRlbmFuY2U8L0ZPTlQ+DQoNCjxCUj48Rk9OVCBTSVpFPTI+YXZ0QGlldGYub3JnPC9G T05UPg0KDQo8QlI+PEZPTlQgU0laRT0yPjxBIEhSRUY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vYXZ0Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2F2dDwvQT48L0ZPTlQ+DQo8L1A+DQoNCjwvQk9EWT4NCjwvSFRNTD4AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPABt AGEAaQBsAHQAbwA6AGEAdgB0AC0AcgBlAHEAdQBlAHMAdABAAGkAZQB0AGYALgBvAHIAZwA/AHMA dQBiAGoAZQBjAHQAPQBoAGUAbABwAD4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAA8AGgAdAB0AHAAcwA6AC8ALwB3AHcAdwAuAGkAZQB0AGYALgBvAHIAZwAvAG0A YQBpAGwAbQBhAG4ALwBsAGkAcwB0AGkAbgBmAG8ALwBhAHYAdAA+ACwACQA8AG0AYQBpAGwAdABv ADoAYQB2AHQALQByAGUAcQB1AGUAcwB0AEAAaQBlAHQAZgAuAG8AcgBnAD8AcwB1AGIAagBlAGMA dAA9AHMAdQBiAHMAYwByAGkAYgBlAD4AAAAAAAAAAAA8AGgAdAB0AHAAcwA6AC8ALwB3AHcAdwAu AGkAZQB0AGYALgBvAHIAZwAvAG0AYQBpAGwAbQBhAG4ALwBvAHAAdABpAG8AbgBzAC8AYQB2AHQA PgAsAAkAPABtAGEAaQBsAHQAbwA6AGEAdgB0AC0AcgBlAHEAdQBlAHMAdABAAGkAZQB0AGYALgBv AHIAZwA/AHMAdQBiAGoAZQBjAHQAPQB1AG4AcwB1AGIAcwBjAHIAaQBiAGUAPgAAAAAAAABfAF8A cwB1AGIAcwB0AGcAMQAuADAAXwAxADAANAA0ADAAMAAxAEYAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAKgACATcAAAA5AAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKIA AAC4AAAAAAAAAF8AXwBzAHUAYgBzAHQAZwAxAC4AMABfADEAMAA0ADUAMAAwADEARgAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAqAAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAApQAAALoAAAAAAAAAXwBfAHMAdQBiAHMAdABnADEALgAwAF8AMwAwADAAQgAw ADEAMAAyAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACoAAgE2AAAAPgAAAP////8AAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACoAAAAEAAAAAAAAABfAF8AcwB1AGIAcwB0AGcAMQAu ADAAXwAzADAAMQA0ADAAMQAwADIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKgACAf////////// /////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKkAAAAMAAAAAAAAAKzTJWMH Mg1Du/rfjc/VbOQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AADWAAAA8xT8sUEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAQgByAGEAbgBkAGUAbgBiAHUAcgBnACwAIABSAC4AIAAoAFIAYQB5ACkAIAB2AGEA bgAAAAAAAAAAAAAAAAAAAAAAAADcp0DIwEIQGrS5CAArL+GCAQAAAAAAAAAvTz1TRVJWSUNFTkVU IERFTEZUL09VPVRTTiBERUxGVC9DTj1SRUNJUElFTlRTL0NOPUJSQU5ERU5CVVJHUlYAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQgByAGEAbgBkAGUAbgBiAHUAcgBnACwAIABS AC4AIAAoAFIAYQB5ACkAIAB2AGEAbgAAAAAAAAAAAAAAAAAAAAAAAADcp0DIwEIQGrS5CAArL+GC AQAAAAAAAAAvTz1TRVJWSUNFTkVUIERFTEZUL09VPVRTTiBERUxGVC9DTj1SRUNJUElFTlRTL0NO PUJSQU5ERU5CVVJHUlYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAXwBfAHMA dQBiAHMAdABnADEALgAwAF8AMwBGAEYAOAAwADAAMQBGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ACoAAgE7AAAAPQAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACqAAAA MgAAAAAAAABfAF8AcwB1AGIAcwB0AGcAMQAuADAAXwAzAEYARgA5ADAAMQAwADIAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAKgACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAKsAAABcAAAAAAAAAF8AXwBzAHUAYgBzAHQAZwAxAC4AMABfADMARgBGAEEAMAAw ADEARgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAqAAIBPAAAAEAAAAD/////AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAArQAAADIAAAAAAAAAXwBfAHMAdQBiAHMAdABnADEALgAw AF8AMwBGAEYAQgAwADEAMAAyAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACoAAgH///////////// //8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACuAAAAXAAAAAAAAABfAF8AcwB1 AGIAcwB0AGcAMQAuADAAXwA0ADAAOAAzADAAMAAxAEYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA KgACAT8AAABBAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALAAAAAQ AAAAAAAAAF8AXwBzAHUAYgBzAHQAZwAxAC4AMABfADUARAAwADEAMAAwADEARgAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAqAAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAsQAAACgAAAAAAAAAXwBfAHMAdQBiAHMAdABnADEALgAwAF8ANQBEADAAMgAwADAA MQBGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACoAAgE6AAAASgAAAP////8AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAACyAAAAMAAAAAAAAABfAF8AcwB1AGIAcwB0AGcAMQAuADAA XwA2ADUARQAwADAAMQAwADIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKgACAf////////////// /wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALMAAAAWAAAAAAAAAGkAZQB0AGYA LgBvAHIAZwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABh AHYAdAAtAGIAbwB1AG4AYwBlAHMAQABpAGUAdABmAC4AbwByAGcAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAaQBuAHQAZQByAG4AZQB0AC0AZAByAGEAZgB0AHMAQABpAGUAdABmAC4AbwByAGcAAAAA AAAAAAAAAAAAAAAAAPzBAPyNawNMuIzYFzstoVgAAArx0nwAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAABFAD0AUwBvAHAAaABvAHMAOwBpAD0AIgA0AC4ANgA1ACwANAA4 ADYALAAxADMAMAA0ADIAOAA3ADIAMAAwACIAOwAgACAAIAAgAGQAPQAiAHMAYwBhAG4AJwAyADAA OAAiADsAYQA9ACIANQA0ADMAOQAzADQANgA1ACIAAAAAAGEAdgB0AC0AYgBvAHUAbgBjAGUAcwBA AGkAZQB0AGYALgBvAHIAZwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAtADkAOAAuADUAOQA5AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAXwBfAHMAdQBi AHMAdABnADEALgAwAF8ANgA1AEUAMwAwADEAMAAyAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACoA AgFDAAAARQAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+////AAAA AAAAAABfAF8AcwB1AGIAcwB0AGcAMQAuADAAXwA4ADAAMAAwADAAMAAxAEYAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAKgACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAALQAAAB8AAAAAAAAAF8AXwBzAHUAYgBzAHQAZwAxAC4AMABfADgAMAAwADEAMAAwADEA RgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAqAAIBRAAAAEgAAAD/////AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAtgAAACgAAAAAAAAAXwBfAHMAdQBiAHMAdABnADEALgAwAF8A OAAwADAAMgAwADAAMQBGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACoAAgH///////////////8A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC3AAAADgAAAAAAAABfAF8AcwB1AGIA cwB0AGcAMQAuADAAXwA4ADAAMAAzADAAMAAxAEYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKgAC AUcAAABJAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALgAAAB+AAAA AAAAAF8AXwBzAHUAYgBzAHQAZwAxAC4AMABfADgAMAAwADQAMAAwADEARgAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAqAAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAugAAAAgAAAAAAAAAXwBfAHMAdQBiAHMAdABnADEALgAwAF8AOAAwADAANQAwADAAMQBG AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACoAAgFGAAAAUgAAAP////8AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAC7AAAAHAEAAAAAAABfAF8AcwB1AGIAcwB0AGcAMQAuADAAXwA4 ADAAMAA2ADAAMAAxAEYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKgACAf///////////////wAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7///8AAAAAAAAAAEEAaAAwAEQAQQBC AHQAUABGAEUANQBBAHEAbQBJAGUAawBtAGQAcwBiADIASgBoAGIAQQBCAFQAbQBSAGkATwBhAHgA UQBCAEEAUQBFAEIAQwBRAHMATABCAHgASQBuAHoARwBhAEcATgBnAFMASABSAG8AcAA3AGsARgB3 AAAAdAByAHUAZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAE4AbwAsACAAcwBjAG8AcgBlAD0ALQA5ADgALgA1ADkAOQAgAHQAYQBnAGcAZQBk AF8AYQBiAG8AdgBlAD0ALQA5ADkAOQAgAHIAZQBxAHUAaQByAGUAZAA9ADUACQB0AGUAcwB0AHMA PQBbAEEAVwBMAD0ALQAzAC4AOQA3ADYALAAgAEIAQQBZAEUAUwBfADAAMAA9AC0AMgAuADUAOQA5 ACwAIABGAFIAVABfAFMAVABPAEMASwAxAD0AMwAuADkAOAA4ACwACQBGAFIAVABfAFMAVABPAEMA SwAyAD0AMwAuADkAOAA4ACwAIABVAFMARQBSAF8ASQBOAF8AVwBIAEkAVABFAEwASQBTAFQAPQAt ADEAMAAwAF0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAXwBfAHMAdQBiAHMA dABnADEALgAwAF8AOAAwADAANwAwADAAMQBGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACoAAgFL AAAATQAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAAAAALgAAAAAA AABfAF8AcwB1AGIAcwB0AGcAMQAuADAAXwA4ADAAMAA4ADAAMAAxAEYAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAKgACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAMEAAAAYAAAAAAAAAF8AXwBzAHUAYgBzAHQAZwAxAC4AMABfADgAMAAwADkAMAAwADEARgAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAqAAIATAAAAFAAAAD/////AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAwgAAAAwAAAAAAAAAXwBfAHMAdQBiAHMAdABnADEALgAwAF8AOAAw ADAAQQAwADAAMQBGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACoAAgH///////////////8AAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADDAAAAagAAAAAAAABhAG0AYQB2AGkAcwBk AC0AbgBlAHcAIABhAHQAIABhAG0AcwBsAC4AYwBvAG0AAAAAAAAAAAAAAAAAAAAAAAAAYQB2AHQA QABpAGUAdABmAC4AbwByAGcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ADIALgAxAC4AMQAyAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAABBAHUAZABpAG8ALwBWAGkAZABlAG8AIABUAHIAYQBuAHMAcABvAHIAdAAgAEMAbwBy AGUAIABNAGEAaQBuAHQAZQBuAGEAbgBjAGUAIAA8AGEAdgB0AC4AaQBlAHQAZgAuAG8AcgBnAD4A AAAAAAAAAAAAAAAAAAAAAAAAAAAAADwAbQBhAGkAbAB0AG8AOgBhAHYAdABAAGkAZQB0AGYALgBv AHIAZwA+AAAAAAAAAAAAAAAAAAAAAAAAAAAAAABGAGEAaQBsACAAKABFAFgAQwAtAEMAQQBTAEgA VQBCADAAMwAuAHQAcwBuAC4AdABuAG8ALgBuAGwAOgAgAGQAbwBtAGEAaQBuACAAbwBmACAAYQB2 AHQALQBiAG8AdQBuAGMAZQBzAEAAaQBlAHQAZgAuAG8AcgBnACAAZABvAF8AXwBzAHUAYgBzAHQA ZwAxAC4AMABfADgAMAAwAEIAMAAwADEARgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAqAAIBTwAA AFEAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAxQAAACoAAAAAAAAA XwBfAHMAdQBiAHMAdABnADEALgAwAF8AOAAwADAAQwAwADAAMQBGAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAACoAAgH///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AADGAAAAhAEAAAAAAABfAF8AcwB1AGIAcwB0AGcAMQAuADAAXwA4ADAAMABEADAAMAAxAEYAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAKgACAU4AAABWAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAM0AAABUAAAAAAAAAF8AXwBzAHUAYgBzAHQAZwAxAC4AMABfADgAMAAw AEUAMAAwADEARgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAqAAIB////////////////AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAzwAAAAQAAAAAAAAAZQBzACAAbgBvAHQAIABk AGUAcwBpAGcAbgBhAHQAZQAgADEAMwA0AC4AMgAyADEALgAxAC4AMQA2ACAAYQBzACAAcABlAHIA bQBpAHQAdABlAGQAIABzAGUAbgBkAGUAcgApACAAcgBlAGMAZQBpAHYAZQByAD0ARQBYAEMALQBD AEEAUwBIAFUAQgAwADMALgB0AHMAbgAuAHQAbgBvAC4AbgBsADsAIABjAGwAaQBlAG4AdAAtAGkA cAA9ADEAMwA0AC4AMgAyADEALgAxAC4AMQA2ADsAIABoAGUAbABvAD0AbQBhAGkAbABvAHUAdABh AC4AdABuAG8ALgBuAGwAOwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAA8AGgAdAB0AHAAOgAvAC8AdwB3AHcALgBpAGUAdABmAC4AbwBy AGcALwBtAGEAaQBsAC0AYQByAGMAaABpAHYAZQAvAHcAZQBiAC8AYQB2AHQAPgAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAE4ATwAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABfAF8AcwB1AGIAcwB0AGcA MQAuADAAXwA4ADAAMABGADAAMAAxAEYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKgACAVMAAABV AAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANAAAAAkAAAAAAAAAF8A XwBzAHUAYgBzAHQAZwAxAC4AMABfADgAMAAxADAAMAAwADEARgAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAqAAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 0QAAACQAAAAAAAAAXwBfAHMAdQBiAHMAdABnADEALgAwAF8AOAAwADEAMQAwADAAMQBGAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAACoAAgBUAAAAWAAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAADSAAAAmAAAAAAAAABfAF8AcwB1AGIAcwB0AGcAMQAuADAAXwA4ADAAMQAy ADAAMAAxAEYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKgACAf///////////////wAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANUAAAAuAAAAAAAAAGEAdgB0AEAAaQBlAHQAZgBh AC4AYQBtAHMAbAAuAGMAbwBtAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABhAHYAdABAAGkA ZQB0AGYAYQAuAGEAbQBzAGwALgBjAG8AbQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQgBU AD0AMAA7AEkASQA9ADwAaQBuAHYAYQBsAGkAZAA+ADsARgBJAFgAVQBQAD0AMQAsADQANgA1ADEA OwBWAGUAcgBzAGkAbwBuAD0AVgBlAHIAcwBpAG8AbgAgADEANAAuADEAIAAoAEIAdQBpAGwAZAAg ADIAOAA5AC4AMAApACwAIABTAHQAYQBnAGUAPQBIADEAMgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAARQBYAEMALQBDAEEAUwBIAFUAQgAwADMALgB0AHMAbgAuAHQAbgBv AC4AbgBsAAAAAAAAAAAAAAAAAAAAAAAAAEEAbgBvAG4AeQBtAG8AdQBzAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAAAAAgAAAAAAAAAA AAAAAAAAAEAABzACAAAAECJ7h7Y8zAFAAAgwAgAAABAie4e2PMwBXwBfAHMAdQBiAHMAdABnADEA LgAwAF8AOAAwADEAMwAwADAAMQBGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACoAAgFXAAAAWgAA AP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADWAAAAEgAAAAAAAABfAF8A cAByAG8AcABlAHIAdABpAGUAcwBfAHYAZQByAHMAaQBvAG4AMQAuADAAAAAAAAAAAAAAAAAAAAAA AAAAMAACAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANcA AACQBgAAAAAAAF8AXwByAGUAYwBpAHAAXwB2AGUAcgBzAGkAbwBuADEALgAwAF8AIwAwADAAMAAw ADAAMAAwADAAAAAAAAAAAAA6AAEBWQAAAGUAAABeAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAG5qH tjzMAcAbmoe2PMwBAAAAAAAAAAAAAAAAXwBfAHMAdQBiAHMAdABnADEALgAwAF8AMABGAEYANgAw ADEAMAAyAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACoAAgH///////////////8AAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADyAAAABAAAAAAAAAADAPcPAgAAAAAAAABcAEMAAwD0 DwIAAAACAAAARgBpAAMADTQCAAAAeQ4EAGMAcgAfAAQOAgAAAC4AAAADABMAHwADDgIAAAAcAAAA AwBTdx8AAg4CAAAAAgAAAAMAAAADAAcOBgAAAAEEAAAAAAAAAwDfPwYAAAD/////AAAAAAsAKQAG AAAAAAAAAAAAAAADAIEQBgAAAGcAAAAAAAAAQACCEAYAAAAAxjab1jvMAR8AHgwGAAAACgAAAAMA AAAfABoMBgAAACoAAAADAAAAHwAfDAYAAAAqAAAAAwAAAAIBGQwGAAAAdgAAAAMAShILACMABgAA AAAAAAAAAAAACwAIDAYAAAAAAAAAAAAAAAMAFw4GAAAAAAAAAAAAAAAfAEQABgAAADQAAAADAAAA HwBAAAYAAAA0AAAAAwAAAB8AGgAGAAAAEgAAAAMAAAADABcABgAAAAEAAAAAAAAAHwA3AAYAAABq AAAAAwAAAB8AHQ4CAAAAagAAAAMAAAAfAD0ABgAAAAIAAAADAAAAAwA2AAYAAAAAAAAAAAAAAB8A AV0GAAAAKgAAAAMAAAAfAEIABgAAADIAAAADAAAAHwBlAAYAAAAyAAAAAwAAAB8AZAAGAAAACgAA AAMAAAACAUEABgAAAIYAAAADAEoSHwACXQYAAAAyAAAAAwAAAEAABg4GAAAAlDvHRNU7zAFAADkA BgAAAIBuCvHUO8wBAwD9PwYAAADkBAAAAAAAAAIBcQAGAAAAFgAAAAMAShIfAHAABgAAAGoAAAAD AAAAAwABYgYAAACV5MWVAAAAAAIBOwAGAAAAHgAAAAMAShIfADUQBgAAAGwAAAADAAAAAwAAYgYA AADMzNciAAAAAAMA3j8GAAAAn04AAAAAAAACARMQBgAAALoTAAADAEoSAgEJEAYAAAAWBQAAAwBK EgsAHw4GAAAAAQAAAAAAAAAfAAAQBgAAAMoPAAADAAAAAwCAEAYAAAAFAQAAAAAAAAsAFjAGAAAA AQAAAAAAAAACAQswBgAAABAAAAADAEoSAgE/AAYAAABcAAAAAwBKEgIBQwAGAAAAXAAAAAMAShIC AVEABgAAAEMAAAADAEoSAgFSAAYAAABDAAAAAwBKEh8AdQAGAAAABgAAAAMAAAAfAHYABgAAAIAA AAADAAAAHwB3AAYAAAAGAAAAAwAAAB8AeAAGAAAAgAAAAAMAAAAfAH0ABgAAAOwWAAADAAAACwAG DAYAAAAAAAAAAAAAAAIBHQwGAAAAGgAAAAMAShIDAHkOBgAAAAEAAAAAAAAAHwAVEAYAAABQAAAA AwAAAB8AQxAGAAAAVgAAAAMAAAAfAEQQBgAAALoAAAADAAAAHwBFEAYAAAC8AAAAAwAAAAIBFDAG AAAADAAAAAMAShIDAPE/BgAAAAkEAAAAAAAAHwD4PwYAAAA0AAAAAwAAAAIB+T8GAAAAXAAAAAMA ShIfAPo/BgAAADQAAAADAAAAAgH7PwYAAABcAAAAAwBKEgMAGUAGAAAAAAABAAAAAAADABpABgAA AAAAAQAAAAAAAwAbQAYAAAAAAAAAAAAAAAMAHEAGAAAAAAAAAAAAAAADAHlABgAAAAMAAAAAAAAA HwCDQAYAAAASAAAAAwAAAAIB4GUGAAAAFgAAAAMAShICAeNlBgAAAAAAAAADAAAAHwAAgAYAAAB+ AAAAAwAAAB8AAYAGAAAAKgAAAAMAAAAfAAKABgAAABAAAAADAAAAHwADgAYAAACAAAAAAwAAAB8A BIAGAAAACgAAAAMAAAAfAAWABgAAAB4BAAADAAAAHwAGgAYAAAACAAAAAwAAAB8AB4AGAAAAMAAA AAMAAAAfAAiABgAAABoAAAADAAAAHwAJgAYAAAAOAAAAAwAAAB8ACoAGAAAAbAAAAAMAAAAfAAuA BgAAACwAAAADAAAAHwAMgAYAAACGAQAAAwAAAB8ADYAGAAAAVgAAAAMAAAAfAA6ABgAAAAYAAAAD AAAAHwAPgAYAAAAmAAAAAwAAAB8AEIAGAAAAJgAAAAMAAAAfABGABgAAAJoAAAADAAAAHwASgAYA AAAwAAAAAwAAAB8AE4AGAAAAFAAAAAMAAAALABSABgAAAAAAAAAAAAAACwAVgAYAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAgSsfpL6jEBmdbgDdAQ9UAgAAAYBpAC0AZAAtAGEAbgBuAG8AdQBuAGMAZQBAAGkAZQB0AGYA LgBvAHIAZwAAAFMATQBUAFAAAABpAC0AZAAtAGEAbgBuAG8AdQBuAGMAZQBAAGkAZQB0AGYALgBv AHIAZwAAAAAAAAAAAGkALQBkAC0AYQBuAG4AbwB1AG4AYwBlAEAAaQBlAHQAZgAuAG8AcgBnAAAA AAAAAAAAAAAAAAAAAAAAAAAAAABTAE0AVABQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaQAtAGQALQBhAG4AbgBvAHUAbgBjAGUAQABpAGUA dABmAC4AbwByAGcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAF8AXwBzAHUAYgBzAHQAZwAxAC4AMABf ADAARgBGAEYAMAAxADAAMgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAqAAIBWwAAAF0AAAD///// AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8wAAAHoAAAAAAAAAXwBfAHMAdQBi AHMAdABnADEALgAwAF8AMwAwADAAMQAwADAAMQBGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACoA AgH///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD1AAAAKgAA AAAAAABfAF8AcwB1AGIAcwB0AGcAMQAuADAAXwAzADAAMAAyADAAMAAxAEYAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAKgACAVwAAABgAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAPYAAAAIAAAAAAAAAF8AXwBzAHUAYgBzAHQAZwAxAC4AMABfADMAMAAwADMAMAAwADEA RgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAqAAIB////////////////AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAA9wAAACoAAAAAAAAAXwBfAHMAdQBiAHMAdABnADEALgAwAF8A MwAwADAAQgAwADEAMAAyAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACoAAgFfAAAAYgAAAP////8A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD4AAAAGwAAAAAAAABfAF8AcwB1AGIA cwB0AGcAMQAuADAAXwAzADkARgBFADAAMAAxAEYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKgAC Af///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPkAAAAqAAAA AAAAAF8AXwBzAHUAYgBzAHQAZwAxAC4AMABfADMAQQAyADAAMAAwADEARgAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAqAAIAYQAAAGMAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA+gAAACoAAAAAAAAAXwBfAHMAdQBiAHMAdABnADEALgAwAF8ANQBGAEYANwAwADEAMAAy AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACoAAgH/////ZAAAAP////8AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAD7AAAAegAAAAAAAABTTVRQOkktRC1BTk5PVU5DRUBJRVRGLk9S RwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaQAtAGQALQBhAG4AbgBvAHUA bgBjAGUAQABpAGUAdABmAC4AbwByAGcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGkALQBkAC0AYQBu AG4AbwB1AG4AYwBlAEAAaQBlAHQAZgAuAG8AcgBnAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA gSsfpL6jEBmdbgDdAQ9UAgAAAYBpAC0AZAAtAGEAbgBuAG8AdQBuAGMAZQBAAGkAZQB0AGYALgBv AHIAZwAAAFMATQBUAFAAAABpAC0AZAAtAGEAbgBuAG8AdQBuAGMAZQBAAGkAZQB0AGYALgBvAHIA ZwAAAAAAAAAAAAAAAAAAAAAAHwABMAYAAAAsAAAAAwAAAB8AAjAGAAAACgAAAAMAAAAfAAMwBgAA ACwAAAADAAAAAgH2DwYAAAAEAAAAAwCmAAMAFQwGAAAAAQAAAAAAAAACAf8PBgAAAHoAAAADAKUA AgELMAYAAAAbAAAAAwClAB8AIDoGAAAALAAAAAMAAAALAA8OBgAAAAEAAAAAAAAACwBAOgYAAAAA AAAAAAAAAAIB918GAAAAegAAAAMAShIfAP45BgAAAF8AXwBwAHIAbwBwAGUAcgB0AGkAZQBzAF8A dgBlAHIAcwBpAG8AbgAxAC4AMAAAAAAAAAAAAAAAAAAAAAAAAAAwAAIA////////////////AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/QAAABgBAAAAAAAAXwBfAHIAZQBjAGkA cABfAHYAZQByAHMAaQBvAG4AMQAuADAAXwAjADAAMAAwADAAMAAwADAAMQAAAAAAAAAAADoAAQD/ /////////2kAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAbmoe2PMwBwBuah7Y8zAEAAAAAAAAAAAAA AABfAF8AcwB1AGIAcwB0AGcAMQAuADAAXwAwAEYARgA2ADAAMQAwADIAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAKgACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAIBAAAEAAAAAAAAAF8AXwBzAHUAYgBzAHQAZwAxAC4AMABfADAARgBGAEYAMAAxADAAMgAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAqAAIBZgAAAGgAAAD/////AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAwEAAFYAAAAAAAAAAQEAAP7////+////BAEAAP7////+/////v// //7////+/////v////7///8MAQAA/v///w4BAAAPAQAAEAEAABEBAAD+//////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////8sAAAAAwAAAAMA/g8GAAAABgAAAAAAAAADAAA5 BgAAAAAAAAAAAAAAAwBxOgYAAAAAAAAAAAAAAAMA/V8GAAAAAQAAAAAAAAADAAAwBgAAAAAAAADe Hyo9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgSsf pL6jEBmdbgDdAQ9UAgAAAYBhAHYAdABAAGkAZQB0AGYALgBvAHIAZwAAAFMATQBUAFAAAABhAHYA dABAAGkAZQB0AGYALgBvAHIAZwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAGEAdgB0AEAAaQBlAHQAZgAuAG8AcgBnAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAABTAE0AVABQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAYQB2AHQAQABpAGUAdABmAC4AbwByAGcAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAF8AXwBzAHUAYgBzAHQAZwAxAC4AMABfADMAMAAw ADEAMAAwADEARgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAqAAIB////////////////AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQEAABgAAAAAAAAAXwBfAHMAdQBiAHMAdABn ADEALgAwAF8AMwAwADAAMgAwADAAMQBGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACoAAgFnAAAA awAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAQAACAAAAAAAAABf AF8AcwB1AGIAcwB0AGcAMQAuADAAXwAzADAAMAAzADAAMAAxAEYAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAKgACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAcBAAAYAAAAAAAAAF8AXwBzAHUAYgBzAHQAZwAxAC4AMABfADMAMAAwAEIAMAAxADAAMgAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAqAAIBagAAAG0AAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAACAEAABIAAAAAAAAAU01UUDpBVlRASUVURi5PUkcAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGEAdgB0AEAAaQBlAHQAZgAuAG8AcgBn AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABhAHYAdABAAGkAZQB0AGYA LgBvAHIAZwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIErH6S+ oxAZnW4A3QEPVAIAAAGAYQB2AHQAQABpAGUAdABmAC4AbwByAGcAAABTAE0AVABQAAAAYQB2AHQA QABpAGUAdABmAC4AbwByAGcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAB8AATAGAAAAGgAAAAMAAAAfAAIwBgAAAAoAAAADAAAAHwADMAYAAAAaAAAA AwAAAAIB9g8GAAAABAAAAAMApgADABUMBgAAAAIAAAAAAAAAAgH/DwYAAABWAAAAAwCnAAIBCzAG AAAAEgAAAAMApQAfACA6BgAAABoAAAADAAAACwAPDgYAAAABAAAAAAAAAAsAQDoGAAAAAAAAAAAA AAACAfdfBgAAAFYAAAADAEoSHwD+OQYAAABfAF8AcwB1AGIAcwB0AGcAMQAuADAAXwAzADkARgBF ADAAMAAxAEYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKgACAf///////////////wAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkBAAAYAAAAAAAAAF8AXwBzAHUAYgBzAHQAZwAx AC4AMABfADMAQQAyADAAMAAwADEARgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAqAAIAbAAAAG4A AAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgEAABgAAAAAAAAAXwBf AHMAdQBiAHMAdABnADEALgAwAF8ANQBGAEYANwAwADEAMAAyAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAACoAAgH/////bwAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAL AQAAVgAAAAAAAABfAF8AcAByAG8AcABlAHIAdABpAGUAcwBfAHYAZQByAHMAaQBvAG4AMQAuADAA AAAAAAAAAAAAAAAAAAAAAAAAMAACAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAA0BAAAYAQAAAAAAABoAAAADAAAAAwD+DwYAAAAGAAAAAAAAAAMAADkGAAAA AAAAAAAAAAADAHE6BgAAAAAAAAAAAAAAAwD9XwYAAAABAAAAAAAAAAMAADAGAAAAAQAAAN4fKj0A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA --00148536e646d6e1ce04a77c10dc-- From mmagliaro@bnisolutions.com Thu Jul 7 15:37:36 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BB3121F88FD for ; Thu, 7 Jul 2011 15:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mKX2jjMEnV7F for ; Thu, 7 Jul 2011 15:37:35 -0700 (PDT) Received: from webmail.numerex.com (webmail.numerex.com [12.36.158.243]) by ietfa.amsl.com (Postfix) with ESMTP id 1ECB721F88FC for ; Thu, 7 Jul 2011 15:37:35 -0700 (PDT) Received: from [192.168.195.3] (71.193.225.106) by webmail.numerex.com (172.31.3.210) with Microsoft SMTP Server (TLS) id 8.1.393.1; Thu, 7 Jul 2011 18:37:34 -0400 Message-ID: <4E16355F.7050108@bnisolutions.com> Date: Thu, 7 Jul 2011 15:38:23 -0700 From: Max Magliaro User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.15) Gecko/20101027 Thunderbird/3.0.10 MIME-Version: 1.0 To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Subject: [AVTCORE] Knowing when to use RFC 2190 vs. RFC 2429/4629 for H.263 video? X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 22:52:54 -0000 RFC 2429 is the preferred format (actually 4629 now). However, 2190 may still have to be used for some legacy systems. If I am one of those legacy endpoints, (and I am) what, in the H.245 call signalling of an H.323 call, do I use to indicate to the other end NOT to send me the newer-style payload header? Specifically, I note that when I call to a Polycom RMX system, it exchanges H.263 with me just fine. However, if it opens a secondary H.239 collaboration video channel, it sends that one with the newer-style headers. When I call a Tandberg system, this doesn't happen (they send 2190 style headers in the collaboration channel and everything works). If I try this with a Polycom VSX, it doesn't do this (all works fine). I assume there is some "hint" in my capability set that I need to set, or avoid setting, so that all endpoints (including Polycom's RMX) will know to not send the newer-style headers. Or maybe it's the opposite, that there is something in the capabilities I need to NOT set. I realize that the ideal solution would be to support the current header structure, but I do not have that option available to me. If anyone has a hint as to how Polycom makes that decision to send RFC 2190 or RFC 2429/4629, I would appreciate it. Thank you, Max Magliaro Broadband Networks, Inc From magnus.westerlund@ericsson.com Fri Jul 8 01:37:13 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81C2A21F85A7 for ; Fri, 8 Jul 2011 01:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.204 X-Spam-Level: X-Spam-Status: No, score=-106.204 tagged_above=-999 required=5 tests=[AWL=-0.205, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jSZSfvCDkxZd for ; Fri, 8 Jul 2011 01:37:12 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 7BB6321F85A6 for ; Fri, 8 Jul 2011 01:37:11 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-db-4e16c1b656ec Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 41.00.20773.6B1C61E4; Fri, 8 Jul 2011 10:37:10 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Fri, 8 Jul 2011 10:37:10 +0200 Message-ID: <4E16C1B2.2000608@ericsson.com> Date: Fri, 8 Jul 2011 10:37:06 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: IETF AVTCore WG X-Enigmail-Version: 1.1.1 Content-Type: multipart/mixed; boundary="------------080405040903000402000500" X-Brightmail-Tracker: AAAAAA== Subject: [AVTCORE] Fwd: Re: [MMUSIC] Issues with bandwidth modifiers in SDP X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 08:37:13 -0000 --------------080405040903000402000500 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit WG, I received comments from Randell Jesup on the MMUSIC reflector, but I think they are equally relevant to this WG. So here it he comments with my response to them. --------------080405040903000402000500 Content-Type: message/rfc822; name="Re: [MMUSIC] Issues with bandwidth modifiers in SDP.eml" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Re: [MMUSIC] Issues with bandwidth modifiers in SDP.eml" Received: from mailgw7.ericsson.se (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.86) with Microsoft SMTP Server id 8.3.137.0; Fri, 8 Jul 2011 10:22:12 +0200 Received: from mail.ietf.org (mail.ietf.org [64.170.98.30]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 0A.67.25859.33EB61E4; Fri, 8 Jul 2011 10:22:12 +0200 (CEST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89CA721F85BD; Fri, 8 Jul 2011 01:22:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 160C021F85BD for ; Fri, 8 Jul 2011 01:21:59 -0700 (PDT) Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jDLNK9GIVsF7 for ; Fri, 8 Jul 2011 01:21:57 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 64B6A21F85BC for ; Fri, 8 Jul 2011 01:21:57 -0700 (PDT) Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id BE.35.09774.32EB61E4; Fri, 8 Jul 2011 10:21:56 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Fri, 8 Jul 2011 10:21:55 +0200 From: Magnus Westerlund To: Randell Jesup CC: "mmusic@ietf.org" Sender: "mmusic-bounces@ietf.org" Date: Fri, 8 Jul 2011 10:21:51 +0200 Subject: Re: [MMUSIC] Issues with bandwidth modifiers in SDP Thread-Topic: [MMUSIC] Issues with bandwidth modifiers in SDP Thread-Index: Acw9SCO690t+w3gIQFOHb86cswKDKg== Message-ID: <4E16BE1F.6080807@ericsson.com> References: <4E157269.1000200@ericsson.com> <4E15CD36.4050308@jesup.org> List-Help: List-Subscribe: , List-Unsubscribe: , In-Reply-To: <4E15CD36.4050308@jesup.org> Accept-Language: en-US Content-Language: en-US X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AuthSource: esessmw0191.eemea.ericsson.se X-MS-Has-Attach: X-Auto-Response-Suppress: All X-MS-TNEF-Correlator: x-auditid: c1b4fb30-b7ba2ae000006503-4f-4e16be338547 x-brightmail-tracker: AAAAAA== user-agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 errors-to: mmusic-bounces@ietf.org x-virus-scanned: amavisd-new at amsl.com x-mailman-version: 2.1.12 list-post: list-archive: list-id: Multiparty Multimedia Session Control Working Group x-beenthere: mmusic@ietf.org x-spam-level: x-spam-status: No, score=-106.217 tagged_above=-999 required=5 tests=[AWL=-0.218, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] x-spam-score: -106.217 x-spam-flag: NO delivered-to: mmusic@ietfa.amsl.com x-original-to: mmusic@ietfa.amsl.com x-enigmail-version: 1.1.1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Hi Randell, Thanks for the feedback. See inline for feedback on your comments. On 2011-07-07 17:13, Randell Jesup wrote: > On 7/7/2011 4:46 AM, Magnus Westerlund wrote: >> Hi, >> >> Bo Burman and I have written an I-D that discusses a number of issues >> around conferencing, including handling of multiple SSRCs in the same >> RTP session. This also has brought forward an issue with the current >> bandwidth modifiers. They are very ill suited when you have both >> asymmetric conditions based on which direction the flows goes and how to >> indicate individual streams versus limits for the whole aggregate. This >> include the issue of having payload specific per stream upper bounds. >> >> https://datatracker.ietf.org/doc/draft-westerlund-avtcore-multistream-an= d-simulcast/ > > Up front: realize I'm commenting as I read, but that means that it's > also an indication if > something wasn't clear up-front without reading more of later parts of > the spec. > > > The purpose of the document is a little fuzzy - is it for simulcast (as > stated and defined > in the doc) or for both multiple-source and simulcast (as implied in the > document and its > title). It seems to be the former, but the title and some early > statements imply it's both. Yes, this is document that has grown while we wrote it. I actually expect that we start splitting up the different pieces into individual documents and tries to clarify what is applicable in what case. But our intention from the start is to address both cases. But yes we started with simulcast and for that we do need to resolve the multiple SSRC in RTP session problems. So simulcast requires multiple SSRCs, however multiple SSRC has many usages beyond simulcast. > > Also it should be made clear (if it isn't; I'm reading fast) that these > mixer cases specifically > would include one-to-one communication through a server. Also: should > this discuss > non-mixer cases (point-to-point simulcast)? I think so. We tried to be clear that our main focus for simulcast is the centralized case using a RTP mixer that selects which version to forward. But Section 3 does look at the other usages of simulcast, like point to point. > > Thus there has been perceived little need for > handling multiple SSRCs in implementations. This has resulted in an > installed legacy base that isn't fully RTP specification compliant > and will have different issues if they receive multiple SSRCs of > media, either simultaneously or in sequence. These issues will > manifest themselves in various ways, either by software crashes, or > simply in limited functionality, like only decoding and playing back > the first or latest SSRC received and discarding any other SSRCs. > > > As an implementer of a point-to-point videophone, we handled SSRC changes= , > but only were set up to decode one stream at a time (especially of > video). (A later > phone could decode up to 3 and encode 1 when acting as a bridge for an > ad-hoc video conference.) > > Our algorithm was to immediately react to an SSRC change, but then lock > out changes > for a (short) period because since we only played one stream at a time > we didn't want to reset the > codec on every other incoming packet. This also helped us with a few > other usecases involving > various B2BUA-ish servers and server-mediated call transfers, etc. > > Not truly compliant per-se, of course, but worked for the usecases we > needed to deal with. Yes, and what you say is a confirmation of the claim we are making. There is a number of implementations that has limited support for multiple SSRCs but they don't express that in signalling. Therefore to make these multiple SSRC applications work well going forward we need explicit signalling of the number of simultanous SSRCs one support. > > Simulcasting has the benefit that it is conceptually simple. It > enables use of any media codec that the participants agree on, > allowing the mixer to be codec-agnostic. Considering today's video > encoders, it is less bit-rate efficient in the path from the sending > client to the mixer but more efficient in the mixer to receiver path > compared to Scalable Video Coding. > > > If you're targeting a single lower-bitrate encoding, yes. If the > bandwidth down to each receiver > is adaptive to their available bandwidth (think mobile reception, or > WiFi) then giving the mixer > the ability to subset differently for each receiver without having to > re-encode. (And it avoids > having to tell the sender to change bitrates if one of the receivers > needs a lower rate than the > sender is sending, and it avoids giving all the other recipients a > lowest-common-denominator > stream). Of course this is part of the entire value-proposition of SVC > - that it enables this sort of > optimized reception with a single encoding and a low-horsepower mixer. > Yes, I realize I'm saying > fairly obvious things here. Exactly, this is the whole point of simulcasting. And our research hows that this has some advantages over SVC. > > If only resolution and temporal variations > are needed, this can be implemented using H.264, as each simulcast > version provides the different resolution, and each media stream > within a simulcast encoding has temporal scalability using no- > reference frames. > > > Note that this implies that the mixer parses the H.264 to the point > where it knows if the frame > will be used as a reference frame. Not a problem, and probably doesn't > require any change to the text. Yes. you need to look at the NRI bits in the H.264 RTP payload header to make this determination. But you need to do similar operations in an SVC MANE if you single stream transport (SST) payload mode. So no real difference for the temporal scalability operation. > > Even within SVC (and you may have stated or implied this) you could make > multiple encodings > with differently-targeted layers - for example a "low" set targeting > bandwidths <500K, and a > high set for 500K and up. This might help avoid the problem of too many > layers degrading > the bit-efficiency of the encoding. I try to make clear that I see combining SVC for medium and fine-grained scalability while using different SVC encodings for the large steps and send them as simulcasts to improve the efficiency of the system as an option. > > 3.2. Simulcasting to Consuming End-Point > > > This section is clearly based on the assumption (up front) that the > streams are in fact identical > content with different encodings. Not a problem, especially if the > target of the document is > a little clearer. Yes, we always target simulcast where the original source of the content is the same, only the encoded representation is different. > > 3.3 and 3.4: These assume no mixer, right? Yes. > > 4.3: negotiation of transmission side - how does an endpoint indicate > these are "equivalent" > streams and not "alternative" streams (different camera/mic, etc). How > are the differing > encodings negotiated, or is that out of scope? (I'd think it would be > in-scope, because the mixer > is the one who knows who's connected to it and their capabilities.) I hope you got this explained when you read on. We have the SCS and SCR grouping semantics to indicate that media lines are simulcast alternatives to each other. The actual SSRCs in the different RTP sessions are paired as alternatives using the SRCNAME SDES item. In practice SRCNAME that are identical for media streams of the same media type are alternatives to each other. The negotiation of what alternative stream is done as regular offer/answer for each media line, thus allowing us to avoid re-inventing that mechanism. > > 4.5: SDP signaling and bandwidth - b=3DAS could be used in theory for > either direction, however > the general offer/answer semantic is that you define what you're > willing/ready to receive, not send, > so b=3DAS would be the downstream direction, not the highest of upstream > or downstream - I don't > know of any that use it that way today. Some use upstream (perhaps > most), some use downstream. Yes, I think there is great confusion around how the bandwidth modifier actually are used. Our examples in the end do use b=3DAS as receive direction only. The discussion in this section may not be as consistent. I think the main point from our side is that there is need for additional bandwidth signalling attributes to allow one to express assymetric capabilities vs desire and do O/A negotiation of it. And do that both for individual steams and encoding proposals and for the whole session aggregate. > Also there should be discussion of how RTCP TMMBR fits into this. Likely, from my perspective TMMBR has quite clear semantics as it applies to a particular SSRC. Thus the stream and direction for a given TMMBR limiation is clear. But, I guess it is good to understand what the upper limit for that stream may be. > > nit in 6.2: > > When one have multiple actual media sources in a session, > > have->has Ok > > 7.1.2: SSRC Multiplexing > > Note that "legacy" receivers will often be much happier with NO SSRC chan= ge when the > mixer switches streams. While in theory they should handle them, not all= do. And even > if they do, they may cause glitches at the transition (decoder resets, et= c). Yes, they > shouldn't do that. Full agree, and as this is an RTP mixer I assume that the mixer will have its own SSRC value that it uses to send what ever stream it mixes or selects from the incomming the content of the media, but sent as a consistent media stream from the mixers SSRC. Thus we don't have SSRC switching. The issue I bring up is that of the CSRC field. If one include CSRC then that changes. But, in fact I think this is mostly a mote argument. Also for Session multiplexing we likely will have this issue as using different SSRCs in the different RTP sessions have advantages. > > > NAT Traversal Failure Rate: Due to that one need more than a single > flow to be established through the NAT there is some risk that one > succeed in establishing the first flow but fails with one or more > of the additional flows. The risk that this happens are hard to > quantify. However, that risk should be fairly low as one has just > prior successfully established one flow from the same interfaces. > Thus only rare events as NAT resource overload, or selecting > particular port numbers that are filtered etc, should be reasons > for failure. > > As the number of flows increases, the odds of a lost packet (or congestio= n) > increase. The pacing timer should help with this, but even so I believe = the > odds of problems will increase above a linear rate. However, this is an > off-the-cuff assessment and I haven't followed the ICE discussions (N zil= lion MB > of them...). :-) Maybe, and I would love to know how real the issue is. Also, to a certain degree this is an orthogonal problem if it is real. Because it will occur also for SSRC multiplexing as even that case has multiple underlying UDP flows, just a few less than Session multiplexed Simulcast. > > 8.2. Mixer Requests of Client streams > > I'd guess TMMBR of 0 may not go over well with some existing clients, or = may be ignored. Very much possible. We plan to follow up on this topic in the future. > > 8.4 Multiplexing sessions > > This touches on the discussions currently in rtcweb Yes, it does. It has also been voiced in discussion around CLUE interest of multiplexing multiple sessions on top one underlying transport flow. My main point is that it is separate problem that needs to be addressed somehow. If you are interested in this problem I would recommend that one do read the next version of: https://datatracker.ietf.org/doc/draft-perkins-rtcweb-rtp-usage/ It will be out on Monday. Which tries to make clear the issues which the Rosenberg's proposal and discuss possible ways forward for that topic. https://datatracker.ietf.org/doc/draft-rosenberg-rtcweb-rtpmux/ > > 8.5.1.2 Multiple sources (telepresence) > > Ok, this confuses me as the discussion I thought was of simultaneous enco= dings > of the same data, not true different sources. Well, this is the case that tries to make it clear how you can combine multiple real media source, like several cameras in a telepresence room, with simulcast. > > At this point I'm afraid my eyes have glazed over reading the (very nicel= y detailed > and explained) SDP examples. :-) Yes, those examples are quite beefy. But, I do hope that they will help people understand, it also helped us making clear that we had a coherent story for many of the different usages we see for what we propose. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --------------080405040903000402000500-- From vsingh.ietf@gmail.com Fri Jul 8 02:29:12 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8586221F892E for ; Fri, 8 Jul 2011 02:29:12 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Emd8ZrrpJLTX for ; Fri, 8 Jul 2011 02:29:11 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 735F021F892D for ; Fri, 8 Jul 2011 02:29:11 -0700 (PDT) Received: by bwb17 with SMTP id 17so1832036bwb.31 for ; Fri, 08 Jul 2011 02:29:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=date:from:to:message-id:subject:x-mailer:mime-version:content-type :content-transfer-encoding:content-disposition; bh=CAwP9PA6MIfjMD88tbCpKAuPZG0sV4Lpfxpq3xkJd9k=; b=EtxskPqTSBvdIGwumbgjmp460x9OGybSt0u6OCJqieqCi4DvzE4+k2pTknDr9rwgdD bUFH0X7l6wuTW3Qn12bl/tP1SVntXqLgsq5YIPBCUIE9jrdl+zIqr5SoEO3n8FevPfGt IDjOJOKlnCOgnYjEoH0j8/Vb9IOeOf5Vg99XM= Received: by 10.204.156.25 with SMTP id u25mr1337347bkw.43.1310117350264; Fri, 08 Jul 2011 02:29:10 -0700 (PDT) Received: from client-103.research.netlab.hut.fi (client-103.research.netlab.hut.fi [195.148.127.104]) by mx.google.com with ESMTPS id p15sm164788bke.46.2011.07.08.02.29.09 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 08 Jul 2011 02:29:09 -0700 (PDT) Date: Fri, 8 Jul 2011 12:29:07 +0300 From: Varun Singh To: "=?utf-8?Q?avt=40ietf.org?=" Message-ID: <6FFE8E143789441CB899531A3F702EC2@gmail.com> X-Mailer: sparrow 1.2.2 (build 767.31) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: [AVTCORE] FW: New Version Notification for draft-singh-avtcore-mprtp-02.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 09:29:12 -0000 Greetings, We have updated the MPRTP draft and the following changes have been made: - RTCP uses only one code point (just realized that this should be 211 as 210 is taken) - MPRTP Header extension uses the one-byte header format instead of two-byte - Changes in SDP consideration: introduced an "interface" attribute in SDP, as an alternative to in-band interface advertisement, some O/A examples are also included. The detailed diff can be seen at http://tools.ietf.org/rfcdiff?url2=draft-singh-avtcore-mprtp-02.txt Regards, Varun Begin forwarded message: > > A new version of I-D, draft-singh-avtcore-mprtp-02.txt has been successfully submitted by Varun Singh and posted to the IETF repository. > > Filename: draft-singh-avtcore-mprtp > Revision: 02 > Title: Multipath RTP (MPRTP) > Creation date: 2011-07-08 > WG ID: Individual Submission > Number of pages: 34 > > Abstract: > The Real-time Transport Protocol (RTP) is used to deliver real-time > content and, along with the RTP Control Protocol (RTCP), forms the > control channel between the sender and receiver. However, RTP and > RTCP assume a single delivery path between the sender and receiver > and make decisions based on the measured characteristics of this > single path. Increasingly, endpoints are becoming multi-homed, which > means that they are connected via multiple Internet paths. Network > utilization can be improved when endpoints use multiple parallel > paths for communication. The resulting increase in reliability and > throughput can also enhance the user experience. This document > extends the Real-time Transport Protocol (RTP) so that a single > session can take advantage of the availability of multiple paths > between two endpoints. > > > > > The IETF Secretariat -- Varun Singh http://www.netlab.tkk.fi/~varun From sato652@oki.com Fri Jul 8 01:14:26 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0886021F86FF for ; Fri, 8 Jul 2011 01:14:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ovj+ghgWfijn for ; Fri, 8 Jul 2011 01:14:25 -0700 (PDT) Received: from gwf1.oki.co.jp (gwf1.oki.co.jp [202.226.91.186]) by ietfa.amsl.com (Postfix) with ESMTP id AD9E121F86EC for ; Fri, 8 Jul 2011 01:14:23 -0700 (PDT) Received: by gwf1.oki.co.jp (Postfix, from userid 0) id 026A3CFA4E; Fri, 8 Jul 2011 17:14:25 +0900 (JST) Received: from s111h121.dm1.oii.oki.co.jp [172.26.101.121] by gwf1.oki.co.jp with ESMTP id TAA28889; Fri, 8 Jul 2011 17:14:25 +0900 Received: from s111h121.dm1.oii.oki.co.jp (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 589BB398002; Fri, 8 Jul 2011 17:14:22 +0900 (JST) Received: from s24c40.dm1.oii.oki.co.jp (s24c40.dm1.oii.oki.co.jp [172.26.76.90]) by s111h121.dm1.oii.oki.co.jp (Postfix) with ESMTP id 446B8398007; Fri, 8 Jul 2011 17:14:22 +0900 (JST) Received: from PC26276 (wl17.kansai.oki.co.jp [10.173.11.17]) by s24c40.dm1.oii.oki.co.jp (Postfix) with ESMTP id 064D225F6DB; Fri, 8 Jul 2011 17:14:22 +0900 (JST) From: "Noriyuki SATO" To: "'RFC Errata System'" , , , , , , , , References: <20110705161819.E460F98C4EF@rfc-editor.org> Date: Fri, 8 Jul 2011 17:14:21 +0900 Message-ID: <205B442E1E9F44A6B0171183D5835E14@power.oki.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 In-Reply-To: <20110705161819.E460F98C4EF@rfc-editor.org> Thread-Index: Acw7LyqIU0ZcHpBORFW5Zk5VM1THIgCFl58g X-Mailman-Approved-At: Fri, 08 Jul 2011 08:03:19 -0700 Cc: avt@ietf.org Subject: Re: [AVTCORE] [Technical Errata Reported] RFC4585 (2853) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 08:14:26 -0000 Hi All, I don't see any problem on applying these errata. --- OKI Electric Industry Co., Ltd. Noriyuki Sato (sato652@oki.com) Tel +81-6-6260-0700 Fax +81-6-6260-0770 > -----Original Message----- > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > Sent: Wednesday, July 06, 2011 1:18 AM > To: jo@acm.org; stewe@stewe.org; sato652@oki.com; > carsten.burmeister@eu.panasonic.com; jose.rey@eu.panasonic.com; > gonzalo.camarillo@ericsson.com; rjsparks@nostrum.com; > keith.drage@alcatel-lucent.com; even.roni@huawei.com > Cc: abegen@cisco.com; avt@ietf.org; rfc-editor@rfc-editor.org > Subject: [Technical Errata Reported] RFC4585 (2853) > > > The following errata report has been submitted for RFC4585, > "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based > Feedback (RTP/AVPF)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=4585&eid=2853 > > -------------------------------------- > Type: Technical > Reported by: Ali Begen > > Section: 4.2 > > Original Text > ------------- > OLD: > rtcp-fb-param = SP "app" [SP byte-string] > / SP token [SP byte-string] > / ; empty > NEW: > rtcp-fb-param = [ SP "app" [SP byte-string] > / SP token [SP byte-string] ] > > > OLD: > rtcp-fb-ack-param = SP "rpsi" > / SP "app" [SP byte-string] > / SP token [SP byte-string] > / ; empty > NEW: > rtcp-fb-ack-param = [ SP "rpsi" > / SP "app" [SP byte-string] > / SP token [SP byte-string] ] > > > OLD: > rtcp-fb-nack-param = SP "pli" > / SP "sli" > / SP "rpsi" > / SP "app" [SP byte-string] > / SP token [SP byte-string] > / ; empty > NEW: > rtcp-fb-nack-param = [ SP "pli" > / SP "sli" > / SP "rpsi" > / SP "app" [SP byte-string] > / SP token [SP byte-string] ] > > > Corrected Text > -------------- > > > Notes > ----- > During the AUTH48 of RFC 6285, we discovered a bug with the ABNF syntax in RFC > 4585. The original ABNF in Section 4.2 (as noted above) is incorrect ("/ ;empty" > is not a valid ABNF - RFC 5234 does not allow empty alternates). > > The NEW text intends to fix it. There are 3 places where the same change should > be applied (changes are identical). > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC4585 (draft-ietf-avt-rtcp-feedback-11) > -------------------------------------- > Title : Extended RTP Profile for Real-time Transport Control > Protocol (RTCP)-Based Feedback (RTP/AVPF) > Publication Date : July 2006 > Author(s) : J. Ott, S. Wenger, N. Sato, C. Burmeister, J. Rey > Category : PROPOSED STANDARD > Source : Audio/Video Transport > Area : Real-time Applications and Infrastructure > Stream : IETF > Verifying Party : IESG From Jose.Rey@eu.panasonic.com Fri Jul 8 01:32:14 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BFC821F85B7 for ; Fri, 8 Jul 2011 01:32:14 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CdCzm8uNG-hg for ; Fri, 8 Jul 2011 01:32:13 -0700 (PDT) Received: from cluster-g.mailcontrol.com (cluster-g.mailcontrol.com [208.87.233.190]) by ietfa.amsl.com (Postfix) with ESMTP id C0E2121F8599 for ; Fri, 8 Jul 2011 01:32:13 -0700 (PDT) Received: from rly22g.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly22g.srv.mailcontrol.com (MailControl) with ESMTP id p688W4OU009315 for ; Fri, 8 Jul 2011 09:32:13 +0100 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by rly22g.srv.mailcontrol.com (MailControl) id p688VOsh006982 for ; Fri, 8 Jul 2011 09:31:24 +0100 Received: from eundsmtpout02.pan.eu ([168.87.60.204]) by rly22g-eth0.srv.mailcontrol.com (envelope-sender ) (MIMEDefang) with ESMTP id p688U2OK031229 (TLS bits=128 verify=NO); Fri, 08 Jul 2011 09:31:24 +0100 (BST) Received: from eundadmi01.pan.eu ([10.109.33.22]) by eundsmtpout02.pan.eu (Lotus Domino Release 7.0.2) with ESMTP id 2011070810311425-416262 ; Fri, 8 Jul 2011 10:31:14 +0200 Received: from VPN-MRelay-01.PRDCG.Panasonic.de ([10.100.176.55]) by eundadmi01.pan.eu (Lotus Domino Release 8.5.1FP4) with ESMTP id 2011070810310670-642902 ; Fri, 8 Jul 2011 10:31:06 +0200 X-Footer: cGFuYXNvbmljLmRl Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PRDCG.Panasonic.de; Fri, 8 Jul 2011 10:31:04 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 In-Reply-To: <20110705161819.E460F98C4EF@rfc-editor.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVTCORE] [Technical Errata Reported] RFC4585 (2853) Thread-Index: Acw8HhH6KFV4Pm1zQf+JGajGrk9j+ABK0O+Q References: <20110705161819.E460F98C4EF@rfc-editor.org> To: "RFC Errata System" , , , , , , , , , X-TNEFEvaluated: 1 Message-ID: <1FEB9B9F2EC38343955D02B2AE86AACB0235BB65@lan-ex-02.panasonic.de> Date: Fri, 8 Jul 2011 10:31:02 +0200 From: "Jose Rey" X-MIMETrack: Itemize by SMTP Server on EUNDADMI01/EUR/Matsushita(Release 8.5.1FP4|July 25, 2010) at 08.07.2011 10:31:06, Serialize by Router on EUNDADMI01/EUR/Matsushita(Release 8.5.1FP4|July 25, 2010) at 08.07.2011 10:31:14, Serialize complete at 08.07.2011 10:31:14, Itemize by SMTP Server on EUNDSMTPOUT02/EUR/PANEXTOUT(Release 7.0.2|September 26, 2006) at 07/08/2011 10:31:14 AM, Serialize by Router on EUNDSMTPOUT02/EUR/PANEXTOUT(Release 7.0.2|September 26, 2006) at 07/08/2011 10:31:24 AM, Serialize complete at 07/08/2011 10:31:24 AM Content-Transfer-Encoding: quoted-printable Content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" X-Scanned-By: MailControl A-12-00-01 (www.mailcontrol.com) on 10.71.1.132 X-Mailman-Approved-At: Fri, 08 Jul 2011 08:03:19 -0700 Cc: avt@ietf.org Subject: Re: [AVTCORE] [Technical Errata Reported] RFC4585 (2853) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 08:32:14 -0000 Fine with me Cheers, Jos=E9 > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On=20 > Behalf Of RFC Errata System > Sent: Tuesday, July 05, 2011 6:18 PM > To: jo@acm.org; stewe@stewe.org; sato652@oki.com;=20 > carsten.burmeister@eu.panasonic.com;=20 > jose.rey@eu.panasonic.com; gonzalo.camarillo@ericsson.com;=20 > rjsparks@nostrum.com; keith.drage@alcatel-lucent.com;=20 > even.roni@huawei.com > Cc: avt@ietf.org; rfc-editor@rfc-editor.org > Subject: [AVTCORE] [Technical Errata Reported] RFC4585 (2853) >=20 >=20 > The following errata report has been submitted for RFC4585, > "Extended RTP Profile for Real-time Transport Control=20 > Protocol (RTCP)-Based Feedback (RTP/AVPF)". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D4585&eid=3D2853 >=20 > -------------------------------------- > Type: Technical > Reported by: Ali Begen >=20 > Section: 4.2 >=20 > Original Text > ------------- > OLD: > rtcp-fb-param =3D SP "app" [SP byte-string] > / SP token [SP byte-string] > / ; empty > NEW: > rtcp-fb-param =3D [ SP "app" [SP byte-string] > / SP token [SP byte-string] ] >=20 >=20 > OLD: > rtcp-fb-ack-param =3D SP "rpsi" > / SP "app" [SP byte-string] > / SP token [SP byte-string] > / ; empty > NEW: > rtcp-fb-ack-param =3D [ SP "rpsi" > / SP "app" [SP byte-string] > / SP token [SP byte-string] ] >=20 >=20 > OLD: > rtcp-fb-nack-param =3D SP "pli" > / SP "sli" > / SP "rpsi" > / SP "app" [SP byte-string] > / SP token [SP byte-string] > / ; empty > NEW: > rtcp-fb-nack-param =3D [ SP "pli" > / SP "sli" > / SP "rpsi" > / SP "app" [SP byte-string] > / SP token [SP byte-string] ] >=20 >=20 > Corrected Text > -------------- >=20 >=20 > Notes > ----- > During the AUTH48 of RFC 6285, we discovered a bug with the=20 > ABNF syntax in RFC 4585. The original ABNF in Section 4.2 (as=20 > noted above) is incorrect ("/ ;empty" is not a valid ABNF -=20 > RFC 5234 does not allow empty alternates). >=20 > The NEW text intends to fix it. There are 3 places where the=20 > same change should be applied (changes are identical). >=20 > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC4585 (draft-ietf-avt-rtcp-feedback-11) > -------------------------------------- > Title : Extended RTP Profile for Real-time=20 > Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF) > Publication Date : July 2006 > Author(s) : J. Ott, S. Wenger, N. Sato, C.=20 > Burmeister, J. Rey > Category : PROPOSED STANDARD > Source : Audio/Video Transport > Area : Real-time Applications and Infrastructure > Stream : IETF > Verifying Party : IESG > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt >=20 >=20 Panasonic R=26D Center Germany GmbH 63225 Langen=2C Hessen=2C Germany Reg=3A AG Offenbach =28Hessen=29 HRB 33974 Managing Director=3A Thomas Micke From sandra.sendra.upv@gmail.com Fri Jul 8 10:33:31 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 510C221F8BE9 for ; Fri, 8 Jul 2011 10:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2J+ITGsyzNwf for ; Fri, 8 Jul 2011 10:33:28 -0700 (PDT) Received: from marfik.cc.upv.es (marfik.cc.upv.es [158.42.249.9]) by ietfa.amsl.com (Postfix) with ESMTP id 2941321F85E5 for ; Fri, 8 Jul 2011 10:33:27 -0700 (PDT) Received: from smtpx.upv.es (smtpxv.cc.upv.es [158.42.249.46]) by marfik.cc.upv.es (8.13.6/8.13.6) with ESMTP id p68HXQWp031854 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 8 Jul 2011 19:33:26 +0200 Received: from smtp.upv.es (celaeno.cc.upv.es [158.42.249.55]) by smtpx.upv.es (8.14.3/8.14.3) with ESMTP id p68HXQJ1009032 for ; Fri, 8 Jul 2011 19:33:26 +0200 Received: from JLLORET (vpn245-11.vpns.upv.es [158.42.245.11]) by smtp.upv.es (8.13.6/8.13.6) with SMTP id p68HXNNl004051 for ; Fri, 8 Jul 2011 19:33:25 +0200 Date: Fri, 8 Jul 2011 19:33:25 +0200 Message-Id: <201107081733.p68HXNNl004051@smtp.upv.es> From: Sandra Sendra To: avt@ietf.org CC: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [AVTCORE] [DEADLINE EXTENDED] CFP - IEEE GLOBECOM 2011 - Smart Communication Protocols & Algorithms (SCPA 2011) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 17:33:31 -0000 Apologies for crossposting ------------------ CALL FOR PAPERS ----------------- Deadline extended to July 17, 2011 Smart Communication Protocols and Algorithms (SCPA 2011) December 5-9, 2011, Huston, Texas (USA) In conjunction with Globecom 2011 http://scpa.it.ubi.pt/ Selected papers will be invited to the Special Issue on Smart Protocols and Algorithms of the International Journal Network Protocols and Algorithms (ISSN 1943-3581) Communication protocols and algorithms are needed to communicate network devices and exchange data between them. The appearance of new technologies usually comes with a protocol procedure and communication rules that allows data communication while taking profit of this new technology. Recent advances in hardware and communication mediums allow proposing new rules, conventions and data structures which could be used by network devices to communicate across the network. Moreover, devices with higher processing capacity let us include more complex algorithms that can be used by the network device to enhance the communication procedure. Smart communication protocols and algorithms make use of several methods and techniques (such as machine learning techniques, decision making techniques, knowledge representation, network management, network optimization, problem solution techniques, and so on), to communicate the network devices to transfer data between them. They can be used to perceive the network conditions, or the user behavior, in order to dynamically plan, adapt, decide, take the appropriate actions, and learn from the consequences of its actions. The algorithms can make use of the information gathered from the protocol in order to sense the environment, plan actions according to the input, take consciousness of what is happening in the environment, and take the appropriate decisions using a reasoning engine. Goals such as decide which scenario fits best its end-to-end purpose, or environment prediction, can be achieved with smart protocols and algorithms. Moreover, they could learn from the past and ! use this knowledge to improve futur e decisions. In this workshop, researchers are encouraged to submit papers focused on the design, development, analysis or optimization of smart communication protocols or algorithms at any communication layer. Algorithms and protocols based on artificial intelligence techniques for network management, network monitoring, quality of service enhancement, performance optimization and network secure are included in the workshop. We welcome technical papers presenting analytical research, simulations, practical results, position papers addressing the pros and cons of specific proposals, and papers addressing the key problems and solutions. The topics suggested by the conference can be discussed in term of concepts, state of the art, standards, deployments, implementations, running experiments and applications. Topics of interest: Authors are invited to submit complete unpublished papers, which are not under review in any other conference or journal, including, but are not limited to, the following topic areas: • Smart network protocols and algorithms for multimedia delivery • Application layer, transport layer and network layer cognitive protocols • Cognitive radio network protocols and algorithms • Automatic protocols and algorithms for environment prediction. • Algorithms and protocols to predict data network states. • Intelligent synchronization techniques for network protocols and algorithms • Smart protocols and algorithms for e-health • Software applications for smart algorithms design and development. • Dynamic protocols based on the perception of their performance • Smart protocols and algorithms for Smartgrids • Protocols and algorithms focused on building conclusions for taking the appropriate actions. • Smart Automatic and self-autonomous ad-hoc and sensor networks. • Artificial intelligence applied in protocols and algorithms for wireless, mobile and dynamic networks. • Smart security protocols and algorithms • Smart cryptographic algorithms for communication • Artificial intelligence applied to power efficiency and energy saving protocols and algorithms • Smart routing and switching protocols and algorithms • Cognitive protocol and algorithm models for saving communication costs. • Any kind of intelligent technique applied to QoS, content delivery, network Monitoring and network management. • Smart collaborative protocols and algorithms • Problem recognition and problem solving protocols • Genetic algorithms, fuzzy logic and neural networks applied to communication protocols and algorithms Important Dates Paper Submission: 17 July 2011 (extended deadline) Paper Acceptance: 14 August 2011 Camera-Ready: 7 September 2011 Submission guidelines: All submissions must be full papers in PDF format and uploaded on EDAS (http://edas.info//N10879). They must not exceed 10 single-spaced, double-column pages using 10 pt size fonts on 8.5 x 11 inch pages in IEEE style format. General Chairs Jaime Lloret, Univ. Politecnica Valencia, Spain Joel Rodrigues, Inst. of Telecommunications, Univ. of Beira Interior, Pt TPC Chairs Nidal Nasser, University of Guelph, Canada Ivan Stojmenovic, University of Ottawa, Canada Poster Chairs Binod Vaidya, University of Ottawa, Canada Bin Wei, AT&T, USA Industry Chairs Haohong Wang, Cisco Chi-Ming Chen, AT&T, USA Publicity Chairs Sandra Sendra, Univ. Politecnica Valencia, Spain Mbaye B. Sene; Cheikh Anta Diop Univ., Dakar, Senegal Web Chair Miguel Garcia, Univ. Politecnica Valencia, Spain From Even.roni@huawei.com Fri Jul 8 13:58:07 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9353A21F8B9E for ; Fri, 8 Jul 2011 13:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.998 X-Spam-Level: X-Spam-Status: No, score=-105.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vD2+smI5crmq for ; Fri, 8 Jul 2011 13:58:07 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id E21AC21F8B85 for ; Fri, 8 Jul 2011 13:58:06 -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 <0LO100E9L8WTB5@szxga04-in.huawei.com> for avt@ietf.org; Sat, 09 Jul 2011 04:58:06 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LO100HZL8WTF7@szxga04-in.huawei.com> for avt@ietf.org; Sat, 09 Jul 2011 04:58:05 +0800 (CST) Received: from windows8d787f9 ([109.65.3.95]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LO100F4T8WJV8@szxml12-in.huawei.com>; Sat, 09 Jul 2011 04:58:05 +0800 (CST) Date: Fri, 08 Jul 2011 23:55:30 +0300 From: Roni Even To: 'IETF AVTCore WG' Message-id: <008801cc3db1$65f48090$31dd81b0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/mixed; boundary="Boundary_(ID_pgm8yqN96a7fzW1zcGUPCQ)" Content-language: en-us Thread-index: Acw9sV3tigiKRptRTCWfXxVoJNdziA== Cc: 'Magnus Westerlund' Subject: [AVTCORE] AVTcore draft agenda for IETF81 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 20:58:07 -0000 This is a multi-part message in MIME format. --Boundary_(ID_pgm8yqN96a7fzW1zcGUPCQ) Content-type: multipart/alternative; boundary="Boundary_(ID_8Oic022C7QtcsagoNpDMzw)" --Boundary_(ID_8Oic022C7QtcsagoNpDMzw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, Here is the proposed agenda for the AVTcore session in Quebec. Please review Roni Even AVTcore co-chair --Boundary_(ID_8Oic022C7QtcsagoNpDMzw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi,

Here is the proposed agenda for the AVTcore session in Quebec.

Please review

Roni Even

AVTcore co-chair

--Boundary_(ID_8Oic022C7QtcsagoNpDMzw)-- --Boundary_(ID_pgm8yqN96a7fzW1zcGUPCQ) Content-type: text/plain; name=a1107.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=a1107.txt Audio/Video Transport Core Maintenance (AVTCore) Working Group =============================================================== CHAIRS: Magnus Westerlund Roni Even AGENDA Wednesday, 27 July 2011 at 9:00-11:30 (208 AB) ---------------------------------------------- 09:00 AVTCore Status Update (Chairs, 20) 09:20 Payload Status Update (Payload Chairs, 15) draft-ramalho-payload-g7110-00 09:35 Encryption of Header Extensions in SRTP (Lennox, 15) draft-ietf-avtcore-srtp-encrypted-header-ext-00 09:50 RTCP Extension for Feedback Suppression Indication (Qin Wu, 15) draft-ietf-avtcore-feedback-supression-rtp-00 10:05 Monitoring Architecture for RTP (Qin Wu, 15) draft-ietf-avtcore-monarch-03 10:20 RTP Multiple Stream Sessions and Simulcast(Magnus Westerlund , 30) draft-westerlund-avtcore-multistream-and-simulcast-00 10:50 Delayed Duplication Attribute and Duplication Grouping in SDP(Begen, 15) draft-begen-mmusic-temporal-interleaving-02 draft-begen-mmusic-redundancy-grouping-01 11:05 Multipath RTP (Varun Singh, 10) draft-singh-avtcore-mprtp-02 11:15 End --Boundary_(ID_pgm8yqN96a7fzW1zcGUPCQ)-- From Even.roni@huawei.com Sat Jul 9 15:04:50 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0813621F8A5D for ; Sat, 9 Jul 2011 15:04:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.299 X-Spam-Level: X-Spam-Status: No, score=-104.299 tagged_above=-999 required=5 tests=[AWL=1.700, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lAx7zpLFpBo9 for ; Sat, 9 Jul 2011 15:04:49 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 5F9B321F8A42 for ; Sat, 9 Jul 2011 15:04:49 -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 <0LO300LKN6O07Q@szxga04-in.huawei.com> for avt@ietf.org; Sun, 10 Jul 2011 06:04:48 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LO300GTR6O0TZ@szxga04-in.huawei.com> for avt@ietf.org; Sun, 10 Jul 2011 06:04:48 +0800 (CST) Received: from windows8d787f9 (bzq-79-179-32-59.red.bezeqint.net [79.179.32.59]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LO3001IK6NUU6@szxml12-in.huawei.com> for avt@ietf.org; Sun, 10 Jul 2011 06:04:48 +0800 (CST) Date: Sun, 10 Jul 2011 01:02:14 +0300 From: Roni Even To: 'IETF AVTCore WG' Message-id: <011401cc3e83$e024fca0$a06ef5e0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/mixed; boundary="Boundary_(ID_Y9iQtvGlZ1P2NAMeDQGJFA)" Content-language: en-us Thread-index: Acw+g9pq64WIjLq0SPm2Uc51bo03SQ== Subject: [AVTCORE] Upadated AVTcore agenda for Quebec X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 22:04:50 -0000 This is a multi-part message in MIME format. --Boundary_(ID_Y9iQtvGlZ1P2NAMeDQGJFA) Content-type: multipart/alternative; boundary="Boundary_(ID_a9801s0TVsGCWXsp/sBmKQ)" --Boundary_(ID_a9801s0TVsGCWXsp/sBmKQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, I uploaded the agenda to the meeting page http://www.ietf.org/proceedings/81/agenda/avtcore.html . Attached is the txt version Roni Even AVTcore co-chair --Boundary_(ID_a9801s0TVsGCWXsp/sBmKQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi,

I uploaded the agenda to the meeting page http://www.ietf.org/proceedings/81/agenda/avtcore.html .

Attached is the txt version

Roni Even

AVTcore co-chair

--Boundary_(ID_a9801s0TVsGCWXsp/sBmKQ)-- --Boundary_(ID_Y9iQtvGlZ1P2NAMeDQGJFA) Content-type: text/plain; name=a1107.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=a1107.txt Audio/Video Transport Core Maintenance (AVTCore) Working Group =============================================================== CHAIRS: Magnus Westerlund Roni Even AGENDA Wednesday, 27 July 2011 at 9:00-11:30 (208 AB) ---------------------------------------------- 09:00 AVTCore Status Update (Chairs, 20) 09:20 Payload Status Update (Payload Chairs, 15) draft-ramalho-payload-g7110-00 09:35 Encryption of Header Extensions in SRTP (Lennox, 15) draft-ietf-avtcore-srtp-encrypted-header-ext-00 09:50 RTCP Extension for Feedback Suppression Indication (Qin Wu, 15) draft-ietf-avtcore-feedback-supression-rtp-00 10:05 Monitoring Architecture for RTP (Qin Wu, 15) draft-ietf-avtcore-monarch-03 10:20 RTP Multiple Stream Sessions and Simulcast(Magnus Westerlund , 30) draft-westerlund-avtcore-multistream-and-simulcast-00 10:50 Retransmission for SSM Sessions (Begen, 10) draft-vancaenegem-avtcore-retransmission-for-ssm-00 11:00 Delayed Duplication Attribute and Duplication Grouping in SDP(Begen, 15) draft-begen-mmusic-temporal-interleaving-02 draft-begen-mmusic-redundancy-grouping-01 11:15 Multipath RTP (Varun Singh, 10) draft-singh-avtcore-mprtp-02 11:25 End --Boundary_(ID_Y9iQtvGlZ1P2NAMeDQGJFA)-- From internet-drafts@ietf.org Sun Jul 10 23:41:05 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2407521F8A06; Sun, 10 Jul 2011 23:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DaDmsgATsMDl; Sun, 10 Jul 2011 23:41:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFBFD21F8596; Sun, 10 Jul 2011 23:41:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110711064104.13324.50600.idtracker@ietfa.amsl.com> Date: Sun, 10 Jul 2011 23:41:04 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-feedback-supression-rtp-05.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 06:41:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenanc= e Working Group of the IETF. Title : RTCP Extension for Third-party Loss Report Author(s) : Qin Wu Frank Xia Roni Even Filename : draft-ietf-avtcore-feedback-supression-rtp-05.txt Pages : 17 Date : 2011-07-10 In a large RTP session using the RTCP feedback mechanism defined in RFC 4585, a feedback target may experience transient overload if some event causes a large number of receivers to send feedback at once. This overload is usually avoided by ensuring that feedback reports are forwarded to all receivers, allowing them to avoid sending duplicate feedback reports. However, there are cases where it is not recommended to forward feedback reports, and this may allow feedback implosion. This memo discusses these cases and defines a new RTCP third-party loss report that can be used to inform receivers that a feedback target is aware of some loss event, allowing them to suppress feedback. Associated SDP signalling is also defined. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avtcore-feedback-supression-= rtp-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtcore-feedback-supression-r= tp-05.txt From Even.roni@huawei.com Mon Jul 11 00:58:48 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07D0421F865F for ; Mon, 11 Jul 2011 00:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.832 X-Spam-Level: X-Spam-Status: No, score=-105.832 tagged_above=-999 required=5 tests=[AWL=0.767, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWVChvaI+QQo for ; Mon, 11 Jul 2011 00:58:47 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id CD0F721F8605 for ; Mon, 11 Jul 2011 00:58:46 -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 <0LO500HUGSTUNY@szxga04-in.huawei.com> for avt@ietf.org; Mon, 11 Jul 2011 15:58:42 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LO500DTXSTUK2@szxga04-in.huawei.com> for avt@ietf.org; Mon, 11 Jul 2011 15:58:42 +0800 (CST) Received: from windows8d787f9 (bzq-79-179-32-59.red.bezeqint.net [79.179.32.59]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LO5002UTSTN3H@szxml12-in.huawei.com>; Mon, 11 Jul 2011 15:58:42 +0800 (CST) Date: Mon, 11 Jul 2011 10:56:04 +0300 From: Roni Even In-reply-to: <4E12ED55.2060301@ericsson.com> To: 'Magnus Westerlund' , 'IETF AVTCore WG' Message-id: <004401cc3fa0$00452330$00cf6990$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: Acw7AhertyURyZerSx+COXVUbQKwVQEjUtwQ References: <4E12ED55.2060301@ericsson.com> Subject: Re: [AVTCORE] Fwd: I-D Action: draft-westerlund-avtcore-multistream-and-simulcast-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 07:58:48 -0000 Hi Magnus, Read the draft, I liked the analysis on the different multiplexing of RTP streams (Session, SSRC and payload type). Some review comments 1. The introduction talks about multistream and simulcast. I noticed that it only talks about how to define the alternatives in terms of the stream but is not saying how to understand the semantics of the streams, for example which camera in Telepresence and in simulcast you assume that all alternative provide the same view (just resolution change, but can also use different view of the room). This is fine and is being discussed in CLUE at the moment and should be out of scope here but it may cause the SDP to be even larger. 2. On the SDP syntax it may be better when you have more than one m-line to have all the descriptions which repeats in all m-line appear st the SDP session level with local identifier and use the identifier in the m-lines. Maybe based on grouping. 3. In section 1.1 "Todays SDP signalling support for this is basically the directionality attribute which indicates an end-point intend to send media or not. No indication of how many media streams." My understanding so far was that the number of PT in the m-line is the maximum number of streams that can be sent in an RTP session. This goes also to the discussion on support of multiple SSRCs. I think that today video conferencing endpoint is doing a second offer answer to fix the PT it will use based on the first offer answer exchange. 4. The above still does not address the multiple SSRC for the same PT and I already mentioned it in the past that I think that a lot of product today will not handle it good. I think that this is a rare case today at least in centralized video conferencing since the MCU (or RTP mixer if exist) will use its own SSRC to send the mixed/switched media. 5. In section 3.2 second paragraph you talk about the receivers controlling what the relay will send but this will make the relay something else than RTP translator. 6. On the bandwidth support. Currently the definition is the b= is a receiver capability. I am not sure why you need the sender one, you claim that there is no way to control the actual bw but the receiver can use RTCP CCM flow control to tell the sender to reduce the rate. As for the syntax, my preference is for TIAS semantics and not the one you proposed. 7. In the last sentence of 7.2.1 you say "This enables a simple fallback solution to exclude a legacy client from all simulcast versions except one, whichever is most suitable for the application". My view is that currently when there are several m-lines of the same media type there is no definition which one to choose if the answerer do not understand the semantics of the offer and can support only one stream. Roni Even > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > Magnus Westerlund > Sent: Tuesday, July 05, 2011 1:54 PM > To: IETF AVTCore WG > Subject: [AVTCORE] Fwd: I-D Action: draft-westerlund-avtcore- > multistream-and-simulcast-00.txt > > WG, > > As an individual Bo Burman and I have written this internet draft that > discusses multistream and simulcast issues and proposes a set of > extensions to resolve the issues. Feedback is much appreciated. > > Cheers > > Magnus From internet-drafts@ietf.org Mon Jul 11 08:03:35 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66C7C21F853B; Mon, 11 Jul 2011 08:03:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id db9J3kxgZ8Bx; Mon, 11 Jul 2011 08:03:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0506C21F8496; Mon, 11 Jul 2011 08:03:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110711150335.7960.35398.idtracker@ietfa.amsl.com> Date: Mon, 11 Jul 2011 08:03:35 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-ecn-for-rtp-03.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 15:03:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenanc= e Working Group of the IETF. Title : Explicit Congestion Notification (ECN) for RTP over UDP Author(s) : Magnus Westerlund Ingemar Johansson Colin Perkins Piers O'Hanlon Ken Carlberg Filename : draft-ietf-avtcore-ecn-for-rtp-03.txt Pages : 55 Date : 2011-07-11 This memo specifies how Explicit Congestion Notification (ECN) can be used with the Real-time Transport Protocol (RTP) running over UDP, using RTP Control Protocol (RTCP) as a feedback mechanism. It defines a new RTCP Extended Report (XR) block for periodic ECN feedback, a new RTCP transport feedback message for timely reporting of congestion events, and a Session Traversal Utilities for NAT (STUN) extension used in the optional initilization method using Interactive Connectivity Establishment (ICE). Signalling and procedures for negotiation of capabilities and initilization methods are also defined. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avtcore-ecn-for-rtp-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtcore-ecn-for-rtp-03.txt From magnus.westerlund@ericsson.com Mon Jul 11 08:07:59 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7731321F85B8 for ; Mon, 11 Jul 2011 08:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.492 X-Spam-Level: X-Spam-Status: No, score=-106.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V2mHeVCJBp0q for ; Mon, 11 Jul 2011 08:07:59 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 513C921F858C for ; Mon, 11 Jul 2011 08:07:45 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-a9-4e1b11c04f6d Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 6E.15.20773.0C11B1E4; Mon, 11 Jul 2011 17:07:44 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Mon, 11 Jul 2011 17:07:44 +0200 Message-ID: <4E1B11BB.6000901@ericsson.com> Date: Mon, 11 Jul 2011 17:07:39 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: IETF AVTCore WG References: <20110711150335.7960.35398.idtracker@ietfa.amsl.com> In-Reply-To: <20110711150335.7960.35398.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-ecn-for-rtp-03.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 15:07:59 -0000 Hi, This update only addresses some editorial minor issues we authors have found in the time since the last update. That include actually removing the open issues section listing issues resolved in the previous version. The authors believe this version being ready for WG last call. The diff against previous version: http://tools.ietf.org/rfcdiff?url2=draft-ietf-avtcore-ecn-for-rtp-03 Cheers Magnus On 2011-07-11 17:03, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Core Maintenance Working Group of the IETF. > > Title : Explicit Congestion Notification (ECN) for RTP over UDP > Author(s) : Magnus Westerlund > Ingemar Johansson > Colin Perkins > Piers O'Hanlon > Ken Carlberg > Filename : draft-ietf-avtcore-ecn-for-rtp-03.txt > Pages : 55 > Date : 2011-07-11 > > This memo specifies how Explicit Congestion Notification (ECN) can be > used with the Real-time Transport Protocol (RTP) running over UDP, > using RTP Control Protocol (RTCP) as a feedback mechanism. It > defines a new RTCP Extended Report (XR) block for periodic ECN > feedback, a new RTCP transport feedback message for timely reporting > of congestion events, and a Session Traversal Utilities for NAT > (STUN) extension used in the optional initilization method using > Interactive Connectivity Establishment (ICE). Signalling and > procedures for negotiation of capabilities and initilization methods > are also defined. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-avtcore-ecn-for-rtp-03.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtcore-ecn-for-rtp-03.txt > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From kpfleming@digium.com Mon Jul 11 08:13:01 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15D3021F8CBB for ; Mon, 11 Jul 2011 08:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AzUq7gY1eDjA for ; Mon, 11 Jul 2011 08:13:00 -0700 (PDT) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id 2164B21F8D16 for ; Mon, 11 Jul 2011 08:12:58 -0700 (PDT) Received: from zimbra.digium.internal ([10.24.55.203] helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1QgIAI-0006IO-2S for avt@ietf.org; Mon, 11 Jul 2011 10:12:54 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id 15881D82AE for ; Mon, 11 Jul 2011 10:12:54 -0500 (CDT) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0m4m3O8yxn3I for ; Mon, 11 Jul 2011 10:12:53 -0500 (CDT) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 8BB03D8024 for ; Mon, 11 Jul 2011 10:12:53 -0500 (CDT) Message-ID: <4E1B12F4.30603@digium.com> Date: Mon, 11 Jul 2011 10:12:52 -0500 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: avt@ietf.org References: <20110711150335.7960.35398.idtracker@ietfa.amsl.com> In-Reply-To: <20110711150335.7960.35398.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-ecn-for-rtp-03.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 15:13:01 -0000 On 07/11/2011 10:03 AM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Core Maintenance Working Group of the IETF. > > Title : Explicit Congestion Notification (ECN) for RTP over UDP > Author(s) : Magnus Westerlund > Ingemar Johansson > Colin Perkins > Piers O'Hanlon > Ken Carlberg > Filename : draft-ietf-avtcore-ecn-for-rtp-03.txt > Pages : 55 > Date : 2011-07-11 > > This memo specifies how Explicit Congestion Notification (ECN) can be > used with the Real-time Transport Protocol (RTP) running over UDP, > using RTP Control Protocol (RTCP) as a feedback mechanism. It > defines a new RTCP Extended Report (XR) block for periodic ECN > feedback, a new RTCP transport feedback message for timely reporting > of congestion events, and a Session Traversal Utilities for NAT > (STUN) extension used in the optional initilization method using > Interactive Connectivity Establishment (ICE). Signalling and > procedures for negotiation of capabilities and initilization methods > are also defined. Editorial note: In two places here, 'initilization' should be 'initialization'. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org From internet-drafts@ietf.org Mon Jul 11 08:43:53 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8449821F8DC2; Mon, 11 Jul 2011 08:43:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HmZRA0P1bL4Z; Mon, 11 Jul 2011 08:43:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25F0621F86D1; Mon, 11 Jul 2011 08:43:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110711154353.26152.76407.idtracker@ietfa.amsl.com> Date: Mon, 11 Jul 2011 08:43:53 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-ecn-for-rtp-04.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 15:43:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenanc= e Working Group of the IETF. Title : Explicit Congestion Notification (ECN) for RTP over UDP Author(s) : Magnus Westerlund Ingemar Johansson Colin Perkins Piers O'Hanlon Ken Carlberg Filename : draft-ietf-avtcore-ecn-for-rtp-04.txt Pages : 55 Date : 2011-07-11 This memo specifies how Explicit Congestion Notification (ECN) can be used with the Real-time Transport Protocol (RTP) running over UDP, using RTP Control Protocol (RTCP) as a feedback mechanism. It defines a new RTCP Extended Report (XR) block for periodic ECN feedback, a new RTCP transport feedback message for timely reporting of congestion events, and a Session Traversal Utilities for NAT (STUN) extension used in the optional initialization method using Interactive Connectivity Establishment (ICE). Signalling and procedures for negotiation of capabilities and initialization methods are also defined. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avtcore-ecn-for-rtp-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtcore-ecn-for-rtp-04.txt From randell-ietf@jesup.org Mon Jul 11 08:44:15 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96C6621F8DCE for ; Mon, 11 Jul 2011 08:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jAcdvokihvu9 for ; Mon, 11 Jul 2011 08:44:14 -0700 (PDT) Received: from arthur.webserversystems.com (arthur.webserversystems.com [174.132.191.98]) by ietfa.amsl.com (Postfix) with ESMTP id BC89A21F8DCB for ; Mon, 11 Jul 2011 08:44:14 -0700 (PDT) Received: from pool-98-111-140-38.phlapa.fios.verizon.net ([98.111.140.38] helo=[192.168.1.12]) by arthur.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QgIec-0005ZZ-1Y for avt@ietf.org; Mon, 11 Jul 2011 10:44:14 -0500 Message-ID: <4E1B1A2B.5070000@jesup.org> Date: Mon, 11 Jul 2011 11:43:39 -0400 From: Randell Jesup User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: avt@ietf.org References: <4E12ED55.2060301@ericsson.com> <004401cc3fa0$00452330$00cf6990$%roni@huawei.com> In-Reply-To: <004401cc3fa0$00452330$00cf6990$%roni@huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - arthur.webserversystems.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jesup.org X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [AVTCORE] Fwd: I-D Action: draft-westerlund-avtcore-multistream-and-simulcast-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 15:44:15 -0000 On 7/11/2011 3:56 AM, Roni Even wrote: > 3. In section 1.1 "Todays SDP signalling support for this is basically the > directionality attribute which indicates an end-point intend to send media > or not. No indication of how many media streams." My understanding so far > was that the number of PT in the m-line is the maximum number of streams > that can be sent in an RTP session. I've never heard of this (perhaps it's an issue with the meaning of stream in "number of streams that can be sent in an RTP session"). The number of distinct payloads, yes. But in theory (though not well supported, if at all) you could have a mixer providing N "streams", all of the same payload or different ones (with different SSRCs). I think it's just a terminology issue (and given the relative positions, I'm probably the one who's wrong). :-) But I'll note your comment isn't clear to me, and it should be. > This goes also to the discussion on > support of multiple SSRCs. I think that today video conferencing endpoint is > doing a second offer answer to fix the PT it will use based on the first > offer answer exchange. They may be; I mostly work with devices designed for point-to-point - but that means that entire conferences either get locked down to the lowest-common-denominator codec, or it demands the MCU transcode. I personally prefer to leave multiple payloads/codecs to allow endpoints to switch payloads in order to help adapt to various things, like network conditions. In theory, an endpoint could even switch between voice codecs and better-at-music-audio-codecs when they detect music, as a random non-network example. I don't know if the non-network use-cases would be compelling, but the network adaptation are compelling, given the time (and possible failures) required to re-INVITE. > 4. The above still does not address the multiple SSRC for the same PT and I > already mentioned it in the past that I think that a lot of product today > will not handle it good. I think that this is a rare case today at least in > centralized video conferencing since the MCU (or RTP mixer if exist) will > use its own SSRC to send the mixed/switched media. Some devices reuse the same incoming ports for multiple sessions, both within a call and between different calls they're involved in or are acting as a conference bridge. As mentioned previously, you're right that many endpoints don't deal well (or consistently) with multiple SSRCs in a session. > 5. In section 3.2 second paragraph you talk about the receivers controlling > what the relay will send but this will make the relay something else than > RTP translator. > > 6. On the bandwidth support. Currently the definition is the b= is a > receiver capability. I am not sure why you need the sender one, you claim > that there is no way to control the actual bw but the receiver can use RTCP > CCM flow control to tell the sender to reduce the rate. As for the syntax, > my preference is for TIAS semantics and not the one you proposed. Well, knowing what rate the sender plans to use *could* be useful in deciding how many resources (memory, CPU/DSP horsepower, etc) might be needed and so help the other side plan or (if it's answering) help it decide how to answer (number of streams, codecs to accept, etc). The fact that it could be useful doesn't always mean that it's a good idea to complicate the protocol to support it directly, however. > 7. In the last sentence of 7.2.1 you say "This enables a simple fallback > solution to exclude a legacy client from all simulcast versions except one, > whichever is most suitable for the application". My view is that currently > when there are several m-lines of the same media type there is no definition > which one to choose if the answerer do not understand the semantics of the > offer and can support only one stream. Agreed - there's no definition; however almost all clients that don't support multiple m= lines of the same type will select the first one, or the first one that they can find a matching payload for. -- Randell Jesup randell-ietf@jesup.org From magnus.westerlund@ericsson.com Mon Jul 11 08:49:03 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E62621F8DFF for ; Mon, 11 Jul 2011 08:49:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.498 X-Spam-Level: X-Spam-Status: No, score=-106.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TcH3JaYZqe2b for ; Mon, 11 Jul 2011 08:49:02 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 4407621F8D7D for ; Mon, 11 Jul 2011 08:49:02 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-49-4e1b1b6d7a74 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 9C.19.20773.D6B1B1E4; Mon, 11 Jul 2011 17:49:01 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Mon, 11 Jul 2011 17:49:01 +0200 Message-ID: <4E1B1B6B.9090203@ericsson.com> Date: Mon, 11 Jul 2011 17:48:59 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: IETF AVTCore WG References: <20110711154353.26152.76407.idtracker@ietfa.amsl.com> In-Reply-To: <20110711154353.26152.76407.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-ecn-for-rtp-04.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 15:49:03 -0000 Hi, A quick update fixing the issues that Kevin noticed and a few more spelling issues. Cheers Magnus On 2011-07-11 17:43, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Core Maintenance Working Group of the IETF. > > Title : Explicit Congestion Notification (ECN) for RTP over UDP > Author(s) : Magnus Westerlund > Ingemar Johansson > Colin Perkins > Piers O'Hanlon > Ken Carlberg > Filename : draft-ietf-avtcore-ecn-for-rtp-04.txt > Pages : 55 > Date : 2011-07-11 > > This memo specifies how Explicit Congestion Notification (ECN) can be > used with the Real-time Transport Protocol (RTP) running over UDP, > using RTP Control Protocol (RTCP) as a feedback mechanism. It > defines a new RTCP Extended Report (XR) block for periodic ECN > feedback, a new RTCP transport feedback message for timely reporting > of congestion events, and a Session Traversal Utilities for NAT > (STUN) extension used in the optional initialization method using > Interactive Connectivity Establishment (ICE). Signalling and > procedures for negotiation of capabilities and initialization methods > are also defined. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-avtcore-ecn-for-rtp-04.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtcore-ecn-for-rtp-04.txt > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From Even.roni@huawei.com Mon Jul 11 09:58:40 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12D4521F8D97 for ; Mon, 11 Jul 2011 09:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.739 X-Spam-Level: X-Spam-Status: No, score=-105.739 tagged_above=-999 required=5 tests=[AWL=0.860, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aBfIBXkhXOYI for ; Mon, 11 Jul 2011 09:58:39 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id D910811E80AA for ; Mon, 11 Jul 2011 09:58:34 -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 <0LO600JGEHTM9S@szxga04-in.huawei.com> for avt@ietf.org; Tue, 12 Jul 2011 00:58:34 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LO600D16HTM5Z@szxga04-in.huawei.com> for avt@ietf.org; Tue, 12 Jul 2011 00:58:34 +0800 (CST) Received: from windows8d787f9 (bzq-79-179-32-59.red.bezeqint.net [79.179.32.59]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LO600DPKHTE6B@szxml12-in.huawei.com>; Tue, 12 Jul 2011 00:58:34 +0800 (CST) Date: Mon, 11 Jul 2011 19:55:54 +0300 From: Roni Even In-reply-to: <4E1B1A2B.5070000@jesup.org> To: 'Randell Jesup' , avt@ietf.org Message-id: <00b801cc3feb$6b0b0310$41210930$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: Acw/4baQVCN8EwF6RbStLZafATzilQACUWwA References: <4E12ED55.2060301@ericsson.com> <004401cc3fa0$00452330$00cf6990$%roni@huawei.com> <4E1B1A2B.5070000@jesup.org> Subject: Re: [AVTCORE] Fwd: I-D Action: draft-westerlund-avtcore-multistream-and-simulcast-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 16:58:40 -0000 Inline Roni > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > Randell Jesup > Sent: Monday, July 11, 2011 6:44 PM > To: avt@ietf.org > Subject: Re: [AVTCORE] Fwd: I-D Action: draft-westerlund-avtcore- > multistream-and-simulcast-00.txt > > On 7/11/2011 3:56 AM, Roni Even wrote: > > 3. In section 1.1 "Todays SDP signalling support for this is > basically the > > directionality attribute which indicates an end-point intend to send > media > > or not. No indication of how many media streams." My understanding > so far > > was that the number of PT in the m-line is the maximum number of > streams > > that can be sent in an RTP session. > > I've never heard of this (perhaps it's an issue with the meaning of > stream in "number of streams > that can be sent in an RTP session"). The number of distinct payloads, > yes. But in theory > (though not well supported, if at all) you could have a mixer providing > N "streams", all of the > same payload or different ones (with different SSRCs). You are if you do ssrc multiplex, I assumed that if you do session multiplex you do not do ssrc multiplex but of course this is allowed. > > I think it's just a terminology issue (and given the relative > positions, > I'm probably the one who's > wrong). :-) But I'll note your comment isn't clear to me, and it > should be. > > > This goes also to the discussion on > > support of multiple SSRCs. I think that today video conferencing > endpoint is > > doing a second offer answer to fix the PT it will use based on the > first > > offer answer exchange. > > They may be; I mostly work with devices designed for point-to-point - > but that means that > entire conferences either get locked down to the > lowest-common-denominator codec, or > it demands the MCU transcode. I personally prefer to leave multiple > payloads/codecs > to allow endpoints to switch payloads in order to help adapt to various > things, like network > conditions. In theory, an endpoint could even switch between voice > codecs and > better-at-music-audio-codecs when they detect music, as a random > non-network example. > I don't know if the non-network use-cases would be compelling, but the > network adaptation > are compelling, given the time (and possible failures) required to > re-INVITE. This is the same point that EP will try to keep one PT in a point to point or MCU that terminates the call leg, and they do not expect SSRC multiplexing as mentioned in the next point > > > 4. The above still does not address the multiple SSRC for the same PT > and I > > already mentioned it in the past that I think that a lot of product > today > > will not handle it good. I think that this is a rare case today at > least in > > centralized video conferencing since the MCU (or RTP mixer if exist) > will > > use its own SSRC to send the mixed/switched media. > > Some devices reuse the same incoming ports for multiple sessions, both > within a call and > between different calls they're involved in or are acting as a > conference bridge. As mentioned > previously, you're right that many endpoints don't deal well (or > consistently) with multiple > SSRCs in a session. > > > 5. In section 3.2 second paragraph you talk about the receivers > controlling > > what the relay will send but this will make the relay something else > than > > RTP translator. > > > > 6. On the bandwidth support. Currently the definition is the b= is a > > receiver capability. I am not sure why you need the sender one, you > claim > > that there is no way to control the actual bw but the receiver can > use RTCP > > CCM flow control to tell the sender to reduce the rate. As for the > syntax, > > my preference is for TIAS semantics and not the one you proposed. > > Well, knowing what rate the sender plans to use *could* be useful in > deciding how many > resources (memory, CPU/DSP horsepower, etc) might be needed and so help > the other side > plan or (if it's answering) help it decide how to answer (number of > streams, codecs to accept, etc). > > The fact that it could be useful doesn't always mean that it's a good > idea to complicate the protocol > to support it directly, however. > > > 7. In the last sentence of 7.2.1 you say "This enables a simple > fallback > > solution to exclude a legacy client from all simulcast versions > except one, > > whichever is most suitable for the application". My view is that > currently > > when there are several m-lines of the same media type there is no > definition > > which one to choose if the answerer do not understand the semantics > of the > > offer and can support only one stream. > > Agreed - there's no definition; however almost all clients that don't > support multiple m= lines > of the same type will select the first one, or the first one that they > can find a matching payload for. > > -- > Randell Jesup > randell-ietf@jesup.org > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From Even.roni@huawei.com Tue Jul 12 01:32:28 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C162D21F901E for ; Tue, 12 Jul 2011 01:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.199 X-Spam-Level: X-Spam-Status: No, score=-105.199 tagged_above=-999 required=5 tests=[AWL=1.400, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ldx2ugtulCue for ; Tue, 12 Jul 2011 01:32:27 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id A622321F9017 for ; Tue, 12 Jul 2011 01:32:26 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LO700MDCOYXOI@szxga03-in.huawei.com> for avt@ietf.org; Tue, 12 Jul 2011 16:30:33 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LO700KXSOYXRN@szxga03-in.huawei.com> for avt@ietf.org; Tue, 12 Jul 2011 16:30:33 +0800 (CST) Received: from windows8d787f9 (bzq-79-179-32-59.red.bezeqint.net [79.179.32.59]) by szxml11-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LO70089XOYN38@szxml11-in.huawei.com>; Tue, 12 Jul 2011 16:30:33 +0800 (CST) Date: Tue, 12 Jul 2011 11:27:49 +0300 From: Roni Even In-reply-to: <20110607084412.16038.596.idtracker@ietfa.amsl.com> To: avt@ietf.org Message-id: <005801cc406d$9c903090$d5b091b0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: Acwk7y28eyXnYPbiSqWcMf0SrfUZBQbfKOBQ References: <20110607084412.16038.596.idtracker@ietfa.amsl.com> Cc: 'Jonathan Lennox' Subject: [AVTCORE] comments on draft-ietf-avtcore-srtp-encrypted-header-ext-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 08:32:28 -0000 Hi, I read the draft, some comments: 1. I think it needs an offer answer section. We need to specify the behavior when an offer to encrypt the header is sent and the answerer do not support the encryption header extension. Can alternatives, one with encryption and one without be offered. 2. Extmap can be a session level attribute. What about encryption, is it only a media level. In general are the offer answer rules from RFC 5285 applicable here and how. Regards Roni Even From jonathan@vidyo.com Tue Jul 12 11:37:51 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2E9721F8D97 for ; Tue, 12 Jul 2011 11:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JFuR0FS6dPP0 for ; Tue, 12 Jul 2011 11:37:51 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 05D6521F8D5A for ; Tue, 12 Jul 2011 11:37:50 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 00A11416D59; Tue, 12 Jul 2011 14:37:49 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB022.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 8A4DF417025; Tue, 12 Jul 2011 14:37:48 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB022.mail.lan ([10.110.17.22]) with mapi; Tue, 12 Jul 2011 14:36:30 -0400 From: Jonathan Lennox To: Roni Even Date: Tue, 12 Jul 2011 14:37:46 -0400 Thread-Topic: comments on draft-ietf-avtcore-srtp-encrypted-header-ext-00.txt Thread-Index: AcxAwpz8Eq0wIzeBQDGkJ9K1IYIqyA== Message-ID: References: <20110607084412.16038.596.idtracker@ietfa.amsl.com> <005801cc406d$9c903090$d5b091b0$%roni@huawei.com> In-Reply-To: <005801cc406d$9c903090$d5b091b0$%roni@huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "avt@ietf.org" Subject: Re: [AVTCORE] comments on draft-ietf-avtcore-srtp-encrypted-header-ext-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 18:37:52 -0000 The intention is that from the point of view of an answerer that doesn't un= derstand this spec, urn:ietf:params:rtp-hdrext:encrypt is just another unkn= own header extension element URI, so it will negotiate not to use it using = the standard RFC 5285 mechanisms. It's thus also possible to offer encrypted and non-encrypted versions of th= e same header extension element, if that's acceptable for security reasons. I can add some explicit text explaining this in the next revision of the dr= aft. On Jul 12, 2011, at 4:27 AM, Roni Even wrote: > Hi, > I read the draft, some comments: >=20 > 1. I think it needs an offer answer section. We need to specify the behav= ior > when an offer to encrypt the header is sent and the answerer do not suppo= rt > the encryption header extension. Can alternatives, one with encryption an= d > one without be offered.=20 >=20 > 2. Extmap can be a session level attribute. What about encryption, is it > only a media level. >=20 > In general are the offer answer rules from RFC 5285 applicable here and h= ow. >=20 >=20 > Regards > Roni Even >=20 -- Jonathan Lennox jonathan@vidyo.com From Even.roni@huawei.com Tue Jul 12 12:10:45 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2BA421F8EF2 for ; Tue, 12 Jul 2011 12:10:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fj-7Bei2sI08 for ; Tue, 12 Jul 2011 12:10:39 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 41B5321F8EDB for ; Tue, 12 Jul 2011 12:10:39 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LO800CVYILEH8@szxga03-in.huawei.com> for avt@ietf.org; Wed, 13 Jul 2011 03:10:26 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LO800LN2ILEIJ@szxga03-in.huawei.com> for avt@ietf.org; Wed, 13 Jul 2011 03:10:26 +0800 (CST) Received: from windows8d787f9 ([109.64.5.142]) by szxml11-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LO800K77IL64B@szxml11-in.huawei.com>; Wed, 13 Jul 2011 03:10:26 +0800 (CST) Date: Tue, 12 Jul 2011 22:07:44 +0300 From: Roni Even In-reply-to: To: 'Jonathan Lennox' Message-id: <001601cc40c6$fef45730$fcdd0590$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=US-ASCII Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcxAwpz8Eq0wIzeBQDGkJ9K1IYIqyAABDFhg References: <20110607084412.16038.596.idtracker@ietfa.amsl.com> <005801cc406d$9c903090$d5b091b0$%roni@huawei.com> Cc: avt@ietf.org Subject: Re: [AVTCORE] comments on draft-ietf-avtcore-srtp-encrypted-header-ext-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 19:10:45 -0000 Hi Jonathan, I think it will be good to have some such text. What about the question about using it at the session level? Thanks Roni > -----Original Message----- > From: Jonathan Lennox [mailto:jonathan@vidyo.com] > Sent: Tuesday, July 12, 2011 9:38 PM > To: Roni Even > Cc: avt@ietf.org > Subject: Re: comments on draft-ietf-avtcore-srtp-encrypted-header-ext- > 00.txt > > The intention is that from the point of view of an answerer that > doesn't understand this spec, urn:ietf:params:rtp-hdrext:encrypt is > just another unknown header extension element URI, so it will negotiate > not to use it using the standard RFC 5285 mechanisms. > > It's thus also possible to offer encrypted and non-encrypted versions > of the same header extension element, if that's acceptable for security > reasons. > > I can add some explicit text explaining this in the next revision of > the draft. > > On Jul 12, 2011, at 4:27 AM, Roni Even wrote: > > > Hi, > > I read the draft, some comments: > > > > 1. I think it needs an offer answer section. We need to specify the > behavior > > when an offer to encrypt the header is sent and the answerer do not > support > > the encryption header extension. Can alternatives, one with > encryption and > > one without be offered. > > > > 2. Extmap can be a session level attribute. What about encryption, is > it > > only a media level. > > > > In general are the offer answer rules from RFC 5285 applicable here > and how. > > > > > > Regards > > Roni Even > > > > -- > Jonathan Lennox > jonathan@vidyo.com From jonathan@vidyo.com Tue Jul 12 12:45:54 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59F2D1F0C36 for ; Tue, 12 Jul 2011 12:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cKFZyLWmar0O for ; Tue, 12 Jul 2011 12:45:53 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id CF7CB21F8C33 for ; Tue, 12 Jul 2011 12:45:53 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 04EB2416DEE; Tue, 12 Jul 2011 15:45:52 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB025.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 966B2416DCC; Tue, 12 Jul 2011 15:45:49 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB025.mail.lan ([10.110.17.25]) with mapi; Tue, 12 Jul 2011 15:45:48 -0400 From: Jonathan Lennox To: Roni Even Date: Tue, 12 Jul 2011 15:45:48 -0400 Thread-Topic: comments on draft-ietf-avtcore-srtp-encrypted-header-ext-00.txt Thread-Index: AcxAzB3flLA/yyOWSfK+p6XA1bkWcg== Message-ID: References: <20110607084412.16038.596.idtracker@ietfa.amsl.com> <005801cc406d$9c903090$d5b091b0$%roni@huawei.com> <001601cc40c6$fef45730$fcdd0590$%roni@huawei.com> In-Reply-To: <001601cc40c6$fef45730$fcdd0590$%roni@huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "avt@ietf.org" Subject: Re: [AVTCORE] comments on draft-ietf-avtcore-srtp-encrypted-header-ext-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 19:45:54 -0000 Hi, Roni -- If extensions are specified at the session level, it's straightforward if a= ll the media streams are using SRTP -- the standard RFC 5285 rules apply. If there's a mix of SRTP and non-SRTP media streams, either we can say that= encrypted extension headers MUST be ignored for non-SRTP streams, or we ca= n forbid specifying encrypted extension headers at the session level in thi= s case. I'm inclined towards the former, but would be fine with either opt= ion. On Jul 12, 2011, at 3:07 PM, Roni Even wrote: > Hi Jonathan, > I think it will be good to have some such text. > What about the question about using it at the session level? >=20 > Thanks > Roni >=20 >> -----Original Message----- >> From: Jonathan Lennox [mailto:jonathan@vidyo.com] >> Sent: Tuesday, July 12, 2011 9:38 PM >> To: Roni Even >> Cc: avt@ietf.org >> Subject: Re: comments on draft-ietf-avtcore-srtp-encrypted-header-ext- >> 00.txt >>=20 >> The intention is that from the point of view of an answerer that >> doesn't understand this spec, urn:ietf:params:rtp-hdrext:encrypt is >> just another unknown header extension element URI, so it will negotiate >> not to use it using the standard RFC 5285 mechanisms. >>=20 >> It's thus also possible to offer encrypted and non-encrypted versions >> of the same header extension element, if that's acceptable for security >> reasons. >>=20 >> I can add some explicit text explaining this in the next revision of >> the draft. >>=20 >> On Jul 12, 2011, at 4:27 AM, Roni Even wrote: >>=20 >>> Hi, >>> I read the draft, some comments: >>>=20 >>> 1. I think it needs an offer answer section. We need to specify the >> behavior >>> when an offer to encrypt the header is sent and the answerer do not >> support >>> the encryption header extension. Can alternatives, one with >> encryption and >>> one without be offered. >>>=20 >>> 2. Extmap can be a session level attribute. What about encryption, is >> it >>> only a media level. >>>=20 >>> In general are the offer answer rules from RFC 5285 applicable here >> and how. >>>=20 >>>=20 >>> Regards >>> Roni Even >>>=20 >>=20 >> -- >> Jonathan Lennox >> jonathan@vidyo.com >=20 >=20 -- Jonathan Lennox jonathan@vidyo.com From Even.roni@huawei.com Tue Jul 12 14:13:35 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9013521F8C8D for ; Tue, 12 Jul 2011 14:13:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x4WF2vifRiKq for ; Tue, 12 Jul 2011 14:13:35 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id E55EE21F8C8C for ; Tue, 12 Jul 2011 14:13:34 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LO8002S5OAK87@szxga05-in.huawei.com> for avt@ietf.org; Wed, 13 Jul 2011 05:13:32 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LO800INGOAJT1@szxga05-in.huawei.com> for avt@ietf.org; Wed, 13 Jul 2011 05:13:32 +0800 (CST) Received: from windows8d787f9 ([109.64.5.142]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LO8005JTOADKR@szxml12-in.huawei.com>; Wed, 13 Jul 2011 05:13:31 +0800 (CST) Date: Wed, 13 Jul 2011 00:10:51 +0300 From: Roni Even In-reply-to: To: 'Jonathan Lennox' Message-id: <001e01cc40d8$321b8640$965292c0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=US-ASCII Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcxAzB3flLA/yyOWSfK+p6XA1bkWcgAC/ZiA References: <20110607084412.16038.596.idtracker@ietfa.amsl.com> <005801cc406d$9c903090$d5b091b0$%roni@huawei.com> <001601cc40c6$fef45730$fcdd0590$%roni@huawei.com> Cc: avt@ietf.org Subject: Re: [AVTCORE] comments on draft-ietf-avtcore-srtp-encrypted-header-ext-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 21:13:35 -0000 Jonathan, I am OK with the first option. Roni > -----Original Message----- > From: Jonathan Lennox [mailto:jonathan@vidyo.com] > Sent: Tuesday, July 12, 2011 10:46 PM > To: Roni Even > Cc: avt@ietf.org > Subject: Re: comments on draft-ietf-avtcore-srtp-encrypted-header-ext- > 00.txt > > Hi, Roni -- > > If extensions are specified at the session level, it's straightforward > if all the media streams are using SRTP -- the standard RFC 5285 rules > apply. > > If there's a mix of SRTP and non-SRTP media streams, either we can say > that encrypted extension headers MUST be ignored for non-SRTP streams, > or we can forbid specifying encrypted extension headers at the session > level in this case. I'm inclined towards the former, but would be fine > with either option. > > On Jul 12, 2011, at 3:07 PM, Roni Even wrote: > > > Hi Jonathan, > > I think it will be good to have some such text. > > What about the question about using it at the session level? > > > > Thanks > > Roni > > > >> -----Original Message----- > >> From: Jonathan Lennox [mailto:jonathan@vidyo.com] > >> Sent: Tuesday, July 12, 2011 9:38 PM > >> To: Roni Even > >> Cc: avt@ietf.org > >> Subject: Re: comments on draft-ietf-avtcore-srtp-encrypted-header- > ext- > >> 00.txt > >> > >> The intention is that from the point of view of an answerer that > >> doesn't understand this spec, urn:ietf:params:rtp-hdrext:encrypt is > >> just another unknown header extension element URI, so it will > negotiate > >> not to use it using the standard RFC 5285 mechanisms. > >> > >> It's thus also possible to offer encrypted and non-encrypted > versions > >> of the same header extension element, if that's acceptable for > security > >> reasons. > >> > >> I can add some explicit text explaining this in the next revision of > >> the draft. > >> > >> On Jul 12, 2011, at 4:27 AM, Roni Even wrote: > >> > >>> Hi, > >>> I read the draft, some comments: > >>> > >>> 1. I think it needs an offer answer section. We need to specify the > >> behavior > >>> when an offer to encrypt the header is sent and the answerer do not > >> support > >>> the encryption header extension. Can alternatives, one with > >> encryption and > >>> one without be offered. > >>> > >>> 2. Extmap can be a session level attribute. What about encryption, > is > >> it > >>> only a media level. > >>> > >>> In general are the offer answer rules from RFC 5285 applicable here > >> and how. > >>> > >>> > >>> Regards > >>> Roni Even > >>> > >> > >> -- > >> Jonathan Lennox > >> jonathan@vidyo.com > > > > > > -- > Jonathan Lennox > jonathan@vidyo.com From bill.wu@huawei.com Thu Jul 14 01:16:35 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B11821F8B2C for ; Thu, 14 Jul 2011 01:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.546 X-Spam-Level: X-Spam-Status: No, score=-3.546 tagged_above=-999 required=5 tests=[AWL=-0.947, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6IdTC2KgwbnR for ; Thu, 14 Jul 2011 01:16:31 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 00F8D21F8B29 for ; Thu, 14 Jul 2011 01:16:31 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LOB00BCRDMIRQ@szxga05-in.huawei.com> for avt@ietf.org; Thu, 14 Jul 2011 16:15:54 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LOB00FQDDJMOV@szxga05-in.huawei.com> for avt@ietf.org; Thu, 14 Jul 2011 16:15:54 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml202-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ACF26642; Thu, 14 Jul 2011 16:15:53 +0800 (CST) Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 14 Jul 2011 16:15:43 +0800 Received: from w53375q (10.138.41.76) by szxeml410-hub.china.huawei.com (10.82.67.137) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 14 Jul 2011 16:15:50 +0800 Date: Thu, 14 Jul 2011 16:15:50 +0800 From: Qin Wu X-Originating-IP: [10.138.41.76] To: Roni Even , avt@ietf.org Message-id: <9E56A50D84704E9EB96FE1EC68445967@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-CFilter-Loop: Reflected References: <20110607084412.16038.596.idtracker@ietfa.amsl.com> <005801cc406d$9c903090$d5b091b0$%roni@huawei.com> Cc: 'Jonathan Lennox' Subject: Re: [AVTCORE] comments on draft-ietf-avtcore-srtp-encrypted-header-ext-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 08:16:35 -0000 One more comment to draft-ietf-avtcore-srtp-encrypted-header-ext: This draft allocates two new lable value from 0x06 to 0x07 for k_he and k_hs, I am wondering Is there a need in the IANA section to regiserter these values and if yes, who are responsible for regisering thes new values? Does it rely on key management protocol or SRTP protcol or this draft? Regards! -Qin ----- Original Message ----- From: "Roni Even" To: Cc: "'Jonathan Lennox'" Sent: Tuesday, July 12, 2011 4:27 PM Subject: [AVTCORE] comments ondraft-ietf-avtcore-srtp-encrypted-header-ext-00.txt > Hi, > I read the draft, some comments: > > 1. I think it needs an offer answer section. We need to specify the behavior > when an offer to encrypt the header is sent and the answerer do not support > the encryption header extension. Can alternatives, one with encryption and > one without be offered. > > 2. Extmap can be a session level attribute. What about encryption, is it > only a media level. > > In general are the offer answer rules from RFC 5285 applicable here and how. > > > Regards > Roni Even > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From jonathan@vidyo.com Thu Jul 14 08:15:30 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 730A721F8B51 for ; Thu, 14 Jul 2011 08:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7sbcyTKNot1b for ; Thu, 14 Jul 2011 08:15:29 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id D0A1A21F8B54 for ; Thu, 14 Jul 2011 08:15:29 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 0F81C8BE670; Thu, 14 Jul 2011 11:15:29 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB013.mail.lan (unknown [10.110.2.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mxout.myoutlookonline.com (Postfix) with ESMTPS id AB0E98BE646; Thu, 14 Jul 2011 11:15:28 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB013.mail.lan ([10.110.17.13]) with mapi; Thu, 14 Jul 2011 11:14:05 -0400 From: Jonathan Lennox To: Qin Wu Date: Thu, 14 Jul 2011 11:15:22 -0400 Thread-Topic: [AVTCORE] comments on draft-ietf-avtcore-srtp-encrypted-header-ext-00.txt Thread-Index: AcxCOK0hTzgE0BWSTWuJTs/SnnAgrw== Message-ID: <58E2C94C-E470-45F2-BC2E-21C929FD221E@vidyo.com> References: <20110607084412.16038.596.idtracker@ietfa.amsl.com> <005801cc406d$9c903090$d5b091b0$%roni@huawei.com> <9E56A50D84704E9EB96FE1EC68445967@china.huawei.com> In-Reply-To: <9E56A50D84704E9EB96FE1EC68445967@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "avt@ietf.org" Subject: Re: [AVTCORE] comments on draft-ietf-avtcore-srtp-encrypted-header-ext-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 15:15:30 -0000 Hi, Qin -- My inclination would be that label values are used rarely enough that there= doesn't need to be an IANA registry for them -- they should only be alloca= ted by standards action, and coordination is done by the usual working grou= p consensus processes. Is there some use case where these values would need to be allocated for no= n-standards-track purposes, or by working groups other than AVTCore? On Jul 14, 2011, at 4:15 AM, Qin Wu wrote: > One more comment to draft-ietf-avtcore-srtp-encrypted-header-ext: > This draft allocates two new lable value from 0x06 to 0x07 for k_he and k= _hs, I am wondering > Is there a need in the IANA section to regiserter these values and if yes= , who are responsible for regisering > thes new values? Does it rely on key management protocol or SRTP protcol = or this draft? -- Jonathan Lennox jonathan@vidyo.com From jonathan@vidyo.com Thu Jul 14 15:35:32 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2324311E8098 for ; Thu, 14 Jul 2011 15:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ktplQV1NYsTX for ; Thu, 14 Jul 2011 15:35:31 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 93D6511E8074 for ; Thu, 14 Jul 2011 15:35:31 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 1BF1578FD1F; Thu, 14 Jul 2011 18:35:31 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB016.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 93F1478FCC9; Thu, 14 Jul 2011 18:35:30 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB016.mail.lan ([10.110.17.16]) with mapi; Thu, 14 Jul 2011 18:35:30 -0400 From: Jonathan Lennox To: Magnus Westerlund Date: Thu, 14 Jul 2011 18:35:29 -0400 Thread-Topic: [AVTCORE] Fwd: I-D Action: draft-westerlund-avtcore-multistream-and-simulcast-00.txt Thread-Index: AcxCdiYgNSFf6yT+T3m3BmN6DLMKrw== Message-ID: <6CE70BE0-ADA3-41C8-B1BD-2F713E083AEB@vidyo.com> References: <4E12ED55.2060301@ericsson.com> In-Reply-To: <4E12ED55.2060301@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF AVTCore WG Subject: Re: [AVTCORE] Fwd: I-D Action: draft-westerlund-avtcore-multistream-and-simulcast-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 22:35:32 -0000 On Jul 5, 2011, at 6:54 AM, Magnus Westerlund wrote: > WG, >=20 > As an individual Bo Burman and I have written this internet draft that > discusses multistream and simulcast issues and proposes a set of > extensions to resolve the issues. Feedback is much appreciated. Hi, Magnus. Thank you for writing this draft; I think multi-stream is a very important = area of RTP, one that's hasn't had enough attention paid to it. The draft discusses a number of different issues: multi-stream, simulcast, = RTX, FEC, etc., but seems to assume that these are separate-but-related pro= blems that can be solved independently, possibly with different solutions t= o the different problems. I don't believe that this is the case; instead, I believe that in practice = you will end up with sessions carrying multiple sources, each of which coul= d be be simulcast, with RTX and FEC being used independently for any or all= of the simulcast streams. Thus we need one solution that can handle all t= hese problems at once, including the interactions among them. (Vidyo has b= een doing multi-stream with scalable coding for many years.) As the draft concludes, the multi-stream scenario is best handled by SSRC-m= ultiplexing, as was originally envisioned by RTP. Given that this is the c= ase, it's not clear to me that it's a good idea to use a separate (and in m= y opinion, less flexible) mechanism for the specific special case of simulc= ast. Instead, given the pressure from groups such as RTCweb to reduce the = port consumption of RTP, I'd recommend SSRC-multiplexing across the board. Note also that in the case of multiple sources which are each independently= simulcast, the simulcast structure of different sources could well be diff= erent. (E.g., source A could be available in two resolutions, while sourc= e B has only one and source C has three.) It'd be extremely difficult to m= ap this in session-multiplexed simulcast, whereas for SSRC-multiplexed simu= lcast it should be no more complex than the single-simulcast-source scenari= o.=20 -- Jonathan Lennox jonathan@vidyo.com From bill.wu@huawei.com Thu Jul 14 19:20:33 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82F2311E8074 for ; Thu, 14 Jul 2011 19:20:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.474 X-Spam-Level: X-Spam-Status: No, score=-5.474 tagged_above=-999 required=5 tests=[AWL=1.125, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bl9Jd6T4Kyfu for ; Thu, 14 Jul 2011 19:20:33 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id D02F411E8070 for ; Thu, 14 Jul 2011 19:20:32 -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 <0LOC0098ARU7NH@szxga04-in.huawei.com> for avt@ietf.org; Fri, 15 Jul 2011 10:20:32 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LOC000WMRTS1R@szxga04-in.huawei.com> for avt@ietf.org; Fri, 15 Jul 2011 10:20:31 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml206-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ACG09138; Fri, 15 Jul 2011 10:20:31 +0800 (CST) Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 15 Jul 2011 10:20:22 +0800 Received: from w53375q (10.138.41.76) by szxeml401-hub.china.huawei.com (10.82.67.31) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 15 Jul 2011 10:20:30 +0800 Date: Fri, 15 Jul 2011 10:20:30 +0800 From: Qin Wu X-Originating-IP: [10.138.41.76] To: Jonathan Lennox Message-id: <3D4B32970B9340049897AF249D25DE58@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-CFilter-Loop: Reflected References: <20110607084412.16038.596.idtracker@ietfa.amsl.com> <005801cc406d$9c903090$d5b091b0$%roni@huawei.com> <9E56A50D84704E9EB96FE1EC68445967@china.huawei.com> <58E2C94C-E470-45F2-BC2E-21C929FD221E@vidyo.com> Cc: avt@ietf.org Subject: Re: [AVTCORE] comments on draft-ietf-avtcore-srtp-encrypted-header-ext-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 02:20:33 -0000 Hi,: The old or new label value is used to calculate the encryption and salting keys that encrypt the either header or payload. It seems they should be registered somewhere. However I am not aware of any other SDO or organization use these values. Anyway, I am okay with your clarification. Regards! -Qin ----- Original Message ----- From: "Jonathan Lennox" To: "Qin Wu" Cc: Sent: Thursday, July 14, 2011 11:15 PM Subject: Re: [AVTCORE] comments on draft-ietf-avtcore-srtp-encrypted-header-ext-00.txt > Hi, Qin -- > > My inclination would be that label values are used rarely enough that there doesn't need to be an IANA registry for them -- they should only be allocated by standards action, and coordination is done by the usual working group consensus processes. > > Is there some use case where these values would need to be allocated for non-standards-track purposes, or by working groups other than AVTCore? > > On Jul 14, 2011, at 4:15 AM, Qin Wu wrote: > >> One more comment to draft-ietf-avtcore-srtp-encrypted-header-ext: >> This draft allocates two new lable value from 0x06 to 0x07 for k_he and k_hs, I am wondering >> Is there a need in the IANA section to regiserter these values and if yes, who are responsible for regisering >> thes new values? Does it rely on key management protocol or SRTP protcol or this draft? > > -- > Jonathan Lennox > jonathan@vidyo.com > > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From bill.wu@huawei.com Thu Jul 14 21:14:47 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35F3321F868A for ; Thu, 14 Jul 2011 21:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.554 X-Spam-Level: X-Spam-Status: No, score=-5.554 tagged_above=-999 required=5 tests=[AWL=1.045, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tn6rRBbugyFY for ; Thu, 14 Jul 2011 21:14:46 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 31A4321F869D for ; Thu, 14 Jul 2011 21:14:46 -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 <0LOC00D90WYU55@szxga04-in.huawei.com> for avt@ietf.org; Fri, 15 Jul 2011 12:11:18 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LOC00I8QWYAJR@szxga04-in.huawei.com> for avt@ietf.org; Fri, 15 Jul 2011 12:11:18 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml201-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ACG21061; Fri, 15 Jul 2011 12:11:18 +0800 (CST) Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 15 Jul 2011 12:11:09 +0800 Received: from w53375q (10.138.41.76) by szxeml404-hub.china.huawei.com (10.82.67.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 15 Jul 2011 12:11:17 +0800 Date: Fri, 15 Jul 2011 12:11:15 +0800 From: Qin Wu X-Originating-IP: [10.138.41.76] To: Magnus Westerlund , IETF AVTCore WG Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-CFilter-Loop: Reflected References: <4E12ED55.2060301@ericsson.com> Subject: Re: [AVTCORE] Fwd: I-D Action:draft-westerlund-avtcore-multistream-and-simulcast-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 04:14:47 -0000 Hi, I have read this draft and think it is well written. Several comments below: Section 1.2. Simulcast " Simulcast is the act of simultaneously sending multiple different versions of a media content. This can be done in several ways and for different purposes. This document focuses on the case where one wants to provide multiple different encodings towards a intermediary so that the intermediary can select which version to forward to other participants in the session. More discussion on the different ways of doing simulcast, which is the focus of this document in "Simulcast Usage and Applicability" (Section 3). " [Qin]:Suppose the multiple different version of the same media content is transmitted simultaneously to the receivers, how do you make sure these multiple streams can be recieved by the intermediary in between at the same time and processed at the same time? Section 1.2: [Qin]: Have you considered the case where multiple streams are sent simultaneously to the same RTP receiver and Intermediary does not involve in simulcast processing. In other words, the intermediary is transparent to simulcasting and the RTP receiver is powerful and intelligent enough to deal with simucasting multiple streams. Section 3.2. Simulcasting to Consuming End-Point " This usage is based on an RTP Transport Translator (Section 3.3: Topo-Trn-Translator) [RFC5117]. ........................ " [Qin] It seems to me translator in the case described in section 3.2 also can send same encoding to multiple destinations or send different encoding to independent destination, It look like to me the case described in section 3.3 and section 3.4 are just two sub-cases under the case described in section 3.2. Also the mixer case described in section 3.1 has the same issue. would you like to clarify a little bit about this? Section 3.3 Simulcasting to Consuming End-Point " ...................... Thus some consideration and mechanism are needed to support such a use case so that it doesn't break RTCP reception reporting. " [Qin] Do you have solution to the translator case since the translator is transparent to the RTP receivers? Section 3.3 Same Encoding to Multiple Destinations " ... As this type of simulcast is analog to ASM usage and RTP has good support for ASM sessions, no further consideration for this case is done. " [Qin]: Have you considered SSM case or ASM case which are also simucasted in this document? Is the solution for SSM case different from the case you described in this document? Regards! -Qin ----- Original Message ----- From: "Magnus Westerlund" To: "IETF AVTCore WG" Sent: Tuesday, July 05, 2011 6:54 PM Subject: [AVTCORE] Fwd: I-D Action:draft-westerlund-avtcore-multistream-and-simulcast-00.txt > WG, > > As an individual Bo Burman and I have written this internet draft that > discusses multistream and simulcast issues and proposes a set of > extensions to resolve the issues. Feedback is much appreciated. > > Cheers > > Magnus > -------------------------------------------------------------------------------- > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > From bill.wu@huawei.com Fri Jul 15 01:39:28 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE85421F8797; Fri, 15 Jul 2011 01:39:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.181 X-Spam-Level: X-Spam-Status: No, score=-5.181 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JivdX89Ep1Cv; Fri, 15 Jul 2011 01:39:24 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id A557E21F87A2; Fri, 15 Jul 2011 01:39:22 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LOD0011C9D0VZ@szxga04-in.huawei.com>; Fri, 15 Jul 2011 16:39:00 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LOD00F3C9CAX8@szxga04-in.huawei.com>; Fri, 15 Jul 2011 16:39:00 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml207-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ACG47519; Fri, 15 Jul 2011 16:39:00 +0800 (CST) Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 15 Jul 2011 16:38:53 +0800 Received: from w53375q (10.138.41.76) by szxeml410-hub.china.huawei.com (10.82.67.137) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 15 Jul 2011 16:38:54 +0800 Date: Fri, 15 Jul 2011 16:38:52 +0800 From: Qin Wu X-Originating-IP: [10.138.41.76] To: Roni Even , 'IETF AVTCore WG' , xrblock@ietf.org Message-id: <80B6C22AD93B44CC9944C2853F7FEBDF@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: multipart/alternative; boundary="Boundary_(ID_DeiN3JeAe1ykPriVxhsNKg)" X-Priority: 3 X-MSMail-priority: Normal X-CFilter-Loop: Reflected References: <011401cc3e83$e024fca0$a06ef5e0$%roni@huawei.com> Subject: Re: [AVTCORE] Upadated AVTcore agenda for Quebec X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 08:39:28 -0000 --Boundary_(ID_DeiN3JeAe1ykPriVxhsNKg) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi, I saw there was quite a lot of traffic in the XRBlock mailing list. As one parpcipant of XRBlock WG, I am wondering why chairs don't arrange a timeslot to discss the update of XRBlock work at this time. Regards! -Qin ----- Original Message ----- From: Roni Even To: 'IETF AVTCore WG' Sent: Sunday, July 10, 2011 6:02 AM Subject: [AVTCORE] Upadated AVTcore agenda for Quebec Hi, I uploaded the agenda to the meeting page http://www.ietf.org/proceedings/81/agenda/avtcore.html . Attached is the txt version Roni Even AVTcore co-chair ------------------------------------------------------------------------------ _______________________________________________ Audio/Video Transport Core Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt --Boundary_(ID_DeiN3JeAe1ykPriVxhsNKg) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Hi,
I saw there was quite a lot of traffic in the XRBlock mailing list.
As one parpcipant of XRBlock WG, I am wondering why chairs
don't arrange a timeslot to discss the update of XRBlock work at this time.
 
Regards!
-Qin
----- Original Message -----
From: Roni Even
Sent: Sunday, July 10, 2011 6:02 AM
Subject: [AVTCORE] Upadated AVTcore agenda for Quebec

Hi,

I uploaded the agenda to the meeting page http://www.ietf.org/proceedings/81/agenda/avtcore.html .

Attached is the txt version

Roni Even

AVTcore co-chair

_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
https://www.ietf.org/mailman/listinfo/avt
--Boundary_(ID_DeiN3JeAe1ykPriVxhsNKg)-- From magnus.westerlund@ericsson.com Tue Jul 19 05:31:52 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB72C21F88AB for ; Tue, 19 Jul 2011 05:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.531 X-Spam-Level: X-Spam-Status: No, score=-106.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-ADyFPUXptl for ; Tue, 19 Jul 2011 05:31:52 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 5C4BB21F8745 for ; Tue, 19 Jul 2011 05:31:51 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-b0-4e257935c508 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 65.E1.20773.539752E4; Tue, 19 Jul 2011 14:31:49 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Tue, 19 Jul 2011 14:31:48 +0200 Message-ID: <4E257934.9020008@ericsson.com> Date: Tue, 19 Jul 2011 14:31:48 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Roni Even References: <4E12ED55.2060301@ericsson.com> <004401cc3fa0$00452330$00cf6990$%roni@huawei.com> In-Reply-To: <004401cc3fa0$00452330$00cf6990$%roni@huawei.com> X-Enigmail-Version: 1.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: 'IETF AVTCore WG' Subject: Re: [AVTCORE] Fwd: I-D Action: draft-westerlund-avtcore-multistream-and-simulcast-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 12:31:52 -0000 Thanks for the comments, Inline responses. On 2011-07-11 09:56, Roni Even wrote: > Hi Magnus, > Read the draft, I liked the analysis on the different multiplexing of RTP > streams (Session, SSRC and payload type). > > Some review comments > > 1. The introduction talks about multistream and simulcast. I noticed that it > only talks about how to define the alternatives in terms of the stream but > is not saying how to understand the semantics of the streams, for example > which camera in Telepresence and in simulcast you assume that all > alternative provide the same view (just resolution change, but can also use > different view of the room). This is fine and is being discussed in CLUE at > the moment and should be out of scope here but it may cause the SDP to be > even larger. Exactly, I think the actual meta information about which streams is captured in relation to another is for the external application to take care of, or at least another part of the system. As you say, CLUE WG's work is highly relevant in this. > > 2. On the SDP syntax it may be better when you have more than one m-line to > have all the descriptions which repeats in all m-line appear st the SDP > session level with local identifier and use the identifier in the m-lines. > Maybe based on grouping. I don't quite understand you. Which parts repeats? An example may look like it repeats a lot, but there is actually not a lot of information that are redundant, or exactly the same. CNAMEs are by design the same. However that repetition comes due to us reusing existing attribute which is actually one of our main points. We want to reuse the existing signalling attributes rather than redefine with some alteration. > > > 3. In section 1.1 "Todays SDP signalling support for this is basically the > directionality attribute which indicates an end-point intend to send media > or not. No indication of how many media streams." My understanding so far > was that the number of PT in the m-line is the maximum number of streams > that can be sent in an RTP session. This goes also to the discussion on > support of multiple SSRCs. I think that today video conferencing endpoint is > doing a second offer answer to fix the PT it will use based on the first > offer answer exchange. Personally I have seen no binding between the number of streams and the number of PTs. A m= line with a single PT can have 100 SSRSs sending media in the RTP session. If you believe such a rule exist, then I would like to press you for quoting that text that specifies that. > > 4. The above still does not address the multiple SSRC for the same PT and I > already mentioned it in the past that I think that a lot of product today > will not handle it good. I think that this is a rare case today at least in > centralized video conferencing since the MCU (or RTP mixer if exist) will > use its own SSRC to send the mixed/switched media. Exactly, I think the reasonable assumption with a legacy terminal is that it handles one stream in and one stream out per RTP session. That is why we want to introduce these new SDP attributes to indicate capability of receiving or intention to send multiple streams in the same RTP session. > > 5. In section 3.2 second paragraph you talk about the receivers controlling > what the relay will send but this will make the relay something else than > RTP translator. Yes, but I think it is a reality that already is in use in some RTP derivate systems. You want a simple non media processing box, at the same time you want to limit the bandwidth consume somehow. Thus you need to do dynamic selection of the streams. At the same time you don't want the concept of the RTP session with a joint SSRC space and reporting to break. Thus I think there is need for work towards this model also. However, this is not something that is Bo's and my intention to focus on. I just identify that in this usage we have short commings. > > 6. On the bandwidth support. Currently the definition is the b= is a > receiver capability. I am not sure why you need the sender one, you claim > that there is no way to control the actual bw but the receiver can use RTCP > CCM flow control to tell the sender to reduce the rate. As for the syntax, > my preference is for TIAS semantics and not the one you proposed. If you with TIAS semantics you mean the "media bitrate" without the header overhead? The draft actually has this an open issue in the document, if one should include IP level or not. Page 19-20: It is an open question exactly what this token bucket is measuring, if it is RTP payload only, like TIAS, or if it includes all headers down to the IP level as most of the other bandwidth modifiers do. We need a send direction for various reasons actually. For example in Send only streams, one like to indicate what the highest bandwidth one intended to send. The receiver may reduce it further, but he should have some value of the desired maximum bit-rate the sender invite to use. Or answering a SDP offer. If the offerer has offered to receive 4 payload types with various bit-rates it makes sense to declare for the sender the highest it intends to generate for any of the payload types it supports. Also, without improved directionality capabilities one can't express that you can receive 3 mbps, but only intended to send 1.5 mbps. It is a matter of making the capabilities and the actual configured usage being known to the parties. > > 7. In the last sentence of 7.2.1 you say "This enables a simple fallback > solution to exclude a legacy client from all simulcast versions except one, > whichever is most suitable for the application". My view is that currently > when there are several m-lines of the same media type there is no definition > which one to choose if the answerer do not understand the semantics of the > offer and can support only one stream. Yes, there might be interoperability issues there, but the most likely behavior for a client that doesn't know what to do with streams is to set the port to 0 for anything but the first, or maybe the one with a=content:main. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Tue Jul 19 05:52:38 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D1A821F858E for ; Tue, 19 Jul 2011 05:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.233 X-Spam-Level: X-Spam-Status: No, score=-106.233 tagged_above=-999 required=5 tests=[AWL=-0.234, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MO0p28DR+LVb for ; Tue, 19 Jul 2011 05:52:37 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 61FA621F851F for ; Tue, 19 Jul 2011 05:52:37 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-2e-4e257e141b6e Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 6E.A4.20773.41E752E4; Tue, 19 Jul 2011 14:52:36 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Tue, 19 Jul 2011 14:52:36 +0200 Message-ID: <4E257E13.7090105@ericsson.com> Date: Tue, 19 Jul 2011 14:52:35 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Jonathan Lennox References: <4E12ED55.2060301@ericsson.com> <6CE70BE0-ADA3-41C8-B1BD-2F713E083AEB@vidyo.com> In-Reply-To: <6CE70BE0-ADA3-41C8-B1BD-2F713E083AEB@vidyo.com> X-Enigmail-Version: 1.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: IETF AVTCore WG Subject: Re: [AVTCORE] Fwd: I-D Action: draft-westerlund-avtcore-multistream-and-simulcast-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 12:52:38 -0000 Jonathan, Thanks for the comments. See inline for further comments. On 2011-07-15 00:35, Jonathan Lennox wrote: > On Jul 5, 2011, at 6:54 AM, Magnus Westerlund wrote: > >> WG, >> >> As an individual Bo Burman and I have written this internet draft >> that discusses multistream and simulcast issues and proposes a set >> of extensions to resolve the issues. Feedback is much appreciated. > > > Hi, Magnus. > > Thank you for writing this draft; I think multi-stream is a very > important area of RTP, one that's hasn't had enough attention paid to > it. > > The draft discusses a number of different issues: multi-stream, > simulcast, RTX, FEC, etc., but seems to assume that these are > separate-but-related problems that can be solved independently, > possibly with different solutions to the different problems. > > I don't believe that this is the case; instead, I believe that in > practice you will end up with sessions carrying multiple sources, > each of which could be be simulcast, with RTX and FEC being used > independently for any or all of the simulcast streams. Thus we need > one solution that can handle all these problems at once, including > the interactions among them. (Vidyo has been doing multi-stream with > scalable coding for many years.) I try to take as encompassing view of this as possible. Yes, we don't include RTX or FEC in the discussion currently. I think mostly because we didn't need to. RTX clearly has two different modes, either SSRC or Session multiplexing. FEC depends on which type of FEC one intend to use for what multiplexing that is available. I think we should try to make clear indications going forward for how these should be structured in future extensions. > > As the draft concludes, the multi-stream scenario is best handled by > SSRC-multiplexing, as was originally envisioned by RTP. Given that > this is the case, it's not clear to me that it's a good idea to use a > separate (and in my opinion, less flexible) mechanism for the > specific special case of simulcast. Instead, given the pressure from > groups such as RTCweb to reduce the port consumption of RTP, I'd > recommend SSRC-multiplexing across the board. Jonathan lets me ask you a question. Is any hesitation to use several RTP sessions when most suitable due to the port consumption issue or for some other reason? And here we can debate what is most suitable. My view is that multiple SSRCs in an RTP session is a very good mechanism for streams that one expect to be treated the same way in both central nodes or in end-points. When it comes to sets of streams that needs a different treatment, I think it is logical and a powerful construct to use the RTP session for separating these sets of streams. Yes, the number of underlying transport flows is an important concern in some use cases. But, I think we shouldn't use that as a reason for removing an important concept in RTP. If the issue we have is that one RTP session results in one UDP flow, then lets do something about that instead of removing the RTP session concept. > > Note also that in the case of multiple sources which are each > independently simulcast, the simulcast structure of different sources > could well be different. (E.g., source A could be available in two > resolutions, while source B has only one and source C has three.) > It'd be extremely difficult to map this in session-multiplexed > simulcast, whereas for SSRC-multiplexed simulcast it should be no > more complex than the single-simulcast-source scenario. This is a valid concern, but which I think we have a reasonable straight story for. In the direction you have a certain number of simulcast versions you negotiate that number of session and their individual configurations. If one looks at the example in Section 8.5.2.2, you see that we have there 3 simulcast versions going towards a central mixer. The return channel from the mixer are only two different sessions, supporting to receive all the possible payload types we can get from the other participants. And the difference between these two return sessions are if they are content:main or content:alternative. In other words what we do with the streams locally when rendering them. The two main points we have for choosing Session multiplexing is: A) RTP sessions provides a context for what purpose the streams in them have. B) We don't need to define any new signalling to negotiate the different simulcast levels. Only a bit of binding together the streams and we are done. The SCS and SCR grouping semantics and the SRCNAME is really all we require for getting session multiplexed simulcast to work. The rest is to provide improvements over todays order when it comes to bandwidth signalling and media control in centralized conferencing. cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Tue Jul 19 06:08:24 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8411E21F86AA for ; Tue, 19 Jul 2011 06:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.526 X-Spam-Level: X-Spam-Status: No, score=-106.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3XJL-MQ6saNS for ; Tue, 19 Jul 2011 06:08:23 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 6745A21F856F for ; Tue, 19 Jul 2011 06:08:23 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-a5-4e2581c62b67 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id A1.C6.20773.6C1852E4; Tue, 19 Jul 2011 15:08:22 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Tue, 19 Jul 2011 15:08:21 +0200 Message-ID: <4E2581C4.4020302@ericsson.com> Date: Tue, 19 Jul 2011 15:08:20 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Qin Wu References: <4E12ED55.2060301@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: IETF AVTCore WG Subject: Re: [AVTCORE] Fwd: I-D Action:draft-westerlund-avtcore-multistream-and-simulcast-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 13:08:24 -0000 Qin, Thanks for your comments. See inline for follow-up. On 2011-07-15 06:11, Qin Wu wrote: > Hi, > I have read this draft and think it is well written. Several comments below: > Section 1.2. Simulcast > " > Simulcast is the act of simultaneously sending multiple different > versions of a media content. This can be done in several ways and > for different purposes. This document focuses on the case where one > wants to provide multiple different encodings towards a intermediary > so that the intermediary can select which version to forward to other > participants in the session. More discussion on the different ways > of doing simulcast, which is the focus of this document in "Simulcast > Usage and Applicability" (Section 3). > " > > [Qin]:Suppose the multiple different version of the same media content > is transmitted simultaneously to the receivers, how do you make sure > these multiple streams can be recieved by the intermediary in between > at the same time and processed at the same time? If you have an conference session using a centralized mixer then you normally negotiate the setup with the conference server, that is the controling entity of the mixer. Thus, that side ensures that the mixer and the client really are agreeing on using simulcast. > > Section 1.2: > > [Qin]: Have you considered the case where multiple streams are sent simultaneously to the same > RTP receiver and Intermediary does not involve in simulcast processing. In other words, > the intermediary is transparent to simulcasting and the RTP receiver is powerful and intelligent enough to > deal with simucasting multiple streams. Yes, that is what Section 3.2, really tries to discuss. We are considering it, but it is not our main case. > > > Section 3.2. Simulcasting to Consuming End-Point > " > This usage is based on an RTP Transport Translator (Section 3.3: > Topo-Trn-Translator) [RFC5117]. ........................ > " > > [Qin] It seems to me translator in the case described in section 3.2 > also can send same encoding to multiple destinations or send > different encoding to independent destination, It look like to me > the case described in section 3.3 and section 3.4 are just two sub-cases > under the case described in section 3.2. > Also the mixer case described in section 3.1 has the same issue. > would you like to clarify a little bit about this? To certain degree I think you are correct. Clearly a relay and a full mesh transport is equivalent from a high level functionality perspective. Their impact on parts of the system is clearly different. However, that is not the main difference between 3.2 and 3.3. In 3.3 all peers receive the same encoding, while the 3.2 client receives multiple encodings of the same version. That is the more fundamental difference. When it comes to 3.4 compared to 3.2. In 3.4 party A receives one version of the encoding, but it is different from what is neighbor, party B, receives. In addition there is no need in that case for A and B to be aware of each other. If A and B needs to be aware when receiving content C then I think that usage maps better onto 3.1. > > Section 3.3 Simulcasting to Consuming End-Point > " > ...................... Thus some > consideration and mechanism are needed to support such a use case so > that it doesn't break RTCP reception reporting. > > " > [Qin] Do you have solution to the translator case since the translator is > transparent to the RTP receivers? No, we don't have a solution. We identify this solution because I have heard about conferencing solutions that operates under very similar premises with end-points or a central control selecting which streams to deliver and where it sounds much more like a basic transport relay than an RTP mixer, selecting streams onto the Mixer's own SSRC values. If there is desire to support this use case, then the proponents for this should propose something. > > Section 3.3 Same Encoding to Multiple Destinations > " > ... As this type of simulcast is analog to ASM usage and RTP has good > support for ASM sessions, no further consideration for this case is > done. > " > > [Qin]: Have you considered SSM case or ASM case which are also simucasted in this document? > Is the solution for SSM case different from the case you described in this document? We haven't considered SSM or ASM specifically. It was not our focus. However, I think Session multiplexed simulcast is a given in any cases where the sender wants to use simulcast. That as sessions can be mapped onto different multicast groups, thus allowing a receiver to jump between the simulcast representations based on each receivers need. That is not possible for SSRC multiplexed simulcast. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Tue Jul 19 06:10:47 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B00FA21F88B7 for ; Tue, 19 Jul 2011 06:10:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.528 X-Spam-Level: X-Spam-Status: No, score=-106.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uO0QP2Mcl5Xx for ; Tue, 19 Jul 2011 06:10:47 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 910CA21F88A0 for ; Tue, 19 Jul 2011 06:10:46 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-a6-4e2582556b61 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 08.17.20773.552852E4; Tue, 19 Jul 2011 15:10:45 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Tue, 19 Jul 2011 15:10:45 +0200 Message-ID: <4E258254.6000101@ericsson.com> Date: Tue, 19 Jul 2011 15:10:44 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: IETF AVTCore WG References: <20110718142840.23814.69863.idtracker@ietfa.amsl.com> In-Reply-To: <20110718142840.23814.69863.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.2 X-Forwarded-Message-Id: <20110718142840.23814.69863.idtracker@ietfa.amsl.com> Content-Type: multipart/mixed; boundary="------------000206090002080704010400" X-Brightmail-Tracker: AAAAAA== Subject: [AVTCORE] Fwd: IPR Disclosure: Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-westerlund-avtcore-multistream-and-simulcast-00 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 13:10:47 -0000 --------------000206090002080704010400 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit For your information. Magnus Westerlund --------------000206090002080704010400 Content-Type: message/rfc822; name="IPR Disclosure: Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-westerlund-avtcore-multistream-and-simulcast-00.eml" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="IPR Disclosure: Telefonaktiebolaget LM Ericsson (publ)'s Sta"; filename*1="tement about IPR related to draft-westerlund-avtcore-multist"; filename*2="ream-and-simulcast-00.eml" Received: from mailgw7.ericsson.se (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.83) with Microsoft SMTP Server id 8.3.137.0; Mon, 18 Jul 2011 16:28:57 +0200 Received: from mail.ietf.org (mail.ietf.org [64.170.98.30]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 50.D6.25859.823442E4; Mon, 18 Jul 2011 16:28:56 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2BCF21F8C44; Mon, 18 Jul 2011 07:28:45 -0700 (PDT) Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yh41mPUGXuOB; Mon, 18 Jul 2011 07:28:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E54021F8548; Mon, 18 Jul 2011 07:28:40 -0700 (PDT) From: IETF Secretariat To: Magnus Westerlund , Bo Burman CC: "housley@vigilsec.com" , "ipr-announce@ietf.org" Date: Mon, 18 Jul 2011 16:28:40 +0200 Subject: IPR Disclosure: Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-westerlund-avtcore-multistream-and-simulcast-00 Thread-Topic: IPR Disclosure: Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-westerlund-avtcore-multistream-and-simulcast-00 Thread-Index: AcxFVwdGM+uPOAAyQoKoTt7geqjnxA== Message-ID: <20110718142840.23814.69863.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AuthSource: esessmw0184.eemea.ericsson.se X-MS-Has-Attach: X-MS-TNEF-Correlator: x-auditid: c1b4fb30-b7ba2ae000006503-83-4e244328171e x-brightmail-tracker: AAAAAA== x-virus-scanned: amavisd-new at amsl.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 DQpEZWFyIE1hZ251cyBXZXN0ZXJsdW5kLCBCbyBCdXJtYW46DQoNCiBBbiBJUFIgZGlzY2xvc3Vy ZSB0aGF0IHBlcnRhaW5zIHRvIHlvdXIgSW50ZXJuZXQtRHJhZnQgZW50aXRsZWQgIlJUUCBNdWx0 aXBsZQ0KU3RyZWFtIFNlc3Npb25zIGFuZCBTaW11bGNhc3QiIChkcmFmdC13ZXN0ZXJsdW5kLWF2 dGNvcmUtbXVsdGlzdHJlYW0tYW5kLQ0Kc2ltdWxjYXN0KSB3YXMgc3VibWl0dGVkIHRvIHRoZSBJ RVRGIFNlY3JldGFyaWF0IG9uIDIwMTEtMDctMTggYW5kIGhhcyBiZWVuDQpwb3N0ZWQgb24gdGhl ICJJRVRGIFBhZ2Ugb2YgSW50ZWxsZWN0dWFsIFByb3BlcnR5IFJpZ2h0cyBEaXNjbG9zdXJlcyIN CihodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2lwci8xNTkyLykuIFRoZSB0aXRsZSBvZiB0 aGUgSVBSIGRpc2Nsb3N1cmUgaXMNCiJUZWxlZm9uYWt0aWVib2xhZ2V0IExNIEVyaWNzc29uIChw dWJsKSdzIFN0YXRlbWVudCBhYm91dCBJUFIgcmVsYXRlZCB0byBkcmFmdC0NCndlc3Rlcmx1bmQt YXZ0Y29yZS1tdWx0aXN0cmVhbS1hbmQtc2ltdWxjYXN0LTAwLiIiKTsNCg0KVGhlIElFVEYgU2Vj cmV0YXJpYXQNCg0K --------------000206090002080704010400-- From magnus.westerlund@ericsson.com Tue Jul 19 08:35:15 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC06611E8070 for ; Tue, 19 Jul 2011 08:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.538 X-Spam-Level: X-Spam-Status: No, score=-106.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-7WXSS9G548 for ; Tue, 19 Jul 2011 08:35:14 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 7ABC121F8AB9 for ; Tue, 19 Jul 2011 08:35:14 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-af-4e25a4311abc Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 9E.FF.09774.134A52E4; Tue, 19 Jul 2011 17:35:13 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.137.0; Tue, 19 Jul 2011 17:35:13 +0200 Message-ID: <4E25A430.5050707@ericsson.com> Date: Tue, 19 Jul 2011 17:35:12 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: IETF AVTCore WG X-Enigmail-Version: 1.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [AVTCORE] RTP Internal Multiplexing of RTP sessions X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 15:35:15 -0000 WG, As Individual contributor. I don't know if people in the WG are aware of the discussion ongoing in RTCWEB around multiplexing of protocols over the same underlying transport flow, like UDP flow. That include RTP sessions. There is a proposal: "Multiplexing of Real-Time Transport Protocol (RTP) Traffic for Browser based Real-Time Communications (RTC)" https://datatracker.ietf.org/doc/draft-rosenberg-rtcweb-rtpmux/?include_text=1 This proposal is criticized by the following draft. https://datatracker.ietf.org/doc/draft-perkins-rtcweb-rtp-usage/?include_text=1 There is an ongoing discussion on several aspects of these proposals on the RTCWEB WG. You are welcome to go join the discussion of the other questions raised on that mailing list. Here I primarily want to raise the issue I see with multiplexing several RTP sessions onto the same lower layer transport without something explicitly identifying these separate sessions. And in particular the RTP SSRC semantics changes that is proposed by the Rosenberg draft. Personally I think it is time we tackle the issue of how to efficiently run multiple RTP sessions over one lower layer transport. This as there are several wanting to have that functionality. However, I think this must be done in a very careful way. As we don't want to create an alternative version of RTP which is what the Rosenberg proposal in fact does. I do want us to gather the requirements on this and think of how we can accomplish this. I think there is a clear risk that we will not be able to accomplish it without either adding some type of shim header which has it sets of drawback or in fact fork or change the RTP protocol in such a way that it will not be fully compatible with what exist today. But if that is to be done, we should have a very clear consensus on that and ensure that we then develop future extensions to RTP within a single version of the protocol, not two. As WG chair: We are considering re-arranging the agenda to facilitate a debate of this topic in Quebec. So please indicate both your view of the topic in general and if you think we should re-prioritize the agenda. cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From Even.roni@huawei.com Tue Jul 19 11:30:46 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0054D228017 for ; Tue, 19 Jul 2011 11:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.399 X-Spam-Level: X-Spam-Status: No, score=-101.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0o6Vja8SQZP3 for ; Tue, 19 Jul 2011 11:30:45 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 191075E8009 for ; Tue, 19 Jul 2011 11:30:45 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LOL003PPFF6GX@szxga05-in.huawei.com> for avt@ietf.org; Wed, 20 Jul 2011 02:30:42 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LOL00FOJFF5NQ@szxga05-in.huawei.com> for avt@ietf.org; Wed, 20 Jul 2011 02:30:42 +0800 (CST) Received: from windows8d787f9 (bzq-79-183-21-130.red.bezeqint.net [79.183.21.130]) by szxml11-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LOL0087TFEY91@szxml11-in.huawei.com>; Wed, 20 Jul 2011 02:30:41 +0800 (CST) Date: Tue, 19 Jul 2011 21:27:59 +0300 From: Roni Even In-reply-to: <4E257934.9020008@ericsson.com> To: 'Magnus Westerlund' Message-id: <00b101cc4641$9bd703c0$d3850b40$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcxGD+XBFGIYKzAuQsixZNArMn2d0wALc43w References: <4E12ED55.2060301@ericsson.com> <004401cc3fa0$00452330$00cf6990$%roni@huawei.com> <4E257934.9020008@ericsson.com> Cc: 'IETF AVTCore WG' Subject: Re: [AVTCORE] Fwd: I-D Action: draft-westerlund-avtcore-multistream-and-simulcast-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 18:30:46 -0000 Hi Magnus, > > 2. On the SDP syntax it may be better when you have more than one m- > line to > > have all the descriptions which repeats in all m-line appear st the > SDP > > session level with local identifier and use the identifier in the m- > lines. > > Maybe based on grouping. > > I don't quite understand you. Which parts repeats? An example may look > like it repeats a lot, but there is actually not a lot of information > that are redundant, or exactly the same. > > CNAMEs are by design the same. However that repetition comes due to us > reusing existing attribute which is actually one of our main points. We > want to reuse the existing signalling attributes rather than redefine > with some alteration. > > > Three options using your example from 8.5.1.2, the second I am not sure since it may change the SDP SSRC syntax 1. v=0 o=alice 2890844526 2890842807 IN IP4 192.0.2.156 s=Telepresence Alice Invite c=IN IP4 192.0.2.156 b=AS:8965 t=0 0 param = 1 cname:alice@foo.example.com param = 2 srcname:a3:d3:4b:f1:22:12 param = 3 srcname:12:3f:ab:d2:ec:32 param = 4 srcname:7f:12:db:87:2d:52 m=audio 49200 RTP/AVP 97 96 b=AS:725 a=rtpmap:96 G719/48000/2 a=rtpmap:97 G719/48000 a=bw:send pt=96 SMT:tb=128800:1500 a=bw:send pt=97 SMT:tb=64800:1500 a=bw:recv pt=* AMT:tb=644000:1500 a=max-recv-ssrc:* 5 a=max-send-ssrc:97 3 a=max-send-ssrc:96 1 a=ssrc:239245219 param:1 a=ssrc:239245219 param:2 a=ssrc:986545121 param:1 a=ssrc:986545121 param:3 a=ssrc:2199983234 param:1 a=ssrc:2199983234 param=4 m=video 49300 RTP/AVP 96 b=AS:8240 a=rtpmap:96 H264/90000 a=fmtp:96 profile-level-id=42c01e a=imageattr:* send [x=1280,y=720] recv [x=1280,y=720] a=bw:send pt=96 SMT:tb=2500000:8192 a=bw:recv pt=96 SMT:tb=3000000:8192 a=bw:send pt=* AMT:tb=8000000:16384 a=max-recv-ssrc:* 5 a=max-send-ssrc:* 3 a=ssrc:245219239 param:1 a=ssrc:245219239 param:2 a=ssrc:545121986 param:1 a=ssrc:545121986 param:3 a=ssrc:199983234 param:1 a=ssrc:199983234 param:4 a=content:main 2. v=0 o=alice 2890844526 2890842807 IN IP4 192.0.2.156 s=Telepresence Alice Invite c=IN IP4 192.0.2.156 b=AS:8965 t=0 0 param = 1 cname:alice@foo.example.com rcname:a3:d3:4b:f1:22:12 param = 2 name:alice@foo.example.com srcname:12:3f:ab:d2:ec:32 param = 3 cname:alice@foo.example.com srcname:7f:12:db:87:2d:52 m=audio 49200 RTP/AVP 97 96 b=AS:725 a=rtpmap:96 G719/48000/2 a=rtpmap:97 G719/48000 a=bw:send pt=96 SMT:tb=128800:1500 a=bw:send pt=97 SMT:tb=64800:1500 a=bw:recv pt=* AMT:tb=644000:1500 a=max-recv-ssrc:* 5 a=max-send-ssrc:97 3 a=max-send-ssrc:96 1 a=ssrc:239245219 param:1 a=ssrc:986545121 param:2 a=ssrc:2199983234 param:3 m=video 49300 RTP/AVP 96 b=AS:8240 a=rtpmap:96 H264/90000 a=fmtp:96 profile-level-id=42c01e a=imageattr:* send [x=1280,y=720] recv [x=1280,y=720] a=bw:send pt=96 SMT:tb=2500000:8192 a=bw:recv pt=96 SMT:tb=3000000:8192 a=bw:send pt=* AMT:tb=8000000:16384 a=max-recv-ssrc:* 5 a=max-send-ssrc:* 3 a=ssrc:245219239 param:1 a=ssrc:545121986 param:2 a=ssrc:199983234 param:3 a=content:main 3. the shortest will be the ssrc-id=id:ssrc-value, the id will identify the id to use in the media level with all the parameters except the other ssrc-id's in the multi line. We can probably give a better syntax but it is shorter. v=0 o=alice 2890844526 2890842807 IN IP4 192.0.2.156 s=Telepresence Alice Invite c=IN IP4 192.0.2.156 b=AS:8965 t=0 0 multi = cname:alice@foo.example.com srcname:a3:d3:4b:f1:22:12 ssrc-id=1:239245219 ssrc-id=2: 245219239 multi= cname:alice@foo.example.com srcname:12:3f:ab:d2:ec:32 ssrc-id=3:986545121 ssrc-id=4:545121986 multi= cname:alice@foo.example.com srcname:7f:12:db:87:2d:52 ssrc-id=5:2199983234 ssrc-id=6:199983234 m=audio 49200 RTP/AVP 97 96 b=AS:725 a=rtpmap:96 G719/48000/2 a=rtpmap:97 G719/48000 a=bw:send pt=96 SMT:tb=128800:1500 a=bw:send pt=97 SMT:tb=64800:1500 a=bw:recv pt=* AMT:tb=644000:1500 a=max-recv-ssrc:* 5 a=max-send-ssrc:97 3 a=max-send-ssrc:96 1 a=multi:1 a= multi:3 a= multi:5 m=video 49300 RTP/AVP 96 b=AS:8240 a=rtpmap:96 H264/90000 a=fmtp:96 profile-level-id=42c01e a=imageattr:* send [x=1280,y=720] recv [x=1280,y=720] a=bw:send pt=96 SMT:tb=2500000:8192 a=bw:recv pt=96 SMT:tb=3000000:8192 a=bw:send pt=* AMT:tb=8000000:16384 a=max-recv-ssrc:* 5 a=max-send-ssrc:* 3 a= multi:2 a= multi:4 a= multi:6 a=content:main Roni From oran@cisco.com Tue Jul 19 12:52:31 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C76585E800D for ; Tue, 19 Jul 2011 12:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17uW8IpMjjdS for ; Tue, 19 Jul 2011 12:52:31 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id C29F65E800C for ; Tue, 19 Jul 2011 12:52:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=oran@cisco.com; l=3158; q=dns/txt; s=iport; t=1311105150; x=1312314750; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=wtMvf334nnlRO+2J+gg3kDQkBgqLGyqooIwfJPnFhJo=; b=UfjrlGXjWHkSg1iWUtD2RG/bl6NZlqIFuIFRjQ61Gb6uPrdbnTRp6fjZ kC1jj/omv59YuOb7LuEtP6GcbAPxbQAx9gXpDoBFL2xjqylTZ+99kM6An fGrVQ4xiWDg9MDcmWs6RZRjnfq7w2pAxa5WoC8iYyei+Vafi14URCvG41 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EACDgJU6rRDoI/2dsb2JhbABUp1F3iHylIJ5PAoVbXwSSZ5B2 X-IronPort-AV: E=Sophos;i="4.67,230,1309737600"; d="scan'208";a="4474813" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-8.cisco.com with ESMTP; 19 Jul 2011 19:52:30 +0000 Received: from dhcp-161-44-173-111.cisco.com (dhcp-161-44-173-111.cisco.com [161.44.173.111]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6JJqS7c005010; Tue, 19 Jul 2011 19:52:29 GMT Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: David R Oran In-Reply-To: <4E25A430.5050707@ericsson.com> Date: Tue, 19 Jul 2011 15:52:27 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1E7F2EB0-7197-49CC-8CEC-20EE74F6BD75@cisco.com> References: <4E25A430.5050707@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1244.3) Cc: IETF AVTCore WG Subject: Re: [AVTCORE] RTP Internal Multiplexing of RTP sessions X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 19:52:31 -0000 I'm very interested in this work and willing to help. On Jul 19, 2011, at 11:35 AM, Magnus Westerlund wrote: > WG, >=20 > As Individual contributor. >=20 > I don't know if people in the WG are aware of the discussion ongoing = in > RTCWEB around multiplexing of protocols over the same underlying > transport flow, like UDP flow. That include RTP sessions. >=20 > There is a proposal: > "Multiplexing of Real-Time Transport Protocol (RTP) Traffic for = Browser > based Real-Time Communications (RTC)" > = https://datatracker.ietf.org/doc/draft-rosenberg-rtcweb-rtpmux/?include_te= xt=3D1 >=20 > This proposal is criticized by the following draft. > = https://datatracker.ietf.org/doc/draft-perkins-rtcweb-rtp-usage/?include_t= ext=3D1 >=20 > There is an ongoing discussion on several aspects of these proposals = on > the RTCWEB WG. You are welcome to go join the discussion of the other > questions raised on that mailing list. >=20 > Here I primarily want to raise the issue I see with multiplexing = several > RTP sessions onto the same lower layer transport without something > explicitly identifying these separate sessions. And in particular the > RTP SSRC semantics changes that is proposed by the Rosenberg draft. >=20 > Personally I think it is time we tackle the issue of how to = efficiently > run multiple RTP sessions over one lower layer transport. This as = there > are several wanting to have that functionality. However, I think this > must be done in a very careful way. As we don't want to create an > alternative version of RTP which is what the Rosenberg proposal in = fact > does. I do want us to gather the requirements on this and think of how > we can accomplish this. >=20 > I think there is a clear risk that we will not be able to accomplish = it > without either adding some type of shim header which has it sets of > drawback or in fact fork or change the RTP protocol in such a way that > it will not be fully compatible with what exist today. But if that is = to > be done, we should have a very clear consensus on that and ensure that > we then develop future extensions to RTP within a single version of = the > protocol, not two. >=20 > As WG chair: >=20 > We are considering re-arranging the agenda to facilitate a debate of > this topic in Quebec. >=20 > So please indicate both your view of the topic in general and if you > think we should re-prioritize the agenda. >=20 > cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From abegen@cisco.com Tue Jul 19 13:49:57 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76BCC21F8ADE for ; Tue, 19 Jul 2011 13:49:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.799 X-Spam-Level: X-Spam-Status: No, score=-5.799 tagged_above=-999 required=5 tests=[AWL=-3.200, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EjoBs-ab66cg for ; Tue, 19 Jul 2011 13:49:53 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 9131C21F8ADC for ; Tue, 19 Jul 2011 13:49:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=3390; q=dns/txt; s=iport; t=1311108593; x=1312318193; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=TPBaNwYpYOWrxpWuwHqI8WT5ngsdEyePQqlu79Dq1yM=; b=M5Kc9L78L7FQe43rUyWuZk9eVU+/QArRNIAe9fzaxYz5mXu11boHHqkx 6Z7GW9pSZqzMiPfKclbYP9T7oniaU8y6bMP2euAvOyQLLl3QDvnvhNDb0 +htKiLPAeFqhj9ScicCcVMB4x6qV9DaPz/mUXR+XyX/fSMM3XsJvB9Wq4 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuIAAOXsJU6rRDoH/2dsb2JhbABUmAyPRXeIfKUUnkkChVtfBIdUkCCLbQ X-IronPort-AV: E=Sophos;i="4.67,230,1309737600"; d="scan'208";a="4490306" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-2.cisco.com with ESMTP; 19 Jul 2011 20:49:53 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6JKnq10009095; Tue, 19 Jul 2011 20:49:52 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 19 Jul 2011 13:49:52 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Tue, 19 Jul 2011 13:49:33 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540F810017@xmb-sjc-215.amer.cisco.com> In-Reply-To: <4E25A430.5050707@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVTCORE] RTP Internal Multiplexing of RTP sessions Thread-Index: AcxGKXrJ7QQh5fJSQXyoxQZ1lgBOxgAK8gsw References: <4E25A430.5050707@ericsson.com> From: "Ali C. Begen (abegen)" To: "Magnus Westerlund" , "IETF AVTCore WG" X-OriginalArrivalTime: 19 Jul 2011 20:49:52.0565 (UTC) FILETIME=[68764E50:01CC4655] Subject: Re: [AVTCORE] RTP Internal Multiplexing of RTP sessions X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 20:49:57 -0000 > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of = Magnus Westerlund > Sent: Tuesday, July 19, 2011 5:35 PM > To: IETF AVTCore WG > Subject: [AVTCORE] RTP Internal Multiplexing of RTP sessions >=20 > WG, >=20 > As Individual contributor. >=20 > I don't know if people in the WG are aware of the discussion ongoing = in > RTCWEB around multiplexing of protocols over the same underlying > transport flow, like UDP flow. That include RTP sessions. >=20 > There is a proposal: > "Multiplexing of Real-Time Transport Protocol (RTP) Traffic for = Browser > based Real-Time Communications (RTC)" > = https://datatracker.ietf.org/doc/draft-rosenberg-rtcweb-rtpmux/?include_t= ext=3D1 >=20 > This proposal is criticized by the following draft. > = https://datatracker.ietf.org/doc/draft-perkins-rtcweb-rtp-usage/?include_= text=3D1 >=20 > There is an ongoing discussion on several aspects of these proposals = on > the RTCWEB WG. You are welcome to go join the discussion of the other > questions raised on that mailing list. >=20 > Here I primarily want to raise the issue I see with multiplexing = several > RTP sessions onto the same lower layer transport without something > explicitly identifying these separate sessions. And in particular the > RTP SSRC semantics changes that is proposed by the Rosenberg draft. >=20 > Personally I think it is time we tackle the issue of how to = efficiently > run multiple RTP sessions over one lower layer transport. This as = there > are several wanting to have that functionality. However, I think this > must be done in a very careful way. As we don't want to create an > alternative version of RTP which is what the Rosenberg proposal in = fact > does. I do want us to gather the requirements on this and think of how > we can accomplish this. >=20 > I think there is a clear risk that we will not be able to accomplish = it > without either adding some type of shim header which has it sets of > drawback or in fact fork or change the RTP protocol in such a way that > it will not be fully compatible with what exist today. But if that is = to > be done, we should have a very clear consensus on that and ensure that > we then develop future extensions to RTP within a single version of = the > protocol, not two. >=20 > As WG chair: >=20 > We are considering re-arranging the agenda to facilitate a debate of > this topic in Quebec. >=20 > So please indicate both your view of the topic in general and if you > think we should re-prioritize the agenda. If that would help, I can donate some minutes from my presentations ;) -acbegen =20 > cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From olivier.crete@collabora.com Tue Jul 19 14:57:51 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93FDF21F8606 for ; Tue, 19 Jul 2011 14:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EelcK88tK7K2 for ; Tue, 19 Jul 2011 14:57:51 -0700 (PDT) Received: from bhuna.collabora.co.uk (bhuna.collabora.co.uk [93.93.128.226]) by ietfa.amsl.com (Postfix) with ESMTP id E284021F85C7 for ; Tue, 19 Jul 2011 14:57:50 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: tester) with ESMTPSA id 9FE58600304 From: Olivier =?ISO-8859-1?Q?Cr=EAte?= To: IETF AVTCore WG Date: Tue, 19 Jul 2011 17:57:47 -0400 Organization: Collabora Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-gQp/sdbPQUIHme9puhbB" X-Mailer: Evolution 3.0.2 (3.0.2-3.fc15) Message-ID: <1311112669.5922.22.camel@TesterTop4> Mime-Version: 1.0 Subject: [AVTCORE] RFC 4585 RPSI and H.264 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 21:57:51 -0000 --=-gQp/sdbPQUIHme9puhbB Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, In RFC 4585, the RPSI message is defined as containing a codec specific FCI. H.263 defines something to be used in such a case, but I see nothing similar for H.264. Is it not used at all? Do people just use H.271 back channel messages wrapped in RFC 5104 message ? Also, I assume the PictureID used for RFC 4585 AVPF SLI messages is the same as in H.271 ? --=20 Olivier Cr=C3=AAte olivier.crete@collabora.com --=-gQp/sdbPQUIHme9puhbB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEABECAAYFAk4l/dsACgkQHTiOWk7ZorsdtQCffXLLPrQc6jczIQefYg/OlgSS nRIAmgII1bKiv6B355g554LqqlVfu7DD =TOa9 -----END PGP SIGNATURE----- --=-gQp/sdbPQUIHme9puhbB-- From Even.roni@huawei.com Wed Jul 20 00:23:37 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C2EF21F8781 for ; Wed, 20 Jul 2011 00:23:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.999 X-Spam-Level: X-Spam-Status: No, score=-103.999 tagged_above=-999 required=5 tests=[AWL=2.600, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6-4eLVaIjrr for ; Wed, 20 Jul 2011 00:23:33 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 0B92B21F877D for ; Wed, 20 Jul 2011 00:23:33 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LOM00BVBF4D2J@szxga03-in.huawei.com> for avt@ietf.org; Wed, 20 Jul 2011 15:21:49 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LOM008J0F48H5@szxga03-in.huawei.com> for avt@ietf.org; Wed, 20 Jul 2011 15:21:44 +0800 (CST) Received: from windows8d787f9 (bzq-79-183-21-130.red.bezeqint.net [79.183.21.130]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LOM00J28F3Z1S@szxml12-in.huawei.com>; Wed, 20 Jul 2011 15:21:44 +0800 (CST) Date: Wed, 20 Jul 2011 10:19:00 +0300 From: Roni Even In-reply-to: To: 'Colin Perkins' , 'Qin Wu' Message-id: <00f501cc46ad$51929830$f4b7c890$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcwwJE+jnR6S0eEiSZeOx01uaknLogWiDJgQ References: <20110616092110.1754.68542.idtracker@ietfa.amsl.com> Cc: avt@ietf.org Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-03.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 07:23:37 -0000 Hi, Looking at the tag mechanism I agree with Colin that using it just to reduce the size of the packet is not the important. Still I can see a different use case for the tag in order to group XR reports as one entity. The monitoring architecture suggest dividing large reports to small blocks and the assumption is the by the SSRC you define a group of blocks per an application. Using the tag may provide another level of freedom allowing more than one tag per SSRC and the tag defines a reporting unit. This is a change from the current usage of tags and I am bringing it to see if this usage is useful. As for the correlation with non-rtp protocols I agree that SDES may be used for it. Regards Roni Even As individual > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > Colin Perkins > Sent: Tuesday, June 21, 2011 5:56 PM > To: Qin Wu > Cc: avt@ietf.org > Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-03.txt > > Qin, > > This does address many of my comments on the earlier versions. Some > quick comments on this draft: > > - In Section 5.2, there is no need to report the CNAME, since this is > redundant with RTCP SDES information. > > - Section 5.2 suggests reporting "the sequence number of the first > packet of the RTP session". A receiver cannot know what is the first > packet of the session, only what was the first packet it received, so > this should be clarified to "the sequence number of the first packet > received in the RTP session". The first sequence number received also > becomes less useful after the sequence number space wraps around, so it > might make sense to include a count of sequence number cycles since > then. > > - Section 5.3 discusses sending information that can be used to > correlate an RTP source with non-RTP protocols. This seems like a > reasonable thing to add. However, since it is describing the source, > rather than providing a quality report, should this be an new RTCP SDES > block type, rather than an RTCP XR block? > > Colin > > > On 16 Jun 2011, at 10:29, Qin Wu wrote: > > > Hi,: > > In response to the recent comments and suggestion on the list, a new > version of draft-ietf-avtcore-monarch is just submitted. > > http://www.ietf.org/internet-drafts/draft-ietf-avtcore-monarch-03.txt > > The diff is: > > http://tools.ietf.org/rfcdiff?url2=draft-ietf-avtcore-monarch-03 > > > > Please check if your comments are addressed in this version. > > > > Regards! > > -Qin > > > > ----- Original Message ----- > > From: > > To: > > Cc: > > Sent: Thursday, June 16, 2011 5:21 PM > > Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-03.txt > > > > > >> A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Audio/Video Transport > Core Maintenance Working Group of the IETF. > >> > >> Title : Monitoring Architectures for RTP > >> Author(s) : Qin Wu > >> Geoff Hunt > >> Philip Arden > >> Filename : draft-ietf-avtcore-monarch-03.txt > >> Pages : 23 > >> Date : 2011-06-16 > >> > >> This memo proposes an architecture for extending RTCP with a new > RTCP > >> XR (RFC3611) block type to report new metrics regarding media > >> transmission or reception quality, as proposed in RFC5968. This > memo > >> suggests that a new block should contain a single metric or a small > >> number of metrics relevant to a single parameter of interest or > >> concern, rather than containing a number of metrics which attempt > to > >> provide full coverage of all those parameters of concern to a > >> specific application. Applications may then "mix and > match" to > >> create a set of blocks which covers their set of concerns. Where > >> possible, a specific block should be designed to be re-usable > across > >> more than one application, for example, for all of voice, streaming > >> audio and video. > >> > >> > >> A URL for this Internet-Draft is: > >> http://www.ietf.org/internet-drafts/draft-ietf-avtcore-monarch- > 03.txt > >> > >> Internet-Drafts are also available by anonymous FTP at: > >> ftp://ftp.ietf.org/internet-drafts/ > >> > >> This Internet-Draft can be retrieved at: > >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtcore-monarch-03.txt > >> _______________________________________________ > >> Audio/Video Transport Core Maintenance > >> avt@ietf.org > >> https://www.ietf.org/mailman/listinfo/avt > >> > > _______________________________________________ > > Audio/Video Transport Core Maintenance > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt > > > > -- > Colin Perkins > http://csperkins.org/ > > > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From john.elwell@siemens-enterprise.com Wed Jul 20 02:30:49 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1A2521F89A7 for ; Wed, 20 Jul 2011 02:30:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.356 X-Spam-Level: X-Spam-Status: No, score=-104.356 tagged_above=-999 required=5 tests=[AWL=-1.757, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HTW0Hy4WddS2 for ; Wed, 20 Jul 2011 02:30:49 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id C0D0E21F898E for ; Wed, 20 Jul 2011 02:30:48 -0700 (PDT) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id D00E323F04E3; Wed, 20 Jul 2011 11:30:47 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 20 Jul 2011 11:30:47 +0200 From: "Elwell, John" To: Magnus Westerlund , IETF AVTCore WG Date: Wed, 20 Jul 2011 11:30:46 +0200 Thread-Topic: [AVTCORE] RTP Internal Multiplexing of RTP sessions Thread-Index: AcxGKXttexBf485yQ46kuNITHafccQAlibjQ Message-ID: References: <4E25A430.5050707@ericsson.com> In-Reply-To: <4E25A430.5050707@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [AVTCORE] RTP Internal Multiplexing of RTP sessions X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 09:30:50 -0000 I think this is an important topic and should receive some agenda time in Q= uebec. John=20 > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On=20 > Behalf Of Magnus Westerlund > Sent: 19 July 2011 16:35 > To: IETF AVTCore WG > Subject: [AVTCORE] RTP Internal Multiplexing of RTP sessions >=20 > WG, >=20 > As Individual contributor. >=20 > I don't know if people in the WG are aware of the discussion=20 > ongoing in > RTCWEB around multiplexing of protocols over the same underlying > transport flow, like UDP flow. That include RTP sessions. >=20 > There is a proposal: > "Multiplexing of Real-Time Transport Protocol (RTP) Traffic=20 > for Browser > based Real-Time Communications (RTC)" > https://datatracker.ietf.org/doc/draft-rosenberg-rtcweb-rtpmux > /?include_text=3D1 >=20 > This proposal is criticized by the following draft. > https://datatracker.ietf.org/doc/draft-perkins-rtcweb-rtp-usag > e/?include_text=3D1 >=20 > There is an ongoing discussion on several aspects of these=20 > proposals on > the RTCWEB WG. You are welcome to go join the discussion of the other > questions raised on that mailing list. >=20 > Here I primarily want to raise the issue I see with=20 > multiplexing several > RTP sessions onto the same lower layer transport without something > explicitly identifying these separate sessions. And in particular the > RTP SSRC semantics changes that is proposed by the Rosenberg draft. >=20 > Personally I think it is time we tackle the issue of how to=20 > efficiently > run multiple RTP sessions over one lower layer transport.=20 > This as there > are several wanting to have that functionality. However, I think this > must be done in a very careful way. As we don't want to create an > alternative version of RTP which is what the Rosenberg=20 > proposal in fact > does. I do want us to gather the requirements on this and think of how > we can accomplish this. >=20 > I think there is a clear risk that we will not be able to=20 > accomplish it > without either adding some type of shim header which has it sets of > drawback or in fact fork or change the RTP protocol in such a way that > it will not be fully compatible with what exist today. But if=20 > that is to > be done, we should have a very clear consensus on that and ensure that > we then develop future extensions to RTP within a single=20 > version of the > protocol, not two. >=20 > As WG chair: >=20 > We are considering re-arranging the agenda to facilitate a debate of > this topic in Quebec. >=20 > So please indicate both your view of the topic in general and if you > think we should re-prioritize the agenda. >=20 > cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > = From magnus.westerlund@ericsson.com Wed Jul 20 02:52:34 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B26621F87A4 for ; Wed, 20 Jul 2011 02:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.641 X-Spam-Level: X-Spam-Status: No, score=-105.641 tagged_above=-999 required=5 tests=[AWL=-0.842, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QrP5V2CNcWnf for ; Wed, 20 Jul 2011 02:52:33 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 1688C21F8794 for ; Wed, 20 Jul 2011 02:52:32 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-41-4e26a5607ab5 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 43.84.20773.065A62E4; Wed, 20 Jul 2011 11:52:32 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Wed, 20 Jul 2011 11:52:31 +0200 Message-ID: <4E26A55D.2000608@ericsson.com> Date: Wed, 20 Jul 2011 11:52:29 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Roni Even References: <4E12ED55.2060301@ericsson.com> <004401cc3fa0$00452330$00cf6990$%roni@huawei.com> <4E257934.9020008@ericsson.com> <00b101cc4641$9bd703c0$d3850b40$%roni@huawei.com> In-Reply-To: <00b101cc4641$9bd703c0$d3850b40$%roni@huawei.com> X-Enigmail-Version: 1.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: 'IETF AVTCore WG' Subject: Re: [AVTCORE] Fwd: I-D Action: draft-westerlund-avtcore-multistream-and-simulcast-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 09:52:34 -0000 Hi Roni, I understand what you are after. But, this looks very much like a general change to the a=ssrc attribute, than something specific to our proposed extension. That we propose a new SDES item seems to make it clearer that the current structure isn't optimized for size. But the question does it really matter. It is not like these SDP anyway results in SIP packets that are below 1500 bytes. It also creates a level of indirection, which isn't that problematic for the machine interpretations but for humans. Lets get back to it when we have agreed on the high level issues and actually are doing the extension. Cheers Magnus On 2011-07-19 20:27, Roni Even wrote: > Hi Magnus, > >>> 2. On the SDP syntax it may be better when you have more than one m- >> line to >>> have all the descriptions which repeats in all m-line appear st the >> SDP >>> session level with local identifier and use the identifier in the m- >> lines. >>> Maybe based on grouping. >> >> I don't quite understand you. Which parts repeats? An example may look >> like it repeats a lot, but there is actually not a lot of information >> that are redundant, or exactly the same. >> >> CNAMEs are by design the same. However that repetition comes due to us >> reusing existing attribute which is actually one of our main points. We >> want to reuse the existing signalling attributes rather than redefine >> with some alteration. >> >>> > Three options using your example from 8.5.1.2, the second I am not sure > since it may change the SDP SSRC syntax > > 1. v=0 > o=alice 2890844526 2890842807 IN IP4 192.0.2.156 > s=Telepresence Alice Invite > c=IN IP4 192.0.2.156 > b=AS:8965 > t=0 0 > > param = 1 cname:alice@foo.example.com > param = 2 srcname:a3:d3:4b:f1:22:12 > param = 3 srcname:12:3f:ab:d2:ec:32 > param = 4 srcname:7f:12:db:87:2d:52 > > > > m=audio 49200 RTP/AVP 97 96 > b=AS:725 > a=rtpmap:96 G719/48000/2 > a=rtpmap:97 G719/48000 > a=bw:send pt=96 SMT:tb=128800:1500 > a=bw:send pt=97 SMT:tb=64800:1500 > a=bw:recv pt=* AMT:tb=644000:1500 > a=max-recv-ssrc:* 5 > a=max-send-ssrc:97 3 > a=max-send-ssrc:96 1 > a=ssrc:239245219 param:1 > a=ssrc:239245219 param:2 > a=ssrc:986545121 param:1 > a=ssrc:986545121 param:3 > a=ssrc:2199983234 param:1 > a=ssrc:2199983234 param=4 > m=video 49300 RTP/AVP 96 > b=AS:8240 > a=rtpmap:96 H264/90000 > a=fmtp:96 profile-level-id=42c01e > a=imageattr:* send [x=1280,y=720] recv [x=1280,y=720] > a=bw:send pt=96 SMT:tb=2500000:8192 > a=bw:recv pt=96 SMT:tb=3000000:8192 > a=bw:send pt=* AMT:tb=8000000:16384 > a=max-recv-ssrc:* 5 > a=max-send-ssrc:* 3 > a=ssrc:245219239 param:1 > a=ssrc:245219239 param:2 > a=ssrc:545121986 param:1 > a=ssrc:545121986 param:3 > a=ssrc:199983234 param:1 > a=ssrc:199983234 param:4 > a=content:main > > > > > 2. v=0 > o=alice 2890844526 2890842807 IN IP4 192.0.2.156 > s=Telepresence Alice Invite > c=IN IP4 192.0.2.156 > b=AS:8965 > t=0 0 > > param = 1 cname:alice@foo.example.com rcname:a3:d3:4b:f1:22:12 > param = 2 name:alice@foo.example.com srcname:12:3f:ab:d2:ec:32 > param = 3 cname:alice@foo.example.com srcname:7f:12:db:87:2d:52 > > > > m=audio 49200 RTP/AVP 97 96 > b=AS:725 > a=rtpmap:96 G719/48000/2 > a=rtpmap:97 G719/48000 > a=bw:send pt=96 SMT:tb=128800:1500 > a=bw:send pt=97 SMT:tb=64800:1500 > a=bw:recv pt=* AMT:tb=644000:1500 > a=max-recv-ssrc:* 5 > a=max-send-ssrc:97 3 > a=max-send-ssrc:96 1 > a=ssrc:239245219 param:1 > a=ssrc:986545121 param:2 > a=ssrc:2199983234 param:3 > m=video 49300 RTP/AVP 96 > b=AS:8240 > a=rtpmap:96 H264/90000 > a=fmtp:96 profile-level-id=42c01e > a=imageattr:* send [x=1280,y=720] recv [x=1280,y=720] > a=bw:send pt=96 SMT:tb=2500000:8192 > a=bw:recv pt=96 SMT:tb=3000000:8192 > a=bw:send pt=* AMT:tb=8000000:16384 > a=max-recv-ssrc:* 5 > a=max-send-ssrc:* 3 > a=ssrc:245219239 param:1 > > a=ssrc:545121986 param:2 > > a=ssrc:199983234 param:3 > > a=content:main > > > > 3. the shortest will be the ssrc-id=id:ssrc-value, the id will identify the > id to use in the media level with all the parameters except the other > ssrc-id's in the multi line. We can probably give a better syntax but it is > shorter. > > > v=0 > o=alice 2890844526 2890842807 IN IP4 192.0.2.156 > s=Telepresence Alice Invite > c=IN IP4 192.0.2.156 > b=AS:8965 > t=0 0 > > multi = cname:alice@foo.example.com srcname:a3:d3:4b:f1:22:12 > ssrc-id=1:239245219 ssrc-id=2: 245219239 > > multi= cname:alice@foo.example.com srcname:12:3f:ab:d2:ec:32 > ssrc-id=3:986545121 ssrc-id=4:545121986 > > multi= cname:alice@foo.example.com srcname:7f:12:db:87:2d:52 > ssrc-id=5:2199983234 ssrc-id=6:199983234 > > > > m=audio 49200 RTP/AVP 97 96 > b=AS:725 > a=rtpmap:96 G719/48000/2 > a=rtpmap:97 G719/48000 > a=bw:send pt=96 SMT:tb=128800:1500 > a=bw:send pt=97 SMT:tb=64800:1500 > a=bw:recv pt=* AMT:tb=644000:1500 > a=max-recv-ssrc:* 5 > a=max-send-ssrc:97 3 > a=max-send-ssrc:96 1 > a=multi:1 > a= multi:3 > a= multi:5 > > m=video 49300 RTP/AVP 96 > b=AS:8240 > a=rtpmap:96 H264/90000 > a=fmtp:96 profile-level-id=42c01e > a=imageattr:* send [x=1280,y=720] recv [x=1280,y=720] > a=bw:send pt=96 SMT:tb=2500000:8192 > a=bw:recv pt=96 SMT:tb=3000000:8192 > a=bw:send pt=* AMT:tb=8000000:16384 > a=max-recv-ssrc:* 5 > a=max-send-ssrc:* 3 > a= multi:2 > a= multi:4 > a= multi:6 > a=content:main > > > Roni > > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From fluffy@cisco.com Wed Jul 20 07:36:10 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B2AE21F8541; Wed, 20 Jul 2011 07:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.886 X-Spam-Level: X-Spam-Status: No, score=-103.886 tagged_above=-999 required=5 tests=[AWL=-1.288, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61pykWuW9q07; Wed, 20 Jul 2011 07:36:06 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id D369021F8888; Wed, 20 Jul 2011 07:36:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=420; q=dns/txt; s=iport; t=1311172566; x=1312382166; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=6Hktg16DgUdtBhLfKYXzFrIjSI+pUtjgjLNGUrEMljQ=; b=iBNhE0Y79PhUyN7n4cwjqr+K8PeCpjfKKLqxLrdTwLrOEs6GN04K/bZ/ H4nSXkPBbzVRUkfkCuzbNpErJMiVLLBzQOikpVHi/LKDhgEizs19PMf/W enuhYRLPpZsyD2m4M24FW+adapIgezM51x7I76yHijkBrvzkjyYeqys7c 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAPjmJk6rRDoI/2dsb2JhbABTp2N3qnKeLoVeXwSHVYsZhQeLdg X-IronPort-AV: E=Sophos;i="4.67,235,1309737600"; d="scan'208";a="4737235" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-1.cisco.com with ESMTP; 20 Jul 2011 14:36:05 +0000 Received: from [10.21.74.120] ([10.21.74.120]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6KEa4Ye011316; Wed, 20 Jul 2011 14:36:04 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 20 Jul 2011 07:36:04 -0700 Message-Id: To: IETF AVT WG , IETF MMUSIC WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [AVTCORE] Comment on draft-westerlund-avtcore-multistream-and-simulcast X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 14:36:10 -0000 In the case were we want to use SDP to indicate video streams are = simulcast of the same thing, I think it would be better to use the SDP = grouping framework instead of using SSRC to indicate this.=20 I also wonder, why not just use layered codecs, seems like outperform = the simulcast approach. I read section 3.1 but don't really find it = convincing that this simulcast is better than layered codecs.=20 From abegen@cisco.com Wed Jul 20 07:44:59 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD6FC21F8777; Wed, 20 Jul 2011 07:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.266 X-Spam-Level: X-Spam-Status: No, score=-5.266 tagged_above=-999 required=5 tests=[AWL=-2.667, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j81yzqnSAHw7; Wed, 20 Jul 2011 07:44:56 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id A3CEB21F86D7; Wed, 20 Jul 2011 07:44:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=1077; q=dns/txt; s=iport; t=1311173095; x=1312382695; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=Szw8D/gPJd5z6/GcWqtPdutyLROmod2ZsmhfIg4rDc8=; b=jO7DZkI0dQ+RVRAo0VWfRZAOe1/KzvskzalutJK9tcfpGvCsHyqPimL4 4Gj3olXKM4spMR9AuXxqOUvQDAYnqui5wli01jNfF6sqlyt3pDuIccZmu KodNHFE1Vg2fXCH1DwLEkKf1TfGpGH5NgGpCajYA3AI4Kh4y18BEVltON w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At8AAFjpJk6rRDoG/2dsb2JhbABTmBiPS3eIfKFgni6FXl8Eh1WQKYtt X-IronPort-AV: E=Sophos;i="4.67,235,1309737600"; d="scan'208";a="4743843" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-6.cisco.com with ESMTP; 20 Jul 2011 14:44:55 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6KEiriP008425; Wed, 20 Jul 2011 14:44:54 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 20 Jul 2011 07:44:53 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Wed, 20 Jul 2011 07:43:47 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540F81022F@xmb-sjc-215.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Comment ondraft-westerlund-avtcore-multistream-and-simulcast Thread-Index: AcxG6mXqnDbDBtWaTPi+OMmdczGS3AAAOBCg References: From: "Ali C. Begen (abegen)" To: "Cullen Jennings (fluffy)" , "IETF AVT WG" , "IETF MMUSIC WG" X-OriginalArrivalTime: 20 Jul 2011 14:44:53.0984 (UTC) FILETIME=[964DC600:01CC46EB] Subject: Re: [AVTCORE] [MMUSIC] Comment ondraft-westerlund-avtcore-multistream-and-simulcast X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 14:44:59 -0000 > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On = Behalf Of Cullen Jennings (fluffy) > Sent: Wednesday, July 20, 2011 4:36 PM > To: IETF AVT WG; IETF MMUSIC WG > Subject: [MMUSIC] Comment = ondraft-westerlund-avtcore-multistream-and-simulcast >=20 >=20 > In the case were we want to use SDP to indicate video streams are = simulcast of the same thing, I think it would be better to > use the SDP grouping framework instead of using SSRC to indicate this. As in: https://datatracker.ietf.org/doc/draft-begen-mmusic-redundancy-grouping/ = > I also wonder, why not just use layered codecs, seems like outperform = the simulcast approach. I read section 3.1 but don't > really find it convincing that this simulcast is better than layered = codecs. The draft above provides some motivation why people would wanna transmit = the same thing twice or more. =20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From stewe@stewe.org Wed Jul 20 08:26:50 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A07A421F85CA; Wed, 20 Jul 2011 08:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqaUo85LIsVX; Wed, 20 Jul 2011 08:26:49 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by ietfa.amsl.com (Postfix) with ESMTP id 5AEB621F85A7; Wed, 20 Jul 2011 08:26:46 -0700 (PDT) Received: from [172.20.140.16] (unverified [130.192.232.18]) by stewe.org (SurgeMail 3.9e) with ESMTP id 15323-1743317 for multiple; Wed, 20 Jul 2011 17:26:45 +0200 User-Agent: Microsoft-MacOutlook/14.12.0.110505 Date: Wed, 20 Jul 2011 08:26:38 -0700 From: Stephan Wenger To: Cullen Jennings , IETF AVT WG , IETF MMUSIC WG Message-ID: Thread-Topic: [AVTCORE] Comment on draft-westerlund-avtcore-multistream-and-simulcast In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3393995204_1741896" X-Originating-IP: 130.192.232.18 X-Authenticated-User: stewe@stewe.org Subject: Re: [AVTCORE] Comment on draft-westerlund-avtcore-multistream-and-simulcast X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 15:26:50 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3393995204_1741896 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit On 7.20.2011 07:36 , "Cullen Jennings" wrote: > > In the case were we want to use SDP to indicate video streams are simulcast of > the same thing, I think it would be better to use the SDP grouping framework > instead of using SSRC to indicate this. > > I also wonder, why not just use layered codecs, seems like outperform the > simulcast approach. I read section 3.1 but don't really find it convincing > that this simulcast is better than layered codecs. > I read the word "scalable" -- can't help to chip in... >From Magnus' draft, section 3.1, second-to-last paragraph characterizing scalable coding, with inline comments: > The scalable video encoding requires a more complex encoder compared > to non-scalable encoding. > This is true from an implementation complexity viewpoint. It is not necessarily true from a cycle viewpoint, at least not in the encoder. I would argue that, in most practical cases, highly optimized scalable and simulcast encoders require about the same number of cycles to code similar resolutions. Perhaps within a +/- 10% range. In the decoder, modern standards such as H.264 SVC allow for something called "single loop decoding", which keep the computational complexity at only marginally higher levels than for non-scalable decoding of the highest simulcasted solution. There are cases where layered decoding actually takes fewer cycles (at very high bitrates, where the overhead due to entropy decoding of the less efficient simulcasted stream outweighs the complexity through cross-layer prediction). > > Also, if the resolution difference is big, > the scalable codec may in fact be only marginally more bandwidth > efficient, between the encoding client and the mixer, than a > simulcast that sends the resolutions in separate streams, assuming > equivalent video quality. > This is correct, but it's only half of the story. One operation point for which most scalable codecs today are optimized is 2:1 spatial scalability, meaning that the base layer is half the resolution in both dimensions or 1/4 of the pixel count. Another one is (roughly) 1.5 scalability, with 720p to 1080p in mind. SVC works still reasonably well at 1:3, although this is not a common operation point. The second half of the story is that SVC (as well as previous layered coding standards) do allow for multilayer scalability. If you know how to implement this (it's not trivial), you get quite a bit of the gain, with the additional advantage of having intermediate operation points that you can use when video pictures are zoomed under user control. In either case, modern scalable video standards, well implemented, are always better than simulcast from a bandwidth viewpoint. And should be. That's information theory 101. > > At the same time, with scalable video > encoding, the transmission of all but the lowest resolution will > definitely consume more bandwidth from the mixer to the other > participants than a non-scalable encoding, again assuming equivalent > video quality. Again, this is correct. Once again, though, only part of the story. First, he overhead of scalable coding over non-scalable coding of the highest resolution has decreased to levels that may not quite be background noise, but not much higher either. You may wish to take a look at a document Alex Eleftheriadis and me wrote for rtcweb, http://tools.ietf.org/html/draft-wenger-rtcweb-layered-codec-00. It contains a reference to the characterization tests conducted by MPEG. Most tests performed in academia roughly mirror those results. Second, most of us sit behind highly asymmetric links, such as cable modem or DSL. In such environments, an overhead (even a large one) for the largest picture resolution is less penalizing than an overhead on the sending side. Sending bits are more expensive than receiving bits. What the draft has omitted are SVC's superior error resilience properties and congestion control options, when being used in an appropriately designed system environment. Some of that stems from temporal scalability (which modern non-scalable video coding standards include in an occasionally crippled form), but a lot more comes from spatial scalability. Alex and my draft cited above provides some input. Regards, Stephan > ___________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > --B_3393995204_1741896 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
On 7.20.2011 07:36 , "Cullen= Jennings" <fluffy@cisco.com> wr= ote:


In the case were we want to use S= DP to indicate video streams are simulcast of the same thing, I think it wou= ld be better to use the SDP grouping framework instead of using SSRC to indi= cate this.

I also wonder, why not just use layered = codecs, seems like outperform the simulcast approach. I read section 3.1 but= don't really find it convincing that this simulcast is better than layered = codecs.


I read the word = "scalable" -- can't help to chip in...

From Magnus'= draft, section 3.1, second-to-last paragraph characterizing scalable coding= , with inline comments:

The scalable video encoding = requires a more complex encoder compared
to non-scalable encodi= ng. 

This is true from an impleme= ntation complexity viewpoint.  It is not necessarily true from a cycle = viewpoint, at least not in the encoder.  I would argue that, in most pr= actical cases, highly optimized scalable and simulcast encoders require abou= t the same number of cycles to code similar resolutions.  Perhaps withi= n a +/- 10% range.
In the decoder, modern standards such as H.264 = SVC allow for something called "single loop decoding", which keep the comput= ational complexity at only marginally higher levels than for non-scalable de= coding of the highest simulcasted solution.  There are cases where laye= red decoding actually takes fewer cycles (at very high bitrates, where the o= verhead due to entropy decoding of the less efficient simulcasted stream out= weighs the complexity through cross-layer prediction).

Also, i= f the resolution difference is big,
the scalable codec may in f= act be only marginally more bandwidth
efficient, between the en= coding client and the mixer, than a
simulcast that sends the re= solutions in separate streams, assuming
equivalent video qualit= y. 

This is correct, but it's onl= y half of the story.  One operation point for which most scalable codec= s today are optimized is 2:1 spatial scalability, meaning that the base laye= r is half the resolution in both dimensions or 1/4 of the pixel count.  = ;Another one is (roughly) 1.5 scalability, with 720p to 1080p in mind.  = ;SVC works still reasonably well at 1:3, although this is not a common opera= tion point.
The second half of the story is that SVC (as well as p= revious layered coding standards) do allow for multilayer scalability.  = ;If you know how to implement this (it's not trivial), you get quite a bit o= f the gain, with the additional advantage of having intermediate operation p= oints that you can use when video pictures are zoomed under user control.
In either case, modern scalable video standards, well implemented, a= re always better than simulcast from a bandwidth viewpoint.  And should= be.  That's information theory 101.


At th= e same time, with scalable video
encoding, the transmission of = all but the lowest resolution will
definitely consume more band= width from the mixer to the other
participants than a non-scala= ble encoding, again assuming equivalent
video quality.

Again, this is correct.  Once again, thou= gh, only part of the story.
First, he overhead of scalable coding = over non-scalable coding of the highest resolution has decreased to levels t= hat may not quite be background noise, but not much higher either.  You= may wish to take a look at a document Alex Eleftheriadis and me wrote for r= tcweb, http://tools.ietf.org/html/draft-wenger-rtcweb-layered-codec-00.=  It contains a reference to the characterization tests conducted by MP= EG.  Most tests performed in academia roughly mirror those results. &nb= sp;Second, most of us sit behind highly asymmetric links, such as cable mode= m or DSL.  In such environments, an overhead (even a large one) for the= largest picture resolution is less penalizing than an overhead on the sendi= ng side.  Sending bits are more expensive than receiving bits.

What the draft has omitted are SVC's superior error resilie= nce properties and congestion control options, when being used in an appropr= iately designed system environment.  Some of that stems from temporal s= calability (which modern non-scalable video coding standards include in an o= ccasionally crippled form), but a lot more comes from spatial scalability. &= nbsp;Alex and my draft cited above provides some input.

=
Regards,
Stephan
  

<= /div>



___________________________
Audio/= Video Transport Core Maintenance

--B_3393995204_1741896-- From jonathan@vidyo.com Wed Jul 20 10:44:47 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47C7721F858D for ; Wed, 20 Jul 2011 10:44:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v0HiQplWsH7g for ; Wed, 20 Jul 2011 10:44:46 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 97E7221F855E for ; Wed, 20 Jul 2011 10:44:46 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id D3F6A78FD8A; Wed, 20 Jul 2011 13:44:45 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB027.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 4EBC778FB32; Wed, 20 Jul 2011 13:44:45 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB027.mail.lan ([10.110.17.27]) with mapi; Wed, 20 Jul 2011 13:44:43 -0400 From: Jonathan Lennox To: Magnus Westerlund Date: Wed, 20 Jul 2011 13:44:43 -0400 Thread-Topic: [AVTCORE] Fwd: I-D Action: draft-westerlund-avtcore-multistream-and-simulcast-00.txt Thread-Index: AcxHBLWOpIeoFmGLRa6/LMtgqMr1qQ== Message-ID: <77803BB4-AC80-40D3-855D-CC0792A07E65@vidyo.com> References: <4E12ED55.2060301@ericsson.com> <6CE70BE0-ADA3-41C8-B1BD-2F713E083AEB@vidyo.com> <4E257E13.7090105@ericsson.com> In-Reply-To: <4E257E13.7090105@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF AVTCore WG Subject: Re: [AVTCORE] Fwd: I-D Action: draft-westerlund-avtcore-multistream-and-simulcast-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 17:44:47 -0000 Hi, Magnus -- thanks for the reply. On Jul 19, 2011, at 8:52 AM, Magnus Westerlund wrote: >>=20 >> As the draft concludes, the multi-stream scenario is best handled by >> SSRC-multiplexing, as was originally envisioned by RTP. Given that >> this is the case, it's not clear to me that it's a good idea to use a >> separate (and in my opinion, less flexible) mechanism for the >> specific special case of simulcast. Instead, given the pressure from >> groups such as RTCweb to reduce the port consumption of RTP, I'd >> recommend SSRC-multiplexing across the board. >=20 > Jonathan lets me ask you a question. Is any hesitation to use several > RTP sessions when most suitable due to the port consumption issue or for > some other reason? And here we can debate what is most suitable. Part of it is port consumption, but more importantly, architecturally, is t= he problem that architectures that are designed around the "one source (in = each direction) per session" assumption break badly in a whole lot of scena= rios that are more complicated than the simple point-to-point one-source-pe= r-media-type model. > My view is that multiple SSRCs in an RTP session is a very good > mechanism for streams that one expect to be treated the same way in both > central nodes or in end-points. When it comes to sets of streams that > needs a different treatment, I think it is logical and a powerful > construct to use the RTP session for separating these sets of streams. This is valid so long as you can make the simplifying assumption that you *= can* treat every source in a session identically, blindly, with no further = information about the content of each one. But there are plenty of scenari= os in which >> Note also that in the case of multiple sources which are each >> independently simulcast, the simulcast structure of different sources >> could well be different. (E.g., source A could be available in two >> resolutions, while source B has only one and source C has three.) >> It'd be extremely difficult to map this in session-multiplexed >> simulcast, whereas for SSRC-multiplexed simulcast it should be no >> more complex than the single-simulcast-source scenario. >=20 > This is a valid concern, but which I think we have a reasonable straight > story for. In the direction you have a certain number of simulcast > versions you negotiate that number of session and their individual > configurations. I'm not thinking about asymmetric sources in each direction -- I'm thinking= about multiple, heterogeneous simulcast sources in the *same* direction. = In this case, it's really unclear how one would map the simulcast channels = to multiple sessions.=20 -- Jonathan Lennox jonathan@vidyo.com From Even.roni@huawei.com Wed Jul 20 15:10:25 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A0A921F8AE6 for ; Wed, 20 Jul 2011 15:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.299 X-Spam-Level: X-Spam-Status: No, score=-105.299 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LzLqjluZalXf for ; Wed, 20 Jul 2011 15:10:25 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id AFFD321F8AE4 for ; Wed, 20 Jul 2011 15:10:24 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LON001JTK99CW@szxga03-in.huawei.com> for avt@ietf.org; Thu, 21 Jul 2011 06:10:21 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LON002SBK99PS@szxga03-in.huawei.com> for avt@ietf.org; Thu, 21 Jul 2011 06:10:21 +0800 (CST) Received: from windows8d787f9 (bzq-79-183-21-130.red.bezeqint.net [79.183.21.130]) by szxml11-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LON00HUVK94FH@szxml11-in.huawei.com> for avt@ietf.org; Thu, 21 Jul 2011 06:10:21 +0800 (CST) Date: Thu, 21 Jul 2011 01:07:39 +0300 From: Roni Even To: avt@ietf.org Message-id: <01a401cc4729$7439fb90$5cadf2b0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_SW7JnkBaKMzYB6N3Yc85MA)" Content-language: en-us Thread-index: AcxHKWsLCxL4JJrPTyOG51DsEjrspw== x-cr-hashedpuzzle: b+I= zic= AQua AySC CQGR ETkM HWvj HqC3 HqiA Igrj JGhA J70s KVpi LPad L9H9 MLEz; 1; YQB2AHQAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {4BBA22D8-DEA6-4057-BE89-60D253469813}; ZQB2AGUAbgAuAHIAbwBuAGkAQABoAHUAYQB3AGUAaQAuAGMAbwBtAA==; Wed, 20 Jul 2011 22:07:30 GMT; UwBtAGEAbABsACAAYgB1AGcAIABmAGkAeAAgAGkAbgAgAEkARQBUAEYAOAAxACAAYQB2AHQAYwBvAHIAZQAgAGEAZwBlAG4AZABhAA== x-cr-puzzleid: {4BBA22D8-DEA6-4057-BE89-60D253469813} Subject: [AVTCORE] Small bug fix in IETF81 avtcore agenda X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 22:10:25 -0000 This is a multi-part message in MIME format. --Boundary_(ID_SW7JnkBaKMzYB6N3Yc85MA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, I had a wrong pointer to the feedback-supression-rtp pointing at 00 version inside 05. It is now updated. Regards Roni Even --Boundary_(ID_SW7JnkBaKMzYB6N3Yc85MA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi,

I had a wrong = pointer to the feedback-supression-rtp pointing at 00 version inside 05. = It is now updated.

Regards

Roni = Even

= --Boundary_(ID_SW7JnkBaKMzYB6N3Yc85MA)-- From csp@csperkins.org Wed Jul 20 15:52:01 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB03821F8A4E for ; Wed, 20 Jul 2011 15:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6XhUikSPttud for ; Wed, 20 Jul 2011 15:52:01 -0700 (PDT) Received: from anchor-msapost-2.mail.demon.net (anchor-msapost-2.mail.demon.net [195.173.77.165]) by ietfa.amsl.com (Postfix) with ESMTP id 145CC21F8888 for ; Wed, 20 Jul 2011 15:52:01 -0700 (PDT) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.26]) by anchor-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1QjfcW-0000Ww-jp; Wed, 20 Jul 2011 22:52:00 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Colin Perkins In-Reply-To: Date: Wed, 20 Jul 2011 23:51:58 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E25A430.5050707@ericsson.com> To: "Elwell, John" X-Mailer: Apple Mail (2.1084) Cc: Magnus Westerlund , IETF AVTCore WG Subject: Re: [AVTCORE] RTP Internal Multiplexing of RTP sessions X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 22:52:02 -0000 I agree that there is a clear perception of a requirement here, and that = we should discuss the issue in Quebec to determine if it's a real issue, = and if so, how we should address the requirement. Colin On 20 Jul 2011, at 10:30, Elwell, John wrote: > I think this is an important topic and should receive some agenda time = in Quebec. >=20 > John=20 >=20 >> -----Original Message----- >> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On=20 >> Behalf Of Magnus Westerlund >> Sent: 19 July 2011 16:35 >> To: IETF AVTCore WG >> Subject: [AVTCORE] RTP Internal Multiplexing of RTP sessions >>=20 >> WG, >>=20 >> As Individual contributor. >>=20 >> I don't know if people in the WG are aware of the discussion=20 >> ongoing in >> RTCWEB around multiplexing of protocols over the same underlying >> transport flow, like UDP flow. That include RTP sessions. >>=20 >> There is a proposal: >> "Multiplexing of Real-Time Transport Protocol (RTP) Traffic=20 >> for Browser >> based Real-Time Communications (RTC)" >> https://datatracker.ietf.org/doc/draft-rosenberg-rtcweb-rtpmux >> /?include_text=3D1 >>=20 >> This proposal is criticized by the following draft. >> https://datatracker.ietf.org/doc/draft-perkins-rtcweb-rtp-usag >> e/?include_text=3D1 >>=20 >> There is an ongoing discussion on several aspects of these=20 >> proposals on >> the RTCWEB WG. You are welcome to go join the discussion of the other >> questions raised on that mailing list. >>=20 >> Here I primarily want to raise the issue I see with=20 >> multiplexing several >> RTP sessions onto the same lower layer transport without something >> explicitly identifying these separate sessions. And in particular the >> RTP SSRC semantics changes that is proposed by the Rosenberg draft. >>=20 >> Personally I think it is time we tackle the issue of how to=20 >> efficiently >> run multiple RTP sessions over one lower layer transport.=20 >> This as there >> are several wanting to have that functionality. However, I think this >> must be done in a very careful way. As we don't want to create an >> alternative version of RTP which is what the Rosenberg=20 >> proposal in fact >> does. I do want us to gather the requirements on this and think of = how >> we can accomplish this. >>=20 >> I think there is a clear risk that we will not be able to=20 >> accomplish it >> without either adding some type of shim header which has it sets of >> drawback or in fact fork or change the RTP protocol in such a way = that >> it will not be fully compatible with what exist today. But if=20 >> that is to >> be done, we should have a very clear consensus on that and ensure = that >> we then develop future extensions to RTP within a single=20 >> version of the >> protocol, not two. >>=20 >> As WG chair: >>=20 >> We are considering re-arranging the agenda to facilitate a debate of >> this topic in Quebec. >>=20 >> So please indicate both your view of the topic in general and if you >> think we should re-prioritize the agenda. >>=20 >> cheers >>=20 >> Magnus Westerlund >>=20 >> = ---------------------------------------------------------------------- >> Multimedia Technologies, Ericsson Research EAB/TVM >> = ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> F=E4r=F6gatan 6 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >> = ---------------------------------------------------------------------- >>=20 >> _______________________________________________ >> Audio/Video Transport Core Maintenance >> avt@ietf.org >> https://www.ietf.org/mailman/listinfo/avt >>=20 > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt --=20 Colin Perkins http://csperkins.org/ From bill.wu@huawei.com Thu Jul 21 00:14:46 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0602221F8B69 for ; Thu, 21 Jul 2011 00:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.657 X-Spam-Level: X-Spam-Status: No, score=-5.657 tagged_above=-999 required=5 tests=[AWL=0.942, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RL-nq80nbj6h for ; Thu, 21 Jul 2011 00:14:44 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC8121F8B6A for ; Thu, 21 Jul 2011 00:14:43 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LOO0009Q9GGBP@szxga03-in.huawei.com> for avt@ietf.org; Thu, 21 Jul 2011 15:14:40 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LOO00FSD9G99W@szxga03-in.huawei.com> for avt@ietf.org; Thu, 21 Jul 2011 15:14:40 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml202-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ACK96860; Thu, 21 Jul 2011 15:14:38 +0800 (CST) Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 21 Jul 2011 15:14:28 +0800 Received: from w53375q (10.138.41.76) by szxeml403-hub.china.huawei.com (10.82.67.35) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 21 Jul 2011 15:14:36 +0800 Date: Thu, 21 Jul 2011 15:14:35 +0800 From: Qin Wu X-Originating-IP: [10.138.41.76] To: Roni Even , 'Colin Perkins' , 'Qin Wu' Message-id: <56FAB1AF9E9345868B29C5BA8437E7EC@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-CFilter-Loop: Reflected References: <20110616092110.1754.68542.idtracker@ietfa.amsl.com> <00f501cc46ad$51929830$f4b7c890$%roni@huawei.com> Cc: avt@ietf.org Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-03.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 07:14:46 -0000 Hi, I think using tag has both disadvantage and advantage. please see my below. ----- Original Message ----- From: "Roni Even" To: "'Colin Perkins'" ; "'Qin Wu'" Cc: Sent: Wednesday, July 20, 2011 3:19 PM Subject: RE: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-03.txt > Hi, > Looking at the tag mechanism I agree with Colin that using it just to reduce > the size of the packet is not the important. [Qin]: Yes, Using tag to associate identity block with other small blocks doesn't reduce size of RTCP if 1. Each RTCP XR packet contains one or more identity block 2. Each identity block contains SSRC. Therefore using tag may introduce extra overhead when it is used to distinguish different stream to be reported On the other hand,, using tag is redundant comparing with using SSRC since SSRC also can be used to distinguish the different stream to be reported. If the identity block is not carried in each RTCP XR packet, e.g., at the start of session, you still need to parse each small bock with tag included and mapping the tag to SSRC when receiving RTCP XR packet. It introduces processing complexity. This is Con part of using tag I know. > Still I can see a different use case for the tag in order to group XR > reports as one entity. The monitoring architecture suggest dividing large > reports to small blocks and the assumption is the by the SSRC you define a > group of blocks per an application. Using the tag may provide another level > of freedom allowing more than one tag per SSRC and the tag defines a > reporting unit. This is a change from the current usage of tags and I am > bringing it to see if this usage is useful. [Qin]: Good point. Using SSRC enables grouping per stream However the Pro of Using tag is may provide more subtle granularity for grouping e.g., a. distinguish the video stream and audio stream with the same SSRC by using different tag b. distinguish the base layer video stream and enhancement layer video stream with the same SSRC by using different tag. Does these two cases mentioned above make sense? > > As for the correlation with non-rtp protocols I agree that SDES may be used > for it. > > Regards > Roni Even > As individual > >> -----Original Message----- >> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of >> Colin Perkins >> Sent: Tuesday, June 21, 2011 5:56 PM >> To: Qin Wu >> Cc: avt@ietf.org >> Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-03.txt >> >> Qin, >> >> This does address many of my comments on the earlier versions. Some >> quick comments on this draft: >> >> - In Section 5.2, there is no need to report the CNAME, since this is >> redundant with RTCP SDES information. >> >> - Section 5.2 suggests reporting "the sequence number of the first >> packet of the RTP session". A receiver cannot know what is the first >> packet of the session, only what was the first packet it received, so >> this should be clarified to "the sequence number of the first packet >> received in the RTP session". The first sequence number received also >> becomes less useful after the sequence number space wraps around, so it >> might make sense to include a count of sequence number cycles since >> then. >> >> - Section 5.3 discusses sending information that can be used to >> correlate an RTP source with non-RTP protocols. This seems like a >> reasonable thing to add. However, since it is describing the source, >> rather than providing a quality report, should this be an new RTCP SDES >> block type, rather than an RTCP XR block? >> >> Colin >> >> >> On 16 Jun 2011, at 10:29, Qin Wu wrote: >> >> > Hi,: >> > In response to the recent comments and suggestion on the list, a new >> version of draft-ietf-avtcore-monarch is just submitted. >> > http://www.ietf.org/internet-drafts/draft-ietf-avtcore-monarch-03.txt >> > The diff is: >> > http://tools.ietf.org/rfcdiff?url2=draft-ietf-avtcore-monarch-03 >> > >> > Please check if your comments are addressed in this version. >> > >> > Regards! >> > -Qin >> > >> > ----- Original Message ----- >> > From: >> > To: >> > Cc: >> > Sent: Thursday, June 16, 2011 5:21 PM >> > Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-03.txt >> > >> > >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This draft is a work item of the Audio/Video Transport >> Core Maintenance Working Group of the IETF. >> >> >> >> Title : Monitoring Architectures for RTP >> >> Author(s) : Qin Wu >> >> Geoff Hunt >> >> Philip Arden >> >> Filename : draft-ietf-avtcore-monarch-03.txt >> >> Pages : 23 >> >> Date : 2011-06-16 >> >> >> >> This memo proposes an architecture for extending RTCP with a new >> RTCP >> >> XR (RFC3611) block type to report new metrics regarding media >> >> transmission or reception quality, as proposed in RFC5968. This >> memo >> >> suggests that a new block should contain a single metric or a small >> >> number of metrics relevant to a single parameter of interest or >> >> concern, rather than containing a number of metrics which attempt >> to >> >> provide full coverage of all those parameters of concern to a >> >> specific application. Applications may then "mix and >> match" to >> >> create a set of blocks which covers their set of concerns. Where >> >> possible, a specific block should be designed to be re-usable >> across >> >> more than one application, for example, for all of voice, streaming >> >> audio and video. >> >> >> >> >> >> A URL for this Internet-Draft is: >> >> http://www.ietf.org/internet-drafts/draft-ietf-avtcore-monarch- >> 03.txt >> >> >> >> Internet-Drafts are also available by anonymous FTP at: >> >> ftp://ftp.ietf.org/internet-drafts/ >> >> >> >> This Internet-Draft can be retrieved at: >> >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtcore-monarch-03.txt >> >> _______________________________________________ >> >> Audio/Video Transport Core Maintenance >> >> avt@ietf.org >> >> https://www.ietf.org/mailman/listinfo/avt >> >> >> > _______________________________________________ >> > Audio/Video Transport Core Maintenance >> > avt@ietf.org >> > https://www.ietf.org/mailman/listinfo/avt >> >> >> >> -- >> Colin Perkins >> http://csperkins.org/ >> >> >> >> _______________________________________________ >> Audio/Video Transport Core Maintenance >> avt@ietf.org >> https://www.ietf.org/mailman/listinfo/avt > From magnus.westerlund@ericsson.com Thu Jul 21 02:24:48 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCFDD21F8BAD; Thu, 21 Jul 2011 02:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.527 X-Spam-Level: X-Spam-Status: No, score=-106.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4m8z9XIzqsOa; Thu, 21 Jul 2011 02:24:48 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id C036D21F8BA9; Thu, 21 Jul 2011 02:24:47 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-e1-4e27f05e1da7 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 8C.DB.20773.E50F72E4; Thu, 21 Jul 2011 11:24:46 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Thu, 21 Jul 2011 11:24:45 +0200 Message-ID: <4E27F05C.9000503@ericsson.com> Date: Thu, 21 Jul 2011 11:24:44 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Cullen Jennings References: In-Reply-To: X-Enigmail-Version: 1.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: IETF AVT WG , IETF MMUSIC WG Subject: Re: [AVTCORE] [MMUSIC] Comment on draft-westerlund-avtcore-multistream-and-simulcast X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 09:24:48 -0000 On 2011-07-20 16:36, Cullen Jennings wrote: > > In the case were we want to use SDP to indicate video streams are > simulcast of the same thing, I think it would be better to use the > SDP grouping framework instead of using SSRC to indicate this. Cullen, I recommend that you go read the draft again. We are proposing to use SDP grouping framework. We suggest that one defines two grouping semantics SCS and SCR. One for grouping media lines where one want to send different simulcast versions, another for indicating the willingness to receive simulcast over a group of media lines. This is to enable simulcast only in one direction and to ensure that we get offer/answer behavior. The grouping semantics is what is used to negotiate the actual usage of simulcast or not. We do have the SRCNAME but that is for actually indicating how different streams map to different sources. This becomes important when an end-point has more than one source of the same media type it want to simulcast, like for example multiple cameras in a telepresence room. The SRCNAME SDES item doesn't need to be in the SDP, it is only included in the examples to show that it is possible to have them to speed up acquisition of this information. > > I also wonder, why not just use layered codecs, seems like outperform > the simulcast approach. I read section 3.1 but don't really find it > convincing that this simulcast is better than layered codecs. Layered coding is less efficient to reach a particular quality level than a stream that is encoded for that particular level without any additional quality levels. This means that layered encoding is guaranteed to be less efficient in the leg from a central mixer to a receiver for selecting a given media quality. Layered encoding is however a bit more efficient in the leg from the media source to the mixer than simulcasting. The exact levels of gain varies with the target points, the number of qualities etc. We see that a clear use case for combining simulcast with codecs that has certain scalability features. For example using H.264/AVC or SVC to provide temporal scalability, but use simulcast for resolution changes. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Thu Jul 21 02:55:30 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C772121F857E for ; Thu, 21 Jul 2011 02:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.528 X-Spam-Level: X-Spam-Status: No, score=-106.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Uh8fSl1LLe0 for ; Thu, 21 Jul 2011 02:55:29 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 5F32D21F8546 for ; Thu, 21 Jul 2011 02:55:29 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-eb-4e27f790a9c0 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 1E.79.09774.097F72E4; Thu, 21 Jul 2011 11:55:28 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Thu, 21 Jul 2011 11:54:54 +0200 Message-ID: <4E27F76C.2020101@ericsson.com> Date: Thu, 21 Jul 2011 11:54:52 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Jonathan Lennox References: <4E12ED55.2060301@ericsson.com> <6CE70BE0-ADA3-41C8-B1BD-2F713E083AEB@vidyo.com> <4E257E13.7090105@ericsson.com> <77803BB4-AC80-40D3-855D-CC0792A07E65@vidyo.com> In-Reply-To: <77803BB4-AC80-40D3-855D-CC0792A07E65@vidyo.com> X-Enigmail-Version: 1.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: IETF AVTCore WG Subject: Re: [AVTCORE] Fwd: I-D Action: draft-westerlund-avtcore-multistream-and-simulcast-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 09:55:30 -0000 Hi Jonathan, Good points although I am not certain I gotten your point in all the cases. On 2011-07-20 19:44, Jonathan Lennox wrote: > > Hi, Magnus -- thanks for the reply. > > On Jul 19, 2011, at 8:52 AM, Magnus Westerlund wrote: > >>> >>> As the draft concludes, the multi-stream scenario is best handled >>> by SSRC-multiplexing, as was originally envisioned by RTP. Given >>> that this is the case, it's not clear to me that it's a good idea >>> to use a separate (and in my opinion, less flexible) mechanism >>> for the specific special case of simulcast. Instead, given the >>> pressure from groups such as RTCweb to reduce the port >>> consumption of RTP, I'd recommend SSRC-multiplexing across the >>> board. >> >> Jonathan lets me ask you a question. Is any hesitation to use >> several RTP sessions when most suitable due to the port consumption >> issue or for some other reason? And here we can debate what is most >> suitable. > > Part of it is port consumption, but more importantly, > architecturally, is the problem that architectures that are designed > around the "one source (in each direction) per session" assumption > break badly in a whole lot of scenarios that are more complicated > than the simple point-to-point one-source-per-media-type model. > I fully agree, but fails to understand how multiple streams in each direction in multiple sessions in one form is different from multiple streams in multiple session in another way is different. Session based simulcast will use m RTP sessions per media type with N streams in them. SSRC multiplexed simulcast will use 1 RTP session per media type with m*N streams in them. In both cases we both have multiple streams and multiple RTP sessions. It is primarily the number of RTP sessions that is the varying factor. >> My view is that multiple SSRCs in an RTP session is a very good >> mechanism for streams that one expect to be treated the same way in >> both central nodes or in end-points. When it comes to sets of >> streams that needs a different treatment, I think it is logical and >> a powerful construct to use the RTP session for separating these >> sets of streams. > > This is valid so long as you can make the simplifying assumption that > you *can* treat every source in a session identically, blindly, with > no further information about the content of each one. But there are > plenty of scenarios in which Yes, I agree that there are scenarios where you will need to have detailed understanding of what exactly each stream is. But SSRC-multiplexed simulcast needs one to always have this control independently if one needs it or not just to get it working. Thus preventing applications that can be done simpler to be simpler. > >>> Note also that in the case of multiple sources which are each >>> independently simulcast, the simulcast structure of different >>> sources could well be different. (E.g., source A could be >>> available in two resolutions, while source B has only one and >>> source C has three.) It'd be extremely difficult to map this in >>> session-multiplexed simulcast, whereas for SSRC-multiplexed >>> simulcast it should be no more complex than the >>> single-simulcast-source scenario. >> >> This is a valid concern, but which I think we have a reasonable >> straight story for. In the direction you have a certain number of >> simulcast versions you negotiate that number of session and their >> individual configurations. > > I'm not thinking about asymmetric sources in each direction -- I'm > thinking about multiple, heterogeneous simulcast sources in the > *same* direction. In this case, it's really unclear how one would > map the simulcast channels to multiple sessions. That is exactly one of the case we are tackling, unless I misunderstand you. An end-point has 2 cameras in a telepresence room capturing different parts of the participant table so they are of the same purpose in the application. Those cameras (sources) we want to simulcast to a mixer in 3 qualities. Then the upstream RTP Session usage would consist of 3 RTP sessions, one for each quality tier. Within each of these RTP sessions there will be 2 streams (SSRCs) one for each camera sending media from the end-point to the mixer. The usage in the other direction can either be independent RTP sessions or for example be overlapped with one the quality tiers (as we do in the advanced examples in the draft). When you talk about multiple sources, are they from the same end-point of different end-points? If they are from the same end-point I think we do have a working solution in this document. If they are from different end-points I think we also have a solution as long as we are talking mixer based sessions. Because in that case we can negotiate each upstream end-point to the central mixer independently. However, the mixer clearly needs to ensure that these streams match the downstream capabilities setup to the other participants. If we are talking relay based based then I think we have issues as we have identified. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From stephen.botzko@gmail.com Thu Jul 21 04:12:46 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B450821F8AE9; Thu, 21 Jul 2011 04:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.32 X-Spam-Level: X-Spam-Status: No, score=-3.32 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yFD3vU7JVp4E; Thu, 21 Jul 2011 04:12:46 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id A36F921F8AF1; Thu, 21 Jul 2011 04:12:45 -0700 (PDT) Received: by vxi40 with SMTP id 40so1003326vxi.31 for ; Thu, 21 Jul 2011 04:12:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gseKVESmGTl81sk35Qhy/Rz3Yv6gZJLarviHg5H+8pE=; b=nMT/BqFnxRiqOvWj5AvVlAot8CIt7A/WIFkAjl7EW19AOh9OcSgD+AAn/4ABFBQ96+ 9BHLbMfjAypriyAXLYQZuwty+hBqyhiRfKBGIsecnIhSB4deYSh6+/74gIXj8tf0HLiY 1Ih14PAYYAnoR/f+kNTtcvu+x4IgA5gENtfek= MIME-Version: 1.0 Received: by 10.52.117.234 with SMTP id kh10mr116575vdb.42.1311246764307; Thu, 21 Jul 2011 04:12:44 -0700 (PDT) Received: by 10.52.188.102 with HTTP; Thu, 21 Jul 2011 04:12:44 -0700 (PDT) In-Reply-To: <4E27F05C.9000503@ericsson.com> References: <4E27F05C.9000503@ericsson.com> Date: Thu, 21 Jul 2011 07:12:44 -0400 Message-ID: From: Stephen Botzko To: Magnus Westerlund Content-Type: multipart/alternative; boundary=bcaec548aa5799741904a8926dc6 Cc: Cullen Jennings , IETF AVT WG , IETF MMUSIC WG Subject: Re: [AVTCORE] [MMUSIC] Comment on draft-westerlund-avtcore-multistream-and-simulcast X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 11:12:46 -0000 --bcaec548aa5799741904a8926dc6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable in-line Stephen Botzko On Thu, Jul 21, 2011 at 5:24 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > On 2011-07-20 16:36, Cullen Jennings wrote: > > > > In the case were we want to use SDP to indicate video streams are > > simulcast of the same thing, I think it would be better to use the > > SDP grouping framework instead of using SSRC to indicate this. > > Cullen, I recommend that you go read the draft again. > > We are proposing to use SDP grouping framework. We suggest that one > defines two grouping semantics SCS and SCR. One for grouping media lines > where one want to send different simulcast versions, another for > indicating the willingness to receive simulcast over a group of media > lines. > > This is to enable simulcast only in one direction and to ensure that we > get offer/answer behavior. The grouping semantics is what is used to > negotiate the actual usage of simulcast or not. > > We do have the SRCNAME but that is for actually indicating how different > streams map to different sources. This becomes important when an > end-point has more than one source of the same media type it want to > simulcast, like for example multiple cameras in a telepresence room. > > The SRCNAME SDES item doesn't need to be in the SDP, it is only included > in the examples to show that it is possible to have them to speed up > acquisition of this information. > > > > > I also wonder, why not just use layered codecs, seems like outperform > > the simulcast approach. I read section 3.1 but don't really find it > > convincing that this simulcast is better than layered codecs. > > Layered coding is less efficient to reach a particular quality level > than a stream that is encoded for that particular level without any > additional quality levels. > > This means that layered encoding is guaranteed to be less efficient in > the leg from a central mixer to a receiver for selecting a given media > quality. > > Layered encoding is however a bit more efficient in the leg from the > media source to the mixer than simulcasting. > > The exact levels of gain varies with the target points, the number of > qualities etc. > > We see that a clear use case for combining simulcast with codecs that > has certain scalability features. For example using H.264/AVC or SVC to > provide temporal scalability, but use simulcast for resolution changes. > > I agree that simulcast is important, including the case where two differe= nt codecs are used. In that scenario, the resolution might be the same. > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > --bcaec548aa5799741904a8926dc6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable in-line
Stephen Botzko

On Thu, Jul 21,= 2011 at 5:24 AM, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:
On 2011-07-20 16:36, Cull= en Jennings wrote:
>
> In the case were we want to use SDP to indicate video streams are
> simulcast of the same thing, I think it would be better to use the
> SDP grouping framework instead of using SSRC to indicate this.

Cullen, I recommend that you go read the draft again.

We are proposing to use SDP grouping framework. We suggest that one
defines two grouping semantics SCS and SCR. One for grouping media lines where one want to send different simulcast versions, another for
indicating the willingness to receive simulcast over a group of media
lines.

This is to enable simulcast only in one direction and to ensure that we
get offer/answer behavior. The grouping semantics is what is used to
negotiate the actual usage of simulcast or not.

We do have the SRCNAME but that is for actually indicating how different streams map to different sources. This becomes important when an
end-point has more than one source of the same media type it want to
simulcast, like for example multiple cameras in a telepresence room.

The SRCNAME SDES item doesn't need to be in the SDP, it is only include= d
in the examples to show that it is possible to have them to speed up
acquisition of this information.

>
> I also wonder, why not just use layered codecs, seems like outperform<= br> > the simulcast approach. I read section 3.1 but don't really find i= t
> convincing that this simulcast is better than layered codecs.

Layered coding is less efficient to reach a particular quality level<= br> than a stream that is encoded for that particular level without any
additional quality levels.

This means that layered encoding is guaranteed to be less efficient in
the leg from a central mixer to a receiver for selecting a given media
quality.

Layered encoding is however a bit more efficient in the leg from the
media source to the mixer than simulcasting.

The exact levels of gain varies with the target points, the number of
qualities etc.

We see that a clear use case for combining simulcast with codecs that
has certain scalability features. For example using H.264/AVC or SVC to
provide temporal scalability, but use simulcast for resolution changes.

I agree that simulcast is important, including the ca= se where two different codecs are used.=A0 In that scenario, the resolution= might be the same.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287
F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/avt

--bcaec548aa5799741904a8926dc6-- From Even.roni@huawei.com Thu Jul 21 06:23:52 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0704821F8B11; Thu, 21 Jul 2011 06:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.8 X-Spam-Level: X-Spam-Status: No, score=-104.8 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.263, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kZfz1HNSXXcz; Thu, 21 Jul 2011 06:23:51 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id CD5E821F87A4; Thu, 21 Jul 2011 06:23:49 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LOO003L5QJMQY@szxga03-in.huawei.com>; Thu, 21 Jul 2011 21:23:47 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LOO00FFNQJM70@szxga03-in.huawei.com>; Thu, 21 Jul 2011 21:23:46 +0800 (CST) Received: from windows8d787f9 (bzq-79-183-21-130.red.bezeqint.net [79.183.21.130]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LOO006D9QJEPT@szxml12-in.huawei.com>; Thu, 21 Jul 2011 21:23:46 +0800 (CST) Date: Thu, 21 Jul 2011 16:21:01 +0300 From: Roni Even To: avt@ietf.org, rtcweb@ietf.org Message-id: <023701cc47a9$0da14660$28e3d320$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/mixed; boundary="Boundary_(ID_JK5DzPDoqh6oPJ3Nh+Btzw)" Content-language: en-us Thread-index: AcxHqQgDSDakdIHASt6N7yX/APEFyQ== Cc: rtcweb-chairs@tools.ietf.org, payload@ietf.org, payload-chairs@tools.ietf.org Subject: [AVTCORE] Updated AVTcore agenda - new slot for multiplexing RTP for broweser based RTC X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 13:23:52 -0000 This is a multi-part message in MIME format. --Boundary_(ID_JK5DzPDoqh6oPJ3Nh+Btzw) Content-type: multipart/alternative; boundary="Boundary_(ID_1T7UMdrcuhl+hRF3i/yHzw)" --Boundary_(ID_1T7UMdrcuhl+hRF3i/yHzw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, We apologize for the last minute change. The topic of "Multiplexing of Real-Time Transport Protocol (RTP) Traffic for Browser based Real-Time Communications (RTC)" proposed in draft-rosenberg-rtcweb-rtpmux-00 caused a long discussion in RTCweb mailing list and the feeling is that it should be also discussed in AVTcore. Magnus has started a thread on the AVTcore list. In order to have a time slot we moved the payload WG status presentation to the AVText slot which will be on Wednesday afternoon. We had to remove the mprtp presentation based on low discussion on the mailing list. We may have one slide on mprtp during the chair status Please review the above draft, I recommend also to look at http://tools.ietf.org/html/draft-perkins-rtcweb-rtp-usage-02 Thanks Roni Even --Boundary_(ID_1T7UMdrcuhl+hRF3i/yHzw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi,

We apologize = for the last minute change. 

The topic =
of "Multiplexing of Real-Time Transport Protocol (RTP) Traffic for =
Browser based Real-Time Communications (RTC)" proposed in =
  draft-rosenberg-rtcweb-rtpmux-00 caused a long discussion in =
RTCweb mailing list and the feeling is that it should be also discussed =
in AVTcore.  Magnus has started a thread on the AVTcore =
list.
In order =
to have a time slot we moved the payload WG status presentation to the =
AVText slot which will be on Wednesday afternoon. =

We had to =
remove the mprtp presentation based on low discussion on the mailing =
list. We may have one slide on mprtp during the chair =
status
 =

Please =
review the above draft, I recommend also to look at htt=
p://tools.ietf.org/html/draft-perkins-rtcweb-rtp-usage-02 =

 =

Thanks=

Roni =
Even

 

 

= --Boundary_(ID_1T7UMdrcuhl+hRF3i/yHzw)-- --Boundary_(ID_JK5DzPDoqh6oPJ3Nh+Btzw) Content-type: text/plain; name=a1107.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=a1107.txt Audio/Video Transport Core Maintenance (AVTCore) Working Group =============================================================== CHAIRS: Magnus Westerlund Roni Even AGENDA Wednesday, 27 July 2011 at 9:00-11:30 (208 AB) ---------------------------------------------- 09:00 AVTCore Status Update (Chairs, 20) 09:20 Encryption of Header Extensions in SRTP (Lennox, 15) draft-ietf-avtcore-srtp-encrypted-header-ext-00 09:35 RTCP Extension for Feedback Suppression Indication (Qin Wu, 15) draft-ietf-avtcore-feedback-supression-rtp-05 09:50 Monitoring Architecture for RTP (Qin Wu, 15) draft-ietf-avtcore-monarch-03 10:05 RTP Multiple Stream Sessions and Simulcast(Magnus Westerlund , 30) draft-westerlund-avtcore-multistream-and-simulcast-00 10:35 Delayed Duplication Attribute and Duplication Grouping in SDP(Begen, 15) draft-begen-mmusic-temporal-interleaving-02 draft-begen-mmusic-redundancy-grouping-01 10:50 Retransmission for SSM Sessions (Begen, 10) draft-vancaenegem-avtcore-retransmission-for-ssm-00 11:00 Multiplexing of RTP trafic for Browser based RTC (Rosenberg, 30) draft-rosenberg-rtcweb-rtpmux-00 11:30 End --Boundary_(ID_JK5DzPDoqh6oPJ3Nh+Btzw) Content-type: text/html; name=a1107.html Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=a1107.html Audio/Video Transport Core Maintenance (AVTCore) Working Group Agenda

Audio/Video Transport Core Maintenance (AVTCore) Working Group Agenda

Chairs: Magnus Westerlund , Roni Even

Wednesday, 27 July 2011 at 9:00-11:30 (208 AB)

09:00 AVTCore Status UpdateChairs
09:20 Encryption of Header Extensions in SRTPLennox
draft-ietf-avtcore-srtp-encrypted-header-ext-00
09:35 RTCP Extension for Feedback Suppression IndicationQin Wu
draft-ietf-avtcore-feedback-supression-rtp-05
09:50 Monitoring Architecture for RTPQin Wu
draft-ietf-avtcore-monarch-03
10:05 RTP Multiple Stream Sessions and SimulcastMagnus Westerlund
draft-westerlund-avtcore-multistream-and-simulcast-00
10:35 Delayed Duplication Attribute and Duplication Grouping in SDPBegen
draft-begen-mmusic-temporal-interleaving-02
draft-begen-mmusic-redundancy-grouping-01
10:50 Retransmission for SSM SessionsBegen
draft-vancaenegem-avtcore-retransmission-for-ssm-00
11:00 Multiplexing of RTP trafic for Browser based RTCRosenberg
draft-rosenberg-rtcweb-rtpmux-00
11:30 End
--Boundary_(ID_JK5DzPDoqh6oPJ3Nh+Btzw)-- From harald@alvestrand.no Thu Jul 21 07:33:18 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39FB821F86F6 for ; Thu, 21 Jul 2011 07:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id utnSJPWr9Utl for ; Thu, 21 Jul 2011 07:33:17 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 3836421F86BC for ; Thu, 21 Jul 2011 07:33:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7A04139E0FC for ; Thu, 21 Jul 2011 16:32:10 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KI9GnZAdUTYQ for ; Thu, 21 Jul 2011 16:32:06 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 1EC2B39E0FA for ; Thu, 21 Jul 2011 16:32:06 +0200 (CEST) Message-ID: <4E2838A7.6050903@alvestrand.no> Date: Thu, 21 Jul 2011 16:33:11 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: avt@ietf.org References: <4E25A430.5050707@ericsson.com> In-Reply-To: <4E25A430.5050707@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [AVTCORE] RTP Internal Multiplexing of RTP sessions X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 14:33:18 -0000 Speaking as RTCWEB contributor.... I think the discussion in RTCWEB has shown clearly that there isn't a=20 clear consensus in the community on what an RTP session is, what the=20 existence of RTP sessions requires from the applications, and what the=20 RTP session is an useful tool for. The debate has been framed in terms of the cost (in both complexity and=20 network resources) of running multiple transports when no difference in=20 treatment is desired from the network - but I think the confusion goes=20 deeper than that; in the discussions in the W3C WEBRTC WG, which deals=20 with the API requirements for the same thing, there doesn't seem to be=20 any sign that anyone sees the need to represent an "RTP session" at the=20 API offered to the Web applications using RTCWEB. I'm looking forward to the discussion, both inside and outside the=20 AVTCORE session, in Quebec. Harald On 07/19/11 17:35, Magnus Westerlund wrote: > WG, > > As Individual contributor. > > I don't know if people in the WG are aware of the discussion ongoing in= > RTCWEB around multiplexing of protocols over the same underlying > transport flow, like UDP flow. That include RTP sessions. > > There is a proposal: > "Multiplexing of Real-Time Transport Protocol (RTP) Traffic for Browser= > based Real-Time Communications (RTC)" > https://datatracker.ietf.org/doc/draft-rosenberg-rtcweb-rtpmux/?include= _text=3D1 > > This proposal is criticized by the following draft. > https://datatracker.ietf.org/doc/draft-perkins-rtcweb-rtp-usage/?includ= e_text=3D1 > > There is an ongoing discussion on several aspects of these proposals on= > the RTCWEB WG. You are welcome to go join the discussion of the other > questions raised on that mailing list. > > Here I primarily want to raise the issue I see with multiplexing severa= l > RTP sessions onto the same lower layer transport without something > explicitly identifying these separate sessions. And in particular the > RTP SSRC semantics changes that is proposed by the Rosenberg draft. > > Personally I think it is time we tackle the issue of how to efficiently= > run multiple RTP sessions over one lower layer transport. This as there= > are several wanting to have that functionality. However, I think this > must be done in a very careful way. As we don't want to create an > alternative version of RTP which is what the Rosenberg proposal in fact= > does. I do want us to gather the requirements on this and think of how > we can accomplish this. > > I think there is a clear risk that we will not be able to accomplish it= > without either adding some type of shim header which has it sets of > drawback or in fact fork or change the RTP protocol in such a way that > it will not be fully compatible with what exist today. But if that is t= o > be done, we should have a very clear consensus on that and ensure that > we then develop future extensions to RTP within a single version of the= > protocol, not two. > > As WG chair: > > We are considering re-arranging the agenda to facilitate a debate of > this topic in Quebec. > > So please indicate both your view of the topic in general and if you > think we should re-prioritize the agenda. > > cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > From tom111.taylor@bell.net Fri Jul 22 13:02:18 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF25721F8B5F for ; Fri, 22 Jul 2011 13:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.163 X-Spam-Level: X-Spam-Status: No, score=-100.163 tagged_above=-999 required=5 tests=[AWL=-0.967, BAYES_50=0.001, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HyyEcQZEZoKf for ; Fri, 22 Jul 2011 13:02:18 -0700 (PDT) Received: from blu0-omc3-s30.blu0.hotmail.com (blu0-omc3-s30.blu0.hotmail.com [65.55.116.105]) by ietfa.amsl.com (Postfix) with ESMTP id 400F821F8B57 for ; Fri, 22 Jul 2011 13:02:18 -0700 (PDT) Received: from BLU0-SMTP8 ([65.55.116.74]) by blu0-omc3-s30.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 22 Jul 2011 13:02:18 -0700 X-Originating-IP: [65.94.104.44] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.17] ([65.94.104.44]) by BLU0-SMTP8.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 22 Jul 2011 13:02:16 -0700 Date: Fri, 22 Jul 2011 16:02:15 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: avt@ietf.org Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jul 2011 20:02:16.0979 (UTC) FILETIME=[41A3B630:01CC48AA] Subject: [AVTCORE] Multicast transition BoF (MULTRANS) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 20:02:18 -0000 A BoF on multicast operation in scenarios where some components (endpoints, network) support IPv4 and others support IPv6 is being held Monday afternoon from 1-3 pm in 205 ABC. Some people on this list may be interested. Starting points are - draft-tsou-multicast-transition-taxonomy-01, which gives some background on older work in the area but is out of date in some aspects - draft-jaclee-behave-v4v6-mcast-ps-02, which is the primary content being placed before the BoF. Tom Taylor From magnus.westerlund@ericsson.com Sat Jul 23 03:58:32 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38B8B21F86EA; Sat, 23 Jul 2011 03:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.034 X-Spam-Level: X-Spam-Status: No, score=-106.034 tagged_above=-999 required=5 tests=[AWL=-0.427, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93msG5jGEt7v; Sat, 23 Jul 2011 03:58:31 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 3026E21F86C0; Sat, 23 Jul 2011 03:58:31 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-f1-4e2aa9552167 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 26.CA.20773.559AA2E4; Sat, 23 Jul 2011 12:58:29 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Sat, 23 Jul 2011 12:58:28 +0200 Message-ID: <4E296F64.70500@ericsson.com> Date: Fri, 22 Jul 2011 14:39:00 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "mmusic (E-mail)" , IETF AVTCore WG X-Enigmail-Version: 1.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [AVTCORE] Comments on draft-begen-mmusic-redundancy-grouping-01 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2011 10:58:32 -0000 Hi, (Primarily as individual, but the WG home question is as WG chair) I have reviewed this draft and some comments on it. 1. If this solution proposal is to be taken forward I think it needs to be discussed in AVTCORE. The reason is that it has several RTP details that needs to be figured out to make stream duplication issue free in a general usage. I will take up a few of these issues in the below comments. 2. One aspect this document has is a relation to what is discussed in draft-westerlund-avtcore-multistream-and-simulcast-00. Stream duplication both results in a certain form of multi-stream and also has a similar but slightly different semantics to simulcast in that the streams are two representations of a single original media source. In this case they are clones, but not true duplicates due to that RTP doesn't handle try duplicates well. 3. Another issue that also the authors has identified is the question of what one do when one has multiple media streams from the same end-point. And in a general case one can't use the CNAME to separate the sources. The reason is that two media sources that has a common timing (synchronization) context do needs to indicate that by having the same CNAME. Thus there are need for some additional mechanism to ensure that SSRC carrying RTP media streams that are duplicates of each other do in fact be labeled explicitly. I also note that a SDP based solution is not sufficient to resolve this issue. I think we need something in RTP, so that SSRC collisions can be handled. 4. In addition there is a few questions how this duplication really should set some RTP fields. Is the duplication only working on Sequence number level? There seem to be additional questions, for example in the need to have RTP timestamp considerations between the streams. They need to point identically into the joint timeline. Otherwise outages, or receiver taking synch from one and not the other stream can end up with different synchronizations. Becomes especially interesting to discuss when the time shifted transmission. 5. The draft also discussed Payload Type differences and have them in the SDP examples. I don't see how that is appropriate. If the streams are true encoding duplicates then they should use the same payload type configuration, and thus a single payload type should be sufficient and in fact recommended, unless the source encoding truly changes. 6. I think it is worth discussing also the benefits of SSRC multiplexed versus the session multiplexed. In multicast context there is clear benefits from a control and congestion perspective to have session multiplexed versions and these mapped onto different multicast groups enabling a receiver to choose one or both streams. 7. Thus I think the signalling aspects of this is the minor part. Although there clearly are some aspects of this needing discussion. For example clearer offer/answer rules for handling these. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From gonzalo.camarillo@ericsson.com Sat Jul 23 09:51:42 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21BD021F84F7 for ; Sat, 23 Jul 2011 09:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.607 X-Spam-Level: X-Spam-Status: No, score=-106.607 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ha4vvHRwx0sP for ; Sat, 23 Jul 2011 09:51:41 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id DEABB21F8782 for ; Sat, 23 Jul 2011 09:51:40 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-2c-4e2afc1b7154 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 09.62.20773.B1CFA2E4; Sat, 23 Jul 2011 18:51:40 +0200 (CEST) Received: from [131.160.126.141] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Sat, 23 Jul 2011 18:51:39 +0200 Message-ID: <4E2AFC1A.4090704@ericsson.com> Date: Sat, 23 Jul 2011 12:51:38 -0400 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: avt@ietf.org X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [AVTCORE] Request to review a SIPREC draft related to RTP X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2011 16:51:42 -0000 Folks, the SIPREC WG is working on a description about how RTP will be used in SIPREC environments. We would like to get someone from AVTCORE to have a look at the document to make sure it is OK from an RTP architecture perspective. http://tools.ietf.org/html/draft-eckel-siprec-rtp-rec-01 Thanks, Gonzalo From bill.wu@huawei.com Sat Jul 23 12:27:55 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70F2821F8A56 for ; Sat, 23 Jul 2011 12:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.112 X-Spam-Level: * X-Spam-Status: No, score=1.112 tagged_above=-999 required=5 tests=[AWL=-5.937, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, J_CHICKENPOX_43=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a4q+Jbas+BQz for ; Sat, 23 Jul 2011 12:27:54 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 6862621F8A4F for ; Sat, 23 Jul 2011 12:27:47 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LOS00B1TWQ8NF@szxga05-in.huawei.com> for avt@ietf.org; Sun, 24 Jul 2011 03:27:44 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LOS008BNWQ7NW@szxga05-in.huawei.com> for avt@ietf.org; Sun, 24 Jul 2011 03:27:44 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml201-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ACN85593; Sun, 24 Jul 2011 03:27:39 +0800 (CST) Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.270.1; Sun, 24 Jul 2011 03:27:38 +0800 Received: from SZXEML523-MBS.china.huawei.com ([169.254.6.121]) by szxeml404-hub.china.huawei.com ([fe80::75b7:3db9:fedc:a56d%13]) with mapi id 14.01.0270.001; Sun, 24 Jul 2011 03:27:23 +0800 Date: Sat, 23 Jul 2011 19:27:23 +0000 From: Qin Wu In-reply-to: <4E2AFC1A.4090704@ericsson.com> X-Originating-IP: [172.24.2.41] To: Gonzalo Camarillo , "avt@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: [AVTCORE] Request to review a SIPREC draft related to RTP Thread-index: AQHMSVrbx/gXTSWeGU2yi0JJCQqnGpT6Q8/Y X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4E2AFC1A.4090704@ericsson.com> Subject: [AVTCORE] =?gb2312?b?tPC4tDogIFJlcXVlc3QgdG8gcmV2aWV3IGEgU0lQUkVD?= =?gb2312?b?IGRyYWZ0IHJlbGF0ZWQgdG8gUlRQ?= X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2011 19:27:55 -0000 SGksDQpJIGhhdmUgcmVhZCB0aGlzIGRyYWZ0IGFuZCBzZWVtcyBpbnRlcmVzdGluZyBhbmQgb24g dGhlIHJpZ2h0IHRyYWNrLCBIb3dldmVyIEkgaGF2ZSBzb21lIGNvbW1lbnRzIGJlbG93Og0KMS4g QWNjb3JkaW5nIHRvIGZpZ3VyZSAxLCB0aGUgQ1MoQ29tbXVuaWNhdGlvbiBTZXNzaW9uKSBpcyBy dW5uaW5nIGJldHdlZW4gVUEgYW5kIFNSUy4gSG93ZXZlciBhY2NvcmRpbmcgdG8gDQpkcmFmdC1p ZXRmLXNpcHJlYy1hcmNoaXRlY3R1cmUsIENTIGlzIHJ1bm5pbmcgYmV0d2VlbiB0d28gVUFzLiBT byBpdCBzZWVtcyB0aGVyZSBpcyBhIGxpdHRsZSBpbmNvbnNpc3RlbmN5IA0Kd2l0aCB0aGlzLiBE b2VzIGl0IGluZGljYXRlIFNSUyBzaG91bGQgYmUgc2l0dGluZyBhdCB0aGUgVUE/IEhvdyB0byBk ZWFsIHdpdGggdGhlIGNhc2Ugd2hlcmUgdGhlIFNSUyBpcyBzaXR0aW5nDQpiZXR3ZWVuIHR3byBV QSwgaW4gdGhpcyBjYXNlLCBDUyBpcyBqdXN0IGZvcndhcmRlZCBieSBTUlMuDQoyLkluIHNlY3Rp b24gOSwgaXQgc2FpZDoNCiIgICBBIG1peGVyIHNlbmRzIG9uZSBTREVTIHBhY2tldCBjb250YWlu aW5nIGENCiAgIGNodW5rIGZvciBlYWNoIGNvbnRyaWJ1dGluZyBzb3VyY2UgZnJvbSB3aGljaCBp dCBpcyByZWNlaXZpbmcgU0RFUw0KICAgaW5mb3JtYXRpb24sIG9yIG11bHRpcGxlIGNvbXBsZXRl IFNERVMgcGFja2V0cy4NCiINClNvIHRoZSBxdWVzdGlvbiBpcyBpbiB3aGljaCBjYXNlLHRoZSBN aXhlciBzaG91bGQgc2VuZCBtdWx0aXBsZSBjb21wbGV0ZSBTREVTIHBhY2tldHMgaW5zdGVhZCBv ZiBzZW5kaW5nIG9ubHkgb24gU0RFUyBwYWNrZXQgY29udGFpbmluZyBhbGwNClNERVMgaW5mb3Jt YXRpb24/DQozLiBJbiBzZWN0aW9uIDEyLjEuMSwgaW4gd2hpY2ggY2lyY3Vtc3RhbmNlIHRoZSB4 bWwgc2NoZW1hIGZvciB2aWRlbyBmYXN0IHVwZGF0ZSB3aWxsIGJlIHVzZWQgaW5zdGVhZCBvZiBS VENQIGZlZWRiYWNrIG1ldGhvZD8NCjQuIEluIHNlY3Rpb24gMTIuMiwgd2h5IFVzaW5nIHRoZSBG SVIgY29tbWFuZCB0byByZWNvdmVyIGZyb20gZXJyb3JzIGlzIGV4cGxpY2l0bHkNCiAgIGRpc2Fs bG93ZWQsIGluc3RlYWQsIHVzaW5nIFBMST8NCg0KUmVnYXJkcyENCi1RaW4NCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCreivP7IyzogYXZ0LWJvdW5jZXNAaWV0Zi5v cmcgW2F2dC1ib3VuY2VzQGlldGYub3JnXSC0+rHtIEdvbnphbG8gQ2FtYXJpbGxvIFtHb256YWxv LkNhbWFyaWxsb0Blcmljc3Nvbi5jb21dDQq3osvNyrG85DogMjAxMcTqN9TCMjTI1SAwOjUxDQq1 vTogYXZ0QGlldGYub3JnDQrW98ziOiBbQVZUQ09SRV0gUmVxdWVzdCB0byByZXZpZXcgYSBTSVBS RUMgZHJhZnQgcmVsYXRlZCB0byBSVFANCg0KRm9sa3MsDQoNCnRoZSBTSVBSRUMgV0cgaXMgd29y a2luZyBvbiBhIGRlc2NyaXB0aW9uIGFib3V0IGhvdyBSVFAgd2lsbCBiZSB1c2VkIGluDQpTSVBS RUMgZW52aXJvbm1lbnRzLiBXZSB3b3VsZCBsaWtlIHRvIGdldCBzb21lb25lIGZyb20gQVZUQ09S RSB0byBoYXZlIGENCmxvb2sgYXQgdGhlIGRvY3VtZW50IHRvIG1ha2Ugc3VyZSBpdCBpcyBPSyBm cm9tIGFuIFJUUCBhcmNoaXRlY3R1cmUNCnBlcnNwZWN0aXZlLg0KDQpodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1lY2tlbC1zaXByZWMtcnRwLXJlYy0wMQ0KDQpUaGFua3MsDQoNCkdv bnphbG8NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpB dWRpby9WaWRlbyBUcmFuc3BvcnQgQ29yZSBNYWludGVuYW5jZQ0KYXZ0QGlldGYub3JnDQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2F2dA0K From Even.roni@huawei.com Sun Jul 24 04:34:02 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0208821F877B for ; Sun, 24 Jul 2011 04:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PtqbOwBKBTNU for ; Sun, 24 Jul 2011 04:34:01 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 5F2E321F84F6 for ; Sun, 24 Jul 2011 04:34:01 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LOU006JC5GMDF@szxga03-in.huawei.com> for avt@ietf.org; Sun, 24 Jul 2011 19:33:58 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LOU00CUZ5GHNS@szxga03-in.huawei.com> for avt@ietf.org; Sun, 24 Jul 2011 19:33:53 +0800 (CST) Received: from windows8d787f9 ([130.129.67.143]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LOU00GMU5GEBN@szxml12-in.huawei.com> for avt@ietf.org; Sun, 24 Jul 2011 19:33:53 +0800 (CST) Date: Sun, 24 Jul 2011 14:30:43 +0300 From: Roni Even In-reply-to: <4E2AFC1A.4090704@ericsson.com> To: avt@ietf.org Message-id: <003201cc49f5$33acce80$9b066b80$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcxJWtxfotiGp5gWTsWFEVoWePCPCgAmhJ9g References: <4E2AFC1A.4090704@ericsson.com> Subject: Re: [AVTCORE] Request to review a SIPREC draft related to RTP - please repond to SIPrec list X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2011 11:34:02 -0000 Hi, If you review this work please respond to sipr@ietf.org and not avtcore list Roni Even AVTcore co-chair > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > Gonzalo Camarillo > Sent: Saturday, July 23, 2011 7:52 PM > To: avt@ietf.org > Subject: [AVTCORE] Request to review a SIPREC draft related to RTP > > Folks, > > the SIPREC WG is working on a description about how RTP will be used in > SIPREC environments. We would like to get someone from AVTCORE to have > a > look at the document to make sure it is OK from an RTP architecture > perspective. > > http://tools.ietf.org/html/draft-eckel-siprec-rtp-rec-01 > > Thanks, > > Gonzalo > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From eckelcu@cisco.com Sun Jul 24 11:28:44 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E129F21F8AD6 for ; Sun, 24 Jul 2011 11:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.192 X-Spam-Level: X-Spam-Status: No, score=0.192 tagged_above=-999 required=5 tests=[AWL=-5.104, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, J_CHICKENPOX_43=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wyr3We6fM6HV for ; Sun, 24 Jul 2011 11:28:44 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 2B2CA21F8AF0 for ; Sun, 24 Jul 2011 11:28:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=3912; q=dns/txt; s=iport; t=1311532124; x=1312741724; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=njbMsbnIY1jG8Z3r0uILldpxKLYpv5gAYoJW/0lQoj8=; b=WBSwL3d6jJeN7Vr3XqQti5FQdglBku1HZzHe9vPxOAy4GsU7+YidOs4A ocyTe8J3pjZMXHpWQ7K9Rpt+KKDhouwF3sCfUUJ3zb5UckGKuc8NTJb+E ZHFq+fPxR+Htb0Hwrq68aJ/iZfmsmCGMKcBap0OG35n0ipnFazOtPJQaI Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AukAAKpjLE6rRDoG/2dsb2JhbAA1AQEBAQIBAQEBEQEhVAcFAgEHAg4DAQECAQEFBgYjAQQCARMYIwMIAwgCBQEWDBuEL5Mrj1J3iHwEn26NHQiQBYEnhAU0XwSHVZAri3A X-IronPort-AV: E=Sophos;i="4.67,257,1309737600"; d="scan'208";a="5928053" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-5.cisco.com with ESMTP; 24 Jul 2011 18:28:43 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6OIShjO029244; Sun, 24 Jul 2011 18:28:43 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 24 Jul 2011 11:28:43 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Date: Sun, 24 Jul 2011 11:28:42 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: =?gb2312?B?W0FWVENPUkVdILTwuLQ6ICBSZXF1ZXN0IHRvIHJldmlldyBhIFNJUA==?= =?gb2312?B?UkVDIGRyYWZ0IHJlbGF0ZWQgdG8gUlRQ?= Thread-Index: AQHMSVrbx/gXTSWeGU2yi0JJCQqnGpT6Q8/YgAFLVmA= References: <4E2AFC1A.4090704@ericsson.com> From: "Charles Eckel (eckelcu)" To: "Qin Wu" , "Gonzalo Camarillo" , X-OriginalArrivalTime: 24 Jul 2011 18:28:43.0057 (UTC) FILETIME=[844EB210:01CC4A2F] Subject: Re: [AVTCORE] =?gb2312?b?tPC4tDogIFJlcXVlc3QgdG8gcmV2aWV3IGEgU0lQUkVD?= =?gb2312?b?IGRyYWZ0IHJlbGF0ZWQgdG8gUlRQ?= X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2011 18:28:45 -0000 Hi Qin, Thank you for reviewing the draft and providing comments. Please see = inline for my responses. > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of = Qin Wu > Sent: Saturday, July 23, 2011 12:27 PM > To: Gonzalo Camarillo; avt@ietf.org > Subject: [AVTCORE] =B4=F0=B8=B4: Request to review a SIPREC draft = related to RTP >=20 > Hi, > I have read this draft and seems interesting and on the right track, = However I have some comments > below: > 1. According to figure 1, the CS(Communication Session) is running = between UA and SRS. However > according to > draft-ietf-siprec-architecture, CS is running between two UAs. So it = seems there is a little > inconsistency > with this. Does it indicate SRS should be sitting at the UA? How to = deal with the case where the SRS > is sitting > between two UA, in this case, CS is just forwarded by SRS. You are correct. In this case, the SRC is acting as the other UA within = the CS. This is similar to Figure 2 of draft-ietf-siprec-architecture. = The case you mention is similar to Figure 1 of = draft-ietf-siprec-architecture. This draft is meant to apply to both = cases. Do you think it would be help if I added another diagram and = additional descriptions regarding this? > 2.In section 9, it said: > " A mixer sends one SDES packet containing a > chunk for each contributing source from which it is receiving SDES > information, or multiple complete SDES packets. > " > So the question is in which case,the Mixer should send multiple = complete SDES packets instead of > sending only on SDES packet containing all > SDES information? My understanding is that this is up to implementation of the mixer. As = such, an SRC needs to be able to handle both cases when dealing with a = CS involving a mixer. Similarly, a SRC may act as a mixer toward the = SRS, so the SRS needs to be able to handle both cases as well. Let me know if that addresses your concern, and if so, I will add it as = clarification. > 3. In section 12.1.1, in which circumstance the xml schema for video = fast update will be used instead > of RTCP feedback method? Its use is discouraged; however, it is mentioned here such that an = SRC/SRS is aware of it and able to send/receive it when necessary. For = example, if I UA does not support RTCP feedback, a SRC may want to use = SIP INFO. Let me know if that addresses your concern, and if so, I will add it as = clarification. =20 > 4. In section 12.2, why Using the FIR command to recover from errors = is explicitly > disallowed, instead, using PLI? I am merely restating the restrictions specified in RFC 5104 in order to = highlight them. My intention is not to add any additional restrictions = that are SIPREC specific. Cheers, Charles =20 > Regards! > -Qin > ________________________________________ > =B7=A2=BC=FE=C8=CB: avt-bounces@ietf.org [avt-bounces@ietf.org] = =B4=FA=B1=ED Gonzalo Camarillo > [Gonzalo.Camarillo@ericsson.com] > =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA7=D4=C224=C8=D5 0:51 > =B5=BD: avt@ietf.org > =D6=F7=CC=E2: [AVTCORE] Request to review a SIPREC draft related to = RTP >=20 > Folks, >=20 > the SIPREC WG is working on a description about how RTP will be used = in > SIPREC environments. We would like to get someone from AVTCORE to have = a > look at the document to make sure it is OK from an RTP architecture > perspective. >=20 > http://tools.ietf.org/html/draft-eckel-siprec-rtp-rec-01 >=20 > Thanks, >=20 > Gonzalo > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From abegen@cisco.com Sun Jul 24 20:22:08 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F01A11E807F; Sun, 24 Jul 2011 20:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.585 X-Spam-Level: X-Spam-Status: No, score=-4.585 tagged_above=-999 required=5 tests=[AWL=-2.586, BAYES_00=-2.599, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3RBHQ+sznnYt; Sun, 24 Jul 2011 20:22:07 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 496A511E8078; Sun, 24 Jul 2011 20:22:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=7862; q=dns/txt; s=iport; t=1311564127; x=1312773727; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=ovuLLBYjLZVxbSfuCK+cA4vYw4xSdaEklznv4xQA5j8=; b=GBHXSj/Uf9Zd7585qzO7RZF7+gvU5tzgBoEmpfHWVOd0YlmUNP58/h/4 wnTlZINtS+RH6am4UxR5PjWB1AhTFS1sBeV/9UNdW5NJfTTvIG7p7PhzK PdOCMtjBKMBnOEESYBkfjAf8NURpGCBpVdflDFyWGYIjheHgX5UIY85SA U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AucAAH/gLE6rRDoG/2dsb2JhbAA0AQEBAQIBAQEBCgcBIT0LDAcDAgIBCREEAQELBgYdAQYBEwwMIw4IAQEFARYMFAeXWo9Td4h8BKIKnTYCgyGCPV8Eh1WQK4tw X-IronPort-AV: E=Sophos;i="4.67,258,1309737600"; d="scan'208";a="5978726" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-9.cisco.com with ESMTP; 25 Jul 2011 03:22:06 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6P3M46Z007822; Mon, 25 Jul 2011 03:22:06 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 24 Jul 2011 20:21:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Sun, 24 Jul 2011 20:21:58 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540F810C54@xmb-sjc-215.amer.cisco.com> In-Reply-To: <4E296F64.70500@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVTCORE] Comments on draft-begen-mmusic-redundancy-grouping-01 Thread-Index: AcxJJ3tw784Q3ueDTSOxilOeoyOOUwBArfdg References: <4E296F64.70500@ericsson.com> From: "Ali C. Begen (abegen)" To: "Magnus Westerlund" , "mmusic (E-mail)" , "IETF AVTCore WG" X-OriginalArrivalTime: 25 Jul 2011 03:21:59.0846 (UTC) FILETIME=[03E13C60:01CC4A7A] Subject: Re: [AVTCORE] Comments on draft-begen-mmusic-redundancy-grouping-01 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 03:22:08 -0000 > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of = Magnus Westerlund > Sent: Friday, July 22, 2011 8:39 AM > To: mmusic (E-mail); IETF AVTCore WG > Subject: [AVTCORE] Comments on = draft-begen-mmusic-redundancy-grouping-01 >=20 > Hi, >=20 > (Primarily as individual, but the WG home question is as WG chair) >=20 > I have reviewed this draft and some comments on it. Thanks for the review. =20 > 1. If this solution proposal is to be taken forward I think it needs = to > be discussed in AVTCORE. The reason is that it has several RTP details > that needs to be figured out to make stream duplication issue free in = a > general usage. I will take up a few of these issues in the below = comments. That is why we asked for a slot in avtcore on wed. =20 > 2. One aspect this document has is a relation to what is discussed in > draft-westerlund-avtcore-multistream-and-simulcast-00. Stream > duplication both results in a certain form of multi-stream and also = has > a similar but slightly different semantics to simulcast in that the > streams are two representations of a single original media source. In > this case they are clones, but not true duplicates due to that RTP > doesn't handle try duplicates well. The data carried in the redundant streams are identical but the rtp = header differs due to the different SSRCs. That is all. SSRC muxing = nicely fits the use case we are tackling with. Simulcasting is quite = different from our use case because in simulcasting different RTP = streams most likely carry different data. =20 > 3. Another issue that also the authors has identified is the question = of > what one do when one has multiple media streams from the same = end-point. >From the same end-point (e.g., source) there could of course of multiple = media streams. You can use SSRC muxing for example to identify your = streams and use ssrc-group to group them if needed. The concern in that editorial note was what if there were multiple = streams in each m line but what if you wanted grouping/association among = only a subset. For example, m=3Dvideo 30000 RTP/AVP 101 102 .... m=3Dvideo 30000 RTP/AVP 103 104 I can easily associate 101 and 102 if I want to, but what if 101 and 103 = were associated with each other. Can I use a=3Dgroup line? Probably not. = But, I don't know why you would need that kind of relation in the first = place (even if you need, there are probably less messy ways to express = them). If that had been a very desirable feature, SDP and grouping = semantics along with RTP would not have defined in their current form I = guess. > And in a general case one can't use the CNAME to separate the sources. > The reason is that two media sources that has a common timing > (synchronization) context do needs to indicate that by having the same > CNAME. Thus there are need for some additional mechanism to ensure = that If 101 and 103 are associated, why can't I use the same CNAME for those = streams? If 102 and 104 are associated/related, I would use a common = CNAME for them, too (but theirs would be separate from 101 and 103's). > SSRC carrying RTP media streams that are duplicates of each other do = in > fact be labeled explicitly. I also note that a SDP based solution is = not > sufficient to resolve this issue. I think we need something in RTP, so > that SSRC collisions can be handled. I can't say I am following. > 4. In addition there is a few questions how this duplication really > should set some RTP fields. Is the duplication only working on = Sequence That is the easiest way for a middle box or endpoint doing the stream = merging (duplicate suppression). If seqnums are different, what would = one do? look into the payload? > number level? There seem to be additional questions, for example in = the > need to have RTP timestamp considerations between the streams. They = need > to point identically into the joint timeline. Otherwise outages, or > receiver taking synch from one and not the other stream can end up = with > different synchronizations. Becomes especially interesting to discuss > when the time shifted transmission. The duplicate streams are coming from the same source, so they have the = same timestamp as well as seqnums. It has to be this way because the = node merging the streams will not re-write anything at all. It is a = simple suppression operation. Beauty of it is that things stay pretty = simple to use and implement without any changes to RTP/RTCP plane at = all. As for the time-shifted transmission, I suppose you are referring to the = temporal diversity/delayed duplication = (draft-begen-mmusic-temporal-interleaving-02). Well, in that case, = timestamps are still the same for the reasons above. Changing the = timestamps for the delayed packets does not bring any benefit (actually = it complicates things) since the ultimate RTP application will still = receive one and only one RTP stream. > 5. The draft also discussed Payload Type differences and have them in > the SDP examples. I don't see how that is appropriate. If the streams When you are doing SSRC muxing, you put multiple streams in the same m = line and they end up having different PT numbers. What is wrong with = that? If they are in separate m lines, they could have the same PT = number. > are true encoding duplicates then they should use the same payload = type > configuration, and thus a single payload type should be sufficient and > in fact recommended, unless the source encoding truly changes. See above. > 6. I think it is worth discussing also the benefits of SSRC = multiplexed > versus the session multiplexed. In multicast context there is clear > benefits from a control and congestion perspective to have session > multiplexed versions and these mapped onto different multicast groups > enabling a receiver to choose one or both streams. This is what we have in section 5.2. Different streams can be sent in = different multicast sessions but it does not mean that they are separate = RTP sessions. I discussed this in detail with Colin. Thanks to him for = trying to teach me over and over what an RTP session actually means. =20 > 7. Thus I think the signalling aspects of this is the minor part. > Although there clearly are some aspects of this needing discussion. = For > example clearer offer/answer rules for handling these. We have some text around O/A stuff. But frankly, I don=92t see any use = case where duplication will be used in a unicast application. I mean if = redundancy is needed, one should use FEC instead for unicast transport. = Duplication is a nice use case for multicast transport where the bw = overhead is easier to justify and the implementation is easier. And one = would naturally implement this spec in networks where he already knows = that the network elements support this spec. So, maybe we should remove = the whole O/A text anyway and write that this will only be used = declaratively. -acbegen =20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From magnus.westerlund@ericsson.com Mon Jul 25 04:54:35 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD7AC21F8515; Mon, 25 Jul 2011 04:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.899 X-Spam-Level: X-Spam-Status: No, score=-105.899 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7UAA+ff780K; Mon, 25 Jul 2011 04:54:34 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id B32EE21F8BC5; Mon, 25 Jul 2011 03:54:24 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-50-4e2d4b5fc872 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id B4.15.20773.F5B4D2E4; Mon, 25 Jul 2011 12:54:23 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Mon, 25 Jul 2011 12:54:21 +0200 Message-ID: <4E2D4B52.80900@ericsson.com> Date: Mon, 25 Jul 2011 06:54:10 -0400 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: <4E296F64.70500@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540F810C54@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540F810C54@xmb-sjc-215.amer.cisco.com> X-Enigmail-Version: 1.2 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "mmusic \(E-mail\)" , IETF AVTCore WG Subject: Re: [AVTCORE] Comments on draft-begen-mmusic-redundancy-grouping-01 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 11:54:35 -0000 On 2011-07-24 23:21, Ali C. Begen (abegen) wrote: > > >> -----Original Message----- From: avt-bounces@ietf.org >> [mailto:avt-bounces@ietf.org] On Behalf Of Magnus Westerlund Sent: >> Friday, July 22, 2011 8:39 AM To: mmusic (E-mail); IETF AVTCore WG >> Subject: [AVTCORE] Comments on >> draft-begen-mmusic-redundancy-grouping-01 >> >> Hi, >> >> (Primarily as individual, but the WG home question is as WG chair) >> >> I have reviewed this draft and some comments on it. > > Thanks for the review. > >> 1. If this solution proposal is to be taken forward I think it >> needs to be discussed in AVTCORE. The reason is that it has several >> RTP details that needs to be figured out to make stream duplication >> issue free in a general usage. I will take up a few of these issues >> in the below comments. > > That is why we asked for a slot in avtcore on wed. > >> 2. One aspect this document has is a relation to what is discussed >> in draft-westerlund-avtcore-multistream-and-simulcast-00. Stream >> duplication both results in a certain form of multi-stream and also >> has a similar but slightly different semantics to simulcast in that >> the streams are two representations of a single original media >> source. In this case they are clones, but not true duplicates due >> to that RTP doesn't handle try duplicates well. > > The data carried in the redundant streams are identical but the rtp > header differs due to the different SSRCs. That is all. SSRC muxing > nicely fits the use case we are tackling with. Simulcasting is quite > different from our use case because in simulcasting different RTP > streams most likely carry different data. I agree that the purpose for multiple RTP streams from the same original media source are different from the primary case I set out to solve. But as Jonathan Lennox pointed out, redundancy and FEC have very similar behaviors to simulcast with different encodings of the same original source. Thus, I do see a need to discuss for example how you identify the streams that are a duplicate of each other. > >> 3. Another issue that also the authors has identified is the >> question of what one do when one has multiple media streams from >> the same end-point. > >> From the same end-point (e.g., source) there could of course of >> multiple media streams. You can use SSRC muxing for example to >> identify your streams and use ssrc-group to group them if needed. > > The concern in that editorial note was what if there were multiple > streams in each m line but what if you wanted grouping/association > among only a subset. > > For example, > > m=video 30000 RTP/AVP 101 102 .... m=video 30000 RTP/AVP 103 104 > > I can easily associate 101 and 102 if I want to, but what if 101 and > 103 were associated with each other. Can I use a=group line? Probably > not. But, I don't know why you would need that kind of relation in > the first place (even if you need, there are probably less messy ways > to express them). If that had been a very desirable feature, SDP and > grouping semantics along with RTP would not have defined in their > current form I guess. Yes, that is a very valid question also for simulcast. And I think we can provide a story for doing that. But I don't think it should be based on using the RTP payload type to identify either of the versions. > >> And in a general case one can't use the CNAME to separate the >> sources. The reason is that two media sources that has a common >> timing (synchronization) context do needs to indicate that by >> having the same CNAME. Thus there are need for some additional >> mechanism to ensure that > > If 101 and 103 are associated, why can't I use the same CNAME for > those streams? If 102 and 104 are associated/related, I would use a > common CNAME for them, too (but theirs would be separate from 101 and > 103's). If SSRC A has a duplciation in SSRC C and SSRC B has a duplication in SSRC D and both A and B comes from the same end-point and have a common synchronization context, then all of A-D needs to have the same CNAME. And I get the impression that you are using a payload type based association scheme here. And I think that is a bad idea. For example it can't support particular many streams. It also looks semantically wrong, as if Stream A uses PT 96, then SSRC C should use PT 96 also for the corresponding packet duplicates. And if A switches from one PT to another the other stream needs to follow. Thus I think a SDES item based approach for indicating that it is in fact A and C that are duplicates, rather than A and B or A and D. > >> SSRC carrying RTP media streams that are duplicates of each other >> do in fact be labeled explicitly. I also note that a SDP based >> solution is not sufficient to resolve this issue. I think we need >> something in RTP, so that SSRC collisions can be handled. > > I can't say I am following. I suggest that you use something like the SRCNAME SDES item extension I propose in my draft. > >> 4. In addition there is a few questions how this duplication >> really should set some RTP fields. Is the duplication only working >> on Sequence > > That is the easiest way for a middle box or endpoint doing the stream > merging (duplicate suppression). If seqnums are different, what would > one do? look into the payload? It was simply that you had not documented what needs to be the same. Sequence number being the same is likely the easiest, but one do have to raise some warning flags if one has processing that changes these streams. For example a translator modifying the packetization must do the exact same manipulation on the other stream. But, I don't think anything else really works. > >> number level? There seem to be additional questions, for example in >> the need to have RTP timestamp considerations between the streams. >> They need to point identically into the joint timeline. Otherwise >> outages, or receiver taking synch from one and not the other stream >> can end up with different synchronizations. Becomes especially >> interesting to discuss when the time shifted transmission. > > The duplicate streams are coming from the same source, so they have > the same timestamp as well as seqnums. It has to be this way because > the node merging the streams will not re-write anything at all. It is > a simple suppression operation. Beauty of it is that things stay > pretty simple to use and implement without any changes to RTP/RTCP > plane at all. Yes, but you hadn't made it clear, and you have both SSRC and implied change of PT. So I didn't want to assume anything. The timestamp field also have implcations due to its binding with RTCP SR information. > > As for the time-shifted transmission, I suppose you are referring to > the temporal diversity/delayed duplication > (draft-begen-mmusic-temporal-interleaving-02). Well, in that case, > timestamps are still the same for the reasons above. Changing the > timestamps for the delayed packets does not bring any benefit > (actually it complicates things) since the ultimate RTP application > will still receive one and only one RTP stream. Ok, but you will need to make clear on how one should set the RTCP SR timestamp NTP mapping to be clear. And what that implies for the RTCP jitter calculation. > >> 5. The draft also discussed Payload Type differences and have them >> in the SDP examples. I don't see how that is appropriate. If the >> streams > > When you are doing SSRC muxing, you put multiple streams in the same > m line and they end up having different PT numbers. What is wrong > with that? If they are in separate m lines, they could have the same > PT number. I am still asking why, there is no reason to use different PTs, unless you are doing the association between the different streams by them having different PTs. Which I believe is a Bad Idea (TM). The encoding in the packet are the same, so why don't they have the same PT. > >> 6. I think it is worth discussing also the benefits of SSRC >> multiplexed versus the session multiplexed. In multicast context >> there is clear benefits from a control and congestion perspective >> to have session multiplexed versions and these mapped onto >> different multicast groups enabling a receiver to choose one or >> both streams. > > This is what we have in section 5.2. Different streams can be sent in > different multicast sessions but it does not mean that they are > separate RTP sessions. I discussed this in detail with Colin. Thanks > to him for trying to teach me over and over what an RTP session > actually means. Yes, you have an example, but not a discussion of why an implementor should choose Session multiplexing over SSRC. I think that should be included, or I think you can wait for the architectural document I think will result from my multi-stream and simulcast draft. > >> 7. Thus I think the signalling aspects of this is the minor part. >> Although there clearly are some aspects of this needing discussion. >> For example clearer offer/answer rules for handling these. > > We have some text around O/A stuff. But frankly, I don’t see any use > case where duplication will be used in a unicast application. I mean > if redundancy is needed, one should use FEC instead for unicast > transport. Duplication is a nice use case for multicast transport > where the bw overhead is easier to justify and the implementation is > easier. And one would naturally implement this spec in networks where > he already knows that the network elements support this spec. So, > maybe we should remove the whole O/A text anyway and write that this > will only be used declaratively. Then, I think we should slap an application statement to the beginning of the draft to ensure that it may only be used in multicast. For example b=TIAS was only intended to used in declarative SDPs, but it has become common in O/A, but it doesn't have clear rules. So I think it imporant that one don't assume to much. Yes, it might not be the best idea for unicast, but that is not going to prevent it from being used. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From oran@cisco.com Mon Jul 25 06:38:43 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0FD421F871E; Mon, 25 Jul 2011 06:38:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.849 X-Spam-Level: X-Spam-Status: No, score=-101.849 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SB-lX3WH8Wmu; Mon, 25 Jul 2011 06:38:42 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 4D7F621F867E; Mon, 25 Jul 2011 06:38:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=oran@cisco.com; l=12055; q=dns/txt; s=iport; t=1311601122; x=1312810722; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=67XbD3/3HVgUmc+msP/Bwx5D/7cwLwWQDUWWeQLzjXg=; b=UktmtJn/9RMNPH1PSvXmkDTZrT7JfIZax0HOKF0GBmqHbh2GKQ7cF4iF 0km73oh3epG/zet20GPH1BmLWUYbq4wFMA7zMCLp3xbbih/lHzvlYoiUc 3f3glbWJYaAEDloXAoIR9Xbz520JHm9sc5WWT3IZ25Wvbg4IgD7hZHlDG 4=; X-IronPort-AV: E=Sophos;i="4.67,261,1309737600"; d="scan'208";a="6114470" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-4.cisco.com with ESMTP; 25 Jul 2011 13:38:41 +0000 Received: from sjc-vpnasa-174.cisco.com (sjc-vpnasa-174.cisco.com [10.21.104.174]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6PDcexY015629; Mon, 25 Jul 2011 13:38:40 GMT Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=windows-1252 From: David R Oran In-Reply-To: <4E2D4B52.80900@ericsson.com> Date: Mon, 25 Jul 2011 09:38:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E296F64.70500@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540F810C54@xmb-sjc-215.amer.cisco.com> <4E2D4B52.80900@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1244.3) Cc: "mmusic \(E-mail\)" , IETF AVTCore WG Subject: Re: [AVTCORE] Comments on draft-begen-mmusic-redundancy-grouping-01 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 13:38:43 -0000 One small comment, basically agreeing with Magnus point about payload = types. Usually when people use payload identifiers to do demultiplexing they = later regret it. Payload identifiers (in RTP or any other protocol for = that matter) should only be used to decide which parser to hand the data = to, not which state variable to bind the data in the packet to.=20 (further aside: this is one of the few things the OSI guys actually got = right when they had both payload ids and SAPs at every layer). DaveO. On Jul 25, 2011, at 6:54 AM, Magnus Westerlund wrote: > On 2011-07-24 23:21, Ali C. Begen (abegen) wrote: >>=20 >>=20 >>> -----Original Message----- From: avt-bounces@ietf.org >>> [mailto:avt-bounces@ietf.org] On Behalf Of Magnus Westerlund Sent: >>> Friday, July 22, 2011 8:39 AM To: mmusic (E-mail); IETF AVTCore WG=20= >>> Subject: [AVTCORE] Comments on >>> draft-begen-mmusic-redundancy-grouping-01 >>>=20 >>> Hi, >>>=20 >>> (Primarily as individual, but the WG home question is as WG chair) >>>=20 >>> I have reviewed this draft and some comments on it. >>=20 >> Thanks for the review. >>=20 >>> 1. If this solution proposal is to be taken forward I think it >>> needs to be discussed in AVTCORE. The reason is that it has several >>> RTP details that needs to be figured out to make stream duplication >>> issue free in a general usage. I will take up a few of these issues >>> in the below comments. >>=20 >> That is why we asked for a slot in avtcore on wed. >>=20 >>> 2. One aspect this document has is a relation to what is discussed >>> in draft-westerlund-avtcore-multistream-and-simulcast-00. Stream=20 >>> duplication both results in a certain form of multi-stream and also >>> has a similar but slightly different semantics to simulcast in that >>> the streams are two representations of a single original media >>> source. In this case they are clones, but not true duplicates due >>> to that RTP doesn't handle try duplicates well. >>=20 >> The data carried in the redundant streams are identical but the rtp >> header differs due to the different SSRCs. That is all. SSRC muxing >> nicely fits the use case we are tackling with. Simulcasting is quite >> different from our use case because in simulcasting different RTP >> streams most likely carry different data. >=20 > I agree that the purpose for multiple RTP streams from the same = original > media source are different from the primary case I set out to solve. = But > as Jonathan Lennox pointed out, redundancy and FEC have very similar > behaviors to simulcast with different encodings of the same original > source. >=20 > Thus, I do see a need to discuss for example how you identify the > streams that are a duplicate of each other. >=20 >>=20 >>> 3. Another issue that also the authors has identified is the >>> question of what one do when one has multiple media streams from >>> the same end-point. >>=20 >>> =46rom the same end-point (e.g., source) there could of course of >>> multiple media streams. You can use SSRC muxing for example to >>> identify your streams and use ssrc-group to group them if needed. >>=20 >> The concern in that editorial note was what if there were multiple >> streams in each m line but what if you wanted grouping/association >> among only a subset. >>=20 >> For example, >>=20 >> m=3Dvideo 30000 RTP/AVP 101 102 .... m=3Dvideo 30000 RTP/AVP 103 104 >>=20 >> I can easily associate 101 and 102 if I want to, but what if 101 and >> 103 were associated with each other. Can I use a=3Dgroup line? = Probably >> not. But, I don't know why you would need that kind of relation in >> the first place (even if you need, there are probably less messy ways >> to express them). If that had been a very desirable feature, SDP and >> grouping semantics along with RTP would not have defined in their >> current form I guess. >=20 > Yes, that is a very valid question also for simulcast. >=20 > And I think we can provide a story for doing that. But I don't think = it > should be based on using the RTP payload type to identify either of = the > versions. >=20 >>=20 >>> And in a general case one can't use the CNAME to separate the >>> sources. The reason is that two media sources that has a common >>> timing (synchronization) context do needs to indicate that by >>> having the same CNAME. Thus there are need for some additional >>> mechanism to ensure that >>=20 >> If 101 and 103 are associated, why can't I use the same CNAME for >> those streams? If 102 and 104 are associated/related, I would use a >> common CNAME for them, too (but theirs would be separate from 101 and >> 103's). >=20 > If SSRC A has a duplciation in SSRC C and SSRC B has a duplication in > SSRC D and both A and B comes from the same end-point and have a = common > synchronization context, then all of A-D needs to have the same CNAME. >=20 > And I get the impression that you are using a payload type based > association scheme here. And I think that is a bad idea. For example = it > can't support particular many streams. It also looks semantically = wrong, > as if Stream A uses PT 96, then SSRC C should use PT 96 also for the > corresponding packet duplicates. And if A switches from one PT to > another the other stream needs to follow. >=20 > Thus I think a SDES item based approach for indicating that it is in > fact A and C that are duplicates, rather than A and B or A and D. >=20 >>=20 >>> SSRC carrying RTP media streams that are duplicates of each other >>> do in fact be labeled explicitly. I also note that a SDP based >>> solution is not sufficient to resolve this issue. I think we need >>> something in RTP, so that SSRC collisions can be handled. >>=20 >> I can't say I am following. >=20 > I suggest that you use something like the SRCNAME SDES item extension = I > propose in my draft. >=20 >>=20 >>> 4. In addition there is a few questions how this duplication >>> really should set some RTP fields. Is the duplication only working >>> on Sequence >>=20 >> That is the easiest way for a middle box or endpoint doing the stream >> merging (duplicate suppression). If seqnums are different, what would >> one do? look into the payload? >=20 > It was simply that you had not documented what needs to be the same. > Sequence number being the same is likely the easiest, but one do have = to > raise some warning flags if one has processing that changes these > streams. For example a translator modifying the packetization must do > the exact same manipulation on the other stream. >=20 > But, I don't think anything else really works. >=20 >>=20 >>> number level? There seem to be additional questions, for example in >>> the need to have RTP timestamp considerations between the streams. >>> They need to point identically into the joint timeline. Otherwise >>> outages, or receiver taking synch from one and not the other stream >>> can end up with different synchronizations. Becomes especially >>> interesting to discuss when the time shifted transmission. >>=20 >> The duplicate streams are coming from the same source, so they have >> the same timestamp as well as seqnums. It has to be this way because >> the node merging the streams will not re-write anything at all. It is >> a simple suppression operation. Beauty of it is that things stay >> pretty simple to use and implement without any changes to RTP/RTCP >> plane at all. >=20 > Yes, but you hadn't made it clear, and you have both SSRC and implied > change of PT. So I didn't want to assume anything. >=20 > The timestamp field also have implcations due to its binding with RTCP > SR information. >=20 >>=20 >> As for the time-shifted transmission, I suppose you are referring to >> the temporal diversity/delayed duplication >> (draft-begen-mmusic-temporal-interleaving-02). Well, in that case, >> timestamps are still the same for the reasons above. Changing the >> timestamps for the delayed packets does not bring any benefit >> (actually it complicates things) since the ultimate RTP application >> will still receive one and only one RTP stream. >=20 > Ok, but you will need to make clear on how one should set the RTCP SR > timestamp NTP mapping to be clear. And what that implies for the RTCP > jitter calculation. >=20 >>=20 >>> 5. The draft also discussed Payload Type differences and have them >>> in the SDP examples. I don't see how that is appropriate. If the >>> streams >>=20 >> When you are doing SSRC muxing, you put multiple streams in the same >> m line and they end up having different PT numbers. What is wrong >> with that? If they are in separate m lines, they could have the same >> PT number. >=20 > I am still asking why, there is no reason to use different PTs, unless > you are doing the association between the different streams by them > having different PTs. Which I believe is a Bad Idea (TM). The encoding > in the packet are the same, so why don't they have the same PT. >=20 >=20 >>=20 >>> 6. I think it is worth discussing also the benefits of SSRC >>> multiplexed versus the session multiplexed. In multicast context >>> there is clear benefits from a control and congestion perspective >>> to have session multiplexed versions and these mapped onto >>> different multicast groups enabling a receiver to choose one or >>> both streams. >>=20 >> This is what we have in section 5.2. Different streams can be sent in >> different multicast sessions but it does not mean that they are >> separate RTP sessions. I discussed this in detail with Colin. Thanks >> to him for trying to teach me over and over what an RTP session >> actually means. >=20 > Yes, you have an example, but not a discussion of why an implementor > should choose Session multiplexing over SSRC. I think that should be > included, or I think you can wait for the architectural document I = think > will result from my multi-stream and simulcast draft. >=20 >>=20 >>> 7. Thus I think the signalling aspects of this is the minor part.=20 >>> Although there clearly are some aspects of this needing discussion. >>> For example clearer offer/answer rules for handling these. >>=20 >> We have some text around O/A stuff. But frankly, I don=92t see any = use >> case where duplication will be used in a unicast application. I mean >> if redundancy is needed, one should use FEC instead for unicast >> transport. Duplication is a nice use case for multicast transport >> where the bw overhead is easier to justify and the implementation is >> easier. And one would naturally implement this spec in networks where >> he already knows that the network elements support this spec. So, >> maybe we should remove the whole O/A text anyway and write that this >> will only be used declaratively. >=20 > Then, I think we should slap an application statement to the beginning > of the draft to ensure that it may only be used in multicast. For > example b=3DTIAS was only intended to used in declarative SDPs, but it = has > become common in O/A, but it doesn't have clear rules. >=20 > So I think it imporant that one don't assume to much. Yes, it might = not > be the best idea for unicast, but that is not going to prevent it from > being used. >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From abegen@cisco.com Mon Jul 25 09:05:34 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4283921F904C; Mon, 25 Jul 2011 09:05:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.962 X-Spam-Level: X-Spam-Status: No, score=-3.962 tagged_above=-999 required=5 tests=[AWL=-2.562, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNJPEWln6cQx; Mon, 25 Jul 2011 09:05:33 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 1370621F8BCF; Mon, 25 Jul 2011 07:08:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=13705; q=dns/txt; s=iport; t=1311602918; x=1312812518; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=4gDIcMINWlF/3I84Dx5mFXixsL9LpG9JIksSelxP8+0=; b=Ze3RDljiS1i5SpPrflcTbGmmF/XzUMKLUKpjG9mquTLfsMEcyeZGCSa7 fwVTi/flzulSX3fQKaqhyiCr3QBMfE0EqwwayhIEpqQwYiPWo496+0Q8u fxvu5dn0RhX3O/6EoWHX1TexbWShmnx62r+GZlfsy3JFNqVDQAW3ulqxW k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AucAAFF4LU6rRDoH/2dsb2JhbAA0AQEBAQIBDQcBIT0LBwUHAwICAQkRBAEBAQoGBh0BBgETDC8OCAEBBRcMFAeXW49Wd4h8olmddwKDIYI9XwSHVZAri3A X-IronPort-AV: E=Sophos;i="4.67,261,1309737600"; d="scan'208";a="6122678" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-2.cisco.com with ESMTP; 25 Jul 2011 14:08:37 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6PE8a3H010229; Mon, 25 Jul 2011 14:08:36 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 25 Jul 2011 07:08:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Jul 2011 07:07:34 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540F810C97@xmb-sjc-215.amer.cisco.com> In-Reply-To: <4E2D4B52.80900@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVTCORE] Comments on draft-begen-mmusic-redundancy-grouping-01 Thread-Index: AcxKuTkhgw3QFwdMQfqcuyQoCT23dgAGJvmA References: <4E296F64.70500@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540F810C54@xmb-sjc-215.amer.cisco.com> <4E2D4B52.80900@ericsson.com> From: "Ali C. Begen (abegen)" To: "Magnus Westerlund" X-OriginalArrivalTime: 25 Jul 2011 14:08:36.0794 (UTC) FILETIME=[58A9B1A0:01CC4AD4] Cc: "mmusic \(E-mail\)" , IETF AVTCore WG Subject: Re: [AVTCORE] Comments on draft-begen-mmusic-redundancy-grouping-01 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 16:05:34 -0000 > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Monday, July 25, 2011 6:54 AM > To: Ali C. Begen (abegen) > Cc: mmusic (E-mail); IETF AVTCore WG > Subject: Re: [AVTCORE] Comments on = draft-begen-mmusic-redundancy-grouping-01 >=20 > On 2011-07-24 23:21, Ali C. Begen (abegen) wrote: > > > > > >> -----Original Message----- From: avt-bounces@ietf.org > >> [mailto:avt-bounces@ietf.org] On Behalf Of Magnus Westerlund Sent: > >> Friday, July 22, 2011 8:39 AM To: mmusic (E-mail); IETF AVTCore WG > >> Subject: [AVTCORE] Comments on > >> draft-begen-mmusic-redundancy-grouping-01 > >> > >> Hi, > >> > >> (Primarily as individual, but the WG home question is as WG chair) > >> > >> I have reviewed this draft and some comments on it. > > > > Thanks for the review. > > > >> 1. If this solution proposal is to be taken forward I think it > >> needs to be discussed in AVTCORE. The reason is that it has several > >> RTP details that needs to be figured out to make stream duplication > >> issue free in a general usage. I will take up a few of these issues > >> in the below comments. > > > > That is why we asked for a slot in avtcore on wed. > > > >> 2. One aspect this document has is a relation to what is discussed > >> in draft-westerlund-avtcore-multistream-and-simulcast-00. Stream > >> duplication both results in a certain form of multi-stream and also > >> has a similar but slightly different semantics to simulcast in that > >> the streams are two representations of a single original media > >> source. In this case they are clones, but not true duplicates due > >> to that RTP doesn't handle try duplicates well. > > > > The data carried in the redundant streams are identical but the rtp > > header differs due to the different SSRCs. That is all. SSRC muxing > > nicely fits the use case we are tackling with. Simulcasting is quite > > different from our use case because in simulcasting different RTP > > streams most likely carry different data. >=20 > I agree that the purpose for multiple RTP streams from the same = original > media source are different from the primary case I set out to solve. = But > as Jonathan Lennox pointed out, redundancy and FEC have very similar > behaviors to simulcast with different encodings of the same original > source. >=20 > Thus, I do see a need to discuss for example how you identify the > streams that are a duplicate of each other. Ok, lets discuss it. My current proposal is to use different SSRCs. PTs = turn out to be different since I designate these streams in the same m = line. Unless I am mistakes, you cannot put two different streams with = the same PT in a single m line. Remember, we do not use PT to demux the = RTP streams, we use SSRC for that purpose. =20 > > > >> 3. Another issue that also the authors has identified is the > >> question of what one do when one has multiple media streams from > >> the same end-point. > > > >> From the same end-point (e.g., source) there could of course of > >> multiple media streams. You can use SSRC muxing for example to > >> identify your streams and use ssrc-group to group them if needed. > > > > The concern in that editorial note was what if there were multiple > > streams in each m line but what if you wanted grouping/association > > among only a subset. > > > > For example, > > > > m=3Dvideo 30000 RTP/AVP 101 102 .... m=3Dvideo 30000 RTP/AVP 103 104 > > > > I can easily associate 101 and 102 if I want to, but what if 101 and > > 103 were associated with each other. Can I use a=3Dgroup line? = Probably > > not. But, I don't know why you would need that kind of relation in > > the first place (even if you need, there are probably less messy = ways > > to express them). If that had been a very desirable feature, SDP and > > grouping semantics along with RTP would not have defined in their > > current form I guess. >=20 > Yes, that is a very valid question also for simulcast. >=20 > And I think we can provide a story for doing that. But I don't think = it > should be based on using the RTP payload type to identify either of = the > versions. >=20 > > > >> And in a general case one can't use the CNAME to separate the > >> sources. The reason is that two media sources that has a common > >> timing (synchronization) context do needs to indicate that by > >> having the same CNAME. Thus there are need for some additional > >> mechanism to ensure that > > > > If 101 and 103 are associated, why can't I use the same CNAME for > > those streams? If 102 and 104 are associated/related, I would use a > > common CNAME for them, too (but theirs would be separate from 101 = and > > 103's). >=20 > If SSRC A has a duplciation in SSRC C and SSRC B has a duplication in > SSRC D and both A and B comes from the same end-point and have a = common > synchronization context, then all of A-D needs to have the same CNAME. Well, above implies that all streams are coming from the same source and = yes, they will end up having the same CNAME since you required A will be = synched with B. But, still I think this is workable without any = additional mechanism. A and C would be in the same m line and B and D = would be in the same (but separate from the first) m line. That would = give me what I want. =20 > And I get the impression that you are using a payload type based > association scheme here. And I think that is a bad idea. For example = it > can't support particular many streams. It also looks semantically = wrong, > as if Stream A uses PT 96, then SSRC C should use PT 96 also for the > corresponding packet duplicates. And if A switches from one PT to > another the other stream needs to follow. No, I am not suggesting to use PT for demuxing. I use SSRC for that = purpose. As I asked above, if I can use the same PT for multiple streams = in the same m line, then I will. But I don=92t think I can. > Thus I think a SDES item based approach for indicating that it is in > fact A and C that are duplicates, rather than A and B or A and D. >=20 > > > >> SSRC carrying RTP media streams that are duplicates of each other > >> do in fact be labeled explicitly. I also note that a SDP based > >> solution is not sufficient to resolve this issue. I think we need > >> something in RTP, so that SSRC collisions can be handled. > > > > I can't say I am following. >=20 > I suggest that you use something like the SRCNAME SDES item extension = I > propose in my draft. >=20 > > > >> 4. In addition there is a few questions how this duplication > >> really should set some RTP fields. Is the duplication only working > >> on Sequence > > > > That is the easiest way for a middle box or endpoint doing the = stream > > merging (duplicate suppression). If seqnums are different, what = would > > one do? look into the payload? >=20 > It was simply that you had not documented what needs to be the same. I think I did, but I will check. > Sequence number being the same is likely the easiest, but one do have = to > raise some warning flags if one has processing that changes these > streams. For example a translator modifying the packetization must do > the exact same manipulation on the other stream. Yes, obviously. We can put this warning. =20 > But, I don't think anything else really works. Right, seqnum is the easiest and possibly the only way in practice. =20 > > > >> number level? There seem to be additional questions, for example in > >> the need to have RTP timestamp considerations between the streams. > >> They need to point identically into the joint timeline. Otherwise > >> outages, or receiver taking synch from one and not the other stream > >> can end up with different synchronizations. Becomes especially > >> interesting to discuss when the time shifted transmission. > > > > The duplicate streams are coming from the same source, so they have > > the same timestamp as well as seqnums. It has to be this way because > > the node merging the streams will not re-write anything at all. It = is > > a simple suppression operation. Beauty of it is that things stay > > pretty simple to use and implement without any changes to RTP/RTCP > > plane at all. >=20 > Yes, but you hadn't made it clear, and you have both SSRC and implied > change of PT. So I didn't want to assume anything. OK, will make this clear, as well. =20 > The timestamp field also have implcations due to its binding with RTCP > SR information. >=20 > > > > As for the time-shifted transmission, I suppose you are referring to > > the temporal diversity/delayed duplication > > (draft-begen-mmusic-temporal-interleaving-02). Well, in that case, > > timestamps are still the same for the reasons above. Changing the > > timestamps for the delayed packets does not bring any benefit > > (actually it complicates things) since the ultimate RTP application > > will still receive one and only one RTP stream. >=20 > Ok, but you will need to make clear on how one should set the RTCP SR > timestamp NTP mapping to be clear. And what that implies for the RTCP > jitter calculation. The fact that you are using delayed duplication or spatial diversity = means that you will likely introduce some jitter into your stream unless = the node merging the streams smooths out that jitter in the first place. = There is not nothing special for the ultimate endpoint for preparing the = reports, it just does what it is supposed to do. In most systems, the = ultimate RTP receivers might not be even aware of the fact that they are = receiving a stream merged from two identical streams. That is a design = feature. > > > >> 5. The draft also discussed Payload Type differences and have them > >> in the SDP examples. I don't see how that is appropriate. If the > >> streams > > > > When you are doing SSRC muxing, you put multiple streams in the same > > m line and they end up having different PT numbers. What is wrong > > with that? If they are in separate m lines, they could have the same > > PT number. >=20 > I am still asking why, there is no reason to use different PTs, unless > you are doing the association between the different streams by them > having different PTs. Which I believe is a Bad Idea (TM). The encoding > in the packet are the same, so why don't they have the same PT. Well again, I am not using it for demuxing purposes. I just believe that = is how the m line works. Tell me otherwise and I will be happy to make = PTs the same. =20 >=20 > > > >> 6. I think it is worth discussing also the benefits of SSRC > >> multiplexed versus the session multiplexed. In multicast context > >> there is clear benefits from a control and congestion perspective > >> to have session multiplexed versions and these mapped onto > >> different multicast groups enabling a receiver to choose one or > >> both streams. > > > > This is what we have in section 5.2. Different streams can be sent = in > > different multicast sessions but it does not mean that they are > > separate RTP sessions. I discussed this in detail with Colin. Thanks > > to him for trying to teach me over and over what an RTP session > > actually means. >=20 > Yes, you have an example, but not a discussion of why an implementor > should choose Session multiplexing over SSRC. I think that should be > included, or I think you can wait for the architectural document I = think > will result from my multi-stream and simulcast draft. Lets discuss in the session. =20 > > > >> 7. Thus I think the signalling aspects of this is the minor part. > >> Although there clearly are some aspects of this needing discussion. > >> For example clearer offer/answer rules for handling these. > > > > We have some text around O/A stuff. But frankly, I don=92t see any = use > > case where duplication will be used in a unicast application. I mean > > if redundancy is needed, one should use FEC instead for unicast > > transport. Duplication is a nice use case for multicast transport > > where the bw overhead is easier to justify and the implementation is > > easier. And one would naturally implement this spec in networks = where > > he already knows that the network elements support this spec. So, > > maybe we should remove the whole O/A text anyway and write that this > > will only be used declaratively. >=20 > Then, I think we should slap an application statement to the beginning > of the draft to ensure that it may only be used in multicast. For Wfm. > example b=3DTIAS was only intended to used in declarative SDPs, but it = has > become common in O/A, but it doesn't have clear rules. >=20 > So I think it imporant that one don't assume to much. Yes, it might = not > be the best idea for unicast, but that is not going to prevent it from > being used. If one really uses this for unicast, let them deal with all the = potential O/A problems that might surface. It is more like they will = deserve it :) Cheers, -acbegen =20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Mon Jul 25 09:12:36 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7AA411E817E; Mon, 25 Jul 2011 09:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.19 X-Spam-Level: X-Spam-Status: No, score=-106.19 tagged_above=-999 required=5 tests=[AWL=-0.191, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o3f-KBiWGc4J; Mon, 25 Jul 2011 09:12:34 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 6028021F8CA7; Mon, 25 Jul 2011 07:55:36 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-43-4e2d83e7cc96 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 36.C3.20773.7E38D2E4; Mon, 25 Jul 2011 16:55:35 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Mon, 25 Jul 2011 16:55:35 +0200 Message-ID: <4E2D83E5.4030100@ericsson.com> Date: Mon, 25 Jul 2011 10:55:33 -0400 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: <4E296F64.70500@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540F810C54@xmb-sjc-215.amer.cisco.com> <4E2D4B52.80900@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540F810C97@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540F810C97@xmb-sjc-215.amer.cisco.com> X-Enigmail-Version: 1.2 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "mmusic \(E-mail\)" , IETF AVTCore WG Subject: Re: [AVTCORE] Comments on draft-begen-mmusic-redundancy-grouping-01 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 16:12:36 -0000 On 2011-07-25 10:07, Ali C. Begen (abegen) wrote: > Ok, lets discuss it. My current proposal is to use different SSRCs. PTs turn out to be different since I designate these streams in the same m line. Unless I am mistakes, you cannot put two different streams with the same PT in a single m line. Remember, we do not use PT to demux the RTP streams, we use SSRC for that purpose. No, that is wrong. The PT is completely unrelated to to which SSRC that use them. The set of configured PTs can be used by any of the sources that transmit in the direction for which they are configured. I do include the direction because of the O/A aspects of having different configurations for receving in different directions. >> If SSRC A has a duplciation in SSRC C and SSRC B has a duplication >> in SSRC D and both A and B comes from the same end-point and have a >> common synchronization context, then all of A-D needs to have the >> same CNAME. > > Well, above implies that all streams are coming from the same source > and yes, they will end up having the same CNAME since you required A > will be synched with B. But, still I think this is workable without > any additional mechanism. A and C would be in the same m line and B > and D would be in the same (but separate from the first) m line. That > would give me what I want. I am not agreeing that you would put A and B in different sessions. This doesn't make sense if you actually like to provide two related media streams of the same type, for example two cameras covering different parts of a telepresence room, or two different camera angels in a movie. What you are suggesting seems to be a hack to just get around the issue that if you have streams that are some form of alternatives of the actual same original source then you need to identify, like the SRCNAME proposal. > >> And I get the impression that you are using a payload type based >> association scheme here. And I think that is a bad idea. For >> example it can't support particular many streams. It also looks >> semantically wrong, as if Stream A uses PT 96, then SSRC C should >> use PT 96 also for the corresponding packet duplicates. And if A >> switches from one PT to another the other stream needs to follow. > > No, I am not suggesting to use PT for demuxing. I use SSRC for that > purpose. As I asked above, if I can use the same PT for multiple > streams in the same m line, then I will. But I don’t think I can. > Yes, understand this is a different type of missunderstanding of RTP. >> >> Ok, but you will need to make clear on how one should set the RTCP >> SR timestamp NTP mapping to be clear. And what that implies for the >> RTCP jitter calculation. > > The fact that you are using delayed duplication or spatial diversity > means that you will likely introduce some jitter into your stream > unless the node merging the streams smooths out that jitter in the > first place. There is not nothing special for the ultimate endpoint > for preparing the reports, it just does what it is supposed to do. > In most systems, the ultimate RTP receivers might not be even aware > of the fact that they are receiving a stream merged from two > identical streams. That is a design feature. > When you talk about jitter here, you are talking about small transport level jitter, rather than jitter on the level of frame intervals. Sure, if you have a translator that merge these, then you clearly should be hidden to the end-point behind translator. >>>> 7. Thus I think the signalling aspects of this is the minor >>>> part. Although there clearly are some aspects of this needing >>>> discussion. For example clearer offer/answer rules for handling >>>> these. >>> >>> We have some text around O/A stuff. But frankly, I don’t see any >>> use case where duplication will be used in a unicast application. >>> I mean if redundancy is needed, one should use FEC instead for >>> unicast transport. Duplication is a nice use case for multicast >>> transport where the bw overhead is easier to justify and the >>> implementation is easier. And one would naturally implement this >>> spec in networks where he already knows that the network elements >>> support this spec. So, maybe we should remove the whole O/A text >>> anyway and write that this will only be used declaratively. >> >> Then, I think we should slap an application statement to the >> beginning of the draft to ensure that it may only be used in >> multicast. For > > Wfm. > >> example b=TIAS was only intended to used in declarative SDPs, but >> it has become common in O/A, but it doesn't have clear rules. >> >> So I think it imporant that one don't assume to much. Yes, it might >> not be the best idea for unicast, but that is not going to prevent >> it from being used. > > If one really uses this for unicast, let them deal with all the > potential O/A problems that might surface. It is more like they will > deserve it :) > :-) Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From mramalho@cisco.com Mon Jul 25 10:56:06 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF9621F8BD1; Mon, 25 Jul 2011 10:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.178 X-Spam-Level: X-Spam-Status: No, score=-0.178 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2kNDa-7KuZz; Mon, 25 Jul 2011 10:56:04 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 99C7C21F8B7F; Mon, 25 Jul 2011 10:56:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mramalho@cisco.com; l=11450; q=dns/txt; s=iport; t=1311616564; x=1312826164; h=mime-version:subject:date:message-id:from:to; bh=KZSx7MZ33bJTSHZ6lKB11Ze4gKXC8yVXH/znNZwYheM=; b=LeAHbrdTlLn9wWHSS8OErmN087hnjsUFYiHu7DDydDaWrNo1u8nMmgzI HWnZlkrjglDQQavu7OMkC4uaRuPIE1Q5z90vYIhC8bEatAm/JNi0M9eBc pFeoCSrMsrzgLACrqbGzwRSzDuq5W0Nyw7g2sRS5O6y3dN7OFfAmIsRlc c=; X-Files: image001.gif : 837 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFADmtLU6tJV2c/2dsb2JhbAA2AQEDBQ8BDAoIAQI6JAQBJgEBAwYPFAEHAQUNBAEHAgkkFwEFARUBCgIbgjakfHeqZZ4ZAoM7giNfBIdVg0GCYYoJi24 X-IronPort-AV: E=Sophos;i="4.67,263,1309737600"; d="gif'147?scan'147,208,217,147";a="6206983" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP; 25 Jul 2011 17:56:04 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p6PHu4oU018874; Mon, 25 Jul 2011 17:56:04 GMT Received: from xmb-rcd-209.cisco.com ([72.163.62.216]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 25 Jul 2011 12:56:03 -0500 X-Mimeole: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: DTNW EO41 FxPH GjGs J5WL Os6u Py1x SVRg U+DP YY6y ZG4x Z7yI dQYM dWo+ eDA3 fimX; 3; YQB2AHQAQABpAGUAdABmAC4AbwByAGcAOwBhAHYAdABlAHgAdABAAGkAZQB0AGYALgBvAHIAZwA7AHAAYQB5AGwAbwBhAGQAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {8AD51F7B-5C7F-4DC9-8806-E319DC357319}; bQByAGEAbQBhAGwAaABvAEAAYwBpAHMAYwBvAC4AYwBvAG0A; Mon, 25 Jul 2011 17:55:56 GMT; ZAByAGEAZgB0AC0AcgBhAG0AYQBsAGgAbwAtAHAAYQB5AGwAbwBhAGQALQBnADcAMQAxADAALQAwADAAIAB0AG8AIABiAGUAIABkAGkAcwBjAHUAcwBzAGUAZAAgAGkAbgAgAEEAVgBUAEUAWABUAA== MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CC4AF4.1E89FDC9" x-cr-puzzleid: {8AD51F7B-5C7F-4DC9-8806-E319DC357319} Content-class: urn:content-classes:message Date: Mon, 25 Jul 2011 12:55:56 -0500 Message-ID: <999109E6BC528947A871CDEB5EB908A00444F743@XMB-RCD-209.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ramalho-payload-g7110-00 to be discussed in AVTEXT Thread-Index: AcxK9Bp9BfwrLmXySG2KIyD5u4pbDw== From: "Michael Ramalho (mramalho)" To: "IETF AVTCore WG" , , X-OriginalArrivalTime: 25 Jul 2011 17:56:03.0342 (UTC) FILETIME=[1EA3AAE0:01CC4AF4] Subject: [AVTCORE] draft-ramalho-payload-g7110-00 to be discussed in AVTEXT X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 17:56:06 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC4AF4.1E89FDC9 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CC4AF4.1E89FDC9" ------_=_NextPart_002_01CC4AF4.1E89FDC9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [Apologies for cross posting AVT lists - reason below] =20 All, =20 I will be discussing issues contained in draft-ramalho-payload g7110-00 at the AVT extensions timeslot on Wednesday afternoon. =20 This draft is a payload WG draft, but there isn't a payload meeting at IETF 81. And this draft was previously scheduled to be discussed the AVT core timeslot prior to its being moved to AVTEXT (thus the reason for the cross post to all AVT groups). Roni and Ali encouraged me to say a few words prior to the discussion this week. =20 G.711.0 is a stateless and lossless compression of G.711 VoIP RTP payloads. Thus it is a compression algorithm tailored for G.711. When negotiated end-to-end it is negotiated "as if it were a codec". =20 However, being lossless and stateless, G.711.0 can be applied anywhere within an end-to-end G.711 negotiated session. When applied in this manner, it suffers no voice quality degradation relative to G.711 (duh, its lossless). =20 Most of the open issues in the draft relate to the use of G.711.0 within the context of an and-to-end G.711 negotiated session. =20 I look forward to comments generated from the discussion of this draft for those cases. =20 Regards, =20 Michael Ramalho =20 =20 Michael Ramalho Technical Leader Product Development mramalho@cisco.com =20 Phone: +1 919 476 2038 Mobile: +1 941 544 2844 Cisco Systems, Inc. 4564 Tuscana Drive Sarasota, FL 34241-4201 United States http://ramalho.webhop.info Skype: mramalho_mar42 =20 =20 =09 =09 =20 =20 ------_=_NextPart_002_01CC4AF4.1E89FDC9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

[Apologies for cross posting AVT lists – = reason below]

 

All,

 

I will be discussing issues contained in = draft-ramalho-payload g7110-00 at the AVT extensions timeslot on Wednesday = afternoon.

 

This draft is a payload WG draft, but there = isn’t a payload meeting at IETF 81. And this draft was previously scheduled to = be discussed  the AVT core timeslot prior to its being moved to AVTEXT = (thus the reason for the cross post to all AVT groups). Roni and Ali encouraged me = to say a few words prior to the discussion this week.

 

G.711.0 is a stateless and lossless compression of = G.711 VoIP RTP payloads. Thus it is a compression algorithm tailored for G.711. = When negotiated end-to-end it is negotiated “as if it were a = codec”.

 

However, being lossless and stateless, G.711.0 can = be applied anywhere within an end-to-end G.711 negotiated session. When = applied in this manner, it suffers no voice quality degradation relative to G.711 = (duh, its lossless).

 

Most of the open issues in the draft relate to the = use of G.711.0 within the context of an and-to-end G.711 negotiated = session.

 

I look forward to comments generated from the = discussion of this draft for those cases.

 

Regards,

 

Michael Ramalho

 

3D"http://www.cisco.com/swa/i/logo.gif"

= Michael Ramalho
Technical Leader
Product Development
mramalho@cisco.com
Phone: +1 919 476 2038
Mobile: +1 941 544 2844

= Cisco Systems, Inc.
4564 Tuscana Drive
Sarasota, FL 34241-4201
United States
http://ramalho.webhop.info
Skype: mramalho_mar42

 

 

 

 

------_=_NextPart_002_01CC4AF4.1E89FDC9-- ------_=_NextPart_001_01CC4AF4.1E89FDC9 Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.gif Content-Location: image001.gif R0lGODlhbgBJAMQAAP///3OXqtapqq1MTcmRki9mgZkAALpqbMl/f6g5O/Xq6+vX2OTIyaMqK/nz 9OW/v5sVFsbV3Nfh5p0PD5kFBf78/P38/Pz6+v/+/rZdXpcKDKAhIvv396QvMO/g4Ny4uSH5BAAA AAAALAAAAABuAEkAQAX/ICCOZGmeaKqubOu+cCzPdG3feK6nkln8pp5LSPoVgrucsbQsAp1HKPM5 alapImtyy+16SwKDmJBCiBEWgMUsPgg8JMHEQCGTMACP2HDgiBQZYglfOQ+GDy2HhiqKKI2EkJGS k5SVlpeYmZpfWkpYmypEV1GjU6QjolmfnZ0AqZWvrj6fski2UiWxsZkcHxkNYg0IABUibAjFIgsH wAYNBwokvb8QEMIOJAwICQYQCQgLoCgLHWIdHwoKCwzExmdpGBwcxRgDYhkXAOTm6OoMfg4CiRGg wAOBOXzEKVzIsKHDhxAjSpxIsaKNCAEibMGo0WKLVjdAVgxQIICpEiRN/7JIeZIEy4WsVsk8BSAm TZstLb0csVMVzZ4AgALtJLQkRY4bM3pcupDAHgMduA1Q484AGmJO7x04kCCaCAIaxFCISmGAVwZP u+1pEK5hVgPYUBxLQ4yBvacfvlIwMCFuCbRi2I34sHfDQ0BpDUyFNxfABTZPGwgGACjsU7MiLLx9 ukEA08+gQ4seTbq06dOoU6tezbq169evd92QHRooDtujRdbQDZr3DN8RkeIaIXxFcZ8ljkPEOVwF 81ILlT9HTkL6zJwilE+aXvN68+43vUO3xL28eOrj0VdSbp0me6XV4acH8L6jRNw28IumXYM/7P8k PJLIISkIWIKBD3GwmcIYiwGAQWP6cJMWHCIoCEFamInwQTNPdYCIQwqUM8YCC3zgWTKNOXAAg14p kA9lIkJAAIkmYsPBim0YcsBeVjn0llcnQAjYHh14phdfQGazx2QAEGaAYQ2FMVAZ75BggTZ7HFCM HHQYWcICeyAjgormPASZYgN00CAAjV0gwAEEEACZlsbwCMEAaWb4wFMJJMDjBkwypAABErbRzoNn FFPBghnkRcKgCVimwQF+VSDAXXw1CuCmnHbq6aeghirqqDiEAAA7 ------_=_NextPart_001_01CC4AF4.1E89FDC9-- From ray.vanbrandenburg@tno.nl Tue Jul 26 15:31:54 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD05521F8749 for ; Tue, 26 Jul 2011 15:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.079 X-Spam-Level: *** X-Spam-Status: No, score=3.079 tagged_above=-999 required=5 tests=[AWL=3.582, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4HCDjis5GXN2 for ; Tue, 26 Jul 2011 15:31:54 -0700 (PDT) Received: from mailoutb.tno.nl (mailoutb.tno.nl [134.221.1.17]) by ietfa.amsl.com (Postfix) with ESMTP id CFA4921F86AE for ; Tue, 26 Jul 2011 15:31:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.67,272,1309730400"; d="scan'208,217";a="12878616" Received: from unknown (HELO mail.tno.nl) ([134.221.225.221]) by mailhost1b.tno.nl with ESMTP; 27 Jul 2011 00:31:52 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.211]) by EXC-CASHUB02.tsn.tno.nl ([134.221.225.221]) with mapi id 14.01.0289.001; Wed, 27 Jul 2011 00:31:53 +0200 From: "Brandenburg, R. (Ray) van" To: "'magnus.westerlund@ericsson.com'" Thread-Topic: Comments on draft-westerlund-avtcore-multistream-and-simulcast-00 Thread-Index: AcxL47A/4Qxg7DIaQ0yT8qSx81XM7A== Date: Tue, 26 Jul 2011 22:31:51 +0000 Message-ID: Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.191] Content-Type: multipart/alternative; boundary="_000_FCC100FC8D6B034CB88CD8173B2DA1580AF452D6EXCMBX03tsntnon_" MIME-Version: 1.0 Cc: "'avt@ietf.org'" Subject: [AVTCORE] Comments on draft-westerlund-avtcore-multistream-and-simulcast-00 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 22:31:55 -0000 --_000_FCC100FC8D6B034CB88CD8173B2DA1580AF452D6EXCMBX03tsntnon_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Magnus, Reading your draft 'RTP Multiple Stream Sessions and Simulcast', I was wond= ering whether the proposed simulcast extensions could allow for RTP to be u= sed for the delivery of spatially segmented content. Spatial segmentation is the concept of spatially dividing a video up into m= ultiple segments, each being independently decodable. It can for example be= used to efficiently deliver video to clients who are only interested in sp= ecific areas of a video. Such bandwidth-saving are especially important whe= n dealing with extremely high resolutions. Depending on the application, the recombination of segments into a single v= ideo might take place on the client or on a network node (such as an RTP mi= xer). Your simulcast extensions might be a good way to more effectively dea= l with the large number of segment streams being received by such a node. I think it would be interesting to see whether we can expand the scope of y= our draft to include the specific properties of spatially segmented content. Cheers, Ray van Brandenburg This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer --_000_FCC100FC8D6B034CB88CD8173B2DA1580AF452D6EXCMBX03tsntnon_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Magnus,

 

Reading your draft 'RTP Multiple Stream Sessions and Simulcast', I = was wondering whether the proposed simulcast extensions could allow for RTP to be used for the delivery of spatially segmented content. =

 

Spatial segmentation is the concept of spatially dividing a video u= p into multiple segments, each being independently decodable. It can for example be used to efficiently deliver video to clients who are= only interested in specific areas of a video. Such bandwidth-saving are es= pecially important when dealing with extremely high resolutions.

 

Depending on the application, the recombination of segments into a = single video might take place on the client or on a network node (such as an RTP mixer). Your simulcast extensions might be a good way= to more effectively deal with the large number of segment streams being re= ceived by such a node.

 

I think it would be interesting to see whether we can expand the sc= ope of your draft to include the specific properties of spatially segmented content.

 

Cheers,=

&n= bsp;

Ray van Brandenburg=

This e-mail and its contents are subject to the DI= SCLAIMER at http://www.tno.nl/emaildisclaimer --_000_FCC100FC8D6B034CB88CD8173B2DA1580AF452D6EXCMBX03tsntnon_-- From stephen.botzko@gmail.com Tue Jul 26 19:19:27 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49D1F21F8AC9 for ; Tue, 26 Jul 2011 19:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.39 X-Spam-Level: X-Spam-Status: No, score=-3.39 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mu-sdIE7c3pZ for ; Tue, 26 Jul 2011 19:19:26 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7DD4921F8AC3 for ; Tue, 26 Jul 2011 19:19:26 -0700 (PDT) Received: by vws12 with SMTP id 12so984308vws.31 for ; Tue, 26 Jul 2011 19:19:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Zc9K4ZOxYLt7ZFwK0vDaARH6ii63+RbbZc533HOyr1c=; b=B+/mGuWEgwAioHcnF85F8wMFeyh2RQWtqUuX0syE86JwoT8YrheDIlhTCkhDyNG48L vNXrrL5cE27PXAyQtT3zXnBtVE5TMj1BqqQYR+lAD0BNHwlVS20xh0NBofP5IXGP8hx0 vouIFVxMkFDZjXV73WRjRpNp5EdPiFvzX/UiE= MIME-Version: 1.0 Received: by 10.52.116.67 with SMTP id ju3mr6544207vdb.63.1311733165833; Tue, 26 Jul 2011 19:19:25 -0700 (PDT) Received: by 10.52.185.71 with HTTP; Tue, 26 Jul 2011 19:19:25 -0700 (PDT) In-Reply-To: References: Date: Tue, 26 Jul 2011 22:19:25 -0400 Message-ID: From: Stephen Botzko To: "Brandenburg, R. (Ray) van" Content-Type: multipart/alternative; boundary=bcaec548aa5963bd1704a903ad8d Cc: "magnus.westerlund@ericsson.com" , "avt@ietf.org" Subject: Re: [AVTCORE] Comments on draft-westerlund-avtcore-multistream-and-simulcast-00 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 02:19:27 -0000 --bcaec548aa5963bd1704a903ad8d Content-Type: text/plain; charset=ISO-8859-1 Such spatial relationships are CLUE's scope. On Tue, Jul 26, 2011 at 6:31 PM, Brandenburg, R. (Ray) van < ray.vanbrandenburg@tno.nl> wrote: > Hi Magnus,**** > > ** ** > > Reading your draft 'RTP Multiple Stream Sessions and Simulcast', I was > wondering whether the proposed simulcast extensions could allow for RTP to > be used for the delivery of spatially segmented content. **** > > ** ** > > Spatial segmentation is the concept of spatially dividing a video up into > multiple segments, each being independently decodable. It can for example be > used to efficiently deliver video to clients who are only interested in > specific areas of a video. Such bandwidth-saving are especially important > when dealing with extremely high resolutions. **** > > ** ** > > Depending on the application, the recombination of segments into a single > video might take place on the client or on a network node (such as an RTP > mixer). Your simulcast extensions might be a good way to more effectively > deal with the large number of segment streams being received by such a node. > **** > > ** ** > > I think it would be interesting to see whether we can expand the scope of > your draft to include the specific properties of spatially segmented > content.**** > > ** ** > > Cheers,**** > > ** ** > > Ray van Brandenburg**** > This e-mail and its contents are subject to the DISCLAIMER at > http://www.tno.nl/emaildisclaimer > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > > --bcaec548aa5963bd1704a903ad8d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Such spatial relationships are CLUE's scope.

On Tue, Jul 26, 2011 at 6:31 PM, Brandenburg, R. (Ray) van <ray.vanbrandenbu= rg@tno.nl> wrote:

Hi Magnus,

=A0

Reading your draft 'RTP Multiple Stream Sessi= ons and Simulcast', I was wondering whether the proposed simulcast exte= nsions could allow for RTP to be used for the delivery of spatially segmented content. =

=A0

Spatial segmentation is the concept of spatially = dividing a video up into multiple segments, each being independently decoda= ble. It can for example be used to efficiently deliver video to clients who are= only interested in specific areas of a video. Such bandwidth-saving are es= pecially important when dealing with extremely high resolutions.

=A0

Depending on the application, the recombination o= f segments into a single video might take place on the client or on a netwo= rk node (such as an RTP mixer). Your simulcast extensions might be a good way= to more effectively deal with the large number of segment streams being re= ceived by such a node.

=A0

I think it would be interesting to see whether we= can expand the scope of your draft to include the specific properties of s= patially segmented content.

=A0

Cheers,

=A0

Ray van Brandenburg=

This e-mail and its contents are subject to the DI= SCLAIMER at http://www.tno.nl/emaildisclaimer

_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/avt


--bcaec548aa5963bd1704a903ad8d-- From adam@nostrum.com Wed Jul 27 06:37:59 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CA7521F8B09 for ; Wed, 27 Jul 2011 06:37:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.456 X-Spam-Level: X-Spam-Status: No, score=-102.456 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1pXBEahkALTT for ; Wed, 27 Jul 2011 06:37:58 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 52E1721F8B0C for ; Wed, 27 Jul 2011 06:37:58 -0700 (PDT) Received: from dhcp-1418.meeting.ietf.org (dhcp-1418.meeting.ietf.org [130.129.20.24]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p6RDbu8i040817 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 27 Jul 2011 08:37:56 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4E3014B4.3020506@nostrum.com> Date: Wed, 27 Jul 2011 09:37:56 -0400 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "AVT (Audio/Video Transport) WG" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.20.24 is authenticated by a trusted mechanism) Subject: [AVTCORE] Media Types Registry X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 13:37:59 -0000 I'm not entirely sure what consensus the chairs took away from the room regarding the "RTP Payload Format media types" IANA registry, but I do want to make sure we consider the following before we call the topic resolved: Has anyone asked Steve Casner? I would appear that he put in the work to get an RFC published on the topic as recently as four years ago. This isn't an easy task, so I would assume he had some pretty good reasons for putting in the effort. I imagine that those reasons would be very relevant input to this conversation. /a From ray.vanbrandenburg@tno.nl Wed Jul 27 07:38:33 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA6821F861A for ; Wed, 27 Jul 2011 07:38:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.363 X-Spam-Level: ** X-Spam-Status: No, score=2.363 tagged_above=-999 required=5 tests=[AWL=2.866, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eLegnQggvut0 for ; Wed, 27 Jul 2011 07:38:32 -0700 (PDT) Received: from mailouta.tno.nl (mailouta.tno.nl [134.221.1.16]) by ietfa.amsl.com (Postfix) with ESMTP id BE06921F8610 for ; Wed, 27 Jul 2011 07:38:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.67,276,1309730400"; d="scan'208,217";a="55466477" Received: from unknown (HELO mail.tno.nl) ([134.221.225.221]) by mailhost1a.tno.nl with ESMTP; 27 Jul 2011 16:38:30 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.211]) by EXC-CASHUB02.tsn.tno.nl ([134.221.225.221]) with mapi id 14.01.0289.001; Wed, 27 Jul 2011 16:38:29 +0200 From: "Brandenburg, R. (Ray) van" To: Stephen Botzko Thread-Topic: [AVTCORE] Comments on draft-westerlund-avtcore-multistream-and-simulcast-00 Thread-Index: AcxL47A/4Qxg7DIaQ0yT8qSx81XM7AADybeAAB1ZLsA= Date: Wed, 27 Jul 2011 14:38:27 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.191] Content-Type: multipart/alternative; boundary="_000_FCC100FC8D6B034CB88CD8173B2DA1580AF45651EXCMBX03tsntnon_" MIME-Version: 1.0 Cc: "magnus.westerlund@ericsson.com" , "avt@ietf.org" Subject: Re: [AVTCORE] Comments on draft-westerlund-avtcore-multistream-and-simulcast-00 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 14:38:33 -0000 --_000_FCC100FC8D6B034CB88CD8173B2DA1580AF45651EXCMBX03tsntnon_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Let me further clarify what I mean by spatial segmentation. In the most general case, you would have a single camera source that record= s in a very high resolution (e.g. 4K or higher). Instead of encoding the re= corded images as a single video stream, the camera spatially segments each = video frame and encodes the results into multiple video streams (e.g. 4 or = 16) each representing a specific area of the recorded video. The result wou= ld be an RTP sender that makes available 16 separate streams. Depending on the area a user is interested in (the region-of-interest), an = RTP receiver (or mixer) would set up one or more sessions to receive the on= e or more streams that are necessary to reconstruct the desired region-of-i= nterest. The result would be that different RTP receivers would simultaneou= sly receive different subsets of the available segment streams. While some of the desired functionality might lie in the CLUE area (which I= must admit I am not that familiar with), I think there is a considerable o= verlap with the use cases described in the Multistream/Simulcast draft. Cheers, Ray van Brandenburg From: Stephen Botzko [mailto:stephen.botzko@gmail.com] Sent: woensdag 27 juli 2011 4:19 To: Brandenburg, R. (Ray) van Cc: magnus.westerlund@ericsson.com; avt@ietf.org Subject: Re: [AVTCORE] Comments on draft-westerlund-avtcore-multistream-and= -simulcast-00 Such spatial relationships are CLUE's scope. On Tue, Jul 26, 2011 at 6:31 PM, Brandenburg, R. (Ray) van > wrote: Hi Magnus, Reading your draft 'RTP Multiple Stream Sessions and Simulcast', I was wond= ering whether the proposed simulcast extensions could allow for RTP to be u= sed for the delivery of spatially segmented content. Spatial segmentation is the concept of spatially dividing a video up into m= ultiple segments, each being independently decodable. It can for example be= used to efficiently deliver video to clients who are only interested in sp= ecific areas of a video. Such bandwidth-saving are especially important whe= n dealing with extremely high resolutions. Depending on the application, the recombination of segments into a single v= ideo might take place on the client or on a network node (such as an RTP mi= xer). Your simulcast extensions might be a good way to more effectively dea= l with the large number of segment streams being received by such a node. I think it would be interesting to see whether we can expand the scope of y= our draft to include the specific properties of spatially segmented content= . Cheers, Ray van Brandenburg This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer _______________________________________________ Audio/Video Transport Core Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt --_000_FCC100FC8D6B034CB88CD8173B2DA1580AF45651EXCMBX03tsntnon_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Let me fur= ther clarify what I mean by spatial segmentation.

 = ;

In the mos= t general case, you would have a single camera source that records in a ver= y high resolution (e.g. 4K or higher). Instead of encoding the recorded images as a single video stream, the camera spatially segment= s each video frame and encodes the results into multiple video streams (e.g= . 4 or 16) each representing a specific area of the recorded video. The res= ult would be an RTP sender that makes available 16 separate streams.

 = ;

Depending = on the area a user is interested in (the region-of-interest), an RTP receiv= er (or mixer) would set up one or more sessions to receive the one or more streams that are necessary to reconstruct the desired regi= on-of-interest. The result would be that different RTP receivers would simu= ltaneously receive different subsets of the available segment streams.=

 = ;

While some= of the desired functionality might lie in the CLUE area (which I must admi= t I am not that familiar with), I think there is a considerable overlap with the use cases described in the Multistream/Simulcast draft. <= o:p>

 = ;

Cheers,

 = ;

Ray van Br= andenburg

 = ;

 = ;

From: Stephen Botzko [mailto:stephen.botzko@gmail.com]
Sent: woensdag 27 juli 2011 4:19
To: Brandenburg, R. (Ray) van
Cc: magnus.westerlund@ericsson.com; avt@ietf.org
Subject: Re: [AVTCORE] Comments on draft-westerlund-avtcore-multistr= eam-and-simulcast-00

 

Such spatial relation= ships are CLUE's scope.

On Tue, Jul 26, 2011 at 6:31 PM, Brandenburg, R. (Ra= y) van <ray.vanbrandenburg@= tno.nl> wrote:

Hi Magnus,

 

Reading your draft 'RTP Multiple Stream Sessions and S= imulcast', I was wondering whether the proposed simulcast extensions could = allow for RTP to be used for the delivery of spatially segmented content.

 

Spatial segmentation is the concept of spatially divid= ing a video up into multiple segments, each being independently decodable. = It can for example be used to efficiently deliver video to clients who are = only interested in specific areas of a video. Such bandwidth-saving are especially important when dealing wi= th extremely high resolutions.

 

Depending on the application, the recombination of seg= ments into a single video might take place on the client or on a network no= de (such as an RTP mixer). Your simulcast extensions might be a good way to= more effectively deal with the large number of segment streams being received by such a node.=

 

I think it would be interesting to see whether we can = expand the scope of your draft to include the specific properties of spatia= lly segmented content.

 

Cheers,

 

Ray van Brandenburg

= This e-mail and its contents are subject to the DISCLAIMER at http://www.= tno.nl/emaildisclaimer


_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/avt

 

--_000_FCC100FC8D6B034CB88CD8173B2DA1580AF45651EXCMBX03tsntnon_-- From casner@acm.org Wed Jul 27 08:36:46 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF2721F89C2 for ; Wed, 27 Jul 2011 08:36:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jE4JvAugYKT1 for ; Wed, 27 Jul 2011 08:36:45 -0700 (PDT) Received: from mailman.packetdesign.com (firewall-gw-dirty-u.packetdesign.com [65.192.41.2]) by ietfa.amsl.com (Postfix) with ESMTP id E3D9F21F891F for ; Wed, 27 Jul 2011 08:36:44 -0700 (PDT) Received: from packetdesign.com (vpn-int.packetdesign.com [192.168.0.180]) by mailman.packetdesign.com (8.13.1/8.13.1) with ESMTP id p6RFaZvc028833; Wed, 27 Jul 2011 08:36:36 -0700 Date: Wed, 27 Jul 2011 08:36:35 -0700 (PDT) From: Stephen Casner To: Adam Roach In-Reply-To: <4E3014B4.3020506@nostrum.com> Message-ID: References: <4E3014B4.3020506@nostrum.com> User-Agent: Alpine 1.10 (OSX 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: "AVT \(Audio/Video Transport\) WG" Subject: Re: [AVTCORE] Media Types Registry X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 15:36:46 -0000 What was the question? -- Steve On Wed, 27 Jul 2011, Adam Roach wrote: > I'm not entirely sure what consensus the chairs took away from the room > regarding the "RTP Payload Format media types" IANA registry, but I do want to > make sure we consider the following before we call the topic resolved: > > Has anyone asked Steve Casner? > > I would appear that he put in the work to get an RFC published on the topic as > recently as four years ago. This isn't an easy task, so I would assume he had > some pretty good reasons for putting in the effort. I imagine that those > reasons would be very relevant input to this conversation. > > /a > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From Even.roni@huawei.com Wed Jul 27 09:26:47 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C357811E80F6 for ; Wed, 27 Jul 2011 09:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.449 X-Spam-Level: X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UzLmRf1Ea6gv for ; Wed, 27 Jul 2011 09:26:47 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id BB71611E810D for ; Wed, 27 Jul 2011 09:26:46 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LP0005H230HLK@szxga05-in.huawei.com> for avt@ietf.org; Thu, 28 Jul 2011 00:26:41 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LP0007XM30GXQ@szxga05-in.huawei.com> for avt@ietf.org; Thu, 28 Jul 2011 00:26:41 +0800 (CST) Received: from windows8d787f9 (dhcp-17b3.meeting.ietf.org [130.129.23.179]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LP00037M30CY3@szxml12-in.huawei.com>; Thu, 28 Jul 2011 00:26:40 +0800 (CST) Date: Wed, 27 Jul 2011 19:23:56 +0300 From: Roni Even In-reply-to: To: 'Stephen Casner' , 'Adam Roach' Message-id: <002501cc4c79$97d193b0$c774bb10$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcxMcw0AuPX0vzMkRt+q6B0EzhjmnAABVgBQ References: <4E3014B4.3020506@nostrum.com> Cc: "'AVT \(Audio/Video Transport\) WG'" Subject: Re: [AVTCORE] Media Types Registry X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 16:26:47 -0000 Hi Steve, We got a question from IANA about RTP Payload Format media types (http://www.iana.org/assignments/rtp-parameters ) registry which is not current and is not well maintained. The payload subtype are registered in the main registry that avoids collision etc. http://www.iana.org/assignments/media-types/index.html . The question was if we see value in keeping it since the uniqueness is based on the main registry. We were not sure why it was created and how it was supposed to be updated. We have two choices, update it and define the procedure to keep it current or cancel it. Regards Roni Even RTP Payload Types are identified by Media Types: The main registry that avoids collision etc. http://www.iana.org/assignments/media-types/index.html Registration in this registry is required, and works as intended There is a second registry: RTP Payload Format media types http://www.iana.org/assignments/rtp-parameters This registry is intended to contain all media types that have RTP Payload formats The issue with the second registry: Poorly maintained, and a lot of formats are missing Limited extra value, only usable if you want to know all RTP payload formats Unknown that it exist > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > Stephen Casner > Sent: Wednesday, July 27, 2011 6:37 PM > To: Adam Roach > Cc: AVT (Audio/Video Transport) WG > Subject: Re: [AVTCORE] Media Types Registry > > What was the question? > > -- Steve > > On Wed, 27 Jul 2011, Adam Roach wrote: > > > I'm not entirely sure what consensus the chairs took away from the > room > > regarding the "RTP Payload Format media types" IANA registry, but I > do want to > > make sure we consider the following before we call the topic > resolved: > > > > Has anyone asked Steve Casner? > > > > I would appear that he put in the work to get an RFC published on the > topic as > > recently as four years ago. This isn't an easy task, so I would > assume he had > > some pretty good reasons for putting in the effort. I imagine that > those > > reasons would be very relevant input to this conversation. > > > > /a > > _______________________________________________ > > Audio/Video Transport Core Maintenance > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From stephen.botzko@gmail.com Wed Jul 27 10:14:46 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C32322800E for ; Wed, 27 Jul 2011 10:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.32 X-Spam-Level: X-Spam-Status: No, score=-3.32 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CnDHzF9wwOn6 for ; Wed, 27 Jul 2011 10:14:45 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id BAF99228006 for ; Wed, 27 Jul 2011 10:14:44 -0700 (PDT) Received: by vxi40 with SMTP id 40so1656054vxi.31 for ; Wed, 27 Jul 2011 10:14:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OTrFxL1SA8x8kPCPJWDOVl3MJusXOvXYS8cQ8Avifzg=; b=JNI0+YXEXdCzR17bfZRg+96WHvpbFL9mf6zWjFLURL93MwupOPYg3ZG2pQyVyysXYx XRYHJKnYZkJxYx1Ir9X0OyQ3iM6jAA4tV/k99kg5Ng5Mwq9nNhSZ0x9go9jxRA6cM70A 2AzSBPmvWNxmartIYfmBTCn7LR+WHT+1FJFv8= MIME-Version: 1.0 Received: by 10.52.179.230 with SMTP id dj6mr76683vdc.130.1311786884123; Wed, 27 Jul 2011 10:14:44 -0700 (PDT) Received: by 10.52.185.71 with HTTP; Wed, 27 Jul 2011 10:14:44 -0700 (PDT) In-Reply-To: References: Date: Wed, 27 Jul 2011 13:14:44 -0400 Message-ID: From: Stephen Botzko To: "Brandenburg, R. (Ray) van" Content-Type: multipart/alternative; boundary=bcaec5014ba93fcd4604a9102f0b Cc: "magnus.westerlund@ericsson.com" , "avt@ietf.org" Subject: Re: [AVTCORE] Comments on draft-westerlund-avtcore-multistream-and-simulcast-00 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 17:14:46 -0000 --bcaec5014ba93fcd4604a9102f0b Content-Type: text/plain; charset=ISO-8859-1 Defining spatial relationships between RTP video sources is one reason CLUE was formed. Although Magnus explicitly used a telepresence system as one of his use cases this morning, he made it clear that the side information needed to define the spatial relationships was not part of his intended scope. Stephen Botzko On Wed, Jul 27, 2011 at 10:38 AM, Brandenburg, R. (Ray) van < ray.vanbrandenburg@tno.nl> wrote: > Let me further clarify what I mean by spatial segmentation. **** > > ** ** > > In the most general case, you would have a single camera source that > records in a very high resolution (e.g. 4K or higher). Instead of encoding > the recorded images as a single video stream, the camera spatially segments > each video frame and encodes the results into multiple video streams (e.g. 4 > or 16) each representing a specific area of the recorded video. The result > would be an RTP sender that makes available 16 separate streams.**** > > ** ** > > Depending on the area a user is interested in (the region-of-interest), an > RTP receiver (or mixer) would set up one or more sessions to receive the one > or more streams that are necessary to reconstruct the desired > region-of-interest. The result would be that different RTP receivers would > simultaneously receive different subsets of the available segment streams. > **** > > ** ** > > While some of the desired functionality might lie in the CLUE area (which I > must admit I am not that familiar with), I think there is a considerable > overlap with the use cases described in the Multistream/Simulcast draft. * > *** > > ** ** > > Cheers,**** > > ** ** > > Ray van Brandenburg**** > > ** ** > > ** ** > > *From:* Stephen Botzko [mailto:stephen.botzko@gmail.com] > *Sent:* woensdag 27 juli 2011 4:19 > *To:* Brandenburg, R. (Ray) van > *Cc:* magnus.westerlund@ericsson.com; avt@ietf.org > *Subject:* Re: [AVTCORE] Comments on > draft-westerlund-avtcore-multistream-and-simulcast-00**** > > ** ** > > Such spatial relationships are CLUE's scope.**** > > On Tue, Jul 26, 2011 at 6:31 PM, Brandenburg, R. (Ray) van < > ray.vanbrandenburg@tno.nl> wrote:**** > > Hi Magnus,**** > > **** > > Reading your draft 'RTP Multiple Stream Sessions and Simulcast', I was > wondering whether the proposed simulcast extensions could allow for RTP to > be used for the delivery of spatially segmented content. **** > > **** > > Spatial segmentation is the concept of spatially dividing a video up into > multiple segments, each being independently decodable. It can for example be > used to efficiently deliver video to clients who are only interested in > specific areas of a video. Such bandwidth-saving are especially important > when dealing with extremely high resolutions. **** > > **** > > Depending on the application, the recombination of segments into a single > video might take place on the client or on a network node (such as an RTP > mixer). Your simulcast extensions might be a good way to more effectively > deal with the large number of segment streams being received by such a node. > **** > > **** > > I think it would be interesting to see whether we can expand the scope of > your draft to include the specific properties of spatially segmented > content.**** > > **** > > Cheers,**** > > **** > > Ray van Brandenburg**** > > This e-mail and its contents are subject to the DISCLAIMER at > http://www.tno.nl/emaildisclaimer**** > > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt**** > > ** ** > --bcaec5014ba93fcd4604a9102f0b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Defining spatial relationships between RTP video sources is one reason CLUE= was formed.=A0

Although Magnus explicitly used a telepresence syst= em as one of his use cases this morning, he made it clear that the side inf= ormation needed to define the spatial relationships was not part of his int= ended scope.

Stephen Botzko

On Wed, Jul 27, 2011 a= t 10:38 AM, Brandenburg, R. (Ray) van <ray.vanbrandenburg@tno.nl> wrot= e:

Let me further clarify what I mean by spatial segmentation.

=A0

In the most general case, you would have a single camera source = that records in a very high resolution (e.g. 4K or higher). Instead of enco= ding the recorded images as a single video stream, the camera spatially segment= s each video frame and encodes the results into multiple video streams (e.g= . 4 or 16) each representing a specific area of the recorded video. The res= ult would be an RTP sender that makes available 16 separate streams.

=A0

Depending on the area a user is interested in (the region-of-int= erest), an RTP receiver (or mixer) would set up one or more sessions to rec= eive the one or more streams that are necessary to reconstruct the desired regi= on-of-interest. The result would be that different RTP receivers would simu= ltaneously receive different subsets of the available segment streams.

=A0

While some of the desired functionality might lie in the CLUE ar= ea (which I must admit I am not that familiar with), I think there is a con= siderable overlap with the use cases described in the Multistream/Simulcast draft. <= u>

=A0

Cheers,

=A0

Ray van Brandenburg

=A0

=A0

F= rom: Stephen Bot= zko [mailto:s= tephen.botzko@gmail.com]
Sent: woensdag 27 juli 2011 4:19
To: Brandenburg, R. (Ray) van
Cc: magnus.westerlund@ericsson.com; avt@ietf.org
Subject: Re: [AVTCORE] Comments on draft-westerlund-avtcore-multistr= eam-and-simulcast-00

=A0

Such spatial relation= ships are CLUE's scope.

On Tue, Jul 26, 2011 at 6:31 PM, Brandenburg, R. (Ra= y) van <r= ay.vanbrandenburg@tno.nl> wrote:

Hi Magnus,

=A0

Reading your draft 'RTP Multiple Stream Sessions a= nd Simulcast', I was wondering whether the proposed simulcast extension= s could allow for RTP to be used for the delivery of spatially segmented co= ntent.

=A0

Spatial segmentation is the concept of spatially divid= ing a video up into multiple segments, each being independently decodable. = It can for example be used to efficiently deliver video to clients who are = only interested in specific areas of a video. Such bandwidth-saving are especially important when dealing wi= th extremely high resolutions.

=A0

Depending on the application, the recombination of seg= ments into a single video might take place on the client or on a network no= de (such as an RTP mixer). Your simulcast extensions might be a good way to= more effectively deal with the large number of segment streams being received by such a node.<= /u>

=A0

I think it would be interesting to see whether we can = expand the scope of your draft to include the specific properties of spatia= lly segmented content.

=A0

Cheers,

=A0

Ray van Brandenburg

= This e-mail and its contents are subject to the DISCLAIMER at http://www.= tno.nl/emaildisclaimer


_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/avt

=A0


--bcaec5014ba93fcd4604a9102f0b-- From magnus.westerlund@ericsson.com Wed Jul 27 10:24:13 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA30511E8125 for ; Wed, 27 Jul 2011 10:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.49 X-Spam-Level: X-Spam-Status: No, score=-106.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7kGDJHgQ2rJz for ; Wed, 27 Jul 2011 10:24:13 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 729E111E80FD for ; Wed, 27 Jul 2011 10:23:47 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-b9-4e3049a27132 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 6B.DB.09774.2A9403E4; Wed, 27 Jul 2011 19:23:46 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Wed, 27 Jul 2011 19:23:45 +0200 Message-ID: <4E30499A.2000501@ericsson.com> Date: Wed, 27 Jul 2011 13:23:38 -0400 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "Brandenburg, R. (Ray) van" References: In-Reply-To: X-Enigmail-Version: 1.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "avt@ietf.org" Subject: Re: [AVTCORE] Comments on draft-westerlund-avtcore-multistream-and-simulcast-00 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 17:24:14 -0000 Hi Ray, As you describe this case, I would say that it would be very similar to having for example 3 cameras covering adjacent fields of view. The spatial relation between the streams are clearly a CLUE question, not a AVTCORE one. Cheers Magnus On 2011-07-27 10:38, Brandenburg, R. (Ray) van wrote: > > In the most general case, you would have a single camera source that > records in a very high resolution (e.g. 4K or higher). Instead of > encoding the recorded images as a single video stream, the camera > spatially segments each video frame and encodes the results into > multiple video streams (e.g. 4 or 16) each representing a specific area > of the recorded video. The result would be an RTP sender that makes > available 16 separate streams. > > > > Depending on the area a user is interested in (the region-of-interest), > an RTP receiver (or mixer) would set up one or more sessions to receive > the one or more streams that are necessary to reconstruct the desired > region-of-interest. The result would be that different RTP receivers > would simultaneously receive different subsets of the available segment > streams. > > > > While some of the desired functionality might lie in the CLUE area > (which I must admit I am not that familiar with), I think there is a > considerable overlap with the use cases described in the > Multistream/Simulcast draft. > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From casner@acm.org Wed Jul 27 10:44:30 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70E6211E810B for ; Wed, 27 Jul 2011 10:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mmCfrLg6LQnd for ; Wed, 27 Jul 2011 10:44:29 -0700 (PDT) Received: from mailman.packetdesign.com (firewall-gw-dirty-u.packetdesign.com [65.192.41.2]) by ietfa.amsl.com (Postfix) with ESMTP id D2BE911E80FE for ; Wed, 27 Jul 2011 10:44:29 -0700 (PDT) Received: from hsa.packetdesign.com (hsa.packetdesign.com [192.168.0.86]) by mailman.packetdesign.com (8.13.1/8.13.1) with ESMTP id p6RHiEFB003106; Wed, 27 Jul 2011 10:44:14 -0700 Date: Wed, 27 Jul 2011 10:44:14 -0700 (PDT) From: Stephen Casner To: Roni Even In-Reply-To: <002501cc4c79$97d193b0$c774bb10$%roni@huawei.com> Message-ID: References: <4E3014B4.3020506@nostrum.com> <002501cc4c79$97d193b0$c774bb10$%roni@huawei.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: "'AVT \(Audio/Video Transport\) WG'" Subject: Re: [AVTCORE] Media Types Registry X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 17:44:30 -0000 Roni and AVT, I created the RTP Payload Format Media Types table initially because I felt that the limited table of static payload types needed to be accompanied by the more extensive list of payload formats that were available using dynamic payload types. As noted below, the expected value was that it identified the subset of registered media subtypes that were defined for transport via RTP. For audio and video, many of the subtypes in the main registry are defined as part of an RTP payload format, but not all. And for the text subtypes in the RTP Payload Format Media Types table, finding those in the main table or realizing that they exist would be harder. Clearly the value of this table depends upon it being maintained. Is IANA willing to establish a practice that when new media subtypes are defined for RTP they would automatically go into this table? I would hope so. Or would IANA require that the IANA Considerations section of each payload format RFC explicitly mention this? -- Steve On Wed, 27 Jul 2011, Roni Even wrote: > Hi Steve, > We got a question from IANA about RTP Payload Format media types > (http://www.iana.org/assignments/rtp-parameters ) registry which is not > current and is not well maintained. > > The payload subtype are registered in the main registry that avoids > collision etc. http://www.iana.org/assignments/media-types/index.html . > > The question was if we see value in keeping it since the uniqueness is based > on the main registry. We were not sure why it was created and how it was > supposed to be updated. > We have two choices, update it and define the procedure to keep it current > or cancel it. > Regards > Roni Even > > > > RTP Payload Types are identified by Media Types: > The main registry that avoids collision etc. > http://www.iana.org/assignments/media-types/index.html > Registration in this registry is required, and works as intended > There is a second registry: > RTP Payload Format media types > http://www.iana.org/assignments/rtp-parameters > This registry is intended to contain all media types that have RTP Payload > formats > The issue with the second registry: > Poorly maintained, and a lot of formats are missing > Limited extra value, only usable if you want to know all RTP payload formats > Unknown that it exist > > > -----Original Message----- > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > > Stephen Casner > > Sent: Wednesday, July 27, 2011 6:37 PM > > To: Adam Roach > > Cc: AVT (Audio/Video Transport) WG > > Subject: Re: [AVTCORE] Media Types Registry > > > > What was the question? > > > > -- Steve > > > > On Wed, 27 Jul 2011, Adam Roach wrote: > > > > > I'm not entirely sure what consensus the chairs took away from the > > room > > > regarding the "RTP Payload Format media types" IANA registry, but I > > do want to > > > make sure we consider the following before we call the topic > > resolved: > > > > > > Has anyone asked Steve Casner? > > > > > > I would appear that he put in the work to get an RFC published on the > > topic as > > > recently as four years ago. This isn't an easy task, so I would > > assume he had > > > some pretty good reasons for putting in the effort. I imagine that > > those > > > reasons would be very relevant input to this conversation. > > > > > > /a > > > _______________________________________________ > > > Audio/Video Transport Core Maintenance > > > avt@ietf.org > > > https://www.ietf.org/mailman/listinfo/avt > > _______________________________________________ > > Audio/Video Transport Core Maintenance > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt > From ray.vanbrandenburg@tno.nl Wed Jul 27 10:53:05 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B80A11E80F2 for ; Wed, 27 Jul 2011 10:53:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.102 X-Spam-Level: ** X-Spam-Status: No, score=2.102 tagged_above=-999 required=5 tests=[AWL=2.606, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mBKoSY95u1+X for ; Wed, 27 Jul 2011 10:53:04 -0700 (PDT) Received: from mailouta.tno.nl (mailouta.tno.nl [134.221.1.16]) by ietfa.amsl.com (Postfix) with ESMTP id 1D16911E80DF for ; Wed, 27 Jul 2011 10:53:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.67,277,1309730400"; d="scan'208";a="55473611" Received: from unknown (HELO mail.tno.nl) ([134.221.225.222]) by mailhost1a.tno.nl with ESMTP; 27 Jul 2011 19:53:02 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.211]) by EXC-CASHUB03.tsn.tno.nl ([134.221.225.222]) with mapi id 14.01.0289.001; Wed, 27 Jul 2011 19:53:02 +0200 From: "Brandenburg, R. (Ray) van" To: 'Magnus Westerlund' Thread-Topic: [AVTCORE] Comments on draft-westerlund-avtcore-multistream-and-simulcast-00 Thread-Index: AcxL47A/4Qxg7DIaQ0yT8qSx81XM7AADybeAAB1ZLsAAAjslAAAE0wmA Date: Wed, 27 Jul 2011 17:53:01 +0000 Message-ID: References: <4E30499A.2000501@ericsson.com> In-Reply-To: <4E30499A.2000501@ericsson.com> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.191] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Cc: "'avt@ietf.org'" Subject: Re: [AVTCORE] Comments on draft-westerlund-avtcore-multistream-and-simulcast-00 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 17:53:05 -0000 I agree. What I meant was that in the case of spatially segmented content and thus r= eceivers receiving multiple streams, you run into the same kind of difficul= ties as you described in your draft: when to use multiple sessions, when to= multiplex multiple streams into one session.=20 Furthermore, for spatially segmented content it might be especially useful = to have multiple versions of the same stream available (in different resolu= tions for example) and some form of RTP Simulcast might thus be useful. Ray -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 Sent: woensdag 27 juli 2011 19:24 To: Brandenburg, R. (Ray) van Cc: Stephen Botzko; avt@ietf.org Subject: Re: [AVTCORE] Comments on draft-westerlund-avtcore-multistream-and= -simulcast-00 Hi Ray, As you describe this case, I would say that it would be very similar to hav= ing for example 3 cameras covering adjacent fields of view. The spatial rel= ation between the streams are clearly a CLUE question, not a AVTCORE one. Cheers Magnus On 2011-07-27 10:38, Brandenburg, R. (Ray) van wrote: >=20 > In the most general case, you would have a single camera source that=20 > records in a very high resolution (e.g. 4K or higher). Instead of=20 > encoding the recorded images as a single video stream, the camera=20 > spatially segments each video frame and encodes the results into=20 > multiple video streams (e.g. 4 or 16) each representing a specific=20 > area of the recorded video. The result would be an RTP sender that=20 > makes available 16 separate streams. >=20 > =20 >=20 > Depending on the area a user is interested in (the=20 > region-of-interest), an RTP receiver (or mixer) would set up one or=20 > more sessions to receive the one or more streams that are necessary to=20 > reconstruct the desired region-of-interest. The result would be that=20 > different RTP receivers would simultaneously receive different subsets=20 > of the available segment streams. >=20 > =20 >=20 > While some of the desired functionality might lie in the CLUE area=20 > (which I must admit I am not that familiar with), I think there is a=20 > considerable overlap with the use cases described in the=20 > Multistream/Simulcast draft. >=20 --=20 Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer From magnus.westerlund@ericsson.com Wed Jul 27 15:22:43 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8EB811E8180 for ; Wed, 27 Jul 2011 15:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.494 X-Spam-Level: X-Spam-Status: No, score=-106.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Us1RJ8WA6Kxk for ; Wed, 27 Jul 2011 15:22:43 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 36FF311E8097 for ; Wed, 27 Jul 2011 15:22:39 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-33-4e308fae05c0 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 6C.69.09774.EAF803E4; Thu, 28 Jul 2011 00:22:38 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Thu, 28 Jul 2011 00:22:37 +0200 Message-ID: <4E308FAA.3000901@ericsson.com> Date: Wed, 27 Jul 2011 18:22:34 -0400 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Stephen Casner References: <4E3014B4.3020506@nostrum.com> <002501cc4c79$97d193b0$c774bb10$%roni@huawei.com> In-Reply-To: X-Enigmail-Version: 1.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "'AVT \(Audio/Video Transport\) WG'" Subject: Re: [AVTCORE] Media Types Registry X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 22:22:44 -0000 Hi, I think one of the reason this registry are missing so much is that we don't have put this into the IANA consideration section or had clear process established with IANA. I have talked with Michelle and it might be possible to a default process into place. RFC 4288 is apparently under way to do revisions. https://datatracker.ietf.org/doc/draft-freed-media-type-regs/ Something we should discuss around this document is if there should be a question in the registration template "Does the media type have an RTP payload type" that thus should result in the media type being added to this registry automatically. But, I think the low work solution is to instruct IANA to add this to their checklist. Have the PAYLOAD WG chairs try to ensure that the IANA section contains the right instruction. And that someone spends the 2-4 hours going through the documents to find all missing RTP payload types. I do think there is some value with this registry, as it is difficult to find the sub-set of media types that has RTP payload formats. Cheers Magnus On 2011-07-27 13:44, Stephen Casner wrote: > Roni and AVT, > > I created the RTP Payload Format Media Types table initially because I > felt that the limited table of static payload types needed to be > accompanied by the more extensive list of payload formats that were > available using dynamic payload types. As noted below, the expected > value was that it identified the subset of registered media subtypes > that were defined for transport via RTP. > > For audio and video, many of the subtypes in the main registry are > defined as part of an RTP payload format, but not all. And for the > text subtypes in the RTP Payload Format Media Types table, finding > those in the main table or realizing that they exist would be harder. > > Clearly the value of this table depends upon it being maintained. Is > IANA willing to establish a practice that when new media subtypes are > defined for RTP they would automatically go into this table? I would > hope so. Or would IANA require that the IANA Considerations section > of each payload format RFC explicitly mention this? > > -- Steve > > On Wed, 27 Jul 2011, Roni Even wrote: > >> Hi Steve, >> We got a question from IANA about RTP Payload Format media types >> (http://www.iana.org/assignments/rtp-parameters ) registry which is not >> current and is not well maintained. >> >> The payload subtype are registered in the main registry that avoids >> collision etc. http://www.iana.org/assignments/media-types/index.html . >> >> The question was if we see value in keeping it since the uniqueness is based >> on the main registry. We were not sure why it was created and how it was >> supposed to be updated. >> We have two choices, update it and define the procedure to keep it current >> or cancel it. >> Regards >> Roni Even >> >> >> >> RTP Payload Types are identified by Media Types: >> The main registry that avoids collision etc. >> http://www.iana.org/assignments/media-types/index.html >> Registration in this registry is required, and works as intended >> There is a second registry: >> RTP Payload Format media types >> http://www.iana.org/assignments/rtp-parameters >> This registry is intended to contain all media types that have RTP Payload >> formats >> The issue with the second registry: >> Poorly maintained, and a lot of formats are missing >> Limited extra value, only usable if you want to know all RTP payload formats >> Unknown that it exist >> >>> -----Original Message----- >>> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of >>> Stephen Casner >>> Sent: Wednesday, July 27, 2011 6:37 PM >>> To: Adam Roach >>> Cc: AVT (Audio/Video Transport) WG >>> Subject: Re: [AVTCORE] Media Types Registry >>> >>> What was the question? >>> >>> -- Steve >>> >>> On Wed, 27 Jul 2011, Adam Roach wrote: >>> >>>> I'm not entirely sure what consensus the chairs took away from the >>> room >>>> regarding the "RTP Payload Format media types" IANA registry, but I >>> do want to >>>> make sure we consider the following before we call the topic >>> resolved: >>>> >>>> Has anyone asked Steve Casner? >>>> >>>> I would appear that he put in the work to get an RFC published on the >>> topic as >>>> recently as four years ago. This isn't an easy task, so I would >>> assume he had >>>> some pretty good reasons for putting in the effort. I imagine that >>> those >>>> reasons would be very relevant input to this conversation. >>>> >>>> /a >>>> _______________________________________________ >>>> Audio/Video Transport Core Maintenance >>>> avt@ietf.org >>>> https://www.ietf.org/mailman/listinfo/avt >>> _______________________________________________ >>> Audio/Video Transport Core Maintenance >>> avt@ietf.org >>> https://www.ietf.org/mailman/listinfo/avt >> > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From casner@acm.org Wed Jul 27 15:50:42 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0597811E809B for ; Wed, 27 Jul 2011 15:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TNaLysiQ8KJA for ; Wed, 27 Jul 2011 15:50:41 -0700 (PDT) Received: from mailman.packetdesign.com (firewall-gw-dirty-u.packetdesign.com [65.192.41.2]) by ietfa.amsl.com (Postfix) with ESMTP id D03B811E8084 for ; Wed, 27 Jul 2011 15:50:40 -0700 (PDT) Received: from hsa.packetdesign.com (hsa.packetdesign.com [192.168.0.86]) by mailman.packetdesign.com (8.13.1/8.13.1) with ESMTP id p6RMo8x4017775; Wed, 27 Jul 2011 15:50:08 -0700 Date: Wed, 27 Jul 2011 15:50:08 -0700 (PDT) From: Stephen Casner To: Magnus Westerlund In-Reply-To: <4E308FAA.3000901@ericsson.com> Message-ID: References: <4E3014B4.3020506@nostrum.com> <002501cc4c79$97d193b0$c774bb10$%roni@huawei.com> <4E308FAA.3000901@ericsson.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: "'AVT \(Audio/Video Transport\) WG'" Subject: Re: [AVTCORE] Media Types Registry X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 22:50:42 -0000 Magnus, > I think one of the reason this registry are missing so much is that we > don't have put this into the IANA consideration section or had clear > process established with IANA. > > I have talked with Michelle and it might be possible to a default > process into place. RFC 4288 is apparently under way to do revisions. > > https://datatracker.ietf.org/doc/draft-freed-media-type-regs/ > > Something we should discuss around this document is if there should be a > question in the registration template "Does the media type have an RTP > payload type" that thus should result in the media type being added to > this registry automatically. Please be careful with terminology. An "RTP Payload Type" is a number, for which a small set has been defined statically, but most are assigned dynamically. So the question you suggested for the template is not correct. In RFC 3555, it was specified that the encoding considerations should be explicit about RTP transport: 2. Procedure For Registering MIME Types for RTP Payload Types [snip] Encoding considerations The fact that the type can be transferred via RTP MUST be noted. In RFC 4855, that instruction is changed, but I don't remember why. Instead, the same fact is noted in under "Restrictions on usage": Restrictions on usage: The fact that the media type is defined for transfer via RTP MUST be noted, in particular, if the transfer depends on RTP framing and hence the media type is only defined for transfer via RTP. Thus, if these procedures have been followed, there should already be sufficient information for IANA to take the additional step. > But, I think the low work solution is to instruct IANA to add this to > their checklist. Have the PAYLOAD WG chairs try to ensure that the IANA > section contains the right instruction. And that someone spends the 2-4 > hours going through the documents to find all missing RTP payload types. > > I do think there is some value with this registry, as it is difficult to > find the sub-set of media types that has RTP payload formats. That is my opinion as well. -- Steve > On 2011-07-27 13:44, Stephen Casner wrote: > > Roni and AVT, > > > > I created the RTP Payload Format Media Types table initially because I > > felt that the limited table of static payload types needed to be > > accompanied by the more extensive list of payload formats that were > > available using dynamic payload types. As noted below, the expected > > value was that it identified the subset of registered media subtypes > > that were defined for transport via RTP. > > > > For audio and video, many of the subtypes in the main registry are > > defined as part of an RTP payload format, but not all. And for the > > text subtypes in the RTP Payload Format Media Types table, finding > > those in the main table or realizing that they exist would be harder. > > > > Clearly the value of this table depends upon it being maintained. Is > > IANA willing to establish a practice that when new media subtypes are > > defined for RTP they would automatically go into this table? I would > > hope so. Or would IANA require that the IANA Considerations section > > of each payload format RFC explicitly mention this? > > > > -- Steve > > > > On Wed, 27 Jul 2011, Roni Even wrote: > > > >> Hi Steve, > >> We got a question from IANA about RTP Payload Format media types > >> (http://www.iana.org/assignments/rtp-parameters ) registry which is not > >> current and is not well maintained. > >> > >> The payload subtype are registered in the main registry that avoids > >> collision etc. http://www.iana.org/assignments/media-types/index.html . > >> > >> The question was if we see value in keeping it since the uniqueness is based > >> on the main registry. We were not sure why it was created and how it was > >> supposed to be updated. > >> We have two choices, update it and define the procedure to keep it current > >> or cancel it. > >> Regards > >> Roni Even > >> > >> > >> > >> RTP Payload Types are identified by Media Types: > >> The main registry that avoids collision etc. > >> http://www.iana.org/assignments/media-types/index.html > >> Registration in this registry is required, and works as intended > >> There is a second registry: > >> RTP Payload Format media types > >> http://www.iana.org/assignments/rtp-parameters > >> This registry is intended to contain all media types that have RTP Payload > >> formats > >> The issue with the second registry: > >> Poorly maintained, and a lot of formats are missing > >> Limited extra value, only usable if you want to know all RTP payload formats > >> Unknown that it exist > >> > >>> -----Original Message----- > >>> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > >>> Stephen Casner > >>> Sent: Wednesday, July 27, 2011 6:37 PM > >>> To: Adam Roach > >>> Cc: AVT (Audio/Video Transport) WG > >>> Subject: Re: [AVTCORE] Media Types Registry > >>> > >>> What was the question? > >>> > >>> -- Steve > >>> > >>> On Wed, 27 Jul 2011, Adam Roach wrote: > >>> > >>>> I'm not entirely sure what consensus the chairs took away from the > >>> room > >>>> regarding the "RTP Payload Format media types" IANA registry, but I > >>> do want to > >>>> make sure we consider the following before we call the topic > >>> resolved: > >>>> > >>>> Has anyone asked Steve Casner? > >>>> > >>>> I would appear that he put in the work to get an RFC published on the > >>> topic as > >>>> recently as four years ago. This isn't an easy task, so I would > >>> assume he had > >>>> some pretty good reasons for putting in the effort. I imagine that > >>> those > >>>> reasons would be very relevant input to this conversation. > >>>> > >>>> /a > >>>> _______________________________________________ > >>>> Audio/Video Transport Core Maintenance > >>>> avt@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/avt > >>> _______________________________________________ > >>> Audio/Video Transport Core Maintenance > >>> avt@ietf.org > >>> https://www.ietf.org/mailman/listinfo/avt > >> > > _______________________________________________ > > Audio/Video Transport Core Maintenance > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt > > > > > -- > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F?r?gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > From magnus.westerlund@ericsson.com Thu Jul 28 08:19:47 2011 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBC5B21F8CB6 for ; Thu, 28 Jul 2011 08:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.497 X-Spam-Level: X-Spam-Status: No, score=-106.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HCEX1nIRmqmn for ; Thu, 28 Jul 2011 08:19:47 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 07DCA21F8BF2 for ; Thu, 28 Jul 2011 08:19:46 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-0c-4e317e1190e0 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 79.9E.20773.11E713E4; Thu, 28 Jul 2011 17:19:46 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Thu, 28 Jul 2011 17:19:45 +0200 Message-ID: <4E317E0E.9030702@ericsson.com> Date: Thu, 28 Jul 2011 11:19:42 -0400 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Stephen Casner References: <4E3014B4.3020506@nostrum.com> <002501cc4c79$97d193b0$c774bb10$%roni@huawei.com> <4E308FAA.3000901@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "'AVT \(Audio/Video Transport\) WG'" Subject: Re: [AVTCORE] Media Types Registry X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 15:19:47 -0000 On 2011-07-27 18:50, Stephen Casner wrote: > Magnus, > >> I think one of the reason this registry are missing so much is that we >> don't have put this into the IANA consideration section or had clear >> process established with IANA. >> >> I have talked with Michelle and it might be possible to a default >> process into place. RFC 4288 is apparently under way to do revisions. >> >> https://datatracker.ietf.org/doc/draft-freed-media-type-regs/ >> >> Something we should discuss around this document is if there should be a >> question in the registration template "Does the media type have an RTP >> payload type" that thus should result in the media type being added to >> this registry automatically. > > Please be careful with terminology. An "RTP Payload Type" is a > number, for which a small set has been defined statically, but most > are assigned dynamically. So the question you suggested for the > template is not correct. > Yes, you are correct. it should say "RTP Payload Format". > In RFC 3555, it was specified that the encoding considerations should > be explicit about RTP transport: > > 2. Procedure For Registering MIME Types for RTP Payload Types > > [snip] > > Encoding considerations > The fact that the type can be transferred via RTP MUST be > noted. > > In RFC 4855, that instruction is changed, but I don't remember why. > Instead, the same fact is noted in under "Restrictions on usage": > > Restrictions on usage: > The fact that the media type is defined for transfer via RTP > MUST be noted, in particular, if the transfer depends on RTP > framing and hence the media type is only defined for transfer > via RTP. > > Thus, if these procedures have been followed, there should already be > sufficient information for IANA to take the additional step. Yes, I think it has been followed. I think who ever gets to do a bit of digging through the RFCs will find if it is solid or have been missed some times. But, I think it is probably safer to have this instruction in the IANA consideration section to avoid that IANA misses this. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ----------------------------------------------------------------------