From harald@alvestrand.no Thu Mar 1 03:12:58 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C685521F8749 for ; Thu, 1 Mar 2012 03:12:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.508 X-Spam-Level: X-Spam-Status: No, score=-110.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HuiYIcvdJIM8 for ; Thu, 1 Mar 2012 03:12:58 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id E77B921F8732 for ; Thu, 1 Mar 2012 03:12:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D073939E0D2 for ; Thu, 1 Mar 2012 12:12:56 +0100 (CET) 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 3IzxEH7pu19f for ; Thu, 1 Mar 2012 12:12:56 +0100 (CET) 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 EBCB139E0A7 for ; Thu, 1 Mar 2012 12:12:55 +0100 (CET) Message-ID: <4F4F59B7.907@alvestrand.no> Date: Thu, 01 Mar 2012 12:12:55 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.26) Gecko/20120131 Thunderbird/3.1.18 MIME-Version: 1.0 To: payload@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [payload] Interest in raft-ietf-avt-rtp-isac X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 11:12:58 -0000 On 02/27/2012 09:09 PM, Ali C. Begen (abegen) wrote: > WG, > > We have a milestone for this draft and we passed the target date some time ago. AFAICT, the current draft has expired and there was no continued work on this draft. I wonder whether the WG still has interest in finishing this work. Please reply to this email (cc'ing the payload list) if you have an interest/desire in seeing this document finished. > > https://datatracker.ietf.org/doc/draft-ietf-avt-rtp-isac/ I have checked with the relevant ex-Gips team (now Google), and it seems that we don't have any particular reason to make this a high priority at the moment. It's stable code. Do other participants see a benefit in having this spec published as an RFC? > Thanks. > -acbegen > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload > From hschhatwal@gmail.com Thu Mar 1 03:28:52 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76B4F21F8664 for ; Thu, 1 Mar 2012 03:28:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.465 X-Spam-Level: X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8qZWqXb4pp5x for ; Thu, 1 Mar 2012 03:28:49 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3051C21F8634 for ; Thu, 1 Mar 2012 03:28:48 -0800 (PST) Received: by wgbdr13 with SMTP id dr13so288849wgb.13 for ; Thu, 01 Mar 2012 03:28:47 -0800 (PST) Received-SPF: pass (google.com: domain of hschhatwal@gmail.com designates 10.180.96.8 as permitted sender) client-ip=10.180.96.8; Authentication-Results: mr.google.com; spf=pass (google.com: domain of hschhatwal@gmail.com designates 10.180.96.8 as permitted sender) smtp.mail=hschhatwal@gmail.com; dkim=pass header.i=hschhatwal@gmail.com Received: from mr.google.com ([10.180.96.8]) by 10.180.96.8 with SMTP id do8mr1295033wib.21.1330601327481 (num_hops = 1); Thu, 01 Mar 2012 03:28:47 -0800 (PST) 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=DKjbXWMrb7HsCX9k7XTa80riLecZiBaoVlrKAtNn/rQ=; b=YS+d1PwpCzLAFiEa5ixO7PCCBoeKs5bLZ24gZqCrhairSXDq9oeiWxeI8IJMu+sNxq KeX+7FqZ2EZjeO9t6z3PwKwUE5XgA1af+X4WdeEKUhJkKRXx4SK+z5YZnS79wBFHnI3Q OC5ibVvantDsgbIygOaDPY8IulIim3Dhs9HBg= MIME-Version: 1.0 Received: by 10.180.96.8 with SMTP id do8mr1032900wib.21.1330601327336; Thu, 01 Mar 2012 03:28:47 -0800 (PST) Received: by 10.180.96.166 with HTTP; Thu, 1 Mar 2012 03:28:47 -0800 (PST) In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E06BEC7@inba-mail01.sonusnet.com> References: <1D062974A4845E4D8A343C653804920207ABB1E1@XMB-BGL-414.cisco.com> <4F4BB973.4060508@alum.mit.edu> <4F4D06B6.6020905@digium.com> <4F4D17C8.7070201@alum.mit.edu> <4F4D26AE.5070009@digium.com> <4F4D40A3.6030309@digium.com> <4F4E44C3.4080803@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E06BEC7@inba-mail01.sonusnet.com> Date: Thu, 1 Mar 2012 11:28:47 +0000 Message-ID: From: "Chhatwal, Harprit S" To: "Ravindran, Parthasarathi" Content-Type: multipart/alternative; boundary=f46d0444813b741d2a04ba2cc362 Cc: "payload@ietf.org" Subject: Re: [payload] FW: I-D Action: draft-muthu-payload-offer-answer-g723-g729-00.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 11:28:52 -0000 --f46d0444813b741d2a04ba2cc362 Content-Type: text/plain; charset=ISO-8859-1 On 1 March 2012 06:13, Ravindran, Parthasarathi wrote: > I'm not very clear on the bandwidth optimization based on asymmetric > annexb parameter negotiation. Could you please elaborate. > > This is for a network where the bandwidth is severely constrained in one direction, so the operator wishes to use G.729B to minimise bandwidth usage in one direction, while not using G.729B in the other direction where bandwidth is less constrained. Regards. Harprit. Harprit S. Chhatwal InnoMedia On 1 March 2012 06:13, Ravindran, Parthasarathi wrote: > Hi Harpit, > > Thanks for looking into the draft. I agree with you that asymmetric annexb > negotiation is not taken into the account in the draft currently. In fact, > I come across the scenario wherein annexb is not supported by offerer > ,mentioned in offer SDP as annexb=no and answerer assumes about annexb > support (no annexb parameter in answer) in offerer side which leads to the > call failure. > > I'm not very clear on the bandwidth optimization based on asymmetric > annexb parameter negotiation. Could you please elaborate. > > Thanks > Partha > > >-----Original Message----- > >From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On > >Behalf Of Paul Kyzivat > >Sent: Wednesday, February 29, 2012 9:01 PM > >To: Chhatwal, Harprit S > >Cc: payload@ietf.org > >Subject: Re: [payload] FW: I-D Action: draft-muthu-payload-offer-answer- > >g723-g729-00.txt > > > >On 2/29/12 9:34 AM, Chhatwal, Harprit S wrote: > >> On 28 February 2012 21:01, Kevin P. Fleming >> > wrote: > >> > >> > >> That requirement is counter to what the draft proposes. We can't > >> have it both ways: either the G.729 'annexb' format parameter is a > >> negotiated parameter (in which case its usage is symmetrical by > >> definition) or it is a declarative parameter (in which case the > >> usage can be, but is not required to be, asymmetrical). > >> > >> > >> Yes, I concur that the draft (as it currently stands) cannot > >> accommodate an asymmetric use of G.729B. However, if we agree that > >> both scenarios are true, real-world scenarios that need addressing, ie > >> (a) the negotiated case where the use of G.729B is symmetric and (b) > >> the declarative case where the use of G.729B can be asymmetric (and, > >> in my opinion, both are valid scenarios), then I would suggest that we > >> need to come up with a way of handling both situations (perhaps > >> through the use of an extra fmtp parameter indicating whether the use > >> is declarative or negotiated - or any other suggestions the group > >might have). > >> > >> If not, and we are only to allow the negotiated, symmetric use, then > >> I'd appreciate any suggestions from the group for how my organisation > >> might deal with the requirement of an asymmetric use of G.729B > >mentioned below. > > > >There is one way that is available right now: > > > >Negotiate two separate one way m-lines. > >But this might be too weird for common use. > > > > Thanks, > > Paul > > > >> Regards. Harprit. > >> > >> Harprit S. Chhatwal > >> InnoMedia > >> > >> On 28 February 2012 21:01, Kevin P. Fleming >> > wrote: > >> > >> On 02/28/2012 02:58 PM, Chhatwal, Harprit S wrote: > >> > >> Speaking as a codec person :-), I think the draft does address > >a > >> real > >> issue and is reasonably clear in its content. However, it > >does not > >> appear to address (as far as I can see), the case where an > >> asymmetric > >> use of G.729B is required. This is an actual issue as we are > >> faced with > >> a customer requirement where the use of G.729B is required in > >one > >> direction and not the other (for bandwidth reasons). Given > >the > >> current > >> specs do not appear to definitively cover this case, it would > >be > >> good to > >> see if this can be addressed through the proposed draft. > >> > >> > >> That requirement is counter to what the draft proposes. We can't > >> have it both ways: either the G.729 'annexb' format parameter is a > >> negotiated parameter (in which case its usage is symmetrical by > >> definition) or it is a declarative parameter (in which case the > >> usage can be, but is not required to be, asymmetrical). > >> > >> > >> Regards. Harprit. > >> > >> Harprit S. Chhatwal > >> InnoMedia > >> > >> On 28 February 2012 19:10, Kevin P. Fleming > >> > >> >> > >wrote: > >> > >> On 02/28/2012 12:07 PM, Paul Kyzivat wrote: > >> > >> Clarification: > >> > >> In my comments on the draft I was not questioning the > >> assumption > >> of that > >> draft that a common value of this parameter is > >> *negotiated* via O/A. > >> *If* you accept that assumption then my comments > >> hopefully make > >> sense. > >> > >> But if there is debate regarding whether the parameter > >is > >> negotiated or > >> declarative, then that needs to be settled first, > >before > >> nailing > >> down > >> clarifications for how the negotiation happens. > >> > >> Not being a codec person, I don't know what the common > >> practice > >> is here. > >> So I'm going to let those that have the knowledge > >argue > >> that. > >> > >> > >> Correct on all points; your comments make complete sense > >if > >> 'annexb' > >> is intended to be a negotiated parameter. > >> > >> I'm not a codec person (although I'd probably be willing > >to > >> play one > >> on TV is the need arose ), but there are so many other > >> codec/format parameters that are declarative already that > >I > >> don't > >> see any need for this one to have to be negotiated. The > >> impact of > >> using Annex B or not is purely on one direction of the > >media > >> stream, > >> and it's not even mandatory that the encoder use Annex B > >> mode just > >> because 'annexb=yes'. Granted, it's pretty unlikely that > >an > >> implementation that cannot accept incoming SID frames > >would > >> also be > >> able to generate them, but I can think of completely > >reasonable > >> situations for an implementation that can generate them > >being > >> willing to do so while at the same time disallowing > >> reception of them. > >> > >> > >> > >> Thanks, > >> Paul > >> > >> On 2/28/12 12:34 PM, Chhatwal, Harprit S wrote: > >> > >> Kevin, > >> > >> First of all, from RFC3264, I agree with you that > >> for things > >> like IP > >> addresses, ports, payload types, ptime, the SDP > >that one > >> party sends > >> indicates the address/port/PT/ptime that the > >sender > >> would > >> like to > >> receive on. However, I don't believe this is > >generally > >> correct for all > >> parameters. For instance, for codecs (again from > >> RFC3264), > >> the codec(s) > >> included in an SDP offer indicates the codec(s) > >the > >> offerer > >> is willing > >> to send AND receive (if the directional attribute > >is > >> 'sendrecv'). As an > >> example, if party A is the offerer and sends G.729 > >& > >> G.711 > >> in its SDP > >> offer, it is saying that it is willing to use > >either > >> codec. > >> If the > >> answerer replies with G.711, then it is only > >willing > >> to use > >> G.711, and > >> then G.729 will not be used in either direction. > >> > >> Turning now to silence suppression, the situation > >> does not > >> seem very > >> clear. This is what RFC3264 has to say about fmtp > >> parameters > >> such as > >> 'annexb' : > >> > >> The interpretation of fmtp parameters in an offer > >> depends on the > >> > >> parameters. In many cases, those parameters > >describe > >> specific > >> > >> configurations of the media format, and should > >> therefore be > >> processed > >> > >> as the media format value itself would be. This > >> means that > >> the same > >> > >> fmtp parameters with the same values MUST be > >present > >> in the > >> answer if > >> > >> the media format they describe is present in the > >answer. > >> Other fmtp > >> > >> parameters are more like parameters, for which it > >is > >> perfectly > >> > >> acceptable for each agent to use different values. > >> In that > >> case, the > >> > >> answer MAY contain fmtp parameters, and those MAY > >> have the same > >> > >> values as those in the offer, or they MAY be > >> different. SDP > >> > >> extensions that define new parameters SHOULD > >specify > >> the proper > >> > >> interpretation in offer/answer. > >> > >> To me, 'annexb' is more like a parameter in this > >> sense and, > >> in this > >> case, everything is allowed - the answer may > >contain the > >> same fmtp or > >> different. RFC3264 doesn't appear to specify the > >> interpretation. The > >> problem is that I don't know of anywhere else > >where the > >> interpretation > >> is specified either. RFC4856 specifies the > >parameter > >> 'annexb', but > >> doesn't say whether it can be used asymmetrically > >> (or how). > >> The only > >> other guidance I can find on this is elsewhere in > >> RFC3264: > >> > >> The list of media formats for each media stream > >> conveys two > >> pieces of > >> > >> information, namely the set of formats (codecs and > >any > >> parameters > >> > >> associated with the codec, in the case of RTP) > >that the > >> offerer is > >> > >> capable of sending and/or receiving (depending on > >> the direction > >> > >> attributes)... > >> > >> ...For a sendrecv stream, the offer SHOULD > >indicate > >> those > >> > >> codecs that the offerer is willing to send and > >> receive with. > >> > >> So, this appears to be lumping codec parameters > >with > >> codecs > >> and so both > >> should behave in the same way. If we take this > >> interpretation, then > >> indicating 'annexb=no' indicates that the sender > >of > >> this SDP > >> is willing > >> to send and receive with silence suppression off. > >So, > >> according to > >> this, if the offerer sends 'annexb=yes' in the > >offer > >> and the > >> answerer > >> sends back 'annexb=no', then there is a mismatch > >and the > >> offerer should > >> send a re-INVITE with 'annexb=no' to resolve the > >> conflict. > >> According to > >> this interpretation, we cannot have an asymmetric > >> use of silence > >> suppression. However, from the discussion we're > >> having, I > >> can see that > >> all of this is somewhat open to interpretation > >> (since the > >> specs do not > >> seem to be clear) and I agree with the authors of > >> this ID > >> that we need > >> some clarification as to how this issue should be > >> dealt with > >> (and > >> whether asymmetric use of annexb should be allowed > >> and, if > >> so, how). > >> > >> > >> Regards. Harprit. > >> > >> > >> Harprit S. Chhatwal > >> > >> InnoMedia > >> > >> > >> On 28 February 2012 16:54, Kevin P. Fleming > >> > >> > > >> > >> >> >>__> > >> > >> wrote: > >> > >> On 02/27/2012 11:12 AM, Paul Kyzivat wrote: > >> > >> On 2/27/12 6:33 AM, Muthu Arul Mozhi Perumal > >> (mperumal) wrote: > >> > >> We have submitted an I-D clarifying the > >offer/answer > >> considerations for > >> the Annex A flavor of G.723 and the Annex B > >flavors of > >> G.729, G.729D and > >> G.729E. This clarification is missing in RFC 4856, > >> leading > >> to interop > >> issues, for e.g: > >> http://sipforum.org/pipermail/______discussion/2008- > >January/______004026.html > >> >January/____004026.html> > >> >__January/__004026.html > >> >January/__004026.html>> > >> >____January/004026.html > >> > >> >> > > >> > >> >__January/004026.html > >> > >> >> > >> > >> We have a couple of open items in the I-D. We > >expect > >> the WG > >> discussions > >> would guide us on how to go about them. > >> > >> Comments welcome. > >> > >> > >> I'm the source of the issues. :-) > >> > >> The fundamental point is that RFC4856 specifies a > >> *default* > >> value of > >> "yes" for annexa and annexb. This means that if > >> annexa/annexb is not > >> specified in an answer, then it will default to > >yes, > >> even if the > >> offer > >> contained "no". > >> > >> I see a few ways to fix this: > >> > >> 1) revise the IANA registration for annexa and > >annexb to > >> remove the > >> default, at least when used with O/A. Instead > >> specify the > >> defaulting > >> separately for offers and answers. > >> > >> 2) REQUIRE that the answer contain "no" if the > >offer > >> contained "no". > >> > >> 3) permit the answer to contain "yes" (explicitly > >or > >> by default) > >> when the offer contained "no", and specify that > >this > >> still means > >> that the annex is *not* to be used. > >> > >> 4) forbid the answer from *explicitly* containing > >> "yes" when the > >> offer contained "no", but allow the answer to > >> *implicitly* > >> contain > >> "yes" (via the default) and ignore it/treat it as "no". > >> > >> None of these are ideal. (1) is problematic > >because > >> this is > >> used in > >> non-O/A contexts, such as RSVP. (2) begs the > >> question of what > >> should be > >> done if this is violated. (3) risks failing to > >> recognize that > >> the two > >> sides disagree. (4) is pragmatic but seems to > >> violate the > >> spirit of > >> defaults. > >> > >> I guess my preference is to make (2) normative for > >> the answerer, > >> while > >> making (4) normative for the offerer, and put > >enough > >> words > >> in so its > >> very clear what is being specified and why. > >> > >> > >> I must *really* be missing something here; why > >does > >> the usage of > >> G.729 Annex B have to be symmetrical? Until I saw > >this > >> thread, it > >> was always my understanding that the 'annexb' > >format > >> parameter for > >> G.729 in SDP indicated the preference of the > >endpoint > >> sending that > >> parameter. Like nearly everything else in SDP, it > >> indicates what > >> that endpoint is *prepared to accept*, and has > >> nothing at > >> all to do > >> with what it will (or could) send. > >> > >> Unless that's a completely broken understanding, > >> then these > >> 'interop' issues are really just very poorly coded > >> implementations. > >> I would interpret the current RFC language as > >follows: > >> > >> 1) If an offer/answer contains 'annexb=no', the > >> receiver of that > >> offer/answer MUST NOT send G.729 Annex B SID > >frames > >> to the > >> offering/answering endpoint. > >> > >> 2) If an offer/answer contains 'annexb=yes', the > >> receiver of > >> that > >> offer/answer SHOULD send G.729 Annex B SID frames > >to the > >> offering/answering endpoint. > >> > >> 3) An answer's value for the 'annexb' parameter is > >> completely > >> independent of the value (if any) present in the > >> offer it is > >> answering. > >> > >> > >> Thanks, > >> Paul > >> > >> Muthu > >> > >> -----Original Message----- > >> From: i-d-announce-bounces@ietf.org > >> > >> >> > > >> >> ____ietf.org > >> >> >> > >> [mailto:i-d-announce-bounces@ > >> > >> >> >______ietf.org > > > >> > >> >> ____ietf.org > >> >> >>] On Behalf Of > >> internet-drafts@ietf.org > >> >> > > >> >> ____org > >> > >> >> >> > >> Sent: Friday, February 24, 2012 5:57 PM > >> To: i-d-announce@ietf.org > >> >> > > >> > >> >announce@ietf.org>>__> > >> Subject: I-D Action: > >> > >> draft-muthu-payload-offer-______answer-g723-g729-00.txt > >> > >> > >> > >> A New Internet-Draft is available from the on-line > >> Internet-Drafts > >> directories. > >> > >> Title : Offer/Answer Considerations for G.723 > >Annex A > >> and G.729 Annex B > >> Author(s) : Muthu Arul Mozhi Perumal > >> Parthasarathi Ravindran > >> Filename : > >> > >> draft-muthu-payload-offer-______answer-g723-g729-00.txt > >> > >> Pages : 8 > >> Date : 2012-02-24 > >> > >> [RFC4856] describes the annexa parameter for G723 > >> and the annexb > >> parameter for G729, G729D and G729E. However, the > >> specification does > >> not describe the offerer and answerer behavior > >when the > >> value of the > >> annexa or annexb parameter does not match in the > >SDP > >> offer and > >> answer. This document provides the offer/answer > >> considerations for > >> these parameters. > >> > >> > >> A URL for this Internet-Draft is: > >> http://www.ietf.org/internet-______drafts/draft-muthu-payload- > >______offer-answer-g72 > >> >____offer-answer-g72> > >> >____offer-answer-g72 > >> > >> >> wer-g72>> > >> > >> > >> >____offer-answer-g72 > >> >__offer-answer-g72> > >> >__offer-answer-g72 > >> > >> >> g72>>> > >> > >> 3-g729-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-muthu-payload- > >______offer-answer-g723 > >> >____offer-answer-g723> > >> >____offer-answer-g723 > >> > >> >> er-g723>> > >> > >> > >> >____offer-answer-g723 > >> >__offer-answer-g723> > >> >__offer-answer-g723 > >> > >> >> 723>>> > >> > >> -g729-00.txt > >> > >> > >> _____________________________________________________ > >> > >> I-D-Announce mailing list > >> I-D-Announce@ietf.org > >> > > >> > >> >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 > >> > >> >> > > >> >> > >> >> >> > >> > >> > >> > >> _____________________________________________________ > >> > >> payload mailing list > >> payload@ietf.org > >> > > >> > >> >> > >> https://www.ietf.org/mailman/______listinfo/payload > >> > >> >> > > >> > >> >> > >> >> >> > >> > >> > >> > >> -- > >> 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 > > > >> > >> > >> _____________________________________________________ > >> > >> payload mailing list > >> payload@ietf.org > >> > > >> > >> >> > >> https://www.ietf.org/mailman/______listinfo/payload > >> > >> >> > > >> > >> >> > >> >> >> > >> > >> > >> > >> > >> > >> -- > >> 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 > >> > >> > >> > >> > >> > >> -- > >> 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 > >> > >> > > > >_______________________________________________ > >payload mailing list > >payload@ietf.org > >https://www.ietf.org/mailman/listinfo/payload > --f46d0444813b741d2a04ba2cc362 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 1 March 2012 06:13, Ravindran, Parthasarathi=A0<pravindran@sonusnet.com>=A0wrote:
I'm not very clear on the bandwidth optimization based on asymmetric an= nexb parameter negotiation. Could you please elaborate.


This is fo= r a network where the bandwidth is severely constrained in one direction, s= o the operator wishes to use G.729B to minimise bandwidth usage in one dire= ction, while not using G.729B in the other direction where bandwidth is les= s constrained.

Regards. = =A0Harprit.

Harprit S. Chhatwal
InnoMedia

On 1 March 2012 06:13, Ravindran, Part= hasarathi <= pravindran@sonusnet.com> wrote:
Hi Harpit,

Thanks for looking into the draft. I agree with you that asymmetric annexb = negotiation is not taken into the account in the draft currently. In fact, = I come across the scenario wherein annexb is not supported by offerer ,ment= ioned in offer SDP as annexb=3Dno and answerer assumes about annexb support= (no annexb parameter in answer) in offerer side which leads to the call fa= ilure.

I'm not very clear on the bandwidth optimization based on asymmetric an= nexb parameter negotiation. Could you please elaborate.

Thanks
Partha

>-----Original Message-----
>From: payload-bounces@ietf.= org [mailto:payload-bounces= @ietf.org] On
>Behalf Of Paul Kyzivat
>Sent: Wednesday, February 29, 2012 9:01 PM
>To: Chhatwal, Harprit S
>Cc: payload@ietf.org
>Subject: Re: [payload] FW: I-D Action: draft-muthu-payload-offer-answer= -
>g723-g729-00.txt
>
>On 2/29/12 9:34 AM, Chhatwal, Harprit S wrote:
>> On 28 February 2012 21:01, Kevin P. Fleming <kpfleming@digium.com
>> <mailto:kpfleming@digiu= m.com>> wrote:
>>
>>
>> =A0 =A0 That requirement is counter to what the draft proposes. We= can't
>> =A0 =A0 have it both ways: either the G.729 'annexb' forma= t parameter is a
>> =A0 =A0 negotiated parameter (in which case its usage is symmetric= al by
>> =A0 =A0 definition) or it is a declarative parameter (in which cas= e the
>> =A0 =A0 usage can be, but is not required to be, asymmetrical). >>
>>
>> Yes, I concur that the draft (as it currently stands) cannot
>> accommodate an asymmetric use of G.729B. =A0However, if we agree t= hat
>> both scenarios are true, real-world scenarios that need addressing= , ie
>> (a) the negotiated case where the use of G.729B is symmetric and (= b)
>> the declarative case where the use of G.729B can be asymmetric (an= d,
>> in my opinion, both are valid scenarios), then I would suggest tha= t we
>> need to come up with a way of handling both situations (perhaps >> through the use of an extra fmtp parameter indicating whether the = use
>> is declarative or negotiated - or any other suggestions the group<= br> >might have).
>>
>> If not, and we are only to allow the negotiated, symmetric use, th= en
>> I'd appreciate any suggestions from the group for how my organ= isation
>> might deal with the requirement of an asymmetric use of G.729B
>mentioned below.
>
>There is one way that is available right now:
>
>Negotiate two separate one way m-lines.
>But this might be too weird for common use.
>
> =A0 =A0 =A0 Thanks,
> =A0 =A0 =A0 Paul
>
>> Regards. =A0Harprit.
>>
>> Harprit S. Chhatwal
>> InnoMedia
>>
>> On 28 February 2012 21:01, Kevin P. Fleming <kpfleming@digium.com
>> <mailto:kpfleming@digiu= m.com>> wrote:
>>
>> =A0 =A0 On 02/28/2012 02:58 PM, Chhatwal, Harprit S wrote:
>>
>> =A0 =A0 =A0 =A0 Speaking as a codec person :-), I think the draft = does address
>a
>> =A0 =A0 =A0 =A0 real
>> =A0 =A0 =A0 =A0 issue and is reasonably clear in its content. =A0H= owever, it
>does not
>> =A0 =A0 =A0 =A0 appear to address (as far as I can see), the case = where an
>> =A0 =A0 =A0 =A0 asymmetric
>> =A0 =A0 =A0 =A0 use of G.729B is required. =A0This is an actual is= sue as we are
>> =A0 =A0 =A0 =A0 faced with
>> =A0 =A0 =A0 =A0 a customer requirement where the use of G.729B is = required in
>one
>> =A0 =A0 =A0 =A0 direction and not the other (for bandwidth reasons= ). =A0Given
>the
>> =A0 =A0 =A0 =A0 current
>> =A0 =A0 =A0 =A0 specs do not appear to definitively cover this cas= e, it would
>be
>> =A0 =A0 =A0 =A0 good to
>> =A0 =A0 =A0 =A0 see if this can be addressed through the proposed = draft.
>>
>>
>> =A0 =A0 That requirement is counter to what the draft proposes. We= can't
>> =A0 =A0 have it both ways: either the G.729 'annexb' forma= t parameter is a
>> =A0 =A0 negotiated parameter (in which case its usage is symmetric= al by
>> =A0 =A0 definition) or it is a declarative parameter (in which cas= e the
>> =A0 =A0 usage can be, but is not required to be, asymmetrical). >>
>>
>> =A0 =A0 =A0 =A0 Regards. =A0Harprit.
>>
>> =A0 =A0 =A0 =A0 Harprit S. Chhatwal
>> =A0 =A0 =A0 =A0 InnoMedia
>>
>> =A0 =A0 =A0 =A0 On 28 February 2012 19:10, Kevin P. Fleming
>> =A0 =A0 =A0 =A0 <kpflem= ing@digium.com <mailto:kpfle= ming@digium.com>
>> =A0 =A0 =A0 =A0 <mailto:kpfleming@digium.com <mailto:kpfleming@digium.com>>>
>wrote:
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 On 02/28/2012 12:07 PM, Paul Kyzivat wrote= :
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Clarification:
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 In my comments on the draft I was = not questioning the
>> =A0 =A0 =A0 =A0 assumption
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 of that
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 draft that a common value of this = parameter is
>> =A0 =A0 =A0 =A0 *negotiated* via O/A.
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 *If* you accept that assumption th= en my comments
>> =A0 =A0 =A0 =A0 hopefully make
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 sense.
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 But if there is debate regarding w= hether the parameter
>is
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 negotiated or
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 declarative, then that needs to be= settled first,
>before
>> =A0 =A0 =A0 =A0 nailing
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 down
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 clarifications for how the negotia= tion happens.
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Not being a codec person, I don= 9;t know what the common
>> =A0 =A0 =A0 =A0 practice
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 is here.
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 So I'm going to let those that= have the knowledge
>argue
>> =A0 =A0 =A0 =A0 that.
>>
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 Correct on all points; your comments make = complete sense
>if
>> =A0 =A0 =A0 =A0 'annexb'
>> =A0 =A0 =A0 =A0 =A0 =A0 is intended to be a negotiated parameter.<= br> >>
>> =A0 =A0 =A0 =A0 =A0 =A0 I'm not a codec person (although I'= ;d probably be willing
>to
>> =A0 =A0 =A0 =A0 play one
>> =A0 =A0 =A0 =A0 =A0 =A0 on TV is the need arose <G>), but th= ere are so many other
>> =A0 =A0 =A0 =A0 =A0 =A0 codec/format parameters that are declarati= ve already that
>I
>> =A0 =A0 =A0 =A0 don't
>> =A0 =A0 =A0 =A0 =A0 =A0 see any need for this one to have to be ne= gotiated. The
>> =A0 =A0 =A0 =A0 impact of
>> =A0 =A0 =A0 =A0 =A0 =A0 using Annex B or not is purely on one dire= ction of the
>media
>> =A0 =A0 =A0 =A0 stream,
>> =A0 =A0 =A0 =A0 =A0 =A0 and it's not even mandatory that the e= ncoder use Annex B
>> =A0 =A0 =A0 =A0 mode just
>> =A0 =A0 =A0 =A0 =A0 =A0 because 'annexb=3Dyes'. Granted, i= t's pretty unlikely that
>an
>> =A0 =A0 =A0 =A0 =A0 =A0 implementation that cannot accept incoming= SID frames
>would
>> =A0 =A0 =A0 =A0 also be
>> =A0 =A0 =A0 =A0 =A0 =A0 able to generate them, but I can think of = completely
>reasonable
>> =A0 =A0 =A0 =A0 =A0 =A0 situations for an implementation that can = generate them
>being
>> =A0 =A0 =A0 =A0 =A0 =A0 willing to do so while at the same time di= sallowing
>> =A0 =A0 =A0 =A0 reception of them.
>>
>>
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Thanks,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Paul
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 On 2/28/12 12:34 PM, Chhatwal, Har= prit S wrote:
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Kevin,
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 First of all, from RFC3264= , I agree with you that
>> =A0 =A0 =A0 =A0 for things
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 like IP
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 addresses, ports, payload = types, ptime, the SDP
>that one
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 party sends
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 indicates the address/port= /PT/ptime that the
>sender
>> =A0 =A0 =A0 =A0 would
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 like to
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 receive on. However, I don= 't believe this is
>generally
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 correct for all
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 parameters. For instance, = for codecs (again from
>> =A0 =A0 =A0 =A0 RFC3264),
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 the codec(s)
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 included in an SDP offer i= ndicates the codec(s)
>the
>> =A0 =A0 =A0 =A0 offerer
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 is willing
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 to send AND receive (if th= e directional attribute
>is
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 'sendrecv'). As an=
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 example, if party A is the= offerer and sends G.729
>&
>> =A0 =A0 =A0 =A0 G.711
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 in its SDP
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 offer, it is saying that i= t is willing to use
>either
>> =A0 =A0 =A0 =A0 codec.
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 If the
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 answerer replies with G.71= 1, then it is only
>willing
>> =A0 =A0 =A0 =A0 to use
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 G.711, and
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 then G.729 will not be use= d in either direction.
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Turning now to silence sup= pression, the situation
>> =A0 =A0 =A0 =A0 does not
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 seem very
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 clear. This is what RFC326= 4 has to say about fmtp
>> =A0 =A0 =A0 =A0 parameters
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 such as
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 'annexb' :
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 The interpretation of fmtp= parameters in an offer
>> =A0 =A0 =A0 =A0 depends on the
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 parameters. In many cases,= those parameters
>describe
>> =A0 =A0 =A0 =A0 specific
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 configurations of the medi= a format, and should
>> =A0 =A0 =A0 =A0 therefore be
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 processed
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 as the media format value = itself would be. This
>> =A0 =A0 =A0 =A0 means that
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 the same
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 fmtp parameters with the s= ame values MUST be
>present
>> =A0 =A0 =A0 =A0 in the
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 answer if
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 the media format they desc= ribe is present in the
>answer.
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Other fmtp
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 parameters are more like p= arameters, for which it
>is
>> =A0 =A0 =A0 =A0 perfectly
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 acceptable for each agent = to use different values.
>> =A0 =A0 =A0 =A0 In that
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 case, the
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 answer MAY contain fmtp pa= rameters, and those MAY
>> =A0 =A0 =A0 =A0 have the same
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 values as those in the off= er, or they MAY be
>> =A0 =A0 =A0 =A0 different. SDP
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 extensions that define new= parameters SHOULD
>specify
>> =A0 =A0 =A0 =A0 the proper
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 interpretation in offer/an= swer.
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 To me, 'annexb' is= more like a parameter in this
>> =A0 =A0 =A0 =A0 sense and,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 in this
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 case, everything is allowe= d - the answer may
>contain the
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 same fmtp or
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 different. RFC3264 doesn&#= 39;t appear to specify the
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 interpretation. The
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 problem is that I don'= t know of anywhere else
>where the
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 interpretation
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 is specified either. RFC48= 56 specifies the
>parameter
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 'annexb', but
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 doesn't say whether it= can be used asymmetrically
>> =A0 =A0 =A0 =A0 (or how).
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 The only
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 other guidance I can find = on this is elsewhere in
>> =A0 =A0 =A0 =A0 RFC3264:
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 The list of media formats = for each media stream
>> =A0 =A0 =A0 =A0 conveys two
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pieces of
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 information, namely the se= t of formats (codecs and
>any
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 parameters
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 associated with the codec,= in the case of RTP)
>that the
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 offerer is
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 capable of sending and/or = receiving (depending on
>> =A0 =A0 =A0 =A0 the direction
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 attributes)...
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ...For a sendrecv stream, = the offer SHOULD
>indicate
>> =A0 =A0 =A0 =A0 those
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 codecs that the offerer is= willing to send and
>> =A0 =A0 =A0 =A0 receive with.
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 So, this appears to be lum= ping codec parameters
>with
>> =A0 =A0 =A0 =A0 codecs
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 and so both
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 should behave in the same = way. If we take this
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 interpretation, then
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 indicating 'annexb=3Dn= o' indicates that the sender
>of
>> =A0 =A0 =A0 =A0 this SDP
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 is willing
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 to send and receive with s= ilence suppression off.
>So,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 according to
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 this, if the offerer sends= 'annexb=3Dyes' in the
>offer
>> =A0 =A0 =A0 =A0 and the
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 answerer
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 sends back 'annexb=3Dn= o', then there is a mismatch
>and the
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 offerer should
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 send a re-INVITE with '= ;annexb=3Dno' to resolve the
>> =A0 =A0 =A0 =A0 conflict.
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 According to
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 this interpretation, we ca= nnot have an asymmetric
>> =A0 =A0 =A0 =A0 use of silence
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 suppression. However, from= the discussion we're
>> =A0 =A0 =A0 =A0 having, I
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 can see that
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 all of this is somewhat op= en to interpretation
>> =A0 =A0 =A0 =A0 (since the
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 specs do not
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 seem to be clear) and I ag= ree with the authors of
>> =A0 =A0 =A0 =A0 this ID
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 that we need
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 some clarification as to h= ow this issue should be
>> =A0 =A0 =A0 =A0 dealt with
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (and
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 whether asymmetric use of = annexb should be allowed
>> =A0 =A0 =A0 =A0 and, if
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 so, how).
>>
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Regards. Harprit.
>>
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Harprit S. Chhatwal
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 InnoMedia
>>
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 On 28 February 2012 16:54,= Kevin P. Fleming
>> =A0 =A0 =A0 =A0 <kpflem= ing@digium.com <mailto:kpfle= ming@digium.com>
>> =A0 =A0 =A0 =A0 <mailto:kpfleming@digium.com <mailto:kpfleming@digium.com>>
>> =A0 =A0 =A0 =A0 <mailto:kpfleming@digium.com <mailto:kpfleming@digium.com>
>> =A0 =A0 =A0 =A0 <mailto:kpfleming@digium.com
>> <mailto:kpfleming@digiu= m.com>>>__>
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 wrote:
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 On 02/27/2012 11:12 AM, Pa= ul Kyzivat wrote:
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 On 2/27/12 6:33 AM, Muthu = Arul Mozhi Perumal
>> =A0 =A0 =A0 =A0 (mperumal) wrote:
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 We have submitted an I-D c= larifying the
>offer/answer
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 considerations for
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 the Annex A flavor of G.72= 3 and the Annex B
>flavors of
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 G.729, G.729D and
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 G.729E. This clarification= is missing in RFC 4856,
>> =A0 =A0 =A0 =A0 leading
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 to interop
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 issues, for e.g:
>> =A0 =A0 =A0 =A0 http://sipforum.org/pipermail/______discus= sion/2008-
>January/______004026.html
>> =A0 =A0 =A0 =A0 <http://sipforum.org/pipermail/____discus= sion/2008-
>January/____004026.html>
>> =A0 =A0 =A0 =A0 <http://sipforum.org/__pipermail/__discus= sion/2008-
>__January/__004026.html
>> =A0 =A0 =A0 =A0 <http://sipforum.org/pipermail/__discussion= /2008-
>January/__004026.html>>
>> =A0 =A0 =A0 =A0 <http://sipforum.org/____pipermail/discus= sion/2008-
>____January/004026.html
>>
>> <http://sipforum.org/__pipermail/discu= ssion/2008-__January/004026.html
>> >
>>
>> =A0 =A0 =A0 =A0 <http://sipforum.org/__pipermail/discussion= /2008-
>__January/004026.html
>>
>> <http://sipforum.org/pipermail/discussion/= 2008-January/004026.html>>>
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 We have a couple of open i= tems in the I-D. We
>expect
>> =A0 =A0 =A0 =A0 the WG
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 discussions
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 would guide us on how to g= o about them.
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Comments welcome.
>>
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 I'm the source of the = issues. :-)
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 The fundamental point is t= hat RFC4856 specifies a
>> =A0 =A0 =A0 =A0 *default*
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 value of
>> =A0 =A0 =A0 =A0 "yes" for annexa and annexb. This means = that if
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 annexa/annexb is not
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 specified in an answer, th= en it will default to
>yes,
>> =A0 =A0 =A0 =A0 even if the
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 offer
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 contained "no".<= br> >>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 I see a few ways to fix th= is:
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1) revise the IANA registr= ation for annexa and
>annexb to
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 remove the
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 default, at least when use= d with O/A. Instead
>> =A0 =A0 =A0 =A0 specify the
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 defaulting
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 separately for offers and = answers.
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 2) REQUIRE that the answer= contain "no" if the
>offer
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 contained "no".<= br> >>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 3) permit the answer to co= ntain "yes" (explicitly
>or
>> =A0 =A0 =A0 =A0 by default)
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 when the offer contained &= quot;no", and specify that
>this
>> =A0 =A0 =A0 =A0 still means
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 that the annex is *not* to= be used.
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 4) forbid the answer from = *explicitly* containing
>> =A0 =A0 =A0 =A0 "yes" when the
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 offer contained "no&q= uot;, but allow the answer to
>> =A0 =A0 =A0 =A0 *implicitly*
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 contain
>> =A0 =A0 =A0 =A0 "yes" (via the default) and ignore it/tr= eat it as "no".
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 None of these are ideal. (= 1) is problematic
>because
>> =A0 =A0 =A0 =A0 this is
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 used in
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 non-O/A contexts, such as = RSVP. (2) begs the
>> =A0 =A0 =A0 =A0 question of what
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 should be
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 done if this is violated. = (3) risks failing to
>> =A0 =A0 =A0 =A0 recognize that
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 the two
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 sides disagree. (4) is pra= gmatic but seems to
>> =A0 =A0 =A0 =A0 violate the
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 spirit of
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 defaults.
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 I guess my preference is t= o make (2) normative for
>> =A0 =A0 =A0 =A0 the answerer,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 while
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 making (4) normative for t= he offerer, and put
>enough
>> =A0 =A0 =A0 =A0 words
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 in so its
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 very clear what is being s= pecified and why.
>>
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 I must *really* be missing= something here; why
>does
>> =A0 =A0 =A0 =A0 the usage of
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 G.729 Annex B have to be s= ymmetrical? Until I saw
>this
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 thread, it
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 was always my understandin= g that the 'annexb'
>format
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 parameter for
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 G.729 in SDP indicated the= preference of the
>endpoint
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 sending that
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 parameter. Like nearly eve= rything else in SDP, it
>> =A0 =A0 =A0 =A0 indicates what
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 that endpoint is *prepared= to accept*, and has
>> =A0 =A0 =A0 =A0 nothing at
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 all to do
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 with what it will (or coul= d) send.
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Unless that's a comple= tely broken understanding,
>> =A0 =A0 =A0 =A0 then these
>> =A0 =A0 =A0 =A0 'interop' issues are really just very poor= ly coded
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 implementations.
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 I would interpret the curr= ent RFC language as
>follows:
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1) If an offer/answer cont= ains 'annexb=3Dno', the
>> =A0 =A0 =A0 =A0 receiver of that
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 offer/answer MUST NOT send= G.729 Annex B SID
>frames
>> =A0 =A0 =A0 =A0 to the
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 offering/answering endpoin= t.
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 2) If an offer/answer cont= ains 'annexb=3Dyes', the
>> =A0 =A0 =A0 =A0 receiver of
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 that
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 offer/answer SHOULD send G= .729 Annex B SID frames
>to the
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 offering/answering endpoin= t.
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 3) An answer's value f= or the 'annexb' parameter is
>> =A0 =A0 =A0 =A0 completely
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 independent of the value (= if any) present in the
>> =A0 =A0 =A0 =A0 offer it is
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 answering.
>>
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Thanks,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Paul
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Muthu
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -----Original Message-----=
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 From: i-d-announce-bounces@ietf.org
>> =A0 =A0 =A0 =A0 <mailto:i-d-announce-bounces@ietf.org>
>> =A0 =A0 =A0 =A0 <mailto:i-d-announce-bounces@__= ietf.org
>> =A0 =A0 =A0 =A0 <mailto:i-d-announce-bounces@ietf.org>>
>> =A0 =A0 =A0 =A0 <mailto:i-d-announce-bounces@
>> =A0 =A0 =A0 =A0 <mailto:i-d-announce-bounces@>____ietf.org <http:/= /ietf.org>
>> =A0 =A0 =A0 =A0 <mailto:i-d-announce-bounces@__= ietf.org
>> =A0 =A0 =A0 =A0 <mailto:i-d-announce-bounces@ietf.org>>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 [mailto:i-d-announce-bounces@
>> =A0 =A0 =A0 =A0 <mailto:i-d-announce-bounces@>
>> =A0 =A0 =A0 =A0 <mailto:i-d-announce-bounces@
>> =A0 =A0 =A0 =A0 <mailto:i-d-announce-bounces@>>______ietf.org
><http://ietf.org&g= t;
>> =A0 =A0 =A0 =A0 <= http://ietf.org>
>> =A0 =A0 =A0 =A0 <mailto:i-d-announce-bounces@
>> =A0 =A0 =A0 =A0 <mailto:i-d-announce-bounces@>____ietf.org <http:/= /ietf.org>
>> =A0 =A0 =A0 =A0 <mailto:i-d-announce-bounces@__= ietf.org
>> =A0 =A0 =A0 =A0 <mailto:i-d-announce-bounces@ietf.org>>>] On Behalf Of
>> =A0 =A0 =A0 =A0 intern= et-drafts@ietf.org <mailto:internet-drafts@ietf.org>
>> =A0 =A0 =A0 =A0 <mailto:internet-drafts@ietf.__org
>> =A0 =A0 =A0 =A0 <mailto:internet-drafts@ietf.org>>
>> =A0 =A0 =A0 =A0 <mailto:internet-drafts@ietf.
>> <mailto:internet-drafts= @ietf.>____org
>>
>> =A0 =A0 =A0 =A0 <mailto:internet-drafts@ietf.__org
>> =A0 =A0 =A0 =A0 <mailto:internet-drafts@ietf.org>>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Sent: Friday, February 24,= 2012 5:57 PM
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 To: i-d-announce@ietf.org
>> =A0 =A0 =A0 =A0 <mailto:i-d-announce@ietf.org> <mailto:i-d-announce@ietf.org
>> =A0 =A0 =A0 =A0 <mailto:i-d-announce@ietf.org>>
>> =A0 =A0 =A0 =A0 <mailto:i-d-announce@ietf.org <mailto:i-d-announce@ietf.org>
>> =A0 =A0 =A0 =A0 <mailto:i-d-announce@ietf.org <mailto:i-d-
>announce@ietf.org>>__>= ;
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Subject: I-D Action:
>>
>> draft-muthu-payload-offer-______answer-g723-g729-00.txt
>>
>>
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 A New Internet-Draft is av= ailable from the on-line
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Internet-Drafts
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 directories.
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Title : Offer/Answer Consi= derations for G.723
>Annex A
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 and G.729 Annex B
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Author(s) : Muthu Arul Moz= hi Perumal
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Parthasarathi Ravindran >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Filename :
>>
>> draft-muthu-payload-offer-______answer-g723-g729-00.txt
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Pages : 8
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Date : 2012-02-24
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 [RFC4856] describes the an= nexa parameter for G723
>> =A0 =A0 =A0 =A0 and the annexb
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 parameter for G729, G729D = and G729E. However, the
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 specification does
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 not describe the offerer a= nd answerer behavior
>when the
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 value of the
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 annexa or annexb parameter= does not match in the
>SDP
>> =A0 =A0 =A0 =A0 offer and
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 answer. This document prov= ides the offer/answer
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 considerations for
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 these parameters.
>>
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 A URL for this Internet-Dr= aft is:
>> =A0 =A0 =A0 =A0 http://www.ietf.org/internet-___= ___drafts/draft-muthu-payload-
>______offer-answer-g72
>> =A0 =A0 =A0 =A0 <http://www.ietf.org/internet-_= ___drafts/draft-muthu-payload-
>____offer-answer-g72>
>> =A0 =A0 =A0 =A0 <http://www.ietf.org/internet-_= ___drafts/draft-muthu-payload-
>____offer-answer-g72
>>
>> <http://www.ietf.org/internet-__drafts= /draft-muthu-payload-__offer-ans
>> wer-g72>>
>>
>>
>> =A0 =A0 =A0 =A0 <http://www.ietf.org/internet-_= ___drafts/draft-muthu-payload-
>____offer-answer-g72
>> =A0 =A0 =A0 =A0 <http://www.ietf.org/internet-__d= rafts/draft-muthu-payload-
>__offer-answer-g72>
>> =A0 =A0 =A0 =A0 <http://www.ietf.org/internet-__d= rafts/draft-muthu-payload-
>__offer-answer-g72
>>
>> <http://www.ietf.org/internet-drafts/d= raft-muthu-payload-offer-answer-
>> g72>>>
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 3-g729-00.txt
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Internet-Drafts are also a= vailable by anonymous
>FTP at:
>> =A0 =A0 =A0 =A0 ftp://ftp.ietf.org/internet-______drafts/
>> =A0 =A0 =A0 =A0 <ftp://ftp.ietf.org/internet-____drafts/>
>> =A0 =A0 =A0 =A0 <ftp://ftp.ietf.org/internet-____drafts/
>> =A0 =A0 =A0 =A0 <ftp://ftp.ietf.org/internet-__drafts/>>
>>
>> =A0 =A0 =A0 =A0 <ftp://ftp.ietf.org/internet-____drafts/
>> =A0 =A0 =A0 =A0 <ftp://ftp.ietf.org/internet-__drafts/>
>> =A0 =A0 =A0 =A0 <ftp://ftp.ietf.org/internet-__drafts/
>> =A0 =A0 =A0 =A0 <ftp://ftp.ietf.org/internet-drafts/>>>
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 This Internet-Draft can be= retrieved at:
>> =A0 =A0 =A0 =A0 ftp://ftp.ietf.org/internet-_____= _drafts/draft-muthu-payload-
>______offer-answer-g723
>> =A0 =A0 =A0 =A0 <ftp://ftp.ietf.org/internet-___= _drafts/draft-muthu-payload-
>____offer-answer-g723>
>> =A0 =A0 =A0 =A0 <ftp://ftp.ietf.org/internet-___= _drafts/draft-muthu-payload-
>____offer-answer-g723
>>
>> <ftp://ftp.ietf.org/internet-__drafts/= draft-muthu-payload-__offer-answ
>> er-g723>>
>>
>>
>> =A0 =A0 =A0 =A0 <ftp://ftp.ietf.org/internet-___= _drafts/draft-muthu-payload-
>____offer-answer-g723
>> =A0 =A0 =A0 =A0 <ftp://ftp.ietf.org/internet-__dra= fts/draft-muthu-payload-
>__offer-answer-g723>
>> =A0 =A0 =A0 =A0 <ftp://ftp.ietf.org/internet-__dra= fts/draft-muthu-payload-
>__offer-answer-g723
>>
>> <ftp://ftp.ietf.org/internet-drafts/dr= aft-muthu-payload-offer-answer-g
>> 723>>>
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -g729-00.txt
>>
>>
>> _____________________________________________________
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 I-D-Announce mailing list<= br> >> =A0 =A0 =A0 =A0 I-D-Annou= nce@ietf.org <mailto:I-D-An= nounce@ietf.org>
>> =A0 =A0 =A0 =A0 <mailto:I-D-Announce@ietf.org <mailto:I-D-Announce@ietf.org>>
>> =A0 =A0 =A0 =A0 <mailto:I-D-Announce@ietf.org <mailto:I-D-Announce@ietf.org>
>> =A0 =A0 =A0 =A0 <mailto:I-D-Announce@ietf.org <mailto:I-D-
>Announce@ietf.org>>__>= ;
>> =A0 =A0 =A0 =A0 https://www.ietf.org/mailman/______lis= tinfo/i-d-announce
>> =A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/____lis= tinfo/i-d-announce>
>> =A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/____lis= tinfo/i-d-announce
>> =A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/__listinf= o/i-d-announce>>
>>
>> =A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/____lis= tinfo/i-d-announce
>> =A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/__listinf= o/i-d-announce>
>> =A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/__listinf= o/i-d-announce
>> =A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/listinfo/i-= d-announce>>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Internet-Draft directories= :
>> =A0 =A0 =A0 =A0 http://www.ietf.org/shadow.______html
>> =A0 =A0 =A0 =A0 <http://www.ietf.org/shadow.____html>
>> =A0 =A0 =A0 =A0 <http://www.ietf.org/shadow.____html
>> =A0 =A0 =A0 =A0 <http://www.ietf.org/shadow.__html>>
>> =A0 =A0 =A0 =A0 <http://www.ietf.org/shadow.____html
>> =A0 =A0 =A0 =A0 <http://www.ietf.org/shadow.__html>
>> =A0 =A0 =A0 =A0 <http://www.ietf.org/shadow.__html
>> =A0 =A0 =A0 =A0 <http://www.ietf.org/shadow.html>>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 or ftp://ftp.ietf.org/i= etf/______1shadow-sites.txt
>> =A0 =A0 =A0 =A0 <ftp://ftp.ietf.org/ietf/____1shadow-sites.txt= >
>> =A0 =A0 =A0 =A0 <ftp://ftp.ietf.org/ietf/____1shadow-sites.txt=
>> =A0 =A0 =A0 =A0 <ftp://ftp.ietf.org/ietf/__1shadow-sites.txt= >>
>> =A0 =A0 =A0 =A0 <ftp://ftp.ietf.org/ietf/____1shadow-sites.txt=
>> =A0 =A0 =A0 =A0 <ftp://ftp.ietf.org/ietf/__1shadow-sites.txt= >
>> =A0 =A0 =A0 =A0 <ftp://ftp.ietf.org/ietf/__1shadow-sites.txt=
>> =A0 =A0 =A0 =A0 <ftp://ftp.ietf.org/ietf/1shadow-sites.txt>= >>
>>
>>
>>
>> _____________________________________________________
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 payload mailing list
>> =A0 =A0 =A0 =A0 payload@ietf.o= rg <mailto:payload@ietf.org&= gt;
>> =A0 =A0 =A0 =A0 <mailto:pay= load@ietf.org <mailto:payload@ie= tf.org>>
>> =A0 =A0 =A0 =A0 <mailto:pay= load@ietf.org <mailto:payload@ie= tf.org>
>> =A0 =A0 =A0 =A0 <mailto:pay= load@ietf.org <mailto:payload@ie= tf.org>>>
>> =A0 =A0 =A0 =A0 https://www.ietf.org/mailman/______listinfo= /payload
>> =A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/____listinfo= /payload>
>> =A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/____listinfo= /payload
>> =A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/__listinfo/pay= load>>
>>
>> =A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/____listinfo= /payload
>> =A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/__listinfo/pay= load>
>> =A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/__listinfo/pay= load
>> =A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/listinfo/payload= >>>
>>
>>
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 --
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Kevin P. Fleming
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Digium, Inc. | Director of= Software Technologies
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Jabber: kfleming@digium.com
>> =A0 =A0 =A0 =A0 <mailto:= kfleming@digium.com> <mailto:kfleming@digium.com
>> =A0 =A0 =A0 =A0 <mailto:= kfleming@digium.com>>
>> =A0 =A0 =A0 =A0 <mailto:= kfleming@digium.com <mailto:k= fleming@digium.com>
>> =A0 =A0 =A0 =A0 <mailto:= kfleming@digium.com <mailto:k= fleming@digium.com>>> |
>SIP:
>> =A0 =A0 =A0 =A0 kpfleming@= digium.com <mailto:kpfleming= @digium.com>
>> =A0 =A0 =A0 =A0 <mailto:kpfleming@digium.com <mailto:kpfleming@digium.com>>
>> =A0 =A0 =A0 =A0 <mailto:kpfleming@digium.com <mailto:kpfleming@digium.com>
>> =A0 =A0 =A0 =A0 <mailto:kpfleming@digium.com <mailto:kpfleming@digium.com>>>
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | Skype: kpfleming
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 445 Jan Davis Drive NW - H= untsville, AL 35806 -
>USA
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Check us out at www.digium.com
>> =A0 =A0 =A0 =A0 <http://www.digium.com> <http://www.digium.com>
>> =A0 =A0 =A0 =A0 <http://www.digium.com> &
>> =A0 =A0 =A0 =A0 www.asterisk.org <http://www.asterisk.org>
><http://www.as= terisk.org>
>> =A0 =A0 =A0 =A0 <http://www.asterisk.org>
>>
>> _____________________________________________________
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 payload mailing list
>> =A0 =A0 =A0 =A0 payload@ietf.o= rg <mailto:payload@ietf.org&= gt;
>> =A0 =A0 =A0 =A0 <mailto:pay= load@ietf.org <mailto:payload@ie= tf.org>>
>> =A0 =A0 =A0 =A0 <mailto:pay= load@ietf.org <mailto:payload@ie= tf.org>
>> =A0 =A0 =A0 =A0 <mailto:pay= load@ietf.org <mailto:payload@ie= tf.org>>>
>> =A0 =A0 =A0 =A0 https://www.ietf.org/mailman/______listinfo= /payload
>> =A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/____listinfo= /payload>
>> =A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/____listinfo= /payload
>> =A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/__listinfo/pay= load>>
>>
>> =A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/____listinfo= /payload
>> =A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/__listinfo/pay= load>
>> =A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/__listinfo/pay= load
>> =A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/listinfo/payload= >>>
>>
>>
>>
>>
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 --
>> =A0 =A0 =A0 =A0 =A0 =A0 Kevin P. Fleming
>> =A0 =A0 =A0 =A0 =A0 =A0 Digium, Inc. | Director of Software Techno= logies
>> =A0 =A0 =A0 =A0 =A0 =A0 Jabber: kfleming@digium.com <mailto:kfleming@digium.com>
>> =A0 =A0 =A0 =A0 <mailto:= kfleming@digium.com <mailto:k= fleming@digium.com>> |
>SIP:
>> =A0 =A0 =A0 =A0 kpfleming@= digium.com <mailto:kpfleming= @digium.com>
>> =A0 =A0 =A0 =A0 <mailto:kpfleming@digium.com <mailto:kpfleming@digium.com>> |
>> =A0 =A0 =A0 =A0 Skype: kpfleming
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 445 Jan Davis Drive NW - Huntsville, AL 35= 806 - USA
>> =A0 =A0 =A0 =A0 =A0 =A0 Check us out at www.digium.com <http://www.digium.com>
>> =A0 =A0 =A0 =A0 <http://www.digium.com> &
>> =A0 =A0 =A0 =A0 www.asterisk.org <http://www.asterisk.org>
>> <http://w= ww.asterisk.org>
>>
>>
>>
>>
>> =A0 =A0 --
>> =A0 =A0 Kevin P. Fleming
>> =A0 =A0 Digium, Inc. | Director of Software Technologies
>> =A0 =A0 Jabber: kfleming@di= gium.com <mailto:kfleming@dig= ium.com> | SIP:
>> =A0 =A0 kpfleming@digium.c= om <mailto:kpfleming@digium.= com> | Skype:
>kpfleming
>> =A0 =A0 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
>> =A0 =A0 Check us out at www.digium.com <http://www.digium.com> &
>> =A0 =A0 www.= asterisk.org <= http://www.asterisk.org>
>>
>>
>
>___________________= ____________________________
>payload mailing list
>payload@ietf.org
>https://www.ietf.org/mailman/listinfo/payload

--f46d0444813b741d2a04ba2cc362-- From kpfleming@digium.com Thu Mar 1 08:54:47 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04E6721E830D for ; Thu, 1 Mar 2012 08:54:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.546 X-Spam-Level: X-Spam-Status: No, score=-106.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Vlv5SQGv5SD for ; Thu, 1 Mar 2012 08:54:45 -0800 (PST) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id B422721E82C2 for ; Thu, 1 Mar 2012 08:52:31 -0800 (PST) Received: from [10.24.55.203] (helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1S39F0-0006yh-I6 for payload@ietf.org; Thu, 01 Mar 2012 10:52:30 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id 85FE6D8007 for ; Thu, 1 Mar 2012 10:52:30 -0600 (CST) 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 Es2NUslpSZRG for ; Thu, 1 Mar 2012 10:52:30 -0600 (CST) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 060E8D8005 for ; Thu, 1 Mar 2012 10:52:29 -0600 (CST) Message-ID: <4F4FA94D.4090508@digium.com> Date: Thu, 01 Mar 2012 10:52:29 -0600 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: payload@ietf.org References: <4F4F59B7.907@alvestrand.no> In-Reply-To: <4F4F59B7.907@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [payload] Interest in raft-ietf-avt-rtp-isac X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 16:54:47 -0000 On 03/01/2012 05:12 AM, Harald Alvestrand wrote: > On 02/27/2012 09:09 PM, Ali C. Begen (abegen) wrote: >> WG, >> >> We have a milestone for this draft and we passed the target date some >> time ago. AFAICT, the current draft has expired and there was no >> continued work on this draft. I wonder whether the WG still has >> interest in finishing this work. Please reply to this email (cc'ing >> the payload list) if you have an interest/desire in seeing this >> document finished. >> >> https://datatracker.ietf.org/doc/draft-ietf-avt-rtp-isac/ > I have checked with the relevant ex-Gips team (now Google), and it seems > that we don't have any particular reason to make this a high priority at > the moment. It's stable code. > > Do other participants see a benefit in having this spec published as an > RFC? At the request of a community member, I've just started working on adding support for iSAC passthrough in Asterisk, and while investigating it I learned that Chrome can currently generate/accept offers with iSAC at 32kHz sample rate, which is not included in this draft. If Google is going to continue to distribute iSAC support in products (and others are as well), I'd be happy to see this draft updated to match the current state of deployments and get pushed towards publication. -- 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 Thu Mar 1 13:55:25 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7288721E8230; Thu, 1 Mar 2012 13:55:25 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xEUW8ddW332Y; Thu, 1 Mar 2012 13:55:24 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41BF421E801C; Thu, 1 Mar 2012 13:54:57 -0800 (PST) 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: 4.00 Message-ID: <20120301215457.17499.41850.idtracker@ietfa.amsl.com> Date: Thu, 01 Mar 2012 13:54:57 -0800 Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-rtp-klv-04.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 21:55:25 -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 Payloads Workin= g Group of the IETF. Title : RTP Payload Format for SMPTE 336M Encoded Data Author(s) : J. Downs J. Arbeiter Filename : draft-ietf-payload-rtp-klv-04.txt Pages : 13 Date : 2012-03-01 This document specifies the payload format for packetization of KLV (Key-Length-Value) Encoded Data, as defined by the Society of Motion Picture and Television Engineers (SMPTE) in SMPTE 336M, into the Real-time Transport Protocol (RTP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-payload-rtp-klv-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-payload-rtp-klv-04.txt From ron.even.tlv@gmail.com Sun Mar 4 04:09:53 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91B9121F8526 for ; Sun, 4 Mar 2012 04:09:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.46 X-Spam-Level: X-Spam-Status: No, score=-3.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0fgcJGO+tjdQ for ; Sun, 4 Mar 2012 04:09:53 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id A1B1D21F851A for ; Sun, 4 Mar 2012 04:09:52 -0800 (PST) Received: by eaaq11 with SMTP id q11so1055512eaa.31 for ; Sun, 04 Mar 2012 04:09:51 -0800 (PST) Received-SPF: pass (google.com: domain of ron.even.tlv@gmail.com designates 10.14.100.207 as permitted sender) client-ip=10.14.100.207; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ron.even.tlv@gmail.com designates 10.14.100.207 as permitted sender) smtp.mail=ron.even.tlv@gmail.com; dkim=pass header.i=ron.even.tlv@gmail.com Received: from mr.google.com ([10.14.100.207]) by 10.14.100.207 with SMTP id z55mr850240eef.104.1330862991939 (num_hops = 1); Sun, 04 Mar 2012 04:09:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; bh=XQ4jJzNoGz66ohvz3i/abt88Puxa/llZUPVBdyvRhjo=; b=EfmVVkPxHtFklWxV5bMEAfRNKyV7Loooyxph64uJKXvtXjoxfxjU3s9coKx/jd3F/r xC4Cn8Hbrhu12hU9DdAldaeEc8bQTHF4Fg1J5sUPlugEf/3UXqfdXoIdolvZI+tSpEcc KDw62cc19q2ki9TWrhKUas44MEepvZvQ3szisyeXhIytqy/s4bQ1T3zMipsZTkONQSl3 rstuAptVptBdzhKIxQXqvhOuQMXngjtPsUTtFgh9lv3vMZIYb/+tygqqjSPunzbB5dG0 C5Nvw5fTt23J2wf8d3oMjw4xhM1uYSy7rFNf2Z9phznoYxbXhAOZ2A+M0R8hb9+d1I06 wtqg== Received: by 10.14.100.207 with SMTP id z55mr639639eef.104.1330862991828; Sun, 04 Mar 2012 04:09:51 -0800 (PST) Received: from windows8d787f9 (bzq-109-67-208-29.red.bezeqint.net. [109.67.208.29]) by mx.google.com with ESMTPS id o11sm39014775eef.4.2012.03.04.04.09.48 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 04 Mar 2012 04:09:49 -0800 (PST) From: "Roni Even" To: "'Ali C. Begen \(abegen\)'" , References: In-Reply-To: Date: Sun, 4 Mar 2012 14:08:45 +0200 Message-ID: <4f535b8d.0b5f0e0a.0445.ffffd49a@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AczrRVxjReHrfWv2TROUTdcmKeO0cAOt+NyQ Content-Language: en-us Subject: Re: [payload] WGLC for draft-ietf-payload-vp8-03 ending March 1st X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2012 12:09:53 -0000 Hi, Sorry for the late review. I have some comments. 1. In section 4.2 the PictureID definition talk about the msb being a flag. Why not show it in figure 2. 2. The first paragraph in section 4.3 talk about 10 octets version of the uncompressed data chunk, I could not find where the 10 octet version is specified. The example in 4.5.1 has the 3 octets version. 3. In the example in 4.5.2 is this a discardable packet in which case N should be 1. 4. In section 6.2.1 the reference to SDP should be RFC 4566. Also in payload specification we typically use the media subtype and not MIME subtype. Roni Even As individual > -----Original Message----- > From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On > Behalf Of Ali C. Begen (abegen) > Sent: Tuesday, February 14, 2012 8:35 PM > To: payload@ietf.org > Subject: [payload] WGLC for draft-ietf-payload-vp8-03 ending March 1st > > WG, > > This is to start the WGLC for the VP8 draft. > https://datatracker.ietf.org/doc/draft-ietf-payload-vp8/ > > Please send your comments and approvals to the payload list by March > 1st. > > Authors, you need to separate the references as informative vs. > normative but please wait till the WGLC ends for a revision. > > -acbegen > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload From iesg-secretary@ietf.org Mon Mar 5 12:59:13 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B54FB21E8018; Mon, 5 Mar 2012 12:59:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2rWnkQLPJrXK; Mon, 5 Mar 2012 12:59:13 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C31C521E801C; Mon, 5 Mar 2012 12:59:12 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120305205912.4453.10070.idtracker@ietfa.amsl.com> Date: Mon, 05 Mar 2012 12:59:12 -0800 Cc: payload chair , payload mailing list , RFC Editor Subject: [payload] Protocol Action: 'RTP Payload Format for SMPTE 336M Encoded Data' to Proposed Standard (draft-ietf-payload-rtp-klv-04.txt) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 20:59:13 -0000 The IESG has approved the following document: - 'RTP Payload Format for SMPTE 336M Encoded Data' (draft-ietf-payload-rtp-klv-04.txt) as a Proposed Standard This document is the product of the Audio/Video Transport Payloads Working Group. The IESG contact persons are Robert Sparks and Gonzalo Camarillo. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-payload-rtp-klv/ Technical Summary This document specifies the payload format for packetization of KLV (Key-Length- Value) Encoded Data, as defined by the Society of Motion Picture and Television Engineers (SMPTE) in SMPTE 336M, into the Real-time Transport Protocol (RTP). Working Group Summary There was nothing exceptional in the working group processing of this document. Document Quality The document achieved consensus in the PAYLOAD working group. According to the authors, there have been prototypical implementations, including implementation inside existing open toolkits and applications. One such prototype involved a (modified to implement) VideoLAN VLC to a proprietary RTP-capable desktop application. Personnel Ali Begen is the document shepherd. Robert Sparks is the responsible Area Director. From abegen@cisco.com Wed Mar 7 09:14:43 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B7B521F87AE for ; Wed, 7 Mar 2012 09:14:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.313 X-Spam-Level: X-Spam-Status: No, score=-10.313 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HH3GsHpVMN7b for ; Wed, 7 Mar 2012 09:14:42 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id BBEDD21F87A9 for ; Wed, 7 Mar 2012 09:14:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=1934; q=dns/txt; s=iport; t=1331140482; x=1332350082; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=/4ngmFmH1trq5E2ubz29ClO2a0ZLXx3zDaK8u/VMfJc=; b=B+gEejvjoHNLsIR/wOrXuwbnTK1/GVLFMCUPdVwJjsiAqrgtWxH7Kbqj fGIf9NkaUWbxKfrjJFHd81hktU7K50PPZ5pfUKH66X4AH8O57o/oF/aa9 +gQ5Y2NCuh7dhyT63rLqgw8VMo/sePnRs7aWhOdU9BuKd4fFEDpOtst5T w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAAaXV0+rRDoI/2dsb2JhbABEtRyBB4IDBwEBAQQBAQEPAVsXBAIBCA4DBAEBCx0HIQYLFAkIAQEEARIIGoUmB4I4AQuaMwGfGASJOYZTYwSgYoR2gmM X-IronPort-AV: E=Sophos;i="4.73,547,1325462400"; d="scan'208";a="34995949" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 07 Mar 2012 17:14:42 +0000 Received: from xht-rcd-x02-p.cisco.com (xht-rcd-x02-p.cisco.com [173.37.178.213]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q27HEgQI023446; Wed, 7 Mar 2012 17:14:42 GMT Received: from xmb-rcd-x01-p.cisco.com ([169.254.3.137]) by xht-rcd-x02-p.cisco.com ([173.37.178.213]) with mapi id 14.02.0283.003; Wed, 7 Mar 2012 09:14:41 -0800 From: "Ali C. Begen (abegen)" To: Roni Even , "payload@ietf.org" Thread-Topic: [payload] WGLC for draft-ietf-payload-vp8-03 ending March 1st Thread-Index: AczrRVxjReHrfWv2TROUTdcmKeO0cAOt+NyQAKIVnyA= Date: Wed, 7 Mar 2012 17:14:41 +0000 Message-ID: References: <4f535b8d.0b5f0e0a.0445.ffffd49a@mx.google.com> In-Reply-To: <4f535b8d.0b5f0e0a.0445.ffffd49a@mx.google.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.37.178.200] x-tm-as-product-ver: SMEX-10.0.0.4211-6.800.1017-18758.005 x-tm-as-result: No--44.597800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [payload] WGLC for draft-ietf-payload-vp8-03 ending March 1st X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 17:14:43 -0000 Thanks Roni, are there any other reviews? I will extend the review period t= ill the 21st. Please provide your comments to the list. -acbegen > -----Original Message----- > From: Roni Even [mailto:ron.even.tlv@gmail.com] > Sent: Sunday, March 04, 2012 7:09 AM > To: Ali C. Begen (abegen); payload@ietf.org > Subject: RE: [payload] WGLC for draft-ietf-payload-vp8-03 ending March 1s= t >=20 > Hi, > Sorry for the late review. > I have some comments. >=20 > 1. In section 4.2 the PictureID definition talk about the msb being a fla= g. > Why not show it in figure 2. >=20 > 2. The first paragraph in section 4.3 talk about 10 octets version of the > uncompressed data chunk, I could not find where the 10 octet version is > specified. The example in 4.5.1 has the 3 octets version. >=20 >=20 > 3. In the example in 4.5.2 is this a discardable packet in which case N > should be 1. >=20 > 4. In section 6.2.1 the reference to SDP should be RFC 4566. Also in payl= oad > specification we typically use the media subtype and not MIME subtype. >=20 > Roni Even > As individual >=20 > > -----Original Message----- > > From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On > > Behalf Of Ali C. Begen (abegen) > > Sent: Tuesday, February 14, 2012 8:35 PM > > To: payload@ietf.org > > Subject: [payload] WGLC for draft-ietf-payload-vp8-03 ending March 1st > > > > WG, > > > > This is to start the WGLC for the VP8 draft. > > https://datatracker.ietf.org/doc/draft-ietf-payload-vp8/ > > > > Please send your comments and approvals to the payload list by March > > 1st. > > > > Authors, you need to separate the references as informative vs. > > normative but please wait till the WGLC ends for a revision. > > > > -acbegen > > _______________________________________________ > > payload mailing list > > payload@ietf.org > > https://www.ietf.org/mailman/listinfo/payload From Even.roni@huawei.com Wed Mar 7 16:00:08 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5740011E80AB for ; Wed, 7 Mar 2012 16:00:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.589 X-Spam-Level: X-Spam-Status: No, score=-106.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BL0UwlkfqH8r for ; Wed, 7 Mar 2012 16:00:07 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 8D77011E8099 for ; Wed, 7 Mar 2012 16:00:07 -0800 (PST) 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 <0M0J00382HC11F@szxga04-in.huawei.com> for payload@ietf.org; Thu, 08 Mar 2012 08:00:01 +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 <0M0J00EI1HC1NQ@szxga04-in.huawei.com> for payload@ietf.org; Thu, 08 Mar 2012 08:00:01 +0800 (CST) Received: from szxeml214-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHQ94882; Thu, 08 Mar 2012 08:00:01 +0800 Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by szxeml214-edg.china.huawei.com (172.24.2.29) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 08 Mar 2012 07:59:20 +0800 Received: from SZXEML536-MBX.china.huawei.com ([169.254.4.220]) by szxeml404-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Thu, 08 Mar 2012 08:00:16 +0800 Date: Wed, 07 Mar 2012 23:59:55 +0000 From: Roni even In-reply-to: X-Originating-IP: [172.24.1.46] To: "Ali C. Begen (abegen)" , Roni Even , "payload@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [payload] WGLC for draft-ietf-payload-vp8-03 ending March 1st Thread-index: AczrRVxjReHrfWv2TROUTdcmKeO0cAOt+NyQAKIVnyAADizuzQ== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4f535b8d.0b5f0e0a.0445.ffffd49a@mx.google.com> Subject: Re: [payload] WGLC for draft-ietf-payload-vp8-03 ending March 1st X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 00:00:09 -0000 Ali, There was a comment from Stephan which I think need discussion since I think it make sense Roni ________________________________________ From: payload-bounces@ietf.org [payload-bounces@ietf.org] on behalf of Ali C. Begen (abegen) [abegen@cisco.com] Sent: Wednesday, March 07, 2012 19:14 To: Roni Even; payload@ietf.org Subject: Re: [payload] WGLC for draft-ietf-payload-vp8-03 ending March 1st Thanks Roni, are there any other reviews? I will extend the review period till the 21st. Please provide your comments to the list. -acbegen > -----Original Message----- > From: Roni Even [mailto:ron.even.tlv@gmail.com] > Sent: Sunday, March 04, 2012 7:09 AM > To: Ali C. Begen (abegen); payload@ietf.org > Subject: RE: [payload] WGLC for draft-ietf-payload-vp8-03 ending March 1st > > Hi, > Sorry for the late review. > I have some comments. > > 1. In section 4.2 the PictureID definition talk about the msb being a flag. > Why not show it in figure 2. > > 2. The first paragraph in section 4.3 talk about 10 octets version of the > uncompressed data chunk, I could not find where the 10 octet version is > specified. The example in 4.5.1 has the 3 octets version. > > > 3. In the example in 4.5.2 is this a discardable packet in which case N > should be 1. > > 4. In section 6.2.1 the reference to SDP should be RFC 4566. Also in payload > specification we typically use the media subtype and not MIME subtype. > > Roni Even > As individual > > > -----Original Message----- > > From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On > > Behalf Of Ali C. Begen (abegen) > > Sent: Tuesday, February 14, 2012 8:35 PM > > To: payload@ietf.org > > Subject: [payload] WGLC for draft-ietf-payload-vp8-03 ending March 1st > > > > WG, > > > > This is to start the WGLC for the VP8 draft. > > https://datatracker.ietf.org/doc/draft-ietf-payload-vp8/ > > > > Please send your comments and approvals to the payload list by March > > 1st. > > > > Authors, you need to separate the references as informative vs. > > normative but please wait till the WGLC ends for a revision. > > > > -acbegen > > _______________________________________________ > > payload mailing list > > payload@ietf.org > > https://www.ietf.org/mailman/listinfo/payload _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload From abegen@cisco.com Wed Mar 7 16:06:11 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D86FB11E809A for ; Wed, 7 Mar 2012 16:06:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.349 X-Spam-Level: X-Spam-Status: No, score=-10.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6hJlb2Yev3b3 for ; Wed, 7 Mar 2012 16:06:10 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id B91BA11E808C for ; Wed, 7 Mar 2012 16:06:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=2982; q=dns/txt; s=iport; t=1331165170; x=1332374770; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=PkHVaxGD9IJfuLXokcEsxGfjz+0WrpZgZRIskQ/is8s=; b=Ef1ZLv+ZVnDKBK9q7vxLcVtPDGPPzRVd+2FZhADqC0bI1yk3ZBIKfe9l yNyofacgFKKudsf83hiM6tzgc6bzQ6Zl5F/HR+KLUaArFFRqRa23jZn27 z/EPXjl02hLVBWNdb08etXzmnV1HXrKwVcaQQOAZx/Yh2rrVL4zBMX/Mt s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALH2V0+rRDoG/2dsb2JhbABEtSeBB4IDBwEBAQQBAQEPAVsXBAIBCBEEAQELHQchBgsUCQgBAQQBEggahSYHgjgBC5pdAZ53BIk5hlNjBKBihHaCYw X-IronPort-AV: E=Sophos;i="4.73,549,1325462400"; d="scan'208";a="32472320" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 08 Mar 2012 00:06:10 +0000 Received: from xht-rcd-x02-p.cisco.com (xht-rcd-x02-p.cisco.com [173.37.178.213]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2806AoS029743; Thu, 8 Mar 2012 00:06:10 GMT Received: from xmb-rcd-x01-p.cisco.com ([169.254.3.137]) by xht-rcd-x02-p.cisco.com ([173.37.178.213]) with mapi id 14.02.0283.003; Wed, 7 Mar 2012 16:06:09 -0800 From: "Ali C. Begen (abegen)" To: Roni even , Roni Even , "payload@ietf.org" Thread-Topic: [payload] WGLC for draft-ietf-payload-vp8-03 ending March 1st Thread-Index: AczrRVxjReHrfWv2TROUTdcmKeO0cAOt+NyQAKIVnyAADizuzQAAOdvA Date: Thu, 8 Mar 2012 00:06:09 +0000 Message-ID: References: <4f535b8d.0b5f0e0a.0445.ffffd49a@mx.google.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.37.178.200] x-tm-as-product-ver: SMEX-10.0.0.4211-6.800.1017-18760.001 x-tm-as-result: No--49.087800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [payload] WGLC for draft-ietf-payload-vp8-03 ending March 1st X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 00:06:12 -0000 Yes, I expect the authors will discuss his and your review in the list.=20 -acbegen > -----Original Message----- > From: Roni even [mailto:Even.roni@huawei.com] > Sent: Wednesday, March 07, 2012 7:00 PM > To: Ali C. Begen (abegen); Roni Even; payload@ietf.org > Subject: RE: [payload] WGLC for draft-ietf-payload-vp8-03 ending March 1s= t >=20 > Ali, > There was a comment from Stephan which I think need discussion since I th= ink it make sense > Roni >=20 > ________________________________________ > From: payload-bounces@ietf.org [payload-bounces@ietf.org] on behalf of Al= i C. Begen (abegen) [abegen@cisco.com] > Sent: Wednesday, March 07, 2012 19:14 > To: Roni Even; payload@ietf.org > Subject: Re: [payload] WGLC for draft-ietf-payload-vp8-03 ending March 1s= t >=20 > Thanks Roni, are there any other reviews? I will extend the review period= till the 21st. Please provide your comments to the > list. >=20 > -acbegen >=20 > > -----Original Message----- > > From: Roni Even [mailto:ron.even.tlv@gmail.com] > > Sent: Sunday, March 04, 2012 7:09 AM > > To: Ali C. Begen (abegen); payload@ietf.org > > Subject: RE: [payload] WGLC for draft-ietf-payload-vp8-03 ending March = 1st > > > > Hi, > > Sorry for the late review. > > I have some comments. > > > > 1. In section 4.2 the PictureID definition talk about the msb being a f= lag. > > Why not show it in figure 2. > > > > 2. The first paragraph in section 4.3 talk about 10 octets version of t= he > > uncompressed data chunk, I could not find where the 10 octet version is > > specified. The example in 4.5.1 has the 3 octets version. > > > > > > 3. In the example in 4.5.2 is this a discardable packet in which case N > > should be 1. > > > > 4. In section 6.2.1 the reference to SDP should be RFC 4566. Also in pa= yload > > specification we typically use the media subtype and not MIME subtype. > > > > Roni Even > > As individual > > > > > -----Original Message----- > > > From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On > > > Behalf Of Ali C. Begen (abegen) > > > Sent: Tuesday, February 14, 2012 8:35 PM > > > To: payload@ietf.org > > > Subject: [payload] WGLC for draft-ietf-payload-vp8-03 ending March 1s= t > > > > > > WG, > > > > > > This is to start the WGLC for the VP8 draft. > > > https://datatracker.ietf.org/doc/draft-ietf-payload-vp8/ > > > > > > Please send your comments and approvals to the payload list by March > > > 1st. > > > > > > Authors, you need to separate the references as informative vs. > > > normative but please wait till the WGLC ends for a revision. > > > > > > -acbegen > > > _______________________________________________ > > > payload mailing list > > > payload@ietf.org > > > https://www.ietf.org/mailman/listinfo/payload >=20 > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload From pravindran@sonusnet.com Thu Mar 8 02:12:38 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F31A21F85F6 for ; Thu, 8 Mar 2012 02:12:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.148 X-Spam-Level: X-Spam-Status: No, score=-2.148 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cizDduWtuLxX for ; Thu, 8 Mar 2012 02:12:33 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id CAD3021F85F2 for ; Thu, 8 Mar 2012 02:12:32 -0800 (PST) Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q28ADGQc007352; Thu, 8 Mar 2012 05:13:16 -0500 Received: from USMA-EX-HUB1.sonusnet.com ([66.203.90.16]) by sonusmail04.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Mar 2012 05:12:26 -0500 Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by usma-ex-hub1.sonusnet.com (66.203.90.16) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 8 Mar 2012 05:12:32 -0500 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0355.002; Thu, 8 Mar 2012 15:42:22 +0530 From: "Ravindran, Parthasarathi" To: "Chhatwal, Harprit S" Thread-Topic: [payload] FW: I-D Action: draft-muthu-payload-offer-answer-g723-g729-00.txt Thread-Index: AQHM9558hTwO4SBBr0mKhi94da3KlZZgNRYw Date: Thu, 8 Mar 2012 10:12:21 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E1F7F40@inba-mail01.sonusnet.com> References: <1D062974A4845E4D8A343C653804920207ABB1E1@XMB-BGL-414.cisco.com> <4F4BB973.4060508@alum.mit.edu> <4F4D06B6.6020905@digium.com> <4F4D17C8.7070201@alum.mit.edu> <4F4D26AE.5070009@digium.com> <4F4D40A3.6030309@digium.com> <4F4E44C3.4080803@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E06BEC7@inba-mail01.sonusnet.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.67] Content-Type: multipart/alternative; boundary="_000_387F9047F55E8C42850AD6B3A7A03C6C0E1F7F40inbamail01sonus_" MIME-Version: 1.0 X-OriginalArrivalTime: 08 Mar 2012 10:12:26.0447 (UTC) FILETIME=[F63F95F0:01CCFD13] Cc: "payload@ietf.org" Subject: Re: [payload] FW: I-D Action: draft-muthu-payload-offer-answer-g723-g729-00.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 10:12:38 -0000 --_000_387F9047F55E8C42850AD6B3A7A03C6C0E1F7F40inbamail01sonus_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Harpit, Sorry for the delay reply. I didn't fully understand your network. My guess is that in case of bandwi= dth constrained in one direction of the session, then the low-bandwidth cod= ec has to be negotiated in that direction. ISTM, asymmetric annexb paramete= r negotiation is not going to solve the bandwidth issue. Please let me know= how asymmetric annexb will solve bandwidth issue. AFAIK, answerer expectation of asymmetric annexb will leads to the interop = issue in case of offerer mentions as "annexb=3Dno" but answerer mandates to= have "annexb=3Dyes". Please let me know your opinion on the same. Thanks Partha From: Chhatwal, Harprit S [mailto:hschhatwal@gmail.com] Sent: Thursday, March 01, 2012 4:59 PM To: Ravindran, Parthasarathi Cc: Paul Kyzivat; Kevin P. Fleming; payload@ietf.org Subject: Re: [payload] FW: I-D Action: draft-muthu-payload-offer-answer-g72= 3-g729-00.txt On 1 March 2012 06:13, Ravindran, Parthasarathi > wrote: I'm not very clear on the bandwidth optimization based on asymmetric annexb= parameter negotiation. Could you please elaborate. This is for a network where the bandwidth is severely constrained in one di= rection, so the operator wishes to use G.729B to minimise bandwidth usage i= n one direction, while not using G.729B in the other direction where bandwi= dth is less constrained. Regards. Harprit. Harprit S. Chhatwal InnoMedia On 1 March 2012 06:13, Ravindran, Parthasarathi > wrote: Hi Harpit, Thanks for looking into the draft. I agree with you that asymmetric annexb = negotiation is not taken into the account in the draft currently. In fact, = I come across the scenario wherein annexb is not supported by offerer ,ment= ioned in offer SDP as annexb=3Dno and answerer assumes about annexb support= (no annexb parameter in answer) in offerer side which leads to the call fa= ilure. I'm not very clear on the bandwidth optimization based on asymmetric annexb= parameter negotiation. Could you please elaborate. Thanks Partha >-----Original Message----- >From: payload-bounces@ietf.org [mailto:pa= yload-bounces@ietf.org] On >Behalf Of Paul Kyzivat >Sent: Wednesday, February 29, 2012 9:01 PM >To: Chhatwal, Harprit S >Cc: payload@ietf.org >Subject: Re: [payload] FW: I-D Action: draft-muthu-payload-offer-answer- >g723-g729-00.txt > >On 2/29/12 9:34 AM, Chhatwal, Harprit S wrote: >> On 28 February 2012 21:01, Kevin P. Fleming >> >> wrote: >> >> >> That requirement is counter to what the draft proposes. We can't >> have it both ways: either the G.729 'annexb' format parameter is a >> negotiated parameter (in which case its usage is symmetrical by >> definition) or it is a declarative parameter (in which case the >> usage can be, but is not required to be, asymmetrical). >> >> >> Yes, I concur that the draft (as it currently stands) cannot >> accommodate an asymmetric use of G.729B. However, if we agree that >> both scenarios are true, real-world scenarios that need addressing, ie >> (a) the negotiated case where the use of G.729B is symmetric and (b) >> the declarative case where the use of G.729B can be asymmetric (and, >> in my opinion, both are valid scenarios), then I would suggest that we >> need to come up with a way of handling both situations (perhaps >> through the use of an extra fmtp parameter indicating whether the use >> is declarative or negotiated - or any other suggestions the group >might have). >> >> If not, and we are only to allow the negotiated, symmetric use, then >> I'd appreciate any suggestions from the group for how my organisation >> might deal with the requirement of an asymmetric use of G.729B >mentioned below. > >There is one way that is available right now: > >Negotiate two separate one way m-lines. >But this might be too weird for common use. > > Thanks, > Paul > >> Regards. Harprit. >> >> Harprit S. Chhatwal >> InnoMedia >> >> On 28 February 2012 21:01, Kevin P. Fleming >> >> wrote: >> >> On 02/28/2012 02:58 PM, Chhatwal, Harprit S wrote: >> >> Speaking as a codec person :-), I think the draft does address >a >> real >> issue and is reasonably clear in its content. However, it >does not >> appear to address (as far as I can see), the case where an >> asymmetric >> use of G.729B is required. This is an actual issue as we are >> faced with >> a customer requirement where the use of G.729B is required in >one >> direction and not the other (for bandwidth reasons). Given >the >> current >> specs do not appear to definitively cover this case, it would >be >> good to >> see if this can be addressed through the proposed draft. >> >> >> That requirement is counter to what the draft proposes. We can't >> have it both ways: either the G.729 'annexb' format parameter is a >> negotiated parameter (in which case its usage is symmetrical by >> definition) or it is a declarative parameter (in which case the >> usage can be, but is not required to be, asymmetrical). >> >> >> Regards. Harprit. >> >> Harprit S. Chhatwal >> InnoMedia >> >> On 28 February 2012 19:10, Kevin P. Fleming >> > >> >>> >wrote: >> >> On 02/28/2012 12:07 PM, Paul Kyzivat wrote: >> >> Clarification: >> >> In my comments on the draft I was not questioning the >> assumption >> of that >> draft that a common value of this parameter is >> *negotiated* via O/A. >> *If* you accept that assumption then my comments >> hopefully make >> sense. >> >> But if there is debate regarding whether the parameter >is >> negotiated or >> declarative, then that needs to be settled first, >before >> nailing >> down >> clarifications for how the negotiation happens. >> >> Not being a codec person, I don't know what the common >> practice >> is here. >> So I'm going to let those that have the knowledge >argue >> that. >> >> >> Correct on all points; your comments make complete sense >if >> 'annexb' >> is intended to be a negotiated parameter. >> >> I'm not a codec person (although I'd probably be willing >to >> play one >> on TV is the need arose ), but there are so many other >> codec/format parameters that are declarative already that >I >> don't >> see any need for this one to have to be negotiated. The >> impact of >> using Annex B or not is purely on one direction of the >media >> stream, >> and it's not even mandatory that the encoder use Annex B >> mode just >> because 'annexb=3Dyes'. Granted, it's pretty unlikely that >an >> implementation that cannot accept incoming SID frames >would >> also be >> able to generate them, but I can think of completely >reasonable >> situations for an implementation that can generate them >being >> willing to do so while at the same time disallowing >> reception of them. >> >> >> >> Thanks, >> Paul >> >> On 2/28/12 12:34 PM, Chhatwal, Harprit S wrote: >> >> Kevin, >> >> First of all, from RFC3264, I agree with you that >> for things >> like IP >> addresses, ports, payload types, ptime, the SDP >that one >> party sends >> indicates the address/port/PT/ptime that the >sender >> would >> like to >> receive on. However, I don't believe this is >generally >> correct for all >> parameters. For instance, for codecs (again from >> RFC3264), >> the codec(s) >> included in an SDP offer indicates the codec(s) >the >> offerer >> is willing >> to send AND receive (if the directional attribute >is >> 'sendrecv'). As an >> example, if party A is the offerer and sends G.729 >& >> G.711 >> in its SDP >> offer, it is saying that it is willing to use >either >> codec. >> If the >> answerer replies with G.711, then it is only >willing >> to use >> G.711, and >> then G.729 will not be used in either direction. >> >> Turning now to silence suppression, the situation >> does not >> seem very >> clear. This is what RFC3264 has to say about fmtp >> parameters >> such as >> 'annexb' : >> >> The interpretation of fmtp parameters in an offer >> depends on the >> >> parameters. In many cases, those parameters >describe >> specific >> >> configurations of the media format, and should >> therefore be >> processed >> >> as the media format value itself would be. This >> means that >> the same >> >> fmtp parameters with the same values MUST be >present >> in the >> answer if >> >> the media format they describe is present in the >answer. >> Other fmtp >> >> parameters are more like parameters, for which it >is >> perfectly >> >> acceptable for each agent to use different values. >> In that >> case, the >> >> answer MAY contain fmtp parameters, and those MAY >> have the same >> >> values as those in the offer, or they MAY be >> different. SDP >> >> extensions that define new parameters SHOULD >specify >> the proper >> >> interpretation in offer/answer. >> >> To me, 'annexb' is more like a parameter in this >> sense and, >> in this >> case, everything is allowed - the answer may >contain the >> same fmtp or >> different. RFC3264 doesn't appear to specify the >> interpretation. The >> problem is that I don't know of anywhere else >where the >> interpretation >> is specified either. RFC4856 specifies the >parameter >> 'annexb', but >> doesn't say whether it can be used asymmetrically >> (or how). >> The only >> other guidance I can find on this is elsewhere in >> RFC3264: >> >> The list of media formats for each media stream >> conveys two >> pieces of >> >> information, namely the set of formats (codecs and >any >> parameters >> >> associated with the codec, in the case of RTP) >that the >> offerer is >> >> capable of sending and/or receiving (depending on >> the direction >> >> attributes)... >> >> ...For a sendrecv stream, the offer SHOULD >indicate >> those >> >> codecs that the offerer is willing to send and >> receive with. >> >> So, this appears to be lumping codec parameters >with >> codecs >> and so both >> should behave in the same way. If we take this >> interpretation, then >> indicating 'annexb=3Dno' indicates that the sender >of >> this SDP >> is willing >> to send and receive with silence suppression off. >So, >> according to >> this, if the offerer sends 'annexb=3Dyes' in the >offer >> and the >> answerer >> sends back 'annexb=3Dno', then there is a mismatch >and the >> offerer should >> send a re-INVITE with 'annexb=3Dno' to resolve the >> conflict. >> According to >> this interpretation, we cannot have an asymmetric >> use of silence >> suppression. However, from the discussion we're >> having, I >> can see that >> all of this is somewhat open to interpretation >> (since the >> specs do not >> seem to be clear) and I agree with the authors of >> this ID >> that we need >> some clarification as to how this issue should be >> dealt with >> (and >> whether asymmetric use of annexb should be allowed >> and, if >> so, how). >> >> >> Regards. Harprit. >> >> >> Harprit S. Chhatwal >> >> InnoMedia >> >> >> On 28 February 2012 16:54, Kevin P. Fleming >> > >> >> >> > >> >> >>>__> >> >> wrote: >> >> On 02/27/2012 11:12 AM, Paul Kyzivat wrote: >> >> On 2/27/12 6:33 AM, Muthu Arul Mozhi Perumal >> (mperumal) wrote: >> >> We have submitted an I-D clarifying the >offer/answer >> considerations for >> the Annex A flavor of G.723 and the Annex B >flavors of >> G.729, G.729D and >> G.729E. This clarification is missing in RFC 4856, >> leading >> to interop >> issues, for e.g: >> http://sipforum.org/pipermail/______discussion/2008- >January/______004026.html >> January/____004026.html> >> __January/__004026.html >> January/__004026.html>> >> ____January/004026.html >> >> > > >> >> __January/004026.html >> >> >> >> >> We have a couple of open items in the I-D. We >expect >> the WG >> discussions >> would guide us on how to go about them. >> >> Comments welcome. >> >> >> I'm the source of the issues. :-) >> >> The fundamental point is that RFC4856 specifies a >> *default* >> value of >> "yes" for annexa and annexb. This means that if >> annexa/annexb is not >> specified in an answer, then it will default to >yes, >> even if the >> offer >> contained "no". >> >> I see a few ways to fix this: >> >> 1) revise the IANA registration for annexa and >annexb to >> remove the >> default, at least when used with O/A. Instead >> specify the >> defaulting >> separately for offers and answers. >> >> 2) REQUIRE that the answer contain "no" if the >offer >> contained "no". >> >> 3) permit the answer to contain "yes" (explicitly >or >> by default) >> when the offer contained "no", and specify that >this >> still means >> that the annex is *not* to be used. >> >> 4) forbid the answer from *explicitly* containing >> "yes" when the >> offer contained "no", but allow the answer to >> *implicitly* >> contain >> "yes" (via the default) and ignore it/treat it as "no". >> >> None of these are ideal. (1) is problematic >because >> this is >> used in >> non-O/A contexts, such as RSVP. (2) begs the >> question of what >> should be >> done if this is violated. (3) risks failing to >> recognize that >> the two >> sides disagree. (4) is pragmatic but seems to >> violate the >> spirit of >> defaults. >> >> I guess my preference is to make (2) normative for >> the answerer, >> while >> making (4) normative for the offerer, and put >enough >> words >> in so its >> very clear what is being specified and why. >> >> >> I must *really* be missing something here; why >does >> the usage of >> G.729 Annex B have to be symmetrical? Until I saw >this >> thread, it >> was always my understanding that the 'annexb' >format >> parameter for >> G.729 in SDP indicated the preference of the >endpoint >> sending that >> parameter. Like nearly everything else in SDP, it >> indicates what >> that endpoint is *prepared to accept*, and has >> nothing at >> all to do >> with what it will (or could) send. >> >> Unless that's a completely broken understanding, >> then these >> 'interop' issues are really just very poorly coded >> implementations. >> I would interpret the current RFC language as >follows: >> >> 1) If an offer/answer contains 'annexb=3Dno', the >> receiver of that >> offer/answer MUST NOT send G.729 Annex B SID >frames >> to the >> offering/answering endpoint. >> >> 2) If an offer/answer contains 'annexb=3Dyes', the >> receiver of >> that >> offer/answer SHOULD send G.729 Annex B SID frames >to the >> offering/answering endpoint. >> >> 3) An answer's value for the 'annexb' parameter is >> completely >> independent of the value (if any) present in the >> offer it is >> answering. >> >> >> Thanks, >> Paul >> >> Muthu >> >> -----Original Message----- >> From: i-d-announce-bounces@ietf.org >> > >> __iet= f.org >> >> >> >> >____= ietf.org >> __iet= f.org >> >>> >> [mailto:i-d-announce-bounces@ >> > >> >> >>___= ___ietf.org > >> >> >> >____= ietf.org >> __iet= f.org >> >>>] On Behalf Of >> internet-drafts@ietf.org > >> __org >> >> >> . >> .>____org >> >> __org >> >>> >> Sent: Friday, February 24, 2012 5:57 PM >> To: i-d-announce@ietf.org >> > >> >> >> > >> >announce@ietf.org>>__> >> Subject: I-D Action: >> >> draft-muthu-payload-offer-______answer-g723-g729-00.txt >> >> >> >> A New Internet-Draft is available from the on-line >> Internet-Drafts >> directories. >> >> Title : Offer/Answer Considerations for G.723 >Annex A >> and G.729 Annex B >> Author(s) : Muthu Arul Mozhi Perumal >> Parthasarathi Ravindran >> Filename : >> >> draft-muthu-payload-offer-______answer-g723-g729-00.txt >> >> Pages : 8 >> Date : 2012-02-24 >> >> [RFC4856] describes the annexa parameter for G723 >> and the annexb >> parameter for G729, G729D and G729E. However, the >> specification does >> not describe the offerer and answerer behavior >when the >> value of the >> annexa or annexb parameter does not match in the >SDP >> offer and >> answer. This document provides the offer/answer >> considerations for >> these parameters. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-______drafts/draft-muthu-payload- >______offer-answer-g72 >> ____offer-answer-g72> >> ____offer-answer-g72 >> >> > wer-g72>> >> >> >> ____offer-answer-g72 >> __offer-answer-g72> >> __offer-answer-g72 >> >> > g72>>> >> >> 3-g729-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-muthu-payload- >______offer-answer-g723 >> ____offer-answer-g723> >> ____offer-answer-g723 >> >> > er-g723>> >> >> >> ____offer-answer-g723 >> __offer-answer-g723> >> __offer-answer-g723 >> >> > 723>>> >> >> -g729-00.txt >> >> >> _____________________________________________________ >> >> I-D-Announce mailing list >> I-D-Announce@ietf.org > >> >> >> > >> >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 >> >> > > >> > >> > >> >> >> >> >> _____________________________________________________ >> >> payload mailing list >> payload@ietf.org > >> >> >> > >> >>> >> https://www.ietf.org/mailman/______listinfo/payload >> >> > > >> >> > >> > >> >> >> >> >> -- >> 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 > >> >> >> _____________________________________________________ >> >> payload mailing list >> payload@ietf.org > >> >> >> > >> >>> >> https://www.ietf.org/mailman/______listinfo/payload >> >> > > >> >> > >> > >> >> >> >> >> >> >> -- >> 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 >> >> >> >> >> >> -- >> 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 >> >> > >_______________________________________________ >payload mailing list >payload@ietf.org >https://www.ietf.org/mailman/listinfo/payload --_000_387F9047F55E8C42850AD6B3A7A03C6C0E1F7F40inbamail01sonus_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Harpit,

 <= /p>

Sorry for the delay reply= .

 <= /p>

I didn’t fully unde= rstand your network. My guess is that  in case of bandwidth constraine= d in one direction of the session, then the low-bandwidth codec has to be negotiated in that direction. ISTM, asymmetric annexb parameter nego= tiation is not going to solve the bandwidth issue. Please let me know how a= symmetric annexb will solve bandwidth issue.

 <= /p>

AFAIK, answerer expectati= on of asymmetric annexb will leads to the interop issue in case of offerer = mentions as “annexb=3Dno” but answerer mandates to have “= annexb=3Dyes”.  Please let me know your opinion on the same.

Thanks
Partha

 <= /p>

 <= /p>

 <= /p>

From: Chhatwal= , Harprit S [mailto:hschhatwal@gmail.com]
Sent: Thursday, March 01, 2012 4:59 PM
To: Ravindran, Parthasarathi
Cc: Paul Kyzivat; Kevin P. Fleming; payload@ietf.org
Subject: Re: [payload] FW: I-D Action: draft-muthu-payload-offer-ans= wer-g723-g729-00.txt

 

On 1 March 2012 06:13, Ravindran, Parthasarathi = ;<pravindran@sonusnet.com= > wrote:

I'm not very clear on= the bandwidth optimization based on asymmetric annexb parameter negotiatio= n. Could you please elaborate.

 

This is for a network where the bandwidth is severel= y constrained in one direction, so the operator wishes to use G.729B to min= imise bandwidth usage in one direction, while not using G.729B in the other= direction where bandwidth is less constrained.

 

Regards.  Harprit.

 

Harprit S. Chhatwal

InnoMedia

 

On 1 March 2012 06:13, Ravindran, Parthasarathi <= pravindran@sonusnet.com> = wrote:

Hi Harpit,

Thanks for looking into the draft. I agree with you that asymmetric annexb = negotiation is not taken into the account in the draft currently. In fact, = I come across the scenario wherein annexb is not supported by offerer ,ment= ioned in offer SDP as annexb=3Dno and answerer assumes about annexb support (no annexb parameter in answer) = in offerer side which leads to the call failure.

I'm not very clear on the bandwidth optimization based on asymmetric annexb= parameter negotiation. Could you please elaborate.

Thanks
Partha


>-----Original Message-----
>From: payload-bounces@ietf.= org [mailto:payload-bounces= @ietf.org] On
>Behalf Of Paul Kyzivat
>Sent: Wednesday, February 29, 2012 9:01 PM
>To: Chhatwal, Harprit S
>Cc: payload@ietf.org
>Subject: Re: [payload] FW: I-D Action: draft-muthu-payload-offer-answer= -
>g723-g729-00.txt
>
>On 2/29/12 9:34 AM, Chhatwal, Harprit S wrote:
>> On 28 February 2012 21:01, Kevin P. Fleming <kpfleming@digium.com
>> <mailto:kpfleming@digiu= m.com>> wrote:
>>
>>
>>     That requirement is counter to what the draft propos= es. We can't
>>     have it both ways: either the G.729 'annexb' format = parameter is a
>>     negotiated parameter (in which case its usage is sym= metrical by
>>     definition) or it is a declarative parameter (in whi= ch case the
>>     usage can be, but is not required to be, asymmetrica= l).
>>
>>
>> Yes, I concur that the draft (as it currently stands) cannot
>> accommodate an asymmetric use of G.729B.  However, if we agre= e that
>> both scenarios are true, real-world scenarios that need addressing= , ie
>> (a) the negotiated case where the use of G.729B is symmetric and (= b)
>> the declarative case where the use of G.729B can be asymmetric (an= d,
>> in my opinion, both are valid scenarios), then I would suggest tha= t we
>> need to come up with a way of handling both situations (perhaps >> through the use of an extra fmtp parameter indicating whether the = use
>> is declarative or negotiated - or any other suggestions the group<= br> >might have).
>>
>> If not, and we are only to allow the negotiated, symmetric use, th= en
>> I'd appreciate any suggestions from the group for how my organisat= ion
>> might deal with the requirement of an asymmetric use of G.729B
>mentioned below.
>
>There is one way that is available right now:
>
>Negotiate two separate one way m-lines.
>But this might be too weird for common use.
>
>       Thanks,
>       Paul
>
>> Regards.  Harprit.
>>
>> Harprit S. Chhatwal
>> InnoMedia
>>
>> On 28 February 2012 21:01, Kevin P. Fleming <kpfleming@digium.com
>> <mailto:kpfleming@digiu= m.com>> wrote:
>>
>>     On 02/28/2012 02:58 PM, Chhatwal, Harprit S wrote: >>
>>         Speaking as a codec person :-), I thin= k the draft does address
>a
>>         real
>>         issue and is reasonably clear in its c= ontent.  However, it
>does not
>>         appear to address (as far as I can see= ), the case where an
>>         asymmetric
>>         use of G.729B is required.  This = is an actual issue as we are
>>         faced with
>>         a customer requirement where the use o= f G.729B is required in
>one
>>         direction and not the other (for bandw= idth reasons).  Given
>the
>>         current
>>         specs do not appear to definitively co= ver this case, it would
>be
>>         good to
>>         see if this can be addressed through t= he proposed draft.
>>
>>
>>     That requirement is counter to what the draft propos= es. We can't
>>     have it both ways: either the G.729 'annexb' format = parameter is a
>>     negotiated parameter (in which case its usage is sym= metrical by
>>     definition) or it is a declarative parameter (in whi= ch case the
>>     usage can be, but is not required to be, asymmetrica= l).
>>
>>
>>         Regards.  Harprit.
>>
>>         Harprit S. Chhatwal
>>         InnoMedia
>>
>>         On 28 February 2012 19:10, Kevin P. Fl= eming
>>         <kpfleming@digium.com <mailto:kpfleming@digium.com>
>>         <mailto:kpfleming@digium.com <mailto:kpfleming@digium.com>>>
>wrote:
>>
>>             On 02/28/2012 12:07 PM, = Paul Kyzivat wrote:
>>
>>                 Clarificat= ion:
>>
>>                 In my comm= ents on the draft I was not questioning the
>>         assumption
>>                 of that >>                 draft that= a common value of this parameter is
>>         *negotiated* via O/A.
>>                 *If* you a= ccept that assumption then my comments
>>         hopefully make
>>                 sense.
>>
>>                 But if the= re is debate regarding whether the parameter
>is
>>                 negotiated= or
>>                 declarativ= e, then that needs to be settled first,
>before
>>         nailing
>>                 down
>>                 clarificat= ions for how the negotiation happens.
>>
>>                 Not being = a codec person, I don't know what the common
>>         practice
>>                 is here. >>                 So I'm goi= ng to let those that have the knowledge
>argue
>>         that.
>>
>>
>>             Correct on all points; y= our comments make complete sense
>if
>>         'annexb'
>>             is intended to be a nego= tiated parameter.
>>
>>             I'm not a codec person (= although I'd probably be willing
>to
>>         play one
>>             on TV is the need arose = <G>), but there are so many other
>>             codec/format parameters = that are declarative already that
>I
>>         don't
>>             see any need for this on= e to have to be negotiated. The
>>         impact of
>>             using Annex B or not is = purely on one direction of the
>media
>>         stream,
>>             and it's not even mandat= ory that the encoder use Annex B
>>         mode just
>>             because 'annexb=3Dyes'. = Granted, it's pretty unlikely that
>an
>>             implementation that cann= ot accept incoming SID frames
>would
>>         also be
>>             able to generate them, b= ut I can think of completely
>reasonable
>>             situations for an implem= entation that can generate them
>being
>>             willing to do so while a= t the same time disallowing
>>         reception of them.
>>
>>
>>
>>                 Thanks, >>                 Paul
>>
>>                 On 2/28/12= 12:34 PM, Chhatwal, Harprit S wrote:
>>
>>                   &nb= sp; Kevin,
>>
>>                   &nb= sp; First of all, from RFC3264, I agree with you that
>>         for things
>>                   &nb= sp; like IP
>>                   &nb= sp; addresses, ports, payload types, ptime, the SDP
>that one
>>                   &nb= sp; party sends
>>                   &nb= sp; indicates the address/port/PT/ptime that the
>sender
>>         would
>>                   &nb= sp; like to
>>                   &nb= sp; receive on. However, I don't believe this is
>generally
>>                   &nb= sp; correct for all
>>                   &nb= sp; parameters. For instance, for codecs (again from
>>         RFC3264),
>>                   &nb= sp; the codec(s)
>>                   &nb= sp; included in an SDP offer indicates the codec(s)
>the
>>         offerer
>>                   &nb= sp; is willing
>>                   &nb= sp; to send AND receive (if the directional attribute
>is
>>                   &nb= sp; 'sendrecv'). As an
>>                   &nb= sp; example, if party A is the offerer and sends G.729
>&
>>         G.711
>>                   &nb= sp; in its SDP
>>                   &nb= sp; offer, it is saying that it is willing to use
>either
>>         codec.
>>                   &nb= sp; If the
>>                   &nb= sp; answerer replies with G.711, then it is only
>willing
>>         to use
>>                   &nb= sp; G.711, and
>>                   &nb= sp; then G.729 will not be used in either direction.
>>
>>                   &nb= sp; Turning now to silence suppression, the situation
>>         does not
>>                   &nb= sp; seem very
>>                   &nb= sp; clear. This is what RFC3264 has to say about fmtp
>>         parameters
>>                   &nb= sp; such as
>>                   &nb= sp; 'annexb' :
>>
>>                   &nb= sp; The interpretation of fmtp parameters in an offer
>>         depends on the
>>
>>                   &nb= sp; parameters. In many cases, those parameters
>describe
>>         specific
>>
>>                   &nb= sp; configurations of the media format, and should
>>         therefore be
>>                   &nb= sp; processed
>>
>>                   &nb= sp; as the media format value itself would be. This
>>         means that
>>                   &nb= sp; the same
>>
>>                   &nb= sp; fmtp parameters with the same values MUST be
>present
>>         in the
>>                   &nb= sp; answer if
>>
>>                   &nb= sp; the media format they describe is present in the
>answer.
>>                   &nb= sp; Other fmtp
>>
>>                   &nb= sp; parameters are more like parameters, for which it
>is
>>         perfectly
>>
>>                   &nb= sp; acceptable for each agent to use different values.
>>         In that
>>                   &nb= sp; case, the
>>
>>                   &nb= sp; answer MAY contain fmtp parameters, and those MAY
>>         have the same
>>
>>                   &nb= sp; values as those in the offer, or they MAY be
>>         different. SDP
>>
>>                   &nb= sp; extensions that define new parameters SHOULD
>specify
>>         the proper
>>
>>                   &nb= sp; interpretation in offer/answer.
>>
>>                   &nb= sp; To me, 'annexb' is more like a parameter in this
>>         sense and,
>>                   &nb= sp; in this
>>                   &nb= sp; case, everything is allowed - the answer may
>contain the
>>                   &nb= sp; same fmtp or
>>                   &nb= sp; different. RFC3264 doesn't appear to specify the
>>                   &nb= sp; interpretation. The
>>                   &nb= sp; problem is that I don't know of anywhere else
>where the
>>                   &nb= sp; interpretation
>>                   &nb= sp; is specified either. RFC4856 specifies the
>parameter
>>                   &nb= sp; 'annexb', but
>>                   &nb= sp; doesn't say whether it can be used asymmetrically
>>         (or how).
>>                   &nb= sp; The only
>>                   &nb= sp; other guidance I can find on this is elsewhere in
>>         RFC3264:
>>
>>                   &nb= sp; The list of media formats for each media stream
>>         conveys two
>>                   &nb= sp; pieces of
>>
>>                   &nb= sp; information, namely the set of formats (codecs and
>any
>>                   &nb= sp; parameters
>>
>>                   &nb= sp; associated with the codec, in the case of RTP)
>that the
>>                   &nb= sp; offerer is
>>
>>                   &nb= sp; capable of sending and/or receiving (depending on
>>         the direction
>>
>>                   &nb= sp; attributes)...
>>
>>                   &nb= sp; ...For a sendrecv stream, the offer SHOULD
>indicate
>>         those
>>
>>                   &nb= sp; codecs that the offerer is willing to send and
>>         receive with.
>>
>>                   &nb= sp; So, this appears to be lumping codec parameters
>with
>>         codecs
>>                   &nb= sp; and so both
>>                   &nb= sp; should behave in the same way. If we take this
>>                   &nb= sp; interpretation, then
>>                   &nb= sp; indicating 'annexb=3Dno' indicates that the sender
>of
>>         this SDP
>>                   &nb= sp; is willing
>>                   &nb= sp; to send and receive with silence suppression off.
>So,
>>                   &nb= sp; according to
>>                   &nb= sp; this, if the offerer sends 'annexb=3Dyes' in the
>offer
>>         and the
>>                   &nb= sp; answerer
>>                   &nb= sp; sends back 'annexb=3Dno', then there is a mismatch
>and the
>>                   &nb= sp; offerer should
>>                   &nb= sp; send a re-INVITE with 'annexb=3Dno' to resolve the
>>         conflict.
>>                   &nb= sp; According to
>>                   &nb= sp; this interpretation, we cannot have an asymmetric
>>         use of silence
>>                   &nb= sp; suppression. However, from the discussion we're
>>         having, I
>>                   &nb= sp; can see that
>>                   &nb= sp; all of this is somewhat open to interpretation
>>         (since the
>>                   &nb= sp; specs do not
>>                   &nb= sp; seem to be clear) and I agree with the authors of
>>         this ID
>>                   &nb= sp; that we need
>>                   &nb= sp; some clarification as to how this issue should be
>>         dealt with
>>                   &nb= sp; (and
>>                   &nb= sp; whether asymmetric use of annexb should be allowed
>>         and, if
>>                   &nb= sp; so, how).
>>
>>
>>                   &nb= sp; Regards. Harprit.
>>
>>
>>                   &nb= sp; Harprit S. Chhatwal
>>
>>                   &nb= sp; InnoMedia
>>
>>
>>                   &nb= sp; On 28 February 2012 16:54, Kevin P. Fleming
>>         <kpfleming@digium.com <mailto:kpfleming@digium.com>
>>         <mailto:kpfleming@digium.com <mailto:kpfleming@digium.com>>
>>         <mailto:kpfleming@digium.com <mailto:kpfleming@digium.com>
>>         <mailto:kpfleming@digium.com
>> <mailto:kpfleming@digiu= m.com>>>__>
>>
>>                   &nb= sp; wrote:
>>
>>                   &nb= sp; On 02/27/2012 11:12 AM, Paul Kyzivat wrote:
>>
>>                   &nb= sp; On 2/27/12 6:33 AM, Muthu Arul Mozhi Perumal
>>         (mperumal) wrote:
>>
>>                   &nb= sp; We have submitted an I-D clarifying the
>offer/answer
>>                   &nb= sp; considerations for
>>                   &nb= sp; the Annex A flavor of G.723 and the Annex B
>flavors of
>>                   &nb= sp; G.729, G.729D and
>>                   &nb= sp; G.729E. This clarification is missing in RFC 4856,
>>         leading
>>                   &nb= sp; to interop
>>                   &nb= sp; issues, for e.g:
>>         http://sipforum.org/pipermail/______discussion/2008-
>January/______004026.html
>>         <http://sipforum.org/pipermai= l/____discussion/2008-
>January/____004026.html>
>>         <http://sipforum.org/__piperm= ail/__discussion/2008-
>__January/__004026.html
>>         <http://sipforum.org/pipermail/= __discussion/2008-
>January/__004026.html>>
>>         <http://sipforum.org/____pipe= rmail/discussion/2008-
>____January/004026.html
>>
>> <http://sipforum.org/__pipermail/discu= ssion/2008-__January/004026.html
>> >
>>
>>         <http://sipforum.org/__pipermai= l/discussion/2008-
>__January/004026.html
>>
>> <http://sipforum.org/pipermail/discussion/= 2008-January/004026.html>>>
>>
>>                   &nb= sp; We have a couple of open items in the I-D. We
>expect
>>         the WG
>>                   &nb= sp; discussions
>>                   &nb= sp; would guide us on how to go about them.
>>
>>                   &nb= sp; Comments welcome.
>>
>>
>>                   &nb= sp; I'm the source of the issues. :-)
>>
>>                   &nb= sp; The fundamental point is that RFC4856 specifies a
>>         *default*
>>                   &nb= sp; value of
>>         "yes" for annexa and annexb.= This means that if
>>                   &nb= sp; annexa/annexb is not
>>                   &nb= sp; specified in an answer, then it will default to
>yes,
>>         even if the
>>                   &nb= sp; offer
>>                   &nb= sp; contained "no".
>>
>>                   &nb= sp; I see a few ways to fix this:
>>
>>                   &nb= sp; 1) revise the IANA registration for annexa and
>annexb to
>>                   &nb= sp; remove the
>>                   &nb= sp; default, at least when used with O/A. Instead
>>         specify the
>>                   &nb= sp; defaulting
>>                   &nb= sp; separately for offers and answers.
>>
>>                   &nb= sp; 2) REQUIRE that the answer contain "no" if the
>offer
>>                   &nb= sp; contained "no".
>>
>>                   &nb= sp; 3) permit the answer to contain "yes" (explicitly
>or
>>         by default)
>>                   &nb= sp; when the offer contained "no", and specify that
>this
>>         still means
>>                   &nb= sp; that the annex is *not* to be used.
>>
>>                   &nb= sp; 4) forbid the answer from *explicitly* containing
>>         "yes" when the
>>                   &nb= sp; offer contained "no", but allow the answer to
>>         *implicitly*
>>                   &nb= sp; contain
>>         "yes" (via the default) and = ignore it/treat it as "no".
>>
>>                   &nb= sp; None of these are ideal. (1) is problematic
>because
>>         this is
>>                   &nb= sp; used in
>>                   &nb= sp; non-O/A contexts, such as RSVP. (2) begs the
>>         question of what
>>                   &nb= sp; should be
>>                   &nb= sp; done if this is violated. (3) risks failing to
>>         recognize that
>>                   &nb= sp; the two
>>                   &nb= sp; sides disagree. (4) is pragmatic but seems to
>>         violate the
>>                   &nb= sp; spirit of
>>                   &nb= sp; defaults.
>>
>>                   &nb= sp; I guess my preference is to make (2) normative for
>>         the answerer,
>>                   &nb= sp; while
>>                   &nb= sp; making (4) normative for the offerer, and put
>enough
>>         words
>>                   &nb= sp; in so its
>>                   &nb= sp; very clear what is being specified and why.
>>
>>
>>                   &nb= sp; I must *really* be missing something here; why
>does
>>         the usage of
>>                   &nb= sp; G.729 Annex B have to be symmetrical? Until I saw
>this
>>                   &nb= sp; thread, it
>>                   &nb= sp; was always my understanding that the 'annexb'
>format
>>                   &nb= sp; parameter for
>>                   &nb= sp; G.729 in SDP indicated the preference of the
>endpoint
>>                   &nb= sp; sending that
>>                   &nb= sp; parameter. Like nearly everything else in SDP, it
>>         indicates what
>>                   &nb= sp; that endpoint is *prepared to accept*, and has
>>         nothing at
>>                   &nb= sp; all to do
>>                   &nb= sp; with what it will (or could) send.
>>
>>                   &nb= sp; Unless that's a completely broken understanding,
>>         then these
>>         'interop' issues are really just very = poorly coded
>>                   &nb= sp; implementations.
>>                   &nb= sp; I would interpret the current RFC language as
>follows:
>>
>>                   &nb= sp; 1) If an offer/answer contains 'annexb=3Dno', the
>>         receiver of that
>>                   &nb= sp; offer/answer MUST NOT send G.729 Annex B SID
>frames
>>         to the
>>                   &nb= sp; offering/answering endpoint.
>>
>>                   &nb= sp; 2) If an offer/answer contains 'annexb=3Dyes', the
>>         receiver of
>>                   &nb= sp; that
>>                   &nb= sp; offer/answer SHOULD send G.729 Annex B SID frames
>to the
>>                   &nb= sp; offering/answering endpoint.
>>
>>                   &nb= sp; 3) An answer's value for the 'annexb' parameter is
>>         completely
>>                   &nb= sp; independent of the value (if any) present in the
>>         offer it is
>>                   &nb= sp; answering.
>>
>>
>>                   &nb= sp; Thanks,
>>                   &nb= sp; Paul
>>
>>                   &nb= sp; Muthu
>>
>>                   &nb= sp; -----Original Message-----
>>                   &nb= sp; From: i-d-announce-bou= nces@ietf.org
>>         <mailto:i-d-announce-bounces@ietf.org>
>>         <mailto:i-d-announce-bounces@__ietf.org
>>         <mailto:i-d-announce-bounces@ietf.org>>
>>         <mailto:i-d-announce-bounces@
>>         <mailto:i-d-announce-bounces@>____ietf.org <http://ietf.org>
>>         <mailto:i-d-announce-bounces@__ietf.org
>>         <mailto:i-d-announce-bounces@ietf.org>>>
>>                   &nb= sp; [mailto:i-d-announce-bounces@<= /a>
>>         <mailto:i-d-announce-bounces@>
>>         <mailto:i-d-announce-bounces@
>>         <mailto:i-d-announce-bounces@>>______ietf.org
><http://ietf.org&g= t;
>>         <http://ietf.org>
>>         <mailto:i-d-announce-bounces@
>>         <mailto:i-d-announce-bounces@>____ietf.org <http://ietf.org>
>>         <mailto:i-d-announce-bounces@__ietf.org
>>         <mailto:i-d-announce-bounces@ietf.org>>>] On Beh= alf Of
>>         internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>
>>         <mailto:internet-drafts@ietf.__org
>>         <mailto:internet-drafts@ietf.org>>
>>         <mailto:internet-drafts@ietf.
>> <mailto:internet-drafts= @ietf.>____org
>>
>>         <mailto:internet-drafts@ietf.__org
>>         <mailto:internet-drafts@ietf.org>>>
>>                   &nb= sp; Sent: Friday, February 24, 2012 5:57 PM
>>                   &nb= sp; To: i-d-announce@ietf.org<= br> >>         <mailto:i-d-announce@ietf.org> <mailto:i-d-announce@ietf.org
>>         <mailto:i-d-announce@ietf.org>>
>>         <mailto:i-d-announce@ietf.org <mailto:i-d-announce@ietf.org>
>>         <mailto:i-d-announce@ietf.org <mailto:= i-d-
>announce@ietf.org>>__>= ;
>>                   &nb= sp; Subject: I-D Action:
>>
>> draft-muthu-payload-offer-______answer-g723-g729-00.txt
>>
>>
>>
>>                   &nb= sp; A New Internet-Draft is available from the on-line
>>                   &nb= sp; Internet-Drafts
>>                   &nb= sp; directories.
>>
>>                   &nb= sp; Title : Offer/Answer Considerations for G.723
>Annex A
>>                   &nb= sp; and G.729 Annex B
>>                   &nb= sp; Author(s) : Muthu Arul Mozhi Perumal
>>                   &nb= sp; Parthasarathi Ravindran
>>                   &nb= sp; Filename :
>>
>> draft-muthu-payload-offer-______answer-g723-g729-00.txt
>>
>>                   &nb= sp; Pages : 8
>>                   &nb= sp; Date : 2012-02-24
>>
>>                   &nb= sp; [RFC4856] describes the annexa parameter for G723
>>         and the annexb
>>                   &nb= sp; parameter for G729, G729D and G729E. However, the
>>                   &nb= sp; specification does
>>                   &nb= sp; not describe the offerer and answerer behavior
>when the
>>                   &nb= sp; value of the
>>                   &nb= sp; annexa or annexb parameter does not match in the
>SDP
>>         offer and
>>                   &nb= sp; answer. This document provides the offer/answer
>>                   &nb= sp; considerations for
>>                   &nb= sp; these parameters.
>>
>>
>>                   &nb= sp; A URL for this Internet-Draft is:
>>         http://www.ietf.org/internet-______drafts/draft-muthu-payload-
>______offer-answer-g72
>>         <http://www.ietf.or= g/internet-____drafts/draft-muthu-payload-
>____offer-answer-g72>
>>         <http://www.ietf.or= g/internet-____drafts/draft-muthu-payload-
>____offer-answer-g72
>>
>> <http://www.ietf.org/internet-__drafts= /draft-muthu-payload-__offer-ans
>> wer-g72>>
>>
>>
>>         <http://www.ietf.or= g/internet-____drafts/draft-muthu-payload-
>____offer-answer-g72
>>         <http://www.ietf.org/= internet-__drafts/draft-muthu-payload-
>__offer-answer-g72>
>>         <http://www.ietf.org/= internet-__drafts/draft-muthu-payload-
>__offer-answer-g72
>>
>> <http://www.ietf.org/internet-drafts/d= raft-muthu-payload-offer-answer-
>> g72>>>
>>
>>                   &nb= sp; 3-g729-00.txt
>>
>>                   &nb= sp; Internet-Drafts are also available by anonymous
>FTP at:
>>         ftp://ftp.ietf.org/internet-______drafts/=
>>         <ftp://ftp.ietf.org/internet-____drafts/= >
>>         <ftp://ftp.ietf.org/internet-____drafts/=
>>         <ftp://ftp.ietf.org/internet-__drafts/= >>
>>
>>         <ftp://ftp.ietf.org/internet-____drafts/=
>>         <ftp://ftp.ietf.org/internet-__drafts/= >
>>         <ftp://ftp.ietf.org/internet-__drafts/=
>>         <ftp://ftp.ietf.org/internet-drafts/>= >>
>>
>>                   &nb= sp; This Internet-Draft can be retrieved at:
>>         ftp://ftp.ietf.org/internet-______drafts/draft-muthu-payload-
>______offer-answer-g723
>>         <ftp://ftp.ietf.org/= internet-____drafts/draft-muthu-payload-
>____offer-answer-g723>
>>         <ftp://ftp.ietf.org/= internet-____drafts/draft-muthu-payload-
>____offer-answer-g723
>>
>> <ftp://ftp.ietf.org/internet-__drafts/= draft-muthu-payload-__offer-answ
>> er-g723>>
>>
>>
>>         <ftp://ftp.ietf.org/= internet-____drafts/draft-muthu-payload-
>____offer-answer-g723
>>         <ftp://ftp.ietf.org/in= ternet-__drafts/draft-muthu-payload-
>__offer-answer-g723>
>>         <ftp://ftp.ietf.org/in= ternet-__drafts/draft-muthu-payload-
>__offer-answer-g723
>>
>> <ftp://ftp.ietf.org/internet-drafts/dr= aft-muthu-payload-offer-answer-g
>> 723>>>
>>
>>                   &nb= sp; -g729-00.txt
>>
>>
>> _____________________________________________________
>>
>>                   &nb= sp; I-D-Announce mailing list
>>         I-D-Announce@ietf.org <mailto:I-D-Announce@ietf.org>
>>         <mailto:I-D-Announce@ietf.org <mailto:I-D-Announce@ietf.org>>
>>         <mailto:I-D-Announce@ietf.org <mailto:I-D-Announce@ietf.org>
>>         <mailto:I-D-Announce@ietf.org <mailto:= I-D-
>Announce@ietf.org>>__>= ;
>>         https://www.ietf.org/mailman/______listinfo/i-d-announce
>>         <https://www.ietf.org/mai= lman/____listinfo/i-d-announce>
>>         <https://www.ietf.org/mai= lman/____listinfo/i-d-announce
>>         <https://www.ietf.org/mailm= an/__listinfo/i-d-announce>>
>>
>>         <https://www.ietf.org/mai= lman/____listinfo/i-d-announce
>>         <https://www.ietf.org/mailm= an/__listinfo/i-d-announce>
>>         <https://www.ietf.org/mailm= an/__listinfo/i-d-announce
>>         <https://www.ietf.org/mailman= /listinfo/i-d-announce>>>
>>                   &nb= sp; Internet-Draft directories:
>>         http://www.ietf.org/shadow.______html
>>         <http://www.ietf.org/shadow.____html>=
>>         <http://www.ietf.org/shadow.____html
>>         <http://www.ietf.org/shadow.__html>>=
>>         <http://www.ietf.org/shadow.____html
>>         <http://www.ietf.org/shadow.__html>
>>         <http://www.ietf.org/shadow.__html
>>         <http://www.ietf.org/shadow.html>>>=
>>                   &nb= sp; or ftp://ftp.ietf.org/ietf/______1shadow-sites.txt
>>         <ftp://ftp.ietf.org/ietf/____1shad= ow-sites.txt>
>>         <ftp://ftp.ietf.org/ietf/____1shad= ow-sites.txt
>>         <ftp://ftp.ietf.org/ietf/__1shadow-s= ites.txt>>
>>         <ftp://ftp.ietf.org/ietf/____1shad= ow-sites.txt
>>         <ftp://ftp.ietf.org/ietf/__1shadow-s= ites.txt>
>>         <ftp://ftp.ietf.org/ietf/__1shadow-s= ites.txt
>>         <ftp://ftp.ietf.org/ietf/1shadow-sites= .txt>>>
>>
>>
>>
>> _____________________________________________________
>>
>>                   &nb= sp; payload mailing list
>>         pa= yload@ietf.org <mailto:payload@i= etf.org>
>>         <mailto:payload@ietf.org <mailto:payload@ietf.org>>
>>         <mailto:payload@ietf.org <mailto:payload@ietf.org>
>>         <mailto:payload@ietf.org <mailto:payload@ietf.org>>>
>>         https://www.ietf.org/mailman/______listinfo/payload
>>         <https://www.ietf.org/mailman/= ____listinfo/payload>
>>         <https://www.ietf.org/mailman/= ____listinfo/payload
>>         <https://www.ietf.org/mailman/__= listinfo/payload>>
>>
>>         <https://www.ietf.org/mailman/= ____listinfo/payload
>>         <https://www.ietf.org/mailman/__= listinfo/payload>
>>         <https://www.ietf.org/mailman/__= listinfo/payload
>>         <https://www.ietf.org/mailman/list= info/payload>>>
>>
>>
>>
>>                   &nb= sp; --
>>                   &nb= sp; Kevin P. Fleming
>>                   &nb= sp; Digium, Inc. | Director of Software Technologies
>>                   &nb= sp; Jabber: kfleming@digium.com<= br> >>         <mailto:kfleming@digium.com> <mailto:kfleming@digium.com
>>         <mailto:kfleming@digium.com>>
>>         <mailto:kfleming@digium.com <mailto:kfleming@digium.com>
>>         <mailto:kfleming@digium.com <mailto:kfleming@digium.com>>> |
>SIP:
>>         kpfleming@digium.com <mailto:kpfleming@digium.com>
>>         <mailto:kpfleming@digium.com <mailto:kpfleming@digium.com>>
>>         <mailto:kpfleming@digium.com <mailto:kpfleming@digium.com>
>>         <mailto:kpfleming@digium.com <mailto:kpfleming@digium.com>>>
>>
>>                   &nb= sp; | Skype: kpfleming
>>                   &nb= sp; 445 Jan Davis Drive NW - Huntsville, AL 35806 -
>USA
>>                   &nb= sp; Check us out at www.digium.com
>>         <http://www.digium.com> <http://www.digium.com>
>>         <http://www.digium.com> &
>>         www.asterisk.org <http://www.asterisk.org>
><http://www.as= terisk.org>
>>         <http://www.asterisk.org>
>>
>> _____________________________________________________
>>
>>                   &nb= sp; payload mailing list
>>         pa= yload@ietf.org <mailto:payload@i= etf.org>
>>         <mailto:payload@ietf.org <mailto:payload@ietf.org>>
>>         <mailto:payload@ietf.org <mailto:payload@ietf.org>
>>         <mailto:payload@ietf.org <mailto:payload@ietf.org>>>
>>         https://www.ietf.org/mailman/______listinfo/payload
>>         <https://www.ietf.org/mailman/= ____listinfo/payload>
>>         <https://www.ietf.org/mailman/= ____listinfo/payload
>>         <https://www.ietf.org/mailman/__= listinfo/payload>>
>>
>>         <https://www.ietf.org/mailman/= ____listinfo/payload
>>         <https://www.ietf.org/mailman/__= listinfo/payload>
>>         <https://www.ietf.org/mailman/__= listinfo/payload
>>         <https://www.ietf.org/mailman/list= info/payload>>>
>>
>>
>>
>>
>>
>>             --
>>             Kevin P. Fleming
>>             Digium, Inc. | Director = of Software Technologies
>>             Jabber: kfleming@digium.com <mailto:kfleming@digium.com>
>>         <mailto:kfleming@digium.com <mailto:kfleming@digium.com>> |
>SIP:
>>         kpfleming@digium.com <mailto:kpfleming@digium.com>
>>         <mailto:kpfleming@digium.com <mailto:kpfleming@digium.com>> |
>>         Skype: kpfleming
>>
>>             445 Jan Davis Drive NW -= Huntsville, AL 35806 - USA
>>             Check us out at www.digium.com <http://www.digium.com><= br> >>         <http://www.digium.com> &
>>         www.asterisk.org <http://www.asterisk.org>
>> <http://w= ww.asterisk.org>
>>
>>
>>
>>
>>     --
>>     Kevin P. Fleming
>>     Digium, Inc. | Director of Software Technologies
>>     Jabber: kflem= ing@digium.com <mailto:kflemi= ng@digium.com> | SIP:
>>     kpfleming@di= gium.com <mailto:kpfleming@d= igium.com> | Skype:
>kpfleming
>>     445 Jan Davis Drive NW - Huntsville, AL 35806 - USA<= br> >>     Check us out at www.digium.com <http://www.digium.com> &
>>     www.asterisk.org <http://www.asterisk.org>
>>
>>
>

>_______________________________________________<= br> >payload mailing list
>payload@ietf.org
>https://www.ietf.org/mailman/listinfo/payload

 

--_000_387F9047F55E8C42850AD6B3A7A03C6C0E1F7F40inbamail01sonus_-- From hschhatwal@gmail.com Thu Mar 8 05:14:02 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2FCD21F86EF for ; Thu, 8 Mar 2012 05:14:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.732 X-Spam-Level: X-Spam-Status: No, score=-2.732 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SRNXSNIMyC05 for ; Thu, 8 Mar 2012 05:13:58 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9BCFD21F86DF for ; Thu, 8 Mar 2012 05:13:57 -0800 (PST) Received: by wgbdr13 with SMTP id dr13so311209wgb.13 for ; Thu, 08 Mar 2012 05:13:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=84J6ncBnHm2WL0WRPGBnF4c7UAP9UmUAXG//vW9Qz6w=; b=wlWjslllAFS8vqswHcGcSAgRpRhSrgztFGm/Wz8vE3lGYOt40xWikxOg6FCraujjth +JcaPtRoH1W2FDkktlT3XnpsJzRI32fboV5/yEKfUnGpCL95EeoWS4l/uQ6zGjWhQciS 3dPlO/1gbW9m4a0glUYdrOFOA/cdZLJQeZyd2sGo6bQTOD/h/sy2S5Z+3Wrg40BC3RDa PVZZOso8GYIyNlZKoiQV+mSSyUt0Yqs+rg3zT032Uh8GZ/CyYkJqreeGBF1MN2ljoRio 0j/aoB70ctwanGgNzo19yyzbunliHM44RdPHV9ibd1p+W2UnEu9wvikXElMoN+21l2Xx 0k3A== MIME-Version: 1.0 Received: by 10.180.79.135 with SMTP id j7mr31657853wix.19.1331212436421; Thu, 08 Mar 2012 05:13:56 -0800 (PST) Received: by 10.180.78.98 with HTTP; Thu, 8 Mar 2012 05:13:56 -0800 (PST) In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E1F7F40@inba-mail01.sonusnet.com> References: <1D062974A4845E4D8A343C653804920207ABB1E1@XMB-BGL-414.cisco.com> <4F4BB973.4060508@alum.mit.edu> <4F4D06B6.6020905@digium.com> <4F4D17C8.7070201@alum.mit.edu> <4F4D26AE.5070009@digium.com> <4F4D40A3.6030309@digium.com> <4F4E44C3.4080803@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E06BEC7@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1F7F40@inba-mail01.sonusnet.com> Date: Thu, 8 Mar 2012 13:13:56 +0000 Message-ID: From: "Chhatwal, Harprit S" To: "Ravindran, Parthasarathi" Content-Type: multipart/alternative; boundary=f46d04428ff464bcee04babb0ccb Cc: "payload@ietf.org" Subject: Re: [payload] FW: I-D Action: draft-muthu-payload-offer-answer-g723-g729-00.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 13:14:03 -0000 --f46d04428ff464bcee04babb0ccb Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable > > I didn=92t fully understand your network. My guess is that in case of > bandwidth constrained in one direction of the session, then the > low-bandwidth codec has to be negotiated in that direction. ISTM, > asymmetric annexb parameter negotiation is not going to solve the bandwid= th > issue. Please let me know how asymmetric annexb will solve bandwidth issu= e. > > Perhaps I have not explained this clearly enough previously, so allow me to try again. The bandwidth in the customer's network is sufficiently constrained in one direction that the customer wishes to use G.729/G.729A with G.729B active (ie using VAD/DTX) to allow the speech codec bandwidth requirements in this direction to fit within the network bandwidth envelope. In the other direction, the network bandwidth available is somewhat less constrained, so the customer would like to use G.729/G.729A without G.729B active to get slightly better quality. However, even in this direction, the network bandwidth is still limited enough that a higher-rate codec such as G.711 will not work. For the second part of your question, please see the earlier mails on this thread as this has been covered previously. Regards. Harprit. Harprit S. Chhatwal InnoMedia On 8 March 2012 10:12, Ravindran, Parthasarathi wr= ote: > Hi Harpit,**** > > ** ** > > Sorry for the delay reply.**** > > ** ** > > I didn=92t fully understand your network. My guess is that in case of > bandwidth constrained in one direction of the session, then the > low-bandwidth codec has to be negotiated in that direction. ISTM, > asymmetric annexb parameter negotiation is not going to solve the bandwid= th > issue. Please let me know how asymmetric annexb will solve bandwidth issu= e. > **** > > ** ** > > AFAIK, answerer expectation of asymmetric annexb will leads to the intero= p > issue in case of offerer mentions as =93annexb=3Dno=94 but answerer manda= tes to > have =93annexb=3Dyes=94. Please let me know your opinion on the same. > > **** > > Thanks > Partha**** > > ** ** > > ** ** > > ** ** > > *From:* Chhatwal, Harprit S [mailto:hschhatwal@gmail.com] > *Sent:* Thursday, March 01, 2012 4:59 PM > *To:* Ravindran, Parthasarathi > *Cc:* Paul Kyzivat; Kevin P. Fleming; payload@ietf.org > > *Subject:* Re: [payload] FW: I-D Action: > draft-muthu-payload-offer-answer-g723-g729-00.txt**** > > ** ** > > On 1 March 2012 06:13, Ravindran, Parthasarathi > wrote:**** > > I'm not very clear on the bandwidth optimization based on asymmetric > annexb parameter negotiation. Could you please elaborate.**** > > ** ** > > This is for a network where the bandwidth is severely constrained in one > direction, so the operator wishes to use G.729B to minimise bandwidth usa= ge > in one direction, while not using G.729B in the other direction where > bandwidth is less constrained.**** > > ** ** > > Regards. Harprit.**** > > ** ** > > Harprit S. Chhatwal**** > > InnoMedia**** > > ** ** > > On 1 March 2012 06:13, Ravindran, Parthasarathi > wrote:**** > > Hi Harpit, > > Thanks for looking into the draft. I agree with you that asymmetric annex= b > negotiation is not taken into the account in the draft currently. In fact= , > I come across the scenario wherein annexb is not supported by offerer > ,mentioned in offer SDP as annexb=3Dno and answerer assumes about annexb > support (no annexb parameter in answer) in offerer side which leads to th= e > call failure. > > I'm not very clear on the bandwidth optimization based on asymmetric > annexb parameter negotiation. Could you please elaborate. > > Thanks > Partha**** > > > >-----Original Message----- > >From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On > >Behalf Of Paul Kyzivat > >Sent: Wednesday, February 29, 2012 9:01 PM > >To: Chhatwal, Harprit S > >Cc: payload@ietf.org > >Subject: Re: [payload] FW: I-D Action: draft-muthu-payload-offer-answer- > >g723-g729-00.txt > > > >On 2/29/12 9:34 AM, Chhatwal, Harprit S wrote: > >> On 28 February 2012 21:01, Kevin P. Fleming >> > wrote: > >> > >> > >> That requirement is counter to what the draft proposes. We can't > >> have it both ways: either the G.729 'annexb' format parameter is a > >> negotiated parameter (in which case its usage is symmetrical by > >> definition) or it is a declarative parameter (in which case the > >> usage can be, but is not required to be, asymmetrical). > >> > >> > >> Yes, I concur that the draft (as it currently stands) cannot > >> accommodate an asymmetric use of G.729B. However, if we agree that > >> both scenarios are true, real-world scenarios that need addressing, ie > >> (a) the negotiated case where the use of G.729B is symmetric and (b) > >> the declarative case where the use of G.729B can be asymmetric (and, > >> in my opinion, both are valid scenarios), then I would suggest that we > >> need to come up with a way of handling both situations (perhaps > >> through the use of an extra fmtp parameter indicating whether the use > >> is declarative or negotiated - or any other suggestions the group > >might have). > >> > >> If not, and we are only to allow the negotiated, symmetric use, then > >> I'd appreciate any suggestions from the group for how my organisation > >> might deal with the requirement of an asymmetric use of G.729B > >mentioned below. > > > >There is one way that is available right now: > > > >Negotiate two separate one way m-lines. > >But this might be too weird for common use. > > > > Thanks, > > Paul > > > >> Regards. Harprit. > >> > >> Harprit S. Chhatwal > >> InnoMedia > >> > >> On 28 February 2012 21:01, Kevin P. Fleming >> > wrote: > >> > >> On 02/28/2012 02:58 PM, Chhatwal, Harprit S wrote: > >> > >> Speaking as a codec person :-), I think the draft does address > >a > >> real > >> issue and is reasonably clear in its content. However, it > >does not > >> appear to address (as far as I can see), the case where an > >> asymmetric > >> use of G.729B is required. This is an actual issue as we are > >> faced with > >> a customer requirement where the use of G.729B is required in > >one > >> direction and not the other (for bandwidth reasons). Given > >the > >> current > >> specs do not appear to definitively cover this case, it would > >be > >> good to > >> see if this can be addressed through the proposed draft. > >> > >> > >> That requirement is counter to what the draft proposes. We can't > >> have it both ways: either the G.729 'annexb' format parameter is a > >> negotiated parameter (in which case its usage is symmetrical by > >> definition) or it is a declarative parameter (in which case the > >> usage can be, but is not required to be, asymmetrical). > >> > >> > >> Regards. Harprit. > >> > >> Harprit S. Chhatwal > >> InnoMedia > >> > >> On 28 February 2012 19:10, Kevin P. Fleming > >> > >> >> > >wrote: > >> > >> On 02/28/2012 12:07 PM, Paul Kyzivat wrote: > >> > >> Clarification: > >> > >> In my comments on the draft I was not questioning the > >> assumption > >> of that > >> draft that a common value of this parameter is > >> *negotiated* via O/A. > >> *If* you accept that assumption then my comments > >> hopefully make > >> sense. > >> > >> But if there is debate regarding whether the parameter > >is > >> negotiated or > >> declarative, then that needs to be settled first, > >before > >> nailing > >> down > >> clarifications for how the negotiation happens. > >> > >> Not being a codec person, I don't know what the common > >> practice > >> is here. > >> So I'm going to let those that have the knowledge > >argue > >> that. > >> > >> > >> Correct on all points; your comments make complete sense > >if > >> 'annexb' > >> is intended to be a negotiated parameter. > >> > >> I'm not a codec person (although I'd probably be willing > >to > >> play one > >> on TV is the need arose ), but there are so many other > >> codec/format parameters that are declarative already that > >I > >> don't > >> see any need for this one to have to be negotiated. The > >> impact of > >> using Annex B or not is purely on one direction of the > >media > >> stream, > >> and it's not even mandatory that the encoder use Annex B > >> mode just > >> because 'annexb=3Dyes'. Granted, it's pretty unlikely that > >an > >> implementation that cannot accept incoming SID frames > >would > >> also be > >> able to generate them, but I can think of completely > >reasonable > >> situations for an implementation that can generate them > >being > >> willing to do so while at the same time disallowing > >> reception of them. > >> > >> > >> > >> Thanks, > >> Paul > >> > >> On 2/28/12 12:34 PM, Chhatwal, Harprit S wrote: > >> > >> Kevin, > >> > >> First of all, from RFC3264, I agree with you that > >> for things > >> like IP > >> addresses, ports, payload types, ptime, the SDP > >that one > >> party sends > >> indicates the address/port/PT/ptime that the > >sender > >> would > >> like to > >> receive on. However, I don't believe this is > >generally > >> correct for all > >> parameters. For instance, for codecs (again from > >> RFC3264), > >> the codec(s) > >> included in an SDP offer indicates the codec(s) > >the > >> offerer > >> is willing > >> to send AND receive (if the directional attribute > >is > >> 'sendrecv'). As an > >> example, if party A is the offerer and sends G.729 > >& > >> G.711 > >> in its SDP > >> offer, it is saying that it is willing to use > >either > >> codec. > >> If the > >> answerer replies with G.711, then it is only > >willing > >> to use > >> G.711, and > >> then G.729 will not be used in either direction. > >> > >> Turning now to silence suppression, the situation > >> does not > >> seem very > >> clear. This is what RFC3264 has to say about fmtp > >> parameters > >> such as > >> 'annexb' : > >> > >> The interpretation of fmtp parameters in an offer > >> depends on the > >> > >> parameters. In many cases, those parameters > >describe > >> specific > >> > >> configurations of the media format, and should > >> therefore be > >> processed > >> > >> as the media format value itself would be. This > >> means that > >> the same > >> > >> fmtp parameters with the same values MUST be > >present > >> in the > >> answer if > >> > >> the media format they describe is present in the > >answer. > >> Other fmtp > >> > >> parameters are more like parameters, for which it > >is > >> perfectly > >> > >> acceptable for each agent to use different values. > >> In that > >> case, the > >> > >> answer MAY contain fmtp parameters, and those MAY > >> have the same > >> > >> values as those in the offer, or they MAY be > >> different. SDP > >> > >> extensions that define new parameters SHOULD > >specify > >> the proper > >> > >> interpretation in offer/answer. > >> > >> To me, 'annexb' is more like a parameter in this > >> sense and, > >> in this > >> case, everything is allowed - the answer may > >contain the > >> same fmtp or > >> different. RFC3264 doesn't appear to specify the > >> interpretation. The > >> problem is that I don't know of anywhere else > >where the > >> interpretation > >> is specified either. RFC4856 specifies the > >parameter > >> 'annexb', but > >> doesn't say whether it can be used asymmetrically > >> (or how). > >> The only > >> other guidance I can find on this is elsewhere in > >> RFC3264: > >> > >> The list of media formats for each media stream > >> conveys two > >> pieces of > >> > >> information, namely the set of formats (codecs and > >any > >> parameters > >> > >> associated with the codec, in the case of RTP) > >that the > >> offerer is > >> > >> capable of sending and/or receiving (depending on > >> the direction > >> > >> attributes)... > >> > >> ...For a sendrecv stream, the offer SHOULD > >indicate > >> those > >> > >> codecs that the offerer is willing to send and > >> receive with. > >> > >> So, this appears to be lumping codec parameters > >with > >> codecs > >> and so both > >> should behave in the same way. If we take this > >> interpretation, then > >> indicating 'annexb=3Dno' indicates that the sender > >of > >> this SDP > >> is willing > >> to send and receive with silence suppression off. > >So, > >> according to > >> this, if the offerer sends 'annexb=3Dyes' in the > >offer > >> and the > >> answerer > >> sends back 'annexb=3Dno', then there is a mismatch > >and the > >> offerer should > >> send a re-INVITE with 'annexb=3Dno' to resolve the > >> conflict. > >> According to > >> this interpretation, we cannot have an asymmetric > >> use of silence > >> suppression. However, from the discussion we're > >> having, I > >> can see that > >> all of this is somewhat open to interpretation > >> (since the > >> specs do not > >> seem to be clear) and I agree with the authors of > >> this ID > >> that we need > >> some clarification as to how this issue should be > >> dealt with > >> (and > >> whether asymmetric use of annexb should be allowed > >> and, if > >> so, how). > >> > >> > >> Regards. Harprit. > >> > >> > >> Harprit S. Chhatwal > >> > >> InnoMedia > >> > >> > >> On 28 February 2012 16:54, Kevin P. Fleming > >> > >> > > >> > >> >> >>__> > >> > >> wrote: > >> > >> On 02/27/2012 11:12 AM, Paul Kyzivat wrote: > >> > >> On 2/27/12 6:33 AM, Muthu Arul Mozhi Perumal > >> (mperumal) wrote: > >> > >> We have submitted an I-D clarifying the > >offer/answer > >> considerations for > >> the Annex A flavor of G.723 and the Annex B > >flavors of > >> G.729, G.729D and > >> G.729E. This clarification is missing in RFC 4856, > >> leading > >> to interop > >> issues, for e.g: > >> http://sipforum.org/pipermail/______discussion/2008- > >January/______004026.html > >> >January/____004026.html> > >> >__January/__004026.html > >> >January/__004026.html>> > >> >____January/004026.html > >> > >> >> > > >> > >> >__January/004026.html > >> > >> >> > >> > >> We have a couple of open items in the I-D. We > >expect > >> the WG > >> discussions > >> would guide us on how to go about them. > >> > >> Comments welcome. > >> > >> > >> I'm the source of the issues. :-) > >> > >> The fundamental point is that RFC4856 specifies a > >> *default* > >> value of > >> "yes" for annexa and annexb. This means that if > >> annexa/annexb is not > >> specified in an answer, then it will default to > >yes, > >> even if the > >> offer > >> contained "no". > >> > >> I see a few ways to fix this: > >> > >> 1) revise the IANA registration for annexa and > >annexb to > >> remove the > >> default, at least when used with O/A. Instead > >> specify the > >> defaulting > >> separately for offers and answers. > >> > >> 2) REQUIRE that the answer contain "no" if the > >offer > >> contained "no". > >> > >> 3) permit the answer to contain "yes" (explicitly > >or > >> by default) > >> when the offer contained "no", and specify that > >this > >> still means > >> that the annex is *not* to be used. > >> > >> 4) forbid the answer from *explicitly* containing > >> "yes" when the > >> offer contained "no", but allow the answer to > >> *implicitly* > >> contain > >> "yes" (via the default) and ignore it/treat it as "no". > >> > >> None of these are ideal. (1) is problematic > >because > >> this is > >> used in > >> non-O/A contexts, such as RSVP. (2) begs the > >> question of what > >> should be > >> done if this is violated. (3) risks failing to > >> recognize that > >> the two > >> sides disagree. (4) is pragmatic but seems to > >> violate the > >> spirit of > >> defaults. > >> > >> I guess my preference is to make (2) normative for > >> the answerer, > >> while > >> making (4) normative for the offerer, and put > >enough > >> words > >> in so its > >> very clear what is being specified and why. > >> > >> > >> I must *really* be missing something here; why > >does > >> the usage of > >> G.729 Annex B have to be symmetrical? Until I saw > >this > >> thread, it > >> was always my understanding that the 'annexb' > >format > >> parameter for > >> G.729 in SDP indicated the preference of the > >endpoint > >> sending that > >> parameter. Like nearly everything else in SDP, it > >> indicates what > >> that endpoint is *prepared to accept*, and has > >> nothing at > >> all to do > >> with what it will (or could) send. > >> > >> Unless that's a completely broken understanding, > >> then these > >> 'interop' issues are really just very poorly coded > >> implementations. > >> I would interpret the current RFC language as > >follows: > >> > >> 1) If an offer/answer contains 'annexb=3Dno', the > >> receiver of that > >> offer/answer MUST NOT send G.729 Annex B SID > >frames > >> to the > >> offering/answering endpoint. > >> > >> 2) If an offer/answer contains 'annexb=3Dyes', the > >> receiver of > >> that > >> offer/answer SHOULD send G.729 Annex B SID frames > >to the > >> offering/answering endpoint. > >> > >> 3) An answer's value for the 'annexb' parameter is > >> completely > >> independent of the value (if any) present in the > >> offer it is > >> answering. > >> > >> > >> Thanks, > >> Paul > >> > >> Muthu > >> > >> -----Original Message----- > >> From: i-d-announce-bounces@ietf.org > >> > >> >> > > >> >> ____ietf.org > >> >> >> > >> [mailto:i-d-announce-bounces@ > >> > >> >> >______ietf.org > > > >> > >> >> ____ietf.org > >> >> >>] On Behalf Of > >> internet-drafts@ietf.org > >> >> > > >> >> ____org > >> > >> >> >> > >> Sent: Friday, February 24, 2012 5:57 PM > >> To: i-d-announce@ietf.org > >> >> > > >> > >> >announce@ietf.org>>__> > >> Subject: I-D Action: > >> > >> draft-muthu-payload-offer-______answer-g723-g729-00.txt > >> > >> > >> > >> A New Internet-Draft is available from the on-line > >> Internet-Drafts > >> directories. > >> > >> Title : Offer/Answer Considerations for G.723 > >Annex A > >> and G.729 Annex B > >> Author(s) : Muthu Arul Mozhi Perumal > >> Parthasarathi Ravindran > >> Filename : > >> > >> draft-muthu-payload-offer-______answer-g723-g729-00.txt > >> > >> Pages : 8 > >> Date : 2012-02-24 > >> > >> [RFC4856] describes the annexa parameter for G723 > >> and the annexb > >> parameter for G729, G729D and G729E. However, the > >> specification does > >> not describe the offerer and answerer behavior > >when the > >> value of the > >> annexa or annexb parameter does not match in the > >SDP > >> offer and > >> answer. This document provides the offer/answer > >> considerations for > >> these parameters. > >> > >> > >> A URL for this Internet-Draft is: > >> http://www.ietf.org/internet-______drafts/draft-muthu-payload- > >______offer-answer-g72 > >> >____offer-answer-g72> > >> >____offer-answer-g72 > >> > >> >> wer-g72>> > >> > >> > >> >____offer-answer-g72 > >> >__offer-answer-g72> > >> >__offer-answer-g72 > >> > >> >> g72>>> > >> > >> 3-g729-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-muthu-payload- > >______offer-answer-g723 > >> >____offer-answer-g723> > >> >____offer-answer-g723 > >> > >> >> er-g723>> > >> > >> > >> >____offer-answer-g723 > >> >__offer-answer-g723> > >> >__offer-answer-g723 > >> > >> >> 723>>> > >> > >> -g729-00.txt > >> > >> > >> _____________________________________________________ > >> > >> I-D-Announce mailing list > >> I-D-Announce@ietf.org > >> > > >> > >> >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 > >> > >> >> > > >> >> > >> >> >> > >> > >> > >> > >> _____________________________________________________ > >> > >> payload mailing list > >> payload@ietf.org > >> > > >> > >> >> > >> https://www.ietf.org/mailman/______listinfo/payload > >> > >> >> > > >> > >> >> > >> >> >> > >> > >> > >> > >> -- > >> 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 > > > >> > >> > >> _____________________________________________________ > >> > >> payload mailing list > >> payload@ietf.org > >> > > >> > >> >> > >> https://www.ietf.org/mailman/______listinfo/payload > >> > >> >> > > >> > >> >> > >> >> >> > >> > >> > >> > >> > >> > >> -- > >> 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 > >> > >> > >> > >> > >> > >> -- > >> 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 > >> > >> > >**** > > >_______________________________________________ > >payload mailing list > >payload@ietf.org > >https://www.ietf.org/mailman/listinfo/payload**** > > ** ** > --f46d04428ff464bcee04babb0ccb Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

I didn=92t fully understand your network. My= guess is that=A0 in case of bandwidth constrained in one direction of the = session, then the low-bandwidth codec has to be negotiated in that directio= n. ISTM, asymmetric annexb parameter negotiation is not going to solve the = bandwidth issue. Please let me know how asymmetric annexb will solve bandwi= dth issue.=A0


Perhaps I have not explained this clearly enough previously, so all= ow me to try again. =A0The bandwidth in the customer's network is suffi= ciently constrained in one direction that the customer wishes to use G.729/= G.729A with G.729B active (ie using VAD/DTX) to allow the speech codec band= width requirements in this direction to fit within the network bandwidth en= velope. In the other direction, the network bandwidth available is somewhat= less constrained,=A0so the customer would like to use G.729/G.729A without= G.729B active to get slightly better quality. =A0However, even in this dir= ection, the network bandwidth is=A0still limited enough that a higher-rate = codec such as G.711 will not work.

For the sec= ond part of your question, please see the earlier mails on this thread as t= his has been covered previously.

=
Regards. =A0Harprit.

Harprit S. Chhatwal
InnoMe= dia

On= 8 March 2012 10:12, Ravindran, Parthasarathi <pravindran@sonusnet.com> = wrote:

Hi Harpit,<= /span>

=A0<= /p>

Sorry for the delay reply= .

=A0<= /p>

I didn=92t fully understa= nd your network. My guess is that=A0 in case of bandwidth constrained in on= e direction of the session, then the low-bandwidth codec has to be negotiated in that direction. ISTM, asymmetric annexb parameter nego= tiation is not going to solve the bandwidth issue. Please let me know how a= symmetric annexb will solve bandwidth issue.

=A0<= /p>

AFAIK, answerer expectati= on of asymmetric annexb will leads to the interop issue in case of offerer = mentions as =93annexb=3Dno=94 but answerer mandates to have =93annexb=3Dyes= =94.=A0 Please let me know your opinion on the same.

Thanks
Partha

=A0<= /p>

=A0<= /p>

=A0<= /p>

From: Chhatwal= , Harprit S [mailto:hschhatwal@gmail.com]
Sent: Thursday, March 01, 2012 4:59 PM
To: Ravindran, Parthasarathi
Cc: Paul Kyzivat; Kevin P. Fleming; payload@ietf.org


Subject: Re: [payload] FW: I-D Action: draft-muthu-payload-offer-ans= wer-g723-g729-00.txt

=A0

On 1 March 2012 06:13, Ravindran, Parthasarathi=A0&l= t;pravindran@s= onusnet.com>=A0wrote:

I'm not very clea= r on the bandwidth optimization based on asymmetric annexb parameter negoti= ation. Could you please elaborate.

=A0

This is for a network where the bandwidth is severel= y constrained in one direction, so the operator wishes to use G.729B to min= imise bandwidth usage in one direction, while not using G.729B in the other= direction where bandwidth is less constrained.

=A0

Regards. =A0Harprit.

=A0

Harprit S. Chhatwal

InnoMedia

=A0

On 1 March 2012 06:13, Ravindran, Parthasarathi <= pravindran@son= usnet.com> wrote:

Hi Harpit,

Thanks for looking into the draft. I agree with you that asymmetric annexb = negotiation is not taken into the account in the draft currently. In fact, = I come across the scenario wherein annexb is not supported by offerer ,ment= ioned in offer SDP as annexb=3Dno and answerer assumes about annexb support (no annexb parameter in answer) = in offerer side which leads to the call failure.

I'm not very clear on the bandwidth optimization based on asymmetric an= nexb parameter negotiation. Could you please elaborate.

Thanks
Partha


>-----Original Message-----
>From: pay= load-bounces@ietf.org [mailto:payload-bounces@ietf.org] On
>Behalf Of Paul Kyzivat
>Sent: Wednesday, February 29, 2012 9:01 PM
>To: Chhatwal, Harprit S
>Cc: payload@ietf.= org
>Subject: Re: [payload] FW: I-D Action: draft-muthu-payload-offer-answer= -
>g723-g729-00.txt
>
>On 2/29/12 9:34 AM, Chhatwal, Harprit S wrote:
>> On 28 February 2012 21:01, Kevin P. Fleming <kpfleming@digium.com
>> <mailto:kpfleming@digium.com>> wrote:
>>
>>
>> =A0 =A0 That requirement is counter to what the draft proposes. We= can't
>> =A0 =A0 have it both ways: either the G.729 'annexb' forma= t parameter is a
>> =A0 =A0 negotiated parameter (in which case its usage is symmetric= al by
>> =A0 =A0 definition) or it is a declarative parameter (in which cas= e the
>> =A0 =A0 usage can be, but is not required to be, asymmetrical). >>
>>
>> Yes, I concur that the draft (as it currently stands) cannot
>> accommodate an asymmetric use of G.729B. =A0However, if we agree t= hat
>> both scenarios are true, real-world scenarios that need addressing= , ie
>> (a) the negotiated case where the use of G.729B is symmetric and (= b)
>> the declarative case where the use of G.729B can be asymmetric (an= d,
>> in my opinion, both are valid scenarios), then I would suggest tha= t we
>> need to come up with a way of handling both situations (perhaps >> through the use of an extra fmtp parameter indicating whether the = use
>> is declarative or negotiated - or any other suggestions the group<= br> >might have).
>>
>> If not, and we are only to allow the negotiated, symmetric use, th= en
>> I'd appreciate any suggestions from the group for how my organ= isation
>> might deal with the requirement of an asymmetric use of G.729B
>mentioned below.
>
>There is one way that is available right now:
>
>Negotiate two separate one way m-lines.
>But this might be too weird for common use.
>
> =A0 =A0 =A0 Thanks,
> =A0 =A0 =A0 Paul
>
>> Regards. =A0Harprit.
>>
>> Harprit S. Chhatwal
>> InnoMedia
>>
>> On 28 February 2012 21:01, Kevin P. Fleming <kpfleming@digium.com
>> <mailto:kpfleming@digium.com>> wrote:
>>
>> =A0 =A0 On 02/28/2012 02:58 PM, Chhatwal, Harprit S wrote:
>>
>> =A0 =A0 =A0 =A0 Speaking as a codec person :-), I think the draft = does address
>a
>> =A0 =A0 =A0 =A0 real
>> =A0 =A0 =A0 =A0 issue and is reasonably clear in its content. =A0H= owever, it
>does not
>> =A0 =A0 =A0 =A0 appear to address (as far as I can see), the case = where an
>> =A0 =A0 =A0 =A0 asymmetric
>> =A0 =A0 =A0 =A0 use of G.729B is required. =A0This is an actual is= sue as we are
>> =A0 =A0 =A0 =A0 faced with
>> =A0 =A0 =A0 =A0 a customer requirement where the use of G.729B is = required in
>one
>> =A0 =A0 =A0 =A0 direction and not the other (for bandwidth reasons= ). =A0Given
>the
>> =A0 =A0 =A0 =A0 current
>> =A0 =A0 =A0 =A0 specs do not appear to definitively cover this cas= e, it would
>be
>> =A0 =A0 =A0 =A0 good to
>> =A0 =A0 =A0 =A0 see if this can be addressed through the proposed = draft.
>>
>>
>> =A0 =A0 That requirement is counter to what the draft proposes. We= can't
>> =A0 =A0 have it both ways: either the G.729 'annexb' forma= t parameter is a
>> =A0 =A0 negotiated parameter (in which case its usage is symmetric= al by
>> =A0 =A0 definition) or it is a declarative parameter (in which cas= e the
>> =A0 =A0 usage can be, but is not required to be, asymmetrical). >>
>>
>> =A0 =A0 =A0 =A0 Regards. =A0Harprit.
>>
>> =A0 =A0 =A0 =A0 Harprit S. Chhatwal
>> =A0 =A0 =A0 =A0 InnoMedia
>>
>> =A0 =A0 =A0 =A0 On 28 February 2012 19:10, Kevin P. Fleming
>> =A0 =A0 =A0 =A0 <kpfleming@digium.com <mailto:kpfleming@digium.com>
>> =A0 =A0 =A0 =A0 <mailto:kpfleming@digium.com <mailto:kpfleming@digium.com>>><= br> >wrote:
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 On 02/28/2012 12:07 PM, Paul Kyzivat wrote= :
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Clarification:
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 In my comments on the draft I was = not questioning the
>> =A0 =A0 =A0 =A0 assumption
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 of that
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 draft that a common value of this = parameter is
>> =A0 =A0 =A0 =A0 *negotiated* via O/A.
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 *If* you accept that assumption th= en my comments
>> =A0 =A0 =A0 =A0 hopefully make
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 sense.
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 But if there is debate regarding w= hether the parameter
>is
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 negotiated or
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 declarative, then that needs to be= settled first,
>before
>> =A0 =A0 =A0 =A0 nailing
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 down
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 clarifications for how the negotia= tion happens.
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Not being a codec person, I don= 9;t know what the common
>> =A0 =A0 =A0 =A0 practice
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 is here.
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 So I'm going to let those that= have the knowledge
>argue
>> =A0 =A0 =A0 =A0 that.
>>
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 Correct on all points; your comments make = complete sense
>if
>> =A0 =A0 =A0 =A0 'annexb'
>> =A0 =A0 =A0 =A0 =A0 =A0 is intended to be a negotiated parameter.<= br> >>
>> =A0 =A0 =A0 =A0 =A0 =A0 I'm not a codec person (although I'= ;d probably be willing
>to
>> =A0 =A0 =A0 =A0 play one
>> =A0 =A0 =A0 =A0 =A0 =A0 on TV is the need arose <G>), but th= ere are so many other
>> =A0 =A0 =A0 =A0 =A0 =A0 codec/format parameters that are declarati= ve already that
>I
>> =A0 =A0 =A0 =A0 don't
>> =A0 =A0 =A0 =A0 =A0 =A0 see any need for this one to have to be ne= gotiated. The
>> =A0 =A0 =A0 =A0 impact of
>> =A0 =A0 =A0 =A0 =A0 =A0 using Annex B or not is purely on one dire= ction of the
>media
>> =A0 =A0 =A0 =A0 stream,
>> =A0 =A0 =A0 =A0 =A0 =A0 and it's not even mandatory that the e= ncoder use Annex B
>> =A0 =A0 =A0 =A0 mode just
>> =A0 =A0 =A0 =A0 =A0 =A0 because 'annexb=3Dyes'. Granted, i= t's pretty unlikely that
>an
>> =A0 =A0 =A0 =A0 =A0 =A0 implementation that cannot accept incoming= SID frames
>would
>> =A0 =A0 =A0 =A0 also be
>> =A0 =A0 =A0 =A0 =A0 =A0 able to generate them, but I can think of = completely
>reasonable
>> =A0 =A0 =A0 =A0 =A0 =A0 situations for an implementation that can = generate them
>being
>> =A0 =A0 =A0 =A0 =A0 =A0 willing to do so while at the same time di= sallowing
>> =A0 =A0 =A0 =A0 reception of them.
>>
>>
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Thanks,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Paul
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 On 2/28/12 12:34 PM, Chhatwal, Har= prit S wrote:
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Kevin,
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 First of all, from RFC3264= , I agree with you that
>> =A0 =A0 =A0 =A0 for things
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 like IP
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 addresses, ports, payload = types, ptime, the SDP
>that one
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 party sends
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 indicates the address/port= /PT/ptime that the
>sender
>> =A0 =A0 =A0 =A0 would
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 like to
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 receive on. However, I don= 't believe this is
>generally
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 correct for all
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 parameters. For instance, = for codecs (again from
>> =A0 =A0 =A0 =A0 RFC3264),
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 the codec(s)
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 included in an SDP offer i= ndicates the codec(s)
>the
>> =A0 =A0 =A0 =A0 offerer
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 is willing
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 to send AND receive (if th= e directional attribute
>is
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 'sendrecv'). As an=
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 example, if party A is the= offerer and sends G.729
>&
>> =A0 =A0 =A0 =A0 G.711
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 in its SDP
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 offer, it is saying that i= t is willing to use
>either
>> =A0 =A0 =A0 =A0 codec.
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 If the
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 answerer replies with G.71= 1, then it is only
>willing
>> =A0 =A0 =A0 =A0 to use
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 G.711, and
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 then G.729 will not be use= d in either direction.
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Turning now to silence sup= pression, the situation
>> =A0 =A0 =A0 =A0 does not
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 seem very
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 clear. This is what RFC326= 4 has to say about fmtp
>> =A0 =A0 =A0 =A0 parameters
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 such as
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 'annexb' :
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 The interpretation of fmtp= parameters in an offer
>> =A0 =A0 =A0 =A0 depends on the
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 parameters. In many cases,= those parameters
>describe
>> =A0 =A0 =A0 =A0 specific
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 configurations of the medi= a format, and should
>> =A0 =A0 =A0 =A0 therefore be
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 processed
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 as the media format value = itself would be. This
>> =A0 =A0 =A0 =A0 means that
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 the same
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 fmtp parameters with the s= ame values MUST be
>present
>> =A0 =A0 =A0 =A0 in the
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 answer if
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 the media format they desc= ribe is present in the
>answer.
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Other fmtp
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 parameters are more like p= arameters, for which it
>is
>> =A0 =A0 =A0 =A0 perfectly
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 acceptable for each agent = to use different values.
>> =A0 =A0 =A0 =A0 In that
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 case, the
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 answer MAY contain fmtp pa= rameters, and those MAY
>> =A0 =A0 =A0 =A0 have the same
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 values as those in the off= er, or they MAY be
>> =A0 =A0 =A0 =A0 different. SDP
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 extensions that define new= parameters SHOULD
>specify
>> =A0 =A0 =A0 =A0 the proper
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 interpretation in offer/an= swer.
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 To me, 'annexb' is= more like a parameter in this
>> =A0 =A0 =A0 =A0 sense and,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 in this
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 case, everything is allowe= d - the answer may
>contain the
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 same fmtp or
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 different. RFC3264 doesn&#= 39;t appear to specify the
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 interpretation. The
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 problem is that I don'= t know of anywhere else
>where the
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 interpretation
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 is specified either. RFC48= 56 specifies the
>parameter
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 'annexb', but
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 doesn't say whether it= can be used asymmetrically
>> =A0 =A0 =A0 =A0 (or how).
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 The only
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 other guidance I can find = on this is elsewhere in
>> =A0 =A0 =A0 =A0 RFC3264:
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 The list of media formats = for each media stream
>> =A0 =A0 =A0 =A0 conveys two
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pieces of
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 information, namely the se= t of formats (codecs and
>any
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 parameters
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 associated with the codec,= in the case of RTP)
>that the
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 offerer is
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 capable of sending and/or = receiving (depending on
>> =A0 =A0 =A0 =A0 the direction
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 attributes)...
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ...For a sendrecv stream, = the offer SHOULD
>indicate
>> =A0 =A0 =A0 =A0 those
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 codecs that the offerer is= willing to send and
>> =A0 =A0 =A0 =A0 receive with.
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 So, this appears to be lum= ping codec parameters
>with
>> =A0 =A0 =A0 =A0 codecs
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 and so both
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 should behave in the same = way. If we take this
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 interpretation, then
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 indicating 'annexb=3Dn= o' indicates that the sender
>of
>> =A0 =A0 =A0 =A0 this SDP
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 is willing
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 to send and receive with s= ilence suppression off.
>So,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 according to
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 this, if the offerer sends= 'annexb=3Dyes' in the
>offer
>> =A0 =A0 =A0 =A0 and the
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 answerer
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 sends back 'annexb=3Dn= o', then there is a mismatch
>and the
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 offerer should
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 send a re-INVITE with '= ;annexb=3Dno' to resolve the
>> =A0 =A0 =A0 =A0 conflict.
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 According to
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 this interpretation, we ca= nnot have an asymmetric
>> =A0 =A0 =A0 =A0 use of silence
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 suppression. However, from= the discussion we're
>> =A0 =A0 =A0 =A0 having, I
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 can see that
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 all of this is somewhat op= en to interpretation
>> =A0 =A0 =A0 =A0 (since the
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 specs do not
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 seem to be clear) and I ag= ree with the authors of
>> =A0 =A0 =A0 =A0 this ID
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 that we need
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 some clarification as to h= ow this issue should be
>> =A0 =A0 =A0 =A0 dealt with
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (and
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 whether asymmetric use of = annexb should be allowed
>> =A0 =A0 =A0 =A0 and, if
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 so, how).
>>
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Regards. Harprit.
>>
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Harprit S. Chhatwal
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 InnoMedia
>>
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 On 28 February 2012 16:54,= Kevin P. Fleming
>> =A0 =A0 =A0 =A0 <kpfleming@digium.com <mailto:kpfleming@digium.com>
>> =A0 =A0 =A0 =A0 <mailto:kpfleming@digium.com <mailto:kpfleming@digium.com>>
>> =A0 =A0 =A0 =A0 <mailto:kpfleming@digium.com <mailto:kpfleming@digium.com>
>> =A0 =A0 =A0 =A0 <mailto:kpfleming@digium.com
>> <mailto:kpfleming@digium.com>>>__>
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 wrote:
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 On 02/27/2012 11:12 AM, Pa= ul Kyzivat wrote:
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 On 2/27/12 6:33 AM, Muthu = Arul Mozhi Perumal
>> =A0 =A0 =A0 =A0 (mperumal) wrote:
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 We have submitted an I-D c= larifying the
>offer/answer
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 considerations for
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 the Annex A flavor of G.72= 3 and the Annex B
>flavors of
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 G.729, G.729D and
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 G.729E. This clarification= is missing in RFC 4856,
>> =A0 =A0 =A0 =A0 leading
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 to interop
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 issues, for e.g:
>> =A0 =A0 =A0 =A0 http://sipforum.org/pipermail/______discussion/2008-
>January/______004026.html
>> =A0 =A0 =A0 =A0 <http://sipforum.org/pipermail/____discus= sion/2008-
>January/____004026.html>
>> =A0 =A0 =A0 =A0 <http://sipforum.org/__pipermail/__discus= sion/2008-
>__January/__004026.html
>> =A0 =A0 =A0 =A0 <http://sipforum.org/pipermail/__discussion= /2008-
>January/__004026.html>>
>> =A0 =A0 =A0 =A0 <http://sipforum.org/____pipermail/discus= sion/2008-
>____January/004026.html
>>
>> <http://sipforum.org/__pipermail/discu= ssion/2008-__January/004026.html
>> >
>>
>> =A0 =A0 =A0 =A0 <http://sipforum.org/__pipermail/discussion= /2008-
>__January/004026.html
>>
>> <http://sipforum.org/pipermail/discussion/= 2008-January/004026.html>>>
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 We have a couple of open i= tems in the I-D. We
>expect
>> =A0 =A0 =A0 =A0 the WG
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 discussions
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 would guide us on how to g= o about them.
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Comments welcome.
>>
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 I'm the source of the = issues. :-)
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 The fundamental point is t= hat RFC4856 specifies a
>> =A0 =A0 =A0 =A0 *default*
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 value of
>> =A0 =A0 =A0 =A0 "yes" for annexa and annexb. This means = that if
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 annexa/annexb is not
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 specified in an answer, th= en it will default to
>yes,
>> =A0 =A0 =A0 =A0 even if the
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 offer
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 contained "no".<= br> >>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 I see a few ways to fix th= is:
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1) revise the IANA registr= ation for annexa and
>annexb to
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 remove the
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 default, at least when use= d with O/A. Instead
>> =A0 =A0 =A0 =A0 specify the
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 defaulting
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 separately for offers and = answers.
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 2) REQUIRE that the answer= contain "no" if the
>offer
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 contained "no".<= br> >>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 3) permit the answer to co= ntain "yes" (explicitly
>or
>> =A0 =A0 =A0 =A0 by default)
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 when the offer contained &= quot;no", and specify that
>this
>> =A0 =A0 =A0 =A0 still means
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 that the annex is *not* to= be used.
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 4) forbid the answer from = *explicitly* containing
>> =A0 =A0 =A0 =A0 "yes" when the
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 offer contained "no&q= uot;, but allow the answer to
>> =A0 =A0 =A0 =A0 *implicitly*
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 contain
>> =A0 =A0 =A0 =A0 "yes" (via the default) and ignore it/tr= eat it as "no".
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 None of these are ideal. (= 1) is problematic
>because
>> =A0 =A0 =A0 =A0 this is
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 used in
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 non-O/A contexts, such as = RSVP. (2) begs the
>> =A0 =A0 =A0 =A0 question of what
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 should be
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 done if this is violated. = (3) risks failing to
>> =A0 =A0 =A0 =A0 recognize that
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 the two
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 sides disagree. (4) is pra= gmatic but seems to
>> =A0 =A0 =A0 =A0 violate the
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 spirit of
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 defaults.
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 I guess my preference is t= o make (2) normative for
>> =A0 =A0 =A0 =A0 the answerer,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 while
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 making (4) normative for t= he offerer, and put
>enough
>> =A0 =A0 =A0 =A0 words
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 in so its
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 very clear what is being s= pecified and why.
>>
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 I must *really* be missing= something here; why
>does
>> =A0 =A0 =A0 =A0 the usage of
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 G.729 Annex B have to be s= ymmetrical? Until I saw
>this
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 thread, it
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 was always my understandin= g that the 'annexb'
>format
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 parameter for
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 G.729 in SDP indicated the= preference of the
>endpoint
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 sending that
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 parameter. Like nearly eve= rything else in SDP, it
>> =A0 =A0 =A0 =A0 indicates what
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 that endpoint is *prepared= to accept*, and has
>> =A0 =A0 =A0 =A0 nothing at
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 all to do
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 with what it will (or coul= d) send.
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Unless that's a comple= tely broken understanding,
>> =A0 =A0 =A0 =A0 then these
>> =A0 =A0 =A0 =A0 'interop' issues are really just very poor= ly coded
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 implementations.
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 I would interpret the curr= ent RFC language as
>follows:
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1) If an offer/answer cont= ains 'annexb=3Dno', the
>> =A0 =A0 =A0 =A0 receiver of that
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 offer/answer MUST NOT send= G.729 Annex B SID
>frames
>> =A0 =A0 =A0 =A0 to the
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 offering/answering endpoin= t.
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 2) If an offer/answer cont= ains 'annexb=3Dyes', the
>> =A0 =A0 =A0 =A0 receiver of
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 that
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 offer/answer SHOULD send G= .729 Annex B SID frames
>to the
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 offering/answering endpoin= t.
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 3) An answer's value f= or the 'annexb' parameter is
>> =A0 =A0 =A0 =A0 completely
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 independent of the value (= if any) present in the
>> =A0 =A0 =A0 =A0 offer it is
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 answering.
>>
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Thanks,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Paul
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Muthu
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -----Original Message-----=
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 From: i-d-announce-bounces@ietf.or= g
>> =A0 =A0 =A0 =A0 <mailto:i-d-announce-bounces@ietf.org>
>> =A0 =A0 =A0 =A0 <mailto:i-d-announce-bounces@__ietf.org
>> =A0 =A0 =A0 =A0 <mailto:i-d-announce-bounces@ietf.org>>
>> =A0 =A0 =A0 =A0 <mailto:i-d-announce-bounces@
>> =A0 =A0 =A0 =A0 <mailto:i-d-announce-bounces@>____ietf.org <http://ietf.org>
>> =A0 =A0 =A0 =A0 <mailto:i-d-announce-bounces@__ietf.org
>> =A0 =A0 =A0 =A0 <mailto:i-d-announce-bounces@ietf.org>>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 [mailto:i-d-announce-bounces@
>> =A0 =A0 =A0 =A0 <mailto:i-d-announce-bounces@>
>> =A0 =A0 =A0 =A0 <mailto:i-d-announce-bounces@
>> =A0 =A0 =A0 =A0 <mailto:i-d-announce-bounces@>>______ietf.org
><http://ietf.org&g= t;
>> =A0 =A0 =A0 =A0 <= http://ietf.org>
>> =A0 =A0 =A0 =A0 <mailto:i-d-announce-bounces@
>> =A0 =A0 =A0 =A0 <mailto:i-d-announce-bounces@>____ietf.org <http://ietf.org>
>> =A0 =A0 =A0 =A0 <mailto:i-d-announce-bounces@__ietf.org
>> =A0 =A0 =A0 =A0 <mailto:i-d-announce-bounces@ietf.org>>>] = On Behalf Of
>> =A0 =A0 =A0 =A0 internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>
>> =A0 =A0 =A0 =A0 <mailto:internet-drafts@ietf.__org
>> =A0 =A0 =A0 =A0 <mailto:internet-drafts@ietf.org>>
>> =A0 =A0 =A0 =A0 <mailto:internet-drafts@ietf.
>> <mailto:internet-drafts@ietf.>____org
>>
>> =A0 =A0 =A0 =A0 <mailto:internet-drafts@ietf.__org
>> =A0 =A0 =A0 =A0 <mailto:internet-drafts@ietf.org>>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Sent: Friday, February 24,= 2012 5:57 PM
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 To: i-d-announce@ietf.org
>> =A0 =A0 =A0 =A0 <mailto:i-d-announce@ietf.org> <mailto:i-d-announce@ietf.org
>> =A0 =A0 =A0 =A0 <mailto:i-d-announce@ietf.org>>
>> =A0 =A0 =A0 =A0 <mailto:i-d-announce@ietf.org <mailto:i-d-announce@ietf.org>
>> =A0 =A0 =A0 =A0 <mailto:i-d-announce@ietf.org <mailto:i-d-
>announce@ietf.or= g>>__>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Subject: I-D Action:
>>
>> draft-muthu-payload-offer-______answer-g723-g729-00.txt
>>
>>
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 A New Internet-Draft is av= ailable from the on-line
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Internet-Drafts
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 directories.
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Title : Offer/Answer Consi= derations for G.723
>Annex A
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 and G.729 Annex B
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Author(s) : Muthu Arul Moz= hi Perumal
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Parthasarathi Ravindran >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Filename :
>>
>> draft-muthu-payload-offer-______answer-g723-g729-00.txt
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Pages : 8
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Date : 2012-02-24
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 [RFC4856] describes the an= nexa parameter for G723
>> =A0 =A0 =A0 =A0 and the annexb
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 parameter for G729, G729D = and G729E. However, the
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 specification does
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 not describe the offerer a= nd answerer behavior
>when the
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 value of the
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 annexa or annexb parameter= does not match in the
>SDP
>> =A0 =A0 =A0 =A0 offer and
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 answer. This document prov= ides the offer/answer
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 considerations for
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 these parameters.
>>
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 A URL for this Internet-Dr= aft is:
>> =A0 =A0 =A0 =A0 http://www.ietf.org/internet-______drafts/draft-muthu-payload-
>______offer-answer-g72
>> =A0 =A0 =A0 =A0 <http://www.ietf.org/internet-_= ___drafts/draft-muthu-payload-
>____offer-answer-g72>
>> =A0 =A0 =A0 =A0 <http://www.ietf.org/internet-_= ___drafts/draft-muthu-payload-
>____offer-answer-g72
>>
>> <http://www.ietf.org/internet-__drafts= /draft-muthu-payload-__offer-ans
>> wer-g72>>
>>
>>
>> =A0 =A0 =A0 =A0 <http://www.ietf.org/internet-_= ___drafts/draft-muthu-payload-
>____offer-answer-g72
>> =A0 =A0 =A0 =A0 <http://www.ietf.org/internet-__d= rafts/draft-muthu-payload-
>__offer-answer-g72>
>> =A0 =A0 =A0 =A0 <http://www.ietf.org/internet-__d= rafts/draft-muthu-payload-
>__offer-answer-g72
>>
>> <http://www.ietf.org/internet-drafts/d= raft-muthu-payload-offer-answer-
>> g72>>>
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 3-g729-00.txt
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Internet-Drafts are also a= vailable by anonymous
>FTP at:
>> =A0 =A0 =A0 =A0 ftp://ftp.ietf.org/internet-______drafts/
>> =A0 =A0 =A0 =A0 <ftp://ftp.ietf.org/internet-____drafts/>
>> =A0 =A0 =A0 =A0 <ftp://ftp.ietf.org/internet-____drafts/
>> =A0 =A0 =A0 =A0 <ftp://ftp.ietf.org/internet-__drafts/>>
>>
>> =A0 =A0 =A0 =A0 <ftp://ftp.ietf.org/internet-____drafts/
>> =A0 =A0 =A0 =A0 <ftp://ftp.ietf.org/internet-__drafts/>
>> =A0 =A0 =A0 =A0 <ftp://ftp.ietf.org/internet-__drafts/
>> =A0 =A0 =A0 =A0 <ftp://ftp.ietf.org/internet-drafts/>>>
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 This Internet-Draft can be= retrieved at:
>> =A0 =A0 =A0 =A0 ftp://ftp.ietf.org/internet-______drafts/draft-muthu-payload-
>______offer-answer-g723
>> =A0 =A0 =A0 =A0 <ftp://ftp.ietf.org/internet-___= _drafts/draft-muthu-payload-
>____offer-answer-g723>
>> =A0 =A0 =A0 =A0 <ftp://ftp.ietf.org/internet-___= _drafts/draft-muthu-payload-
>____offer-answer-g723
>>
>> <ftp://ftp.ietf.org/internet-__drafts/= draft-muthu-payload-__offer-answ
>> er-g723>>
>>
>>
>> =A0 =A0 =A0 =A0 <ftp://ftp.ietf.org/internet-___= _drafts/draft-muthu-payload-
>____offer-answer-g723
>> =A0 =A0 =A0 =A0 <ftp://ftp.ietf.org/internet-__dra= fts/draft-muthu-payload-
>__offer-answer-g723>
>> =A0 =A0 =A0 =A0 <ftp://ftp.ietf.org/internet-__dra= fts/draft-muthu-payload-
>__offer-answer-g723
>>
>> <ftp://ftp.ietf.org/internet-drafts/dr= aft-muthu-payload-offer-answer-g
>> 723>>>
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -g729-00.txt
>>
>>
>> _____________________________________________________
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 I-D-Announce mailing list<= br> >> =A0 =A0 =A0 =A0 I-D-Announce@ietf.org <mailto:I-D-Announce@ietf.org>
>> =A0 =A0 =A0 =A0 <mailto:I-D-Announce@ietf.org <mailto:I-D-Announce@ietf.org>><= br> >> =A0 =A0 =A0 =A0 <mailto:I-D-Announce@ietf.org <mailto:I-D-Announce@ietf.org>
>> =A0 =A0 =A0 =A0 <mailto:I-D-Announce@ietf.org <mailto:I-D-
>Announce@ietf.or= g>>__>
>> =A0 =A0 =A0 =A0 https://www.ietf.org/mailman/______listinfo/i-d-announce
>> =A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/____lis= tinfo/i-d-announce>
>> =A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/____lis= tinfo/i-d-announce
>> =A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/__listinf= o/i-d-announce>>
>>
>> =A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/____lis= tinfo/i-d-announce
>> =A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/__listinf= o/i-d-announce>
>> =A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/__listinf= o/i-d-announce
>> =A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/listinfo/i-= d-announce>>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Internet-Draft directories= :
>> =A0 =A0 =A0 =A0 http://www.ietf.org/shadow.______html
>> =A0 =A0 =A0 =A0 <http://www.ietf.org/shadow.____html>
>> =A0 =A0 =A0 =A0 <http://www.ietf.org/shadow.____html
>> =A0 =A0 =A0 =A0 <http://www.ietf.org/shadow.__html>>
>> =A0 =A0 =A0 =A0 <http://www.ietf.org/shadow.____html
>> =A0 =A0 =A0 =A0 <http://www.ietf.org/shadow.__html>
>> =A0 =A0 =A0 =A0 <http://www.ietf.org/shadow.__html
>> =A0 =A0 =A0 =A0 <http://www.ietf.org/shadow.html>>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 or ftp://ftp.ietf.org/ietf/______1shadow-sites.txt
>> =A0 =A0 =A0 =A0 <ftp://ftp.ietf.org/ietf/____1shadow-sites.txt= >
>> =A0 =A0 =A0 =A0 <ftp://ftp.ietf.org/ietf/____1shadow-sites.txt=
>> =A0 =A0 =A0 =A0 <ftp://ftp.ietf.org/ietf/__1shadow-sites.txt= >>
>> =A0 =A0 =A0 =A0 <ftp://ftp.ietf.org/ietf/____1shadow-sites.txt=
>> =A0 =A0 =A0 =A0 <ftp://ftp.ietf.org/ietf/__1shadow-sites.txt= >
>> =A0 =A0 =A0 =A0 <ftp://ftp.ietf.org/ietf/__1shadow-sites.txt=
>> =A0 =A0 =A0 =A0 <ftp://ftp.ietf.org/ietf/1shadow-sites.txt>= >>
>>
>>
>>
>> _____________________________________________________
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 payload mailing list
>> =A0 =A0 =A0 =A0 payload@ietf.org <mailto:payload@ietf.org>
>> =A0 =A0 =A0 =A0 <mailto:payload@ietf.org <mailto:payload@ietf.org>>
>> =A0 =A0 =A0 =A0 <mailto:payload@ietf.org <mailto:payload@ietf.org>
>> =A0 =A0 =A0 =A0 <mailto:payload@ietf.org <mailto:payload@ietf.org>>>
>> =A0 =A0 =A0 =A0 https://www.ietf.org/mailman/______listinfo/payload
>> =A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/____listinfo= /payload>
>> =A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/____listinfo= /payload
>> =A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/__listinfo/pay= load>>
>>
>> =A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/____listinfo= /payload
>> =A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/__listinfo/pay= load>
>> =A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/__listinfo/pay= load
>> =A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/listinfo/payload= >>>
>>
>>
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 --
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Kevin P. Fleming
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Digium, Inc. | Director of= Software Technologies
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Jabber: kfleming@digium.com
>> =A0 =A0 =A0 =A0 <mailto:kfleming@digium.com> <mailto:kfleming@digium.com
>> =A0 =A0 =A0 =A0 <mailto:kfleming@digium.com>>
>> =A0 =A0 =A0 =A0 <mailto:kfleming@digium.com <mailto:kfleming@digium.com>
>> =A0 =A0 =A0 =A0 <mailto:kfleming@digium.com <mailto:kfleming@digium.com>>> | >SIP:
>> =A0 =A0 =A0 =A0 kpfleming@digium.com <mailto:kpfleming@digium.com>
>> =A0 =A0 =A0 =A0 <mailto:kpfleming@digium.com <mailto:kpfleming@digium.com>>
>> =A0 =A0 =A0 =A0 <mailto:kpfleming@digium.com <mailto:kpfleming@digium.com>
>> =A0 =A0 =A0 =A0 <mailto:kpfleming@digium.com <mailto:kpfleming@digium.com>>><= br> >>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | Skype: kpfleming
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 445 Jan Davis Drive NW - H= untsville, AL 35806 -
>USA
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Check us out at www.digium.com
>> =A0 =A0 =A0 =A0 <http://www.digium.com> <http://www.digium.com>
>> =A0 =A0 =A0 =A0 <http://www.digium.com> &
>> =A0 =A0 =A0 =A0 www.asterisk.org <http://www.asterisk.org>
><http://www.as= terisk.org>
>> =A0 =A0 =A0 =A0 <http://www.asterisk.org>
>>
>> _____________________________________________________
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 payload mailing list
>> =A0 =A0 =A0 =A0 payload@ietf.org <mailto:payload@ietf.org>
>> =A0 =A0 =A0 =A0 <mailto:payload@ietf.org <mailto:payload@ietf.org>>
>> =A0 =A0 =A0 =A0 <mailto:payload@ietf.org <mailto:payload@ietf.org>
>> =A0 =A0 =A0 =A0 <mailto:payload@ietf.org <mailto:payload@ietf.org>>>
>> =A0 =A0 =A0 =A0 https://www.ietf.org/mailman/______listinfo/payload
>> =A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/____listinfo= /payload>
>> =A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/____listinfo= /payload
>> =A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/__listinfo/pay= load>>
>>
>> =A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/____listinfo= /payload
>> =A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/__listinfo/pay= load>
>> =A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/__listinfo/pay= load
>> =A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/listinfo/payload= >>>
>>
>>
>>
>>
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 --
>> =A0 =A0 =A0 =A0 =A0 =A0 Kevin P. Fleming
>> =A0 =A0 =A0 =A0 =A0 =A0 Digium, Inc. | Director of Software Techno= logies
>> =A0 =A0 =A0 =A0 =A0 =A0 Jabber: kfleming@digium.com <mailto:kfleming@digium.com>
>> =A0 =A0 =A0 =A0 <mailto:kfleming@digium.com <mailto:kfleming@digium.com>> |
>SIP:
>> =A0 =A0 =A0 =A0 kpfleming@digium.com <mailto:kpfleming@digium.com>
>> =A0 =A0 =A0 =A0 <mailto:kpfleming@digium.com <mailto:kpfleming@digium.com>> | >> =A0 =A0 =A0 =A0 Skype: kpfleming
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 445 Jan Davis Drive NW - Huntsville, AL 35= 806 - USA
>> =A0 =A0 =A0 =A0 =A0 =A0 Check us out at www.digium.com <http://www.digium.com>
>> =A0 =A0 =A0 =A0 <http://www.digium.com> &
>> =A0 =A0 =A0 =A0 www.asterisk.org <http://www.asterisk.org>
>> <http://w= ww.asterisk.org>
>>
>>
>>
>>
>> =A0 =A0 --
>> =A0 =A0 Kevin P. Fleming
>> =A0 =A0 Digium, Inc. | Director of Software Technologies
>> =A0 =A0 Jabber: kfleming@digium.com <mailto:kfleming@digium.com> | SIP:
>> =A0 =A0 = kpfleming@digium.com <mailto:kpfleming@digium.com> | Skype:
>kpfleming
>> =A0 =A0 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
>> =A0 =A0 Check us out at www.digium.com <http://www.digium.com> &
>> =A0 =A0 www.= asterisk.org <= http://www.asterisk.org>
>>
>>
>

>_______________________________________________<= br> >payload mailing list
>payload@ietf.org<= /a>
>https://www.ietf.org/mailman/listinfo/payload

=A0


--f46d04428ff464bcee04babb0ccb-- From daveoran@orandom.net Thu Mar 8 06:04:26 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC34821F8691 for ; Thu, 8 Mar 2012 06:04:26 -0800 (PST) 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=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TDb0WMSCSGvo for ; Thu, 8 Mar 2012 06:04:23 -0800 (PST) Received: from spark.crystalorb.net (spark.crystalorb.net [IPv6:2001:470:d:21b:3c00::1]) by ietfa.amsl.com (Postfix) with ESMTP id 680E421F8674 for ; Thu, 8 Mar 2012 06:04:23 -0800 (PST) Received: from stealth-10-32-245-150.cisco.com (c-66-31-41-8.hsd1.ma.comcast.net [66.31.41.8]) (authenticated bits=0) by spark.crystalorb.net (8.14.3/8.14.3/Debian-9.4) with ESMTP id q28E4IDJ027543 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 8 Mar 2012 06:04:19 -0800 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_A827B55D-AE14-433B-94D9-51E5E0FC33CC" From: David R Oran In-Reply-To: Date: Thu, 8 Mar 2012 09:04:15 -0500 Message-Id: References: <1D062974A4845E4D8A343C653804920207ABB1E1@XMB-BGL-414.cisco.com> <4F4BB973.4060508@alum.mit.edu> <4F4D06B6.6020905@digium.com> <4F4D17C8.7070201@alum.mit.edu> <4F4D26AE.5070009@digium.com> <4F4D40A3.6030309@digium.com> <4F4E44C3.4080803@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E06BEC7@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E1F7F40@inba-mail01.sonusnet.com> To: "Chhatwal, Harprit S" X-Mailer: Apple Mail (2.1257) Cc: "payload@ietf.org" Subject: Re: [payload] FW: I-D Action: draft-muthu-payload-offer-answer-g723-g729-00.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 14:04:27 -0000 --Apple-Mail=_A827B55D-AE14-433B-94D9-51E5E0FC33CC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Mar 8, 2012, at 8:13 AM, Chhatwal, Harprit S wrote: > I didn=92t fully understand your network. My guess is that in case of = bandwidth constrained in one direction of the session, then the = low-bandwidth codec has to be negotiated in that direction. ISTM, = asymmetric annexb parameter negotiation is not going to solve the = bandwidth issue. Please let me know how asymmetric annexb will solve = bandwidth issue.=20 >=20 >=20 > Perhaps I have not explained this clearly enough previously, so allow = me to try again. The bandwidth in the customer's network is = sufficiently constrained in one direction that the customer wishes to = use G.729/G.729A with G.729B active (ie using VAD/DTX) to allow the = speech codec bandwidth requirements in this direction to fit within the = network bandwidth envelope. In the other direction, the network = bandwidth available is somewhat less constrained, so the customer would = like to use G.729/G.729A without G.729B active to get slightly better = quality. =20 Well, even if you've negotiated it, it doesn't mean you actually have to = use it. If the endpoint is smart enough to know whether to negotiate it = or not, I suspect it's smart enough to know not to bother using it when = the bandwidth is sufficient. Seems like a corner case, although the general problem of how to do = asymmetric codec negotiation probably has more compelling use cases. > However, even in this direction, the network bandwidth is still = limited enough that a higher-rate codec such as G.711 will not work. >=20 > For the second part of your question, please see the earlier mails on = this thread as this has been covered previously. >=20 > Regards. Harprit. >=20 > Harprit S. Chhatwal > InnoMedia >=20 > On 8 March 2012 10:12, Ravindran, Parthasarathi = wrote: > Hi Harpit, >=20 > =20 >=20 > Sorry for the delay reply. >=20 > =20 >=20 > I didn=92t fully understand your network. My guess is that in case of = bandwidth constrained in one direction of the session, then the = low-bandwidth codec has to be negotiated in that direction. ISTM, = asymmetric annexb parameter negotiation is not going to solve the = bandwidth issue. Please let me know how asymmetric annexb will solve = bandwidth issue. >=20 > =20 >=20 > AFAIK, answerer expectation of asymmetric annexb will leads to the = interop issue in case of offerer mentions as =93annexb=3Dno=94 but = answerer mandates to have =93annexb=3Dyes=94. Please let me know your = opinion on the same. >=20 >=20 > Thanks > Partha >=20 > =20 >=20 > =20 >=20 > =20 >=20 > From: Chhatwal, Harprit S [mailto:hschhatwal@gmail.com]=20 > Sent: Thursday, March 01, 2012 4:59 PM > To: Ravindran, Parthasarathi > Cc: Paul Kyzivat; Kevin P. Fleming; payload@ietf.org >=20 >=20 > Subject: Re: [payload] FW: I-D Action: = draft-muthu-payload-offer-answer-g723-g729-00.txt >=20 > =20 >=20 > On 1 March 2012 06:13, Ravindran, Parthasarathi = wrote: >=20 > I'm not very clear on the bandwidth optimization based on asymmetric = annexb parameter negotiation. Could you please elaborate. >=20 > =20 >=20 > This is for a network where the bandwidth is severely constrained in = one direction, so the operator wishes to use G.729B to minimise = bandwidth usage in one direction, while not using G.729B in the other = direction where bandwidth is less constrained. >=20 > =20 >=20 > Regards. Harprit. >=20 > =20 >=20 > Harprit S. Chhatwal >=20 > InnoMedia >=20 > =20 >=20 > On 1 March 2012 06:13, Ravindran, Parthasarathi = wrote: >=20 > Hi Harpit, >=20 > Thanks for looking into the draft. I agree with you that asymmetric = annexb negotiation is not taken into the account in the draft currently. = In fact, I come across the scenario wherein annexb is not supported by = offerer ,mentioned in offer SDP as annexb=3Dno and answerer assumes = about annexb support (no annexb parameter in answer) in offerer side = which leads to the call failure. >=20 > I'm not very clear on the bandwidth optimization based on asymmetric = annexb parameter negotiation. Could you please elaborate. >=20 > Thanks > Partha >=20 >=20 > >-----Original Message----- > >From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On > >Behalf Of Paul Kyzivat > >Sent: Wednesday, February 29, 2012 9:01 PM > >To: Chhatwal, Harprit S > >Cc: payload@ietf.org > >Subject: Re: [payload] FW: I-D Action: = draft-muthu-payload-offer-answer- > >g723-g729-00.txt > > > >On 2/29/12 9:34 AM, Chhatwal, Harprit S wrote: > >> On 28 February 2012 21:01, Kevin P. Fleming >> > wrote: > >> > >> > >> That requirement is counter to what the draft proposes. We = can't > >> have it both ways: either the G.729 'annexb' format parameter = is a > >> negotiated parameter (in which case its usage is symmetrical by > >> definition) or it is a declarative parameter (in which case the > >> usage can be, but is not required to be, asymmetrical). > >> > >> > >> Yes, I concur that the draft (as it currently stands) cannot > >> accommodate an asymmetric use of G.729B. However, if we agree that > >> both scenarios are true, real-world scenarios that need addressing, = ie > >> (a) the negotiated case where the use of G.729B is symmetric and = (b) > >> the declarative case where the use of G.729B can be asymmetric = (and, > >> in my opinion, both are valid scenarios), then I would suggest that = we > >> need to come up with a way of handling both situations (perhaps > >> through the use of an extra fmtp parameter indicating whether the = use > >> is declarative or negotiated - or any other suggestions the group > >might have). > >> > >> If not, and we are only to allow the negotiated, symmetric use, = then > >> I'd appreciate any suggestions from the group for how my = organisation > >> might deal with the requirement of an asymmetric use of G.729B > >mentioned below. > > > >There is one way that is available right now: > > > >Negotiate two separate one way m-lines. > >But this might be too weird for common use. > > > > Thanks, > > Paul > > > >> Regards. Harprit. > >> > >> Harprit S. Chhatwal > >> InnoMedia > >> > >> On 28 February 2012 21:01, Kevin P. Fleming >> > wrote: > >> > >> On 02/28/2012 02:58 PM, Chhatwal, Harprit S wrote: > >> > >> Speaking as a codec person :-), I think the draft does = address > >a > >> real > >> issue and is reasonably clear in its content. However, it > >does not > >> appear to address (as far as I can see), the case where an > >> asymmetric > >> use of G.729B is required. This is an actual issue as we = are > >> faced with > >> a customer requirement where the use of G.729B is required = in > >one > >> direction and not the other (for bandwidth reasons). Given > >the > >> current > >> specs do not appear to definitively cover this case, it = would > >be > >> good to > >> see if this can be addressed through the proposed draft. > >> > >> > >> That requirement is counter to what the draft proposes. We = can't > >> have it both ways: either the G.729 'annexb' format parameter = is a > >> negotiated parameter (in which case its usage is symmetrical by > >> definition) or it is a declarative parameter (in which case the > >> usage can be, but is not required to be, asymmetrical). > >> > >> > >> Regards. Harprit. > >> > >> Harprit S. Chhatwal > >> InnoMedia > >> > >> On 28 February 2012 19:10, Kevin P. Fleming > >> > >> >> > >wrote: > >> > >> On 02/28/2012 12:07 PM, Paul Kyzivat wrote: > >> > >> Clarification: > >> > >> In my comments on the draft I was not questioning = the > >> assumption > >> of that > >> draft that a common value of this parameter is > >> *negotiated* via O/A. > >> *If* you accept that assumption then my comments > >> hopefully make > >> sense. > >> > >> But if there is debate regarding whether the = parameter > >is > >> negotiated or > >> declarative, then that needs to be settled first, > >before > >> nailing > >> down > >> clarifications for how the negotiation happens. > >> > >> Not being a codec person, I don't know what the = common > >> practice > >> is here. > >> So I'm going to let those that have the knowledge > >argue > >> that. > >> > >> > >> Correct on all points; your comments make complete = sense > >if > >> 'annexb' > >> is intended to be a negotiated parameter. > >> > >> I'm not a codec person (although I'd probably be = willing > >to > >> play one > >> on TV is the need arose ), but there are so many = other > >> codec/format parameters that are declarative already = that > >I > >> don't > >> see any need for this one to have to be negotiated. The > >> impact of > >> using Annex B or not is purely on one direction of the > >media > >> stream, > >> and it's not even mandatory that the encoder use Annex = B > >> mode just > >> because 'annexb=3Dyes'. Granted, it's pretty unlikely = that > >an > >> implementation that cannot accept incoming SID frames > >would > >> also be > >> able to generate them, but I can think of completely > >reasonable > >> situations for an implementation that can generate them > >being > >> willing to do so while at the same time disallowing > >> reception of them. > >> > >> > >> > >> Thanks, > >> Paul > >> > >> On 2/28/12 12:34 PM, Chhatwal, Harprit S wrote: > >> > >> Kevin, > >> > >> First of all, from RFC3264, I agree with you = that > >> for things > >> like IP > >> addresses, ports, payload types, ptime, the SDP > >that one > >> party sends > >> indicates the address/port/PT/ptime that the > >sender > >> would > >> like to > >> receive on. However, I don't believe this is > >generally > >> correct for all > >> parameters. For instance, for codecs (again = from > >> RFC3264), > >> the codec(s) > >> included in an SDP offer indicates the codec(s) > >the > >> offerer > >> is willing > >> to send AND receive (if the directional = attribute > >is > >> 'sendrecv'). As an > >> example, if party A is the offerer and sends = G.729 > >& > >> G.711 > >> in its SDP > >> offer, it is saying that it is willing to use > >either > >> codec. > >> If the > >> answerer replies with G.711, then it is only > >willing > >> to use > >> G.711, and > >> then G.729 will not be used in either = direction. > >> > >> Turning now to silence suppression, the = situation > >> does not > >> seem very > >> clear. This is what RFC3264 has to say about = fmtp > >> parameters > >> such as > >> 'annexb' : > >> > >> The interpretation of fmtp parameters in an = offer > >> depends on the > >> > >> parameters. In many cases, those parameters > >describe > >> specific > >> > >> configurations of the media format, and should > >> therefore be > >> processed > >> > >> as the media format value itself would be. This > >> means that > >> the same > >> > >> fmtp parameters with the same values MUST be > >present > >> in the > >> answer if > >> > >> the media format they describe is present in = the > >answer. > >> Other fmtp > >> > >> parameters are more like parameters, for which = it > >is > >> perfectly > >> > >> acceptable for each agent to use different = values. > >> In that > >> case, the > >> > >> answer MAY contain fmtp parameters, and those = MAY > >> have the same > >> > >> values as those in the offer, or they MAY be > >> different. SDP > >> > >> extensions that define new parameters SHOULD > >specify > >> the proper > >> > >> interpretation in offer/answer. > >> > >> To me, 'annexb' is more like a parameter in = this > >> sense and, > >> in this > >> case, everything is allowed - the answer may > >contain the > >> same fmtp or > >> different. RFC3264 doesn't appear to specify = the > >> interpretation. The > >> problem is that I don't know of anywhere else > >where the > >> interpretation > >> is specified either. RFC4856 specifies the > >parameter > >> 'annexb', but > >> doesn't say whether it can be used = asymmetrically > >> (or how). > >> The only > >> other guidance I can find on this is elsewhere = in > >> RFC3264: > >> > >> The list of media formats for each media stream > >> conveys two > >> pieces of > >> > >> information, namely the set of formats (codecs = and > >any > >> parameters > >> > >> associated with the codec, in the case of RTP) > >that the > >> offerer is > >> > >> capable of sending and/or receiving (depending = on > >> the direction > >> > >> attributes)... > >> > >> ...For a sendrecv stream, the offer SHOULD > >indicate > >> those > >> > >> codecs that the offerer is willing to send and > >> receive with. > >> > >> So, this appears to be lumping codec parameters > >with > >> codecs > >> and so both > >> should behave in the same way. If we take this > >> interpretation, then > >> indicating 'annexb=3Dno' indicates that the = sender > >of > >> this SDP > >> is willing > >> to send and receive with silence suppression = off. > >So, > >> according to > >> this, if the offerer sends 'annexb=3Dyes' in = the > >offer > >> and the > >> answerer > >> sends back 'annexb=3Dno', then there is a = mismatch > >and the > >> offerer should > >> send a re-INVITE with 'annexb=3Dno' to resolve = the > >> conflict. > >> According to > >> this interpretation, we cannot have an = asymmetric > >> use of silence > >> suppression. However, from the discussion we're > >> having, I > >> can see that > >> all of this is somewhat open to interpretation > >> (since the > >> specs do not > >> seem to be clear) and I agree with the authors = of > >> this ID > >> that we need > >> some clarification as to how this issue should = be > >> dealt with > >> (and > >> whether asymmetric use of annexb should be = allowed > >> and, if > >> so, how). > >> > >> > >> Regards. Harprit. > >> > >> > >> Harprit S. Chhatwal > >> > >> InnoMedia > >> > >> > >> On 28 February 2012 16:54, Kevin P. Fleming > >> > >> > > >> > >> >> >>__> > >> > >> wrote: > >> > >> On 02/27/2012 11:12 AM, Paul Kyzivat wrote: > >> > >> On 2/27/12 6:33 AM, Muthu Arul Mozhi Perumal > >> (mperumal) wrote: > >> > >> We have submitted an I-D clarifying the > >offer/answer > >> considerations for > >> the Annex A flavor of G.723 and the Annex B > >flavors of > >> G.729, G.729D and > >> G.729E. This clarification is missing in RFC = 4856, > >> leading > >> to interop > >> issues, for e.g: > >> http://sipforum.org/pipermail/______discussion/2008- > >January/______004026.html > >> >January/____004026.html> > >> >__January/__004026.html > >> >January/__004026.html>> > >> >____January/004026.html > >> > >> = >> > > >> > >> >__January/004026.html > >> > >> = >> > >> > >> We have a couple of open items in the I-D. We > >expect > >> the WG > >> discussions > >> would guide us on how to go about them. > >> > >> Comments welcome. > >> > >> > >> I'm the source of the issues. :-) > >> > >> The fundamental point is that RFC4856 specifies = a > >> *default* > >> value of > >> "yes" for annexa and annexb. This means that if > >> annexa/annexb is not > >> specified in an answer, then it will default to > >yes, > >> even if the > >> offer > >> contained "no". > >> > >> I see a few ways to fix this: > >> > >> 1) revise the IANA registration for annexa and > >annexb to > >> remove the > >> default, at least when used with O/A. Instead > >> specify the > >> defaulting > >> separately for offers and answers. > >> > >> 2) REQUIRE that the answer contain "no" if the > >offer > >> contained "no". > >> > >> 3) permit the answer to contain "yes" = (explicitly > >or > >> by default) > >> when the offer contained "no", and specify that > >this > >> still means > >> that the annex is *not* to be used. > >> > >> 4) forbid the answer from *explicitly* = containing > >> "yes" when the > >> offer contained "no", but allow the answer to > >> *implicitly* > >> contain > >> "yes" (via the default) and ignore it/treat it as "no". > >> > >> None of these are ideal. (1) is problematic > >because > >> this is > >> used in > >> non-O/A contexts, such as RSVP. (2) begs the > >> question of what > >> should be > >> done if this is violated. (3) risks failing to > >> recognize that > >> the two > >> sides disagree. (4) is pragmatic but seems to > >> violate the > >> spirit of > >> defaults. > >> > >> I guess my preference is to make (2) normative = for > >> the answerer, > >> while > >> making (4) normative for the offerer, and put > >enough > >> words > >> in so its > >> very clear what is being specified and why. > >> > >> > >> I must *really* be missing something here; why > >does > >> the usage of > >> G.729 Annex B have to be symmetrical? Until I = saw > >this > >> thread, it > >> was always my understanding that the 'annexb' > >format > >> parameter for > >> G.729 in SDP indicated the preference of the > >endpoint > >> sending that > >> parameter. Like nearly everything else in SDP, = it > >> indicates what > >> that endpoint is *prepared to accept*, and has > >> nothing at > >> all to do > >> with what it will (or could) send. > >> > >> Unless that's a completely broken = understanding, > >> then these > >> 'interop' issues are really just very poorly coded > >> implementations. > >> I would interpret the current RFC language as > >follows: > >> > >> 1) If an offer/answer contains 'annexb=3Dno', = the > >> receiver of that > >> offer/answer MUST NOT send G.729 Annex B SID > >frames > >> to the > >> offering/answering endpoint. > >> > >> 2) If an offer/answer contains 'annexb=3Dyes', = the > >> receiver of > >> that > >> offer/answer SHOULD send G.729 Annex B SID = frames > >to the > >> offering/answering endpoint. > >> > >> 3) An answer's value for the 'annexb' parameter = is > >> completely > >> independent of the value (if any) present in = the > >> offer it is > >> answering. > >> > >> > >> Thanks, > >> Paul > >> > >> Muthu > >> > >> -----Original Message----- > >> From: i-d-announce-bounces@ietf.org > >> > >> >> > > >> >> ____ietf.org = > >> >> >> > >> [mailto:i-d-announce-bounces@ > >> > >> >> >______ietf.org > > > >> > >> >> ____ietf.org = > >> >> >>] On Behalf Of > >> internet-drafts@ietf.org > >> >> > > >> >> ____org > >> > >> >> >> > >> Sent: Friday, February 24, 2012 5:57 PM > >> To: i-d-announce@ietf.org > >> = >> > > >> > >> >announce@ietf.org>>__> > >> Subject: I-D Action: > >> > >> draft-muthu-payload-offer-______answer-g723-g729-00.txt > >> > >> > >> > >> A New Internet-Draft is available from the = on-line > >> Internet-Drafts > >> directories. > >> > >> Title : Offer/Answer Considerations for G.723 > >Annex A > >> and G.729 Annex B > >> Author(s) : Muthu Arul Mozhi Perumal > >> Parthasarathi Ravindran > >> Filename : > >> > >> draft-muthu-payload-offer-______answer-g723-g729-00.txt > >> > >> Pages : 8 > >> Date : 2012-02-24 > >> > >> [RFC4856] describes the annexa parameter for = G723 > >> and the annexb > >> parameter for G729, G729D and G729E. However, = the > >> specification does > >> not describe the offerer and answerer behavior > >when the > >> value of the > >> annexa or annexb parameter does not match in = the > >SDP > >> offer and > >> answer. This document provides the offer/answer > >> considerations for > >> these parameters. > >> > >> > >> A URL for this Internet-Draft is: > >> = http://www.ietf.org/internet-______drafts/draft-muthu-payload- > >______offer-answer-g72 > >> = >____offer-answer-g72> > >> = >____offer-answer-g72 > >> > >> = >> wer-g72>> > >> > >> > >> = >____offer-answer-g72 > >> >__offer-answer-g72> > >> >__offer-answer-g72 > >> > >> = >> g72>>> > >> > >> 3-g729-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-muthu-payload- > >______offer-answer-g723 > >> = >____offer-answer-g723> > >> = >____offer-answer-g723 > >> > >> = >> er-g723>> > >> > >> > >> = >____offer-answer-g723 > >> >__offer-answer-g723> > >> >__offer-answer-g723 > >> > >> = >> 723>>> > >> > >> -g729-00.txt > >> > >> > >> _____________________________________________________ > >> > >> I-D-Announce mailing list > >> I-D-Announce@ietf.org > >> > > >> > >> >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 > >> > >> >> > > >> >> > >> >> >> > >> > >> > >> > >> _____________________________________________________ > >> > >> payload mailing list > >> payload@ietf.org > >> > > >> > >> >> > >> https://www.ietf.org/mailman/______listinfo/payload > >> > >> >> > > >> > >> >> > >> >> >> > >> > >> > >> > >> -- > >> 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 > > > >> > >> > >> _____________________________________________________ > >> > >> payload mailing list > >> payload@ietf.org > >> > > >> > >> >> > >> https://www.ietf.org/mailman/______listinfo/payload > >> > >> >> > > >> > >> >> > >> >> >> > >> > >> > >> > >> > >> > >> -- > >> 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 > >> > >> > >> > >> > >> > >> -- > >> 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 > >> > >> > > >=20 > >_______________________________________________ > >payload mailing list > >payload@ietf.org > >https://www.ietf.org/mailman/listinfo/payload >=20 > =20 >=20 >=20 > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload --Apple-Mail=_A827B55D-AE14-433B-94D9-51E5E0FC33CC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

I didn=92t fully understand your network. My guess is that  in = case of bandwidth constrained in one direction of the session, then the = low-bandwidth codec has to be negotiated in that direction. ISTM, = asymmetric annexb parameter negotiation is not going to solve the = bandwidth issue. Please let me know how asymmetric annexb will solve = bandwidth issue. 


Perhaps I have not explained this clearly enough = previously, so allow me to try again.  The bandwidth in the = customer's network is sufficiently constrained in one direction that the = customer wishes to use G.729/G.729A with G.729B active (ie using = VAD/DTX) to allow the speech codec bandwidth requirements in this = direction to fit within the network bandwidth envelope. In the other = direction, the network bandwidth available is somewhat less = constrained, so the customer would like to use G.729/G.729A without = G.729B active to get slightly better quality. =  
Well, even if you've negotiated it, it doesn't = mean you actually have to use it. If the endpoint is smart enough to = know whether to negotiate it or not, I suspect it's smart enough to know = not to bother using it when the bandwidth is = sufficient.

Seems like a corner case, although = the general problem of how to do asymmetric codec negotiation probably = has more compelling use cases.

However, even in this = direction, the network bandwidth is still limited enough that a = higher-rate codec such as G.711 will not work.

For the = second part of your question, please see the earlier mails on this = thread as this has been covered previously.

Regards.  Harprit.

Harprit S. Chhatwal
InnoMedia

On 8 March = 2012 10:12, Ravindran, Parthasarathi <pravindran@sonusnet.com> wrote:

Hi Harpit,

 

Sorry for the delay = reply.

 

I didn=92t fully understand your network. My guess = is that  in case of bandwidth constrained in one direction of the = session, then the low-bandwidth codec has to be negotiated in that direction. ISTM, asymmetric annexb parameter = negotiation is not going to solve the bandwidth issue. Please let me = know how asymmetric annexb will solve bandwidth = issue.

 

AFAIK, answerer expectation of asymmetric annexb = will leads to the interop issue in case of offerer mentions as = =93annexb=3Dno=94 but answerer mandates to have =93annexb=3Dyes=94.  Please let me know your opinion on the same.

Thanks
Partha

 

 

 

From: Chhatwal, Harprit S [mailto:hschhatwal@gmail.com]
Sent: Thursday, March 01, 2012 4:59 PM
To: Ravindran, Parthasarathi
Cc: Paul Kyzivat; Kevin P. Fleming; payload@ietf.org


Subject: Re: [payload] FW: I-D Action: = draft-muthu-payload-offer-answer-g723-g729-00.txt

 

On 1 = March 2012 06:13, Ravindran, Parthasarathi <pravindran@sonusnet.com> wrote:

I'm not very = clear on the bandwidth optimization based on asymmetric annexb parameter = negotiation. Could you please elaborate.

 

This is for a network where the bandwidth is = severely constrained in one direction, so the operator wishes to use = G.729B to minimise bandwidth usage in one direction, while not using = G.729B in the other direction where bandwidth is less constrained.

 

Regards.  Harprit.

 

Harprit S. Chhatwal

InnoMedia

 

On 1 March 2012 06:13, Ravindran, = Parthasarathi <pravindran@sonusnet.com> = wrote:

Hi Harpit,

Thanks for looking into the draft. I agree with you that asymmetric = annexb negotiation is not taken into the account in the draft currently. = In fact, I come across the scenario wherein annexb is not supported by = offerer ,mentioned in offer SDP as annexb=3Dno and answerer assumes about annexb support (no annexb parameter in = answer) in offerer side which leads to the call failure.

I'm not very clear on the bandwidth optimization based on asymmetric = annexb parameter negotiation. Could you please elaborate.

Thanks
Partha


>-----Original Message-----
>From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On
>Behalf Of Paul Kyzivat
>Sent: Wednesday, February 29, 2012 9:01 PM
>To: Chhatwal, Harprit S
>Cc: payload@ietf.org
>Subject: Re: [payload] FW: I-D Action: = draft-muthu-payload-offer-answer-
>g723-g729-00.txt
>
>On 2/29/12 9:34 AM, Chhatwal, Harprit S wrote:
>> On 28 February 2012 21:01, Kevin P. Fleming <kpfleming@digium.com
>> <mailto:kpfleming@digium.com>> wrote:
>>
>>
>>     That requirement is counter to what the draft = proposes. We can't
>>     have it both ways: either the G.729 'annexb' = format parameter is a
>>     negotiated parameter (in which case its usage is = symmetrical by
>>     definition) or it is a declarative parameter (in = which case the
>>     usage can be, but is not required to be, = asymmetrical).
>>
>>
>> Yes, I concur that the draft (as it currently stands) = cannot
>> accommodate an asymmetric use of G.729B.  However, if we = agree that
>> both scenarios are true, real-world scenarios that need = addressing, ie
>> (a) the negotiated case where the use of G.729B is symmetric = and (b)
>> the declarative case where the use of G.729B can be asymmetric = (and,
>> in my opinion, both are valid scenarios), then I would suggest = that we
>> need to come up with a way of handling both situations = (perhaps
>> through the use of an extra fmtp parameter indicating whether = the use
>> is declarative or negotiated - or any other suggestions the = group
>might have).
>>
>> If not, and we are only to allow the negotiated, symmetric use, = then
>> I'd appreciate any suggestions from the group for how my = organisation
>> might deal with the requirement of an asymmetric use of = G.729B
>mentioned below.
>
>There is one way that is available right now:
>
>Negotiate two separate one way m-lines.
>But this might be too weird for common use.
>
>       Thanks,
>       Paul
>
>> Regards.  Harprit.
>>
>> Harprit S. Chhatwal
>> InnoMedia
>>
>> On 28 February 2012 21:01, Kevin P. Fleming <kpfleming@digium.com
>> <mailto:kpfleming@digium.com>> wrote:
>>
>>     On 02/28/2012 02:58 PM, Chhatwal, Harprit S = wrote:
>>
>>         Speaking as a codec person :-), I = think the draft does address
>a
>>         real
>>         issue and is reasonably clear in = its content.  However, it
>does not
>>         appear to address (as far as I can = see), the case where an
>>         asymmetric
>>         use of G.729B is required. =  This is an actual issue as we are
>>         faced with
>>         a customer requirement where the = use of G.729B is required in
>one
>>         direction and not the other (for = bandwidth reasons).  Given
>the
>>         current
>>         specs do not appear to definitively = cover this case, it would
>be
>>         good to
>>         see if this can be addressed = through the proposed draft.
>>
>>
>>     That requirement is counter to what the draft = proposes. We can't
>>     have it both ways: either the G.729 'annexb' = format parameter is a
>>     negotiated parameter (in which case its usage is = symmetrical by
>>     definition) or it is a declarative parameter (in = which case the
>>     usage can be, but is not required to be, = asymmetrical).
>>
>>
>>         Regards.  Harprit.
>>
>>         Harprit S. Chhatwal
>>         InnoMedia
>>
>>         On 28 February 2012 19:10, Kevin P. = Fleming
>>         <kpfleming@digium.com <mailto:kpfleming@digium.com>
>>         <mailto:kpfleming@digium.com <mailto:kpfleming@digium.com>>>
>wrote:
>>
>>             On 02/28/2012 12:07 = PM, Paul Kyzivat wrote:
>>
>>                 = Clarification:
>>
>>                 In my = comments on the draft I was not questioning the
>>         assumption
>>                 of = that
>>                 draft = that a common value of this parameter is
>>         *negotiated* via O/A.
>>                 *If* = you accept that assumption then my comments
>>         hopefully make
>>                 = sense.
>>
>>                 But if = there is debate regarding whether the parameter
>is
>>                 = negotiated or
>>                 = declarative, then that needs to be settled first,
>before
>>         nailing
>>                 = down
>>                 = clarifications for how the negotiation happens.
>>
>>                 Not = being a codec person, I don't know what the common
>>         practice
>>                 is = here.
>>                 So I'm = going to let those that have the knowledge
>argue
>>         that.
>>
>>
>>             Correct on all = points; your comments make complete sense
>if
>>         'annexb'
>>             is intended to be a = negotiated parameter.
>>
>>             I'm not a codec = person (although I'd probably be willing
>to
>>         play one
>>             on TV is the need = arose <G>), but there are so many other
>>             codec/format = parameters that are declarative already that
>I
>>         don't
>>             see any need for this = one to have to be negotiated. The
>>         impact of
>>             using Annex B or not = is purely on one direction of the
>media
>>         stream,
>>             and it's not even = mandatory that the encoder use Annex B
>>         mode just
>>             because 'annexb=3Dyes'.= Granted, it's pretty unlikely that
>an
>>             implementation that = cannot accept incoming SID frames
>would
>>         also be
>>             able to generate = them, but I can think of completely
>reasonable
>>             situations for an = implementation that can generate them
>being
>>             willing to do so = while at the same time disallowing
>>         reception of them.
>>
>>
>>
>>                 = Thanks,
>>                 = Paul
>>
>>                 On = 2/28/12 12:34 PM, Chhatwal, Harprit S wrote:
>>
>>                   =   Kevin,
>>
>>                   =   First of all, from RFC3264, I agree with you that
>>         for things
>>                   =   like IP
>>                   =   addresses, ports, payload types, ptime, the SDP
>that one
>>                   =   party sends
>>                   =   indicates the address/port/PT/ptime that the
>sender
>>         would
>>                   =   like to
>>                   =   receive on. However, I don't believe this is
>generally
>>                   =   correct for all
>>                   =   parameters. For instance, for codecs (again from
>>         RFC3264),
>>                   =   the codec(s)
>>                   =   included in an SDP offer indicates the codec(s)
>the
>>         offerer
>>                   =   is willing
>>                   =   to send AND receive (if the directional attribute
>is
>>                   =   'sendrecv'). As an
>>                   =   example, if party A is the offerer and sends G.729
>&
>>         G.711
>>                   =   in its SDP
>>                   =   offer, it is saying that it is willing to use
>either
>>         codec.
>>                   =   If the
>>                   =   answerer replies with G.711, then it is only
>willing
>>         to use
>>                   =   G.711, and
>>                   =   then G.729 will not be used in either direction.
>>
>>                   =   Turning now to silence suppression, the situation
>>         does not
>>                   =   seem very
>>                   =   clear. This is what RFC3264 has to say about fmtp
>>         parameters
>>                   =   such as
>>                   =   'annexb' :
>>
>>                   =   The interpretation of fmtp parameters in an offer
>>         depends on the
>>
>>                   =   parameters. In many cases, those parameters
>describe
>>         specific
>>
>>                   =   configurations of the media format, and should
>>         therefore be
>>                   =   processed
>>
>>                   =   as the media format value itself would be. This
>>         means that
>>                   =   the same
>>
>>                   =   fmtp parameters with the same values MUST be
>present
>>         in the
>>                   =   answer if
>>
>>                   =   the media format they describe is present in the
>answer.
>>                   =   Other fmtp
>>
>>                   =   parameters are more like parameters, for which it
>is
>>         perfectly
>>
>>                   =   acceptable for each agent to use different values.
>>         In that
>>                   =   case, the
>>
>>                   =   answer MAY contain fmtp parameters, and those MAY
>>         have the same
>>
>>                   =   values as those in the offer, or they MAY be
>>         different. SDP
>>
>>                   =   extensions that define new parameters SHOULD
>specify
>>         the proper
>>
>>                   =   interpretation in offer/answer.
>>
>>                   =   To me, 'annexb' is more like a parameter in this
>>         sense and,
>>                   =   in this
>>                   =   case, everything is allowed - the answer may
>contain the
>>                   =   same fmtp or
>>                   =   different. RFC3264 doesn't appear to specify the
>>                   =   interpretation. The
>>                   =   problem is that I don't know of anywhere else
>where the
>>                   =   interpretation
>>                   =   is specified either. RFC4856 specifies the
>parameter
>>                   =   'annexb', but
>>                   =   doesn't say whether it can be used asymmetrically
>>         (or how).
>>                   =   The only
>>                   =   other guidance I can find on this is elsewhere in
>>         RFC3264:
>>
>>                   =   The list of media formats for each media stream
>>         conveys two
>>                   =   pieces of
>>
>>                   =   information, namely the set of formats (codecs and
>any
>>                   =   parameters
>>
>>                   =   associated with the codec, in the case of RTP)
>that the
>>                   =   offerer is
>>
>>                   =   capable of sending and/or receiving (depending on
>>         the direction
>>
>>                   =   attributes)...
>>
>>                   =   ...For a sendrecv stream, the offer SHOULD
>indicate
>>         those
>>
>>                   =   codecs that the offerer is willing to send and
>>         receive with.
>>
>>                   =   So, this appears to be lumping codec parameters
>with
>>         codecs
>>                   =   and so both
>>                   =   should behave in the same way. If we take this
>>                   =   interpretation, then
>>                   =   indicating 'annexb=3Dno' indicates that the sender
>of
>>         this SDP
>>                   =   is willing
>>                   =   to send and receive with silence suppression off.
>So,
>>                   =   according to
>>                   =   this, if the offerer sends 'annexb=3Dyes' in the
>offer
>>         and the
>>                   =   answerer
>>                   =   sends back 'annexb=3Dno', then there is a mismatch
>and the
>>                   =   offerer should
>>                   =   send a re-INVITE with 'annexb=3Dno' to resolve the
>>         conflict.
>>                   =   According to
>>                   =   this interpretation, we cannot have an asymmetric
>>         use of silence
>>                   =   suppression. However, from the discussion we're
>>         having, I
>>                   =   can see that
>>                   =   all of this is somewhat open to interpretation
>>         (since the
>>                   =   specs do not
>>                   =   seem to be clear) and I agree with the authors of
>>         this ID
>>                   =   that we need
>>                   =   some clarification as to how this issue should be
>>         dealt with
>>                   =   (and
>>                   =   whether asymmetric use of annexb should be allowed
>>         and, if
>>                   =   so, how).
>>
>>
>>                   =   Regards. Harprit.
>>
>>
>>                   =   Harprit S. Chhatwal
>>
>>                   =   InnoMedia
>>
>>
>>                   =   On 28 February 2012 16:54, Kevin P. Fleming
>>         <kpfleming@digium.com <mailto:kpfleming@digium.com>
>>         <mailto:kpfleming@digium.com <mailto:kpfleming@digium.com>>
>>         <mailto:kpfleming@digium.com <mailto:kpfleming@digium.com>
>>         <mailto:kpfleming@digium.com
>> <mailto:kpfleming@digium.com>>>__>
>>
>>                   =   wrote:
>>
>>                   =   On 02/27/2012 11:12 AM, Paul Kyzivat wrote:
>>
>>                   =   On 2/27/12 6:33 AM, Muthu Arul Mozhi Perumal
>>         (mperumal) wrote:
>>
>>                   =   We have submitted an I-D clarifying the
>offer/answer
>>                   =   considerations for
>>                   =   the Annex A flavor of G.723 and the Annex B
>flavors of
>>                   =   G.729, G.729D and
>>                   =   G.729E. This clarification is missing in RFC 4856,
>>         leading
>>                   =   to interop
>>                   =   issues, for e.g:
>>         http://sipforum.org/pipermail/______discussion/2008-
>January/______004026.html
>>         <http://sipforum.org/pipermail/____discussion/2008- >January/____004026.html>
>>         <http://sipforum.org/__pipermail/__discussion/2008- >__January/__004026.html
>>         <http://sipforum.org/pipermail/__discussion/2008-
= >January/__004026.html>>
>>         <http://sipforum.org/____pipermail/discussion/2008- >____January/004026.html
>>
>> <http://sipforum.org/__pipermail/discussion/2008-__Januar= y/004026.html
>> >
>>
>>         <http://sipforum.org/__pipermail/discussion/2008-
= >__January/004026.html
>>
>> <http://sipforum.org/pipermail/discussion/2008-January/00= 4026.html>>>
>>
>>                   =   We have a couple of open items in the I-D. We
>expect
>>         the WG
>>                   =   discussions
>>                   =   would guide us on how to go about them.
>>
>>                   =   Comments welcome.
>>
>>
>>                   =   I'm the source of the issues. :-)
>>
>>                   =   The fundamental point is that RFC4856 specifies a
>>         *default*
>>                   =   value of
>>         "yes" for annexa and annexb. This = means that if
>>                   =   annexa/annexb is not
>>                   =   specified in an answer, then it will default to
>yes,
>>         even if the
>>                   =   offer
>>                   =   contained "no".
>>
>>                   =   I see a few ways to fix this:
>>
>>                   =   1) revise the IANA registration for annexa and
>annexb to
>>                   =   remove the
>>                   =   default, at least when used with O/A. Instead
>>         specify the
>>                   =   defaulting
>>                   =   separately for offers and answers.
>>
>>                   =   2) REQUIRE that the answer contain "no" if the
>offer
>>                   =   contained "no".
>>
>>                   =   3) permit the answer to contain "yes" (explicitly
>or
>>         by default)
>>                   =   when the offer contained "no", and specify that
>this
>>         still means
>>                   =   that the annex is *not* to be used.
>>
>>                   =   4) forbid the answer from *explicitly* containing
>>         "yes" when the
>>                   =   offer contained "no", but allow the answer to
>>         *implicitly*
>>                   =   contain
>>         "yes" (via the default) and ignore = it/treat it as "no".
>>
>>                   =   None of these are ideal. (1) is problematic
>because
>>         this is
>>                   =   used in
>>                   =   non-O/A contexts, such as RSVP. (2) begs the
>>         question of what
>>                   =   should be
>>                   =   done if this is violated. (3) risks failing to
>>         recognize that
>>                   =   the two
>>                   =   sides disagree. (4) is pragmatic but seems to
>>         violate the
>>                   =   spirit of
>>                   =   defaults.
>>
>>                   =   I guess my preference is to make (2) normative for
>>         the answerer,
>>                   =   while
>>                   =   making (4) normative for the offerer, and put
>enough
>>         words
>>                   =   in so its
>>                   =   very clear what is being specified and why.
>>
>>
>>                   =   I must *really* be missing something here; why
>does
>>         the usage of
>>                   =   G.729 Annex B have to be symmetrical? Until I saw
>this
>>                   =   thread, it
>>                   =   was always my understanding that the 'annexb'
>format
>>                   =   parameter for
>>                   =   G.729 in SDP indicated the preference of the
>endpoint
>>                   =   sending that
>>                   =   parameter. Like nearly everything else in SDP, it
>>         indicates what
>>                   =   that endpoint is *prepared to accept*, and has
>>         nothing at
>>                   =   all to do
>>                   =   with what it will (or could) send.
>>
>>                   =   Unless that's a completely broken understanding,
>>         then these
>>         'interop' issues are really just = very poorly coded
>>                   =   implementations.
>>                   =   I would interpret the current RFC language as
>follows:
>>
>>                   =   1) If an offer/answer contains 'annexb=3Dno', the
>>         receiver of that
>>                   =   offer/answer MUST NOT send G.729 Annex B SID
>frames
>>         to the
>>                   =   offering/answering endpoint.
>>
>>                   =   2) If an offer/answer contains 'annexb=3Dyes', the
>>         receiver of
>>                   =   that
>>                   =   offer/answer SHOULD send G.729 Annex B SID frames
>to the
>>                   =   offering/answering endpoint.
>>
>>                   =   3) An answer's value for the 'annexb' parameter is
>>         completely
>>                   =   independent of the value (if any) present in the
>>         offer it is
>>                   =   answering.
>>
>>
>>                   =   Thanks,
>>                   =   Paul
>>
>>                   =   Muthu
>>
>>                   =   -----Original Message-----
>>                   =   From: i-d-announce-bounces@ietf.org
>>         <mailto:i-d-announce-bounces@ietf.org>
>>         <mailto:i-d-announce-bounces@__ietf.org
>>         <mailto:i-d-announce-bounces@ietf.org>>
>>         <mailto:i-d-announce-bounces@
>>         <mailto:i-d-announce-bounces@>____ietf.org <http://ietf.org>
>>         <mailto:i-d-announce-bounces@__ietf.org
>>         <mailto:i-d-announce-bounces@ietf.org>>>
>>                   =   [mailto:i-d-announce-bounces@
>>         <mailto:i-d-announce-bounces@>
>>         <mailto:i-d-announce-bounces@
>>         <mailto:i-d-announce-bounces@>>______ietf.org
><http://ietf.org>
>>         <http://ietf.org>
>>         <mailto:i-d-announce-bounces@
>>         <mailto:i-d-announce-bounces@>____ietf.org <http://ietf.org>
>>         <mailto:i-d-announce-bounces@__ietf.org
>>         <mailto:i-d-announce-bounces@ietf.org>>>] On = Behalf Of
>>         internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>
>>         <mailto:internet-drafts@ietf.__org
>>         <mailto:internet-drafts@ietf.org>>
>>         <mailto:internet-drafts@ietf.
>> <mailto:internet-drafts@ietf.>____org
>>
>>         <mailto:internet-drafts@ietf.__org
>>         <mailto:internet-drafts@ietf.org>>>
>>                   =   Sent: Friday, February 24, 2012 5:57 PM
>>                   =   To: i-d-announce@ietf.org
>>         <mailto:i-d-announce@ietf.org> <mailto:i-d-announce@ietf.org
>>         <mailto:i-d-announce@ietf.org>>
>>         <mailto:i-d-announce@ietf.org <mailto:i-d-announce@ietf.org>
>>         <mailto:i-d-announce@ietf.org <mailto:i-d-
>announce@ietf.org>>__>
>>                   =   Subject: I-D Action:
>>
>> draft-muthu-payload-offer-______answer-g723-g729-00.txt
>>
>>
>>
>>                   =   A New Internet-Draft is available from the on-line
>>                   =   Internet-Drafts
>>                   =   directories.
>>
>>                   =   Title : Offer/Answer Considerations for G.723
>Annex A
>>                   =   and G.729 Annex B
>>                   =   Author(s) : Muthu Arul Mozhi Perumal
>>                   =   Parthasarathi Ravindran
>>                   =   Filename :
>>
>> draft-muthu-payload-offer-______answer-g723-g729-00.txt
>>
>>                   =   Pages : 8
>>                   =   Date : 2012-02-24
>>
>>                   =   [RFC4856] describes the annexa parameter for G723
>>         and the annexb
>>                   =   parameter for G729, G729D and G729E. However, the
>>                   =   specification does
>>                   =   not describe the offerer and answerer behavior
>when the
>>                   =   value of the
>>                   =   annexa or annexb parameter does not match in the
>SDP
>>         offer and
>>                   =   answer. This document provides the offer/answer
>>                   =   considerations for
>>                   =   these parameters.
>>
>>
>>                   =   A URL for this Internet-Draft is:
>>         http://www.ietf.org/internet-______drafts/draft-muthu-payload-
>______offer-answer-g72
>>         <http://www.ietf.org/internet-____drafts/draft-muthu-payl= oad-
>____offer-answer-g72>
>>         <http://www.ietf.org/internet-____drafts/draft-muthu-payl= oad-
>____offer-answer-g72
>>
>> <http://www.ietf.org/internet-__drafts/draft-muthu-payloa= d-__offer-ans
>> wer-g72>>
>>
>>
>>         <http://www.ietf.org/internet-____drafts/draft-muthu-payl= oad-
>____offer-answer-g72
>>         <http://www.ietf.org/internet-__drafts/draft-muthu-payloa= d-
>__offer-answer-g72>
>>         <http://www.ietf.org/internet-__drafts/draft-muthu-payloa= d-
>__offer-answer-g72
>>
>> <http://www.ietf.org/internet-drafts/draft-muthu-payload-= offer-answer-
>> g72>>>
>>
>>                   =   3-g729-00.txt
>>
>>                   =   Internet-Drafts are also available by anonymous
>FTP at:
>>         ftp://ftp.ietf.org/internet-______drafts/
>>         <ftp://ftp.ietf.org/internet-____drafts/>
>>         <ftp://ftp.ietf.org/internet-____drafts/
>>         <ftp://ftp.ietf.org/internet-__drafts/>>
>>
>>         <ftp://ftp.ietf.org/internet-____drafts/
>>         <ftp://ftp.ietf.org/internet-__drafts/>
>>         <ftp://ftp.ietf.org/internet-__drafts/
>>         <ftp://ftp.ietf.org/internet-drafts/>>>
>>
>>                   =   This Internet-Draft can be retrieved at:
>>         ftp://ftp.ietf.org/internet-______drafts/draft-muthu-payload-
>______offer-answer-g723
>>         <ftp://ftp.ietf.org/internet-____drafts/draft-muthu-paylo= ad-
>____offer-answer-g723>
>>         <ftp://ftp.ietf.org/internet-____drafts/draft-muthu-paylo= ad-
>____offer-answer-g723
>>
>> <ftp://ftp.ietf.org/internet-__drafts/draft-muthu-payload= -__offer-answ
>> er-g723>>
>>
>>
>>         <ftp://ftp.ietf.org/internet-____drafts/draft-muthu-paylo= ad-
>____offer-answer-g723
>>         <ftp://ftp.ietf.org/internet-__drafts/draft-muthu-payload= -
>__offer-answer-g723>
>>         <ftp://ftp.ietf.org/internet-__drafts/draft-muthu-payload= -
>__offer-answer-g723
>>
>> <ftp://ftp.ietf.org/internet-drafts/draft-muthu-payload-o= ffer-answer-g
>> 723>>>
>>
>>                   =   -g729-00.txt
>>
>>
>> _____________________________________________________
>>
>>                   =   I-D-Announce mailing list
>>         I-D-Announce@ietf.org <mailto:I-D-Announce@ietf.org>
>>         <mailto:I-D-Announce@ietf.org <mailto:I-D-Announce@ietf.org>>
>>         <mailto:I-D-Announce@ietf.org <mailto:I-D-Announce@ietf.org>
>>         <mailto:I-D-Announce@ietf.org <mailto:I-D-
>Announce@ietf.org>>__>
>>         https://www.ietf.org/mailman/______listinfo/i-d-announce
>>         <https://www.ietf.org/mailman/____listinfo/i-d-announce>
>>         <https://www.ietf.org/mailman/____listinfo/i-d-announce
>>         <https://www.ietf.org/mailman/__listinfo/i-d-announce= >>
>>
>>         <https://www.ietf.org/mailman/____listinfo/i-d-announce
>>         <https://www.ietf.org/mailman/__listinfo/i-d-announce= >
>>         <https://www.ietf.org/mailman/__listinfo/i-d-announce=
>>         <https://www.ietf.org/mailman/listinfo/i-d-announce&g= t;>>
>>                   =   Internet-Draft directories:
>>         http://www.ietf.org/shadow.______html
>>         <http://www.ietf.org/shadow.____html>
>>         <http://www.ietf.org/shadow.____html
>>         <http://www.ietf.org/shadow.__html>>
>>         <http://www.ietf.org/shadow.____html
>>         <http://www.ietf.org/shadow.__html>
>>         <http://www.ietf.org/shadow.__html
>>         <http://www.ietf.org/shadow.html>>>
>>                   =   or ftp://ftp.ietf.org/ietf/______1shadow-sites.txt
>>         <ftp://ftp.ietf.org/ietf/____1shadow-sites.txt> >>         <ftp://ftp.ietf.org/ietf/____1shadow-sites.txt
>>         <ftp://ftp.ietf.org/ietf/__1shadow-sites.txt>><= br> >>         <ftp://ftp.ietf.org/ietf/____1shadow-sites.txt
>>         <ftp://ftp.ietf.org/ietf/__1shadow-sites.txt>
>>         <ftp://ftp.ietf.org/ietf/__1shadow-sites.txt
>>         <ftp://ftp.ietf.org/ietf/1shadow-sites.txt>>>= ;
>>
>>
>>
>> _____________________________________________________
>>
>>                   =   payload mailing list
>>         payload@ietf.org <mailto:payload@ietf.org>
>>         <mailto:payload@ietf.org = <mailto:payload@ietf.org>>
>>         <mailto:payload@ietf.org = <mailto:payload@ietf.org>
>>         <mailto:payload@ietf.org = <mailto:payload@ietf.org>>>
>>         https://www.ietf.org/mailman/______listinfo/payload
>>         <https://www.ietf.org/mailman/____listinfo/payload>= ;
>>         <https://www.ietf.org/mailman/____listinfo/payload >>         <https://www.ietf.org/mailman/__listinfo/payload>&= gt;
>>
>>         <https://www.ietf.org/mailman/____listinfo/payload >>         <https://www.ietf.org/mailman/__listinfo/payload><= br> >>         <https://www.ietf.org/mailman/__listinfo/payload
>>         <https://www.ietf.org/mailman/listinfo/payload>>= ;>
>>
>>
>>
>>                   =   --
>>                   =   Kevin P. Fleming
>>                   =   Digium, Inc. | Director of Software Technologies
>>                   =   Jabber: kfleming@digium.com
>>         <mailto:kfleming@digium.com> <mailto:kfleming@digium.com
>>         <mailto:kfleming@digium.com>>
>>         <mailto:kfleming@digium.com <mailto:kfleming@digium.com>
>>         <mailto:kfleming@digium.com <mailto:kfleming@digium.com>>> |
>SIP:
>>         kpfleming@digium.com <mailto:kpfleming@digium.com>
>>         <mailto:kpfleming@digium.com <mailto:kpfleming@digium.com>>
>>         <mailto:kpfleming@digium.com <mailto:kpfleming@digium.com>
>>         <mailto:kpfleming@digium.com <mailto:kpfleming@digium.com>>>
>>
>>                   =   | Skype: kpfleming
>>                   =   445 Jan Davis Drive NW - Huntsville, AL 35806 -
>USA
>>                   =   Check us out at www.digium.com
>>         <http://www.digium.com> <http://www.digium.com>
>>         <http://www.digium.com> &
>>         www.asterisk.org <http://www.asterisk.org>
><http://www.asterisk.org>
>>         <http://www.asterisk.org>
>>
>> _____________________________________________________
>>
>>                   =   payload mailing list
>>         payload@ietf.org <mailto:payload@ietf.org>
>>         <mailto:payload@ietf.org = <mailto:payload@ietf.org>>
>>         <mailto:payload@ietf.org = <mailto:payload@ietf.org>
>>         <mailto:payload@ietf.org = <mailto:payload@ietf.org>>>
>>         https://www.ietf.org/mailman/______listinfo/payload
>>         <https://www.ietf.org/mailman/____listinfo/payload>= ;
>>         <https://www.ietf.org/mailman/____listinfo/payload >>         <https://www.ietf.org/mailman/__listinfo/payload>&= gt;
>>
>>         <https://www.ietf.org/mailman/____listinfo/payload >>         <https://www.ietf.org/mailman/__listinfo/payload><= br> >>         <https://www.ietf.org/mailman/__listinfo/payload
>>         <https://www.ietf.org/mailman/listinfo/payload>>= ;>
>>
>>
>>
>>
>>
>>             --
>>             Kevin P. Fleming
>>             Digium, Inc. | = Director of Software Technologies
>>             Jabber: kfleming@digium.com <mailto:kfleming@digium.com>
>>         <mailto:kfleming@digium.com <mailto:kfleming@digium.com>> |
>SIP:
>>         kpfleming@digium.com <mailto:kpfleming@digium.com>
>>         <mailto:kpfleming@digium.com <mailto:kpfleming@digium.com>> |
>>         Skype: kpfleming
>>
>>             445 Jan Davis Drive = NW - Huntsville, AL 35806 - USA
>>             Check us out at www.digium.com = <http://www.digium.com>
>>         <http://www.digium.com> &
>>         www.asterisk.org <http://www.asterisk.org>
>> <http://www.asterisk.org>
>>
>>
>>
>>
>>     --
>>     Kevin P. Fleming
>>     Digium, Inc. | Director of Software = Technologies
>>     Jabber: kfleming@digium.com <mailto:kfleming@digium.com> | SIP:
>>     kpfleming@digium.com <mailto:kpfleming@digium.com> | Skype:
>kpfleming
>>     445 Jan Davis Drive NW - Huntsville, AL 35806 - = USA
>>     Check us out at www.digium.com <http://www.digium.com> &
>>     www.asterisk.org <http://www.asterisk.org>
>>
>>
>

>_______________________________________________ >payload mailing list
>payload@ietf.org
>https://www.ietf.org/mailman/listinfo/payload=

 


_______________________________________________
payload mailing = list
payload@ietf.org
https://www.ietf.= org/mailman/listinfo/payload

= --Apple-Mail=_A827B55D-AE14-433B-94D9-51E5E0FC33CC-- From harald@alvestrand.no Thu Mar 8 08:07:33 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E38821F8724 for ; Thu, 8 Mar 2012 08:07:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.513 X-Spam-Level: X-Spam-Status: No, score=-110.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rwGfhV6SPIG7 for ; Thu, 8 Mar 2012 08:07:32 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 3C55621F870A for ; Thu, 8 Mar 2012 08:07:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7F95B39E27B; Thu, 8 Mar 2012 17:07:31 +0100 (CET) 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 QE0WJm80y534; Thu, 8 Mar 2012 17:07:31 +0100 (CET) Received: from hta-dell.lul.corp.google.com (unknown [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 09FDD39E149; Thu, 8 Mar 2012 17:07:31 +0100 (CET) Message-ID: <4F58D942.3060603@alvestrand.no> Date: Thu, 08 Mar 2012 17:07:30 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: "Kevin P. Fleming" References: <4F4F59B7.907@alvestrand.no> <4F4FA94D.4090508@digium.com> In-Reply-To: <4F4FA94D.4090508@digium.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: payload@ietf.org Subject: Re: [payload] Interest in raft-ietf-avt-rtp-isac X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 16:07:33 -0000 I've queried within Google, and we're going to resurrect the draft. It'll be a while still until we manage to get the information about 32 kHz sample rate added, sorry. Harald On 03/01/2012 05:52 PM, Kevin P. Fleming wrote: > On 03/01/2012 05:12 AM, Harald Alvestrand wrote: >> On 02/27/2012 09:09 PM, Ali C. Begen (abegen) wrote: >>> WG, >>> >>> We have a milestone for this draft and we passed the target date some >>> time ago. AFAICT, the current draft has expired and there was no >>> continued work on this draft. I wonder whether the WG still has >>> interest in finishing this work. Please reply to this email (cc'ing >>> the payload list) if you have an interest/desire in seeing this >>> document finished. >>> >>> https://datatracker.ietf.org/doc/draft-ietf-avt-rtp-isac/ >> I have checked with the relevant ex-Gips team (now Google), and it seems >> that we don't have any particular reason to make this a high priority at >> the moment. It's stable code. >> >> Do other participants see a benefit in having this spec published as an >> RFC? > > At the request of a community member, I've just started working on > adding support for iSAC passthrough in Asterisk, and while > investigating it I learned that Chrome can currently generate/accept > offers with iSAC at 32kHz sample rate, which is not included in this > draft. > > If Google is going to continue to distribute iSAC support in products > (and others are as well), I'd be happy to see this draft updated to > match the current state of deployments and get pushed towards > publication. > From kpfleming@digium.com Thu Mar 8 08:10:49 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4A6321F851C for ; Thu, 8 Mar 2012 08:10:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.549 X-Spam-Level: X-Spam-Status: No, score=-106.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DztIAEew3Npc for ; Thu, 8 Mar 2012 08:10:49 -0800 (PST) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id 841A521F8505 for ; Thu, 8 Mar 2012 08:10:45 -0800 (PST) Received: from [10.24.55.203] (helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1S5fvQ-0002R9-5V; Thu, 08 Mar 2012 10:10:44 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id 2B2C6D8006; Thu, 8 Mar 2012 10:10:44 -0600 (CST) 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 9HJGN03LRwof; Thu, 8 Mar 2012 10:10:43 -0600 (CST) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 93A85D8004; Thu, 8 Mar 2012 10:10:43 -0600 (CST) Message-ID: <4F58DA03.2010503@digium.com> Date: Thu, 08 Mar 2012 10:10:43 -0600 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Harald Alvestrand References: <4F4F59B7.907@alvestrand.no> <4F4FA94D.4090508@digium.com> <4F58D942.3060603@alvestrand.no> In-Reply-To: <4F58D942.3060603@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: payload@ietf.org Subject: Re: [payload] Interest in raft-ietf-avt-rtp-isac X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 16:10:49 -0000 On 03/08/2012 10:07 AM, Harald Alvestrand wrote: > I've queried within Google, and we're going to resurrect the draft. > It'll be a while still until we manage to get the information about 32 > kHz sample rate added, sorry. No problem. Based on experiments it looks pretty easy to support 32kHz mode anyway. > > Harald > > On 03/01/2012 05:52 PM, Kevin P. Fleming wrote: >> On 03/01/2012 05:12 AM, Harald Alvestrand wrote: >>> On 02/27/2012 09:09 PM, Ali C. Begen (abegen) wrote: >>>> WG, >>>> >>>> We have a milestone for this draft and we passed the target date some >>>> time ago. AFAICT, the current draft has expired and there was no >>>> continued work on this draft. I wonder whether the WG still has >>>> interest in finishing this work. Please reply to this email (cc'ing >>>> the payload list) if you have an interest/desire in seeing this >>>> document finished. >>>> >>>> https://datatracker.ietf.org/doc/draft-ietf-avt-rtp-isac/ >>> I have checked with the relevant ex-Gips team (now Google), and it seems >>> that we don't have any particular reason to make this a high priority at >>> the moment. It's stable code. >>> >>> Do other participants see a benefit in having this spec published as an >>> RFC? >> >> At the request of a community member, I've just started working on >> adding support for iSAC passthrough in Asterisk, and while >> investigating it I learned that Chrome can currently generate/accept >> offers with iSAC at 32kHz sample rate, which is not included in this >> draft. >> >> If Google is going to continue to distribute iSAC support in products >> (and others are as well), I'd be happy to see this draft updated to >> match the current state of deployments and get pushed towards >> publication. >> > -- 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 Even.roni@huawei.com Mon Mar 12 23:52:18 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB5C21F88BF for ; Mon, 12 Mar 2012 23:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.529 X-Spam-Level: X-Spam-Status: No, score=-106.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VzBo9QZJ1Syk for ; Mon, 12 Mar 2012 23:52:17 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id A567221F88BB for ; Mon, 12 Mar 2012 23:52:17 -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 <0M0T002JB9OM4C@szxga05-in.huawei.com> for payload@ietf.org; Tue, 13 Mar 2012 14:50:46 +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 <0M0T005L59OM1Z@szxga05-in.huawei.com> for payload@ietf.org; Tue, 13 Mar 2012 14:50:46 +0800 (CST) Received: from szxeml211-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHU40536; Tue, 13 Mar 2012 14:50:46 +0800 Received: from SZXEML423-HUB.china.huawei.com (10.82.67.162) by szxeml211-edg.china.huawei.com (172.24.2.182) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 13 Mar 2012 14:49:55 +0800 Received: from SZXEML536-MBX.china.huawei.com ([169.254.4.13]) by szxeml423-hub.china.huawei.com ([10.82.67.162]) with mapi id 14.01.0323.003; Tue, 13 Mar 2012 14:50:43 +0800 Date: Tue, 13 Mar 2012 06:50:45 +0000 From: Roni even In-reply-to: X-Originating-IP: [172.24.1.45] To: "payload@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: Agenda for AVTEXT in Paris Thread-index: Ac0AqZuiyvvVGVIxTpCh6fNEZaS12wAO9o+a X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: Subject: [payload] FW: Agenda for AVTEXT in Paris X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 06:52:18 -0000 Hi, Note that the payload WG will have two presentations during this time slots Roni Even ________________________________________ From: avtext-bounces@ietf.org [avtext-bounces@ietf.org] on behalf of DRAGE, Keith (Keith) [keith.drage@alcatel-lucent.com] Sent: Tuesday, March 13, 2012 1:41 To: avtext@ietf.org Subject: [avtext] Agenda for AVTEXT in Paris (As WG cochair) I've uploaded an initial agenda for the Paris meeting of AVTEXT and I also include it below. Note we are hosting a short session of PAYLOAD within our time. Feel free to bash it now rather than waiting for the start of the meeting in Paris. Draft Agenda for AVTEXT Tuesday 27th March 2012 15:20 - 17:00 Chairs: Keith Drage Magnus Westerlund (Note we will invite the PAYLOAD chairs to join us at the front when we get to the PAYLOAD drafts) 15 (15:20 - 15:35) Agenda bash; working group draft status; future work Chairs 5 (15:35 - 15:40) IEEE 1588/802.1AS Synchronisation for RTP Streams Aidan Williams draft-williams-avtext-absync-02 30 (15:40 - 16:10) Codec Operation Point RTCP Extension Bo Burman draft-westerlund-avtext-codec-operation-point-00 [As PAYLOAD working group] 10 (16:10 - 16:20) RTP Payload Format for High Efficiency Video Coding Thomas Schierl draft-schierl-payload-rtp-h265-00 10 (16:20 - 16:30) Offer/Answer Considerations for G.723 Annex A and G.729 Annex B Muthu A M. Perumal draft-muthu-payload-offer-answer-g723-g729-00 (16:30 - 17:00 Unallocated) _______________________________________________ avtext mailing list avtext@ietf.org https://www.ietf.org/mailman/listinfo/avtext From ron.even.tlv@gmail.com Tue Mar 13 00:23:33 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C38C911E8085; Tue, 13 Mar 2012 00:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.429 X-Spam-Level: X-Spam-Status: No, score=-2.429 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.263, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5M+qXkCSF-xG; Tue, 13 Mar 2012 00:23:33 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4E67D11E8079; Tue, 13 Mar 2012 00:23:32 -0700 (PDT) Received: by werb10 with SMTP id b10so236632wer.31 for ; Tue, 13 Mar 2012 00:23:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:mime-version:content-type :x-mailer:thread-index:content-language; bh=uRXPr//wTuNVLFj7tQK9hUb7ZtCFQleFCb2Kxgcup7M=; b=HZtP97mB26FzpWTXzq/Rtri8Z3pQpiFTEYll27+ZTjPQ/wWzuOxmJw4yV2ufwC482m 0wLRumWGLOEBJ/eeDb1oVlDtWh+S59gP/oAstoOE8F6VsZq6jtFkAlq/7W+UvfxeaTQ8 RTxKqRR9sWdWdTGQSbk2AmWddhPQzL4csj6QZWP1idppsr1FmG/o1X6Gu4exflGKgZjD QdB0EBbZmpdnBSvcWtRnXDd93rq/EL4iMlulzJ7igKKRMcLMkwsXEY9bs6xA51apAIZm VAdOZqKPdOjiJjdw5ANazOMBHBEpWsK7J0eFSXcXY62YhaB07GPX7gSOyUlm9moTZ5Un +ayA== Received: by 10.180.100.228 with SMTP id fb4mr4772676wib.1.1331623410984; Tue, 13 Mar 2012 00:23:30 -0700 (PDT) Received: from windows8d787f9 (bzq-79-179-219-130.red.bezeqint.net. [79.179.219.130]) by mx.google.com with ESMTPS id n8sm69536435wix.10.2012.03.13.00.23.28 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 13 Mar 2012 00:23:29 -0700 (PDT) From: "Roni Even" To: "'IETF AVTCore WG'" Date: Tue, 13 Mar 2012 09:22:38 +0200 Message-ID: <4f5ef5f1.0850b40a.2c3f.ffffe33c@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00E3_01CD00FA.D6BA25C0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0A6hGBVnmRA0ADQR6uMnLdAUm2Og== Content-Language: en-us Cc: payload@ietf.org Subject: [payload] Agenda for AVTcore IETF83 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 07:23:33 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00E3_01CD00FA.D6BA25C0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00E4_01CD00FA.D6BA25C0" ------=_NextPart_001_00E4_01CD00FA.D6BA25C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, This is the preliminary agenda for the AVTcore session in Paris. Please review and comment. We have two adjacent time slots and we will have a 10 minutes break in the middle. We had requests to present some payload WG drafts, they will be presented during AVText time slot on Tuesday 15:20-17:00. Attached is the html version Thanks Roni Even AVTcore co-chair Audio/Video Transport Core Maintenance (AVTCore) Working Group =============================================================== CHAIRS: Magnus Westerlund Roni Even AGENDA Monday, 26 March 2012 at 13:00-16:10 (252B) ------------------------------------------- 13:00 AVTCore Status Update (Chairs, 15) 13:15 Why RTP Sessions Should Be Content Neutral(Harald Alvestrand , 15) draft-alvestrand-rtp-sess-neutral-00 13:30 RTP Multiplexing Architecture (Magnus Westerlund , 20) draft-westerlund-avtcore-multiplex-architecture-01 13:50 Multiple RTP Session on a Single Lower-Layer Transport(Magnus Westerlund , 35) draft-westerlund-avtcore-transport-multiplexing-02 14:25 RTP Congestion Control: Circuit Breakers for Unicast Sessions(Colin Perkins , 15) draft-perkins-avtcore-rtp-circuit-breakers-00 14:40 RTP Topology Considerations for Offer/Answer-Initiated Sessions(Jonathan Lennox, 20) draft-lennox-avtcore-rtp-topo-offer-answer-00 15:00 Break (if needed) (, 10) 15:10 RTCP for inter-destination media synchronization(Ray van Brandenburg, 10) draft-ietf-avtcore-idms-03 15:20 RTP Clock Source Signalling (Ray van Brandenburg, 10) draft-williams-avtcore-clksrc-00 15:30 Duplicating RTP Streams (Begen, 10) draft-begen-avtcore-rtp-duplication-01 15:40 Multipath RTP (Varun Singh, 10) draft-singh-avt-mprtp-04 15:50 End ------=_NextPart_001_00E4_01CD00FA.D6BA25C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

This is the = preliminary agenda for the AVTcore session in Paris. Please review and = comment.

 

We have two adjacent time slots and we will have a 10 = minutes break in the middle.

 

We had = requests to present some payload WG drafts, they will be presented = during AVText time slot on Tuesday 15:20-17:00.

 

Attached is = the html version

 

Thanks

Roni = Even

AVTcore = co-chair

 

 

 

 

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

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

<= p class=3DMsoNormal> 

CHAIRS:  Magnus = Westerlund       = <magnus.westerlund@ericsson.com>

         Roni = Even         = <even.roni@huawei.com>

 

AGENDA

 

Monday, 26 = March 2012 at 13:00-16:10 (252B)

-------------------------------------------<= /p>

13:00   AVTCore Status = Update           &= nbsp;           &n= bsp;       (Chairs, 15)

 

13:15   Why RTP Sessions Should Be Content = Neutral(Harald Alvestrand , 15)

        = draft-alvestrand-rtp-sess-neutral-00

 

13:30   RTP Multiplexing = Architecture           = (Magnus Westerlund , 20)

        = draft-westerlund-avtcore-multiplex-architecture-01

 

13:50   Multiple RTP Session on a Single = Lower-Layer Transport(Magnus Westerlund , 35)

        = draft-westerlund-avtcore-transport-multiplexing-02

 

14:25   RTP Congestion Control: Circuit = Breakers for Unicast Sessions(Colin Perkins , 15)

        = draft-perkins-avtcore-rtp-circuit-breakers-00

 

14:40   RTP Topology Considerations for = Offer/Answer-Initiated Sessions(Jonathan Lennox, 20)

        = draft-lennox-avtcore-rtp-topo-offer-answer-00

 

15:00   Break (if = needed)           =             &= nbsp;           &n= bsp;     (, 10)

 

15:10   RTCP for inter-destination media = synchronization(Ray van Brandenburg, 10)

        = draft-ietf-avtcore-idms-03

 

15:20   RTP Clock Source = Signalling          &nb= sp; (Ray van Brandenburg, 10)

        = draft-williams-avtcore-clksrc-00

 

15:30   Duplicating RTP = Streams           =             &= nbsp;      (Begen, 10)

        = draft-begen-avtcore-rtp-duplication-01

 

15:40   Multipath = RTP           &nbs= p;            = ;          (Varun Singh, = 10)

        = draft-singh-avt-mprtp-04

 

15:50   = End

------=_NextPart_001_00E4_01CD00FA.D6BA25C0-- ------=_NextPart_000_00E3_01CD00FA.D6BA25C0 Content-Type: text/html; name="agenda.html" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="agenda.html" Audio/Video Transport Core Maintenance (AVTCore) Working Group = Agenda

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

Chairs: Magnus Westerlund , Roni = Even

Monday, 26 March 2012 at 13:00-16:10 (252B)

13:00 AVTCore Status UpdateChairs
13:15 Why RTP Sessions Should Be Content NeutralHarald Alvestrand=20
dr= aft-alvestrand-rtp-sess-neutral-00
13:30 RTP Multiplexing ArchitectureMagnus Westerlund=20
draft-westerlund-avtcore-multiplex-architecture-01
13:50 Multiple RTP Session on a Single Lower-Layer = TransportMagnus Westerlund=20
draft-westerlund-avtcore-transport-multiplexing-02
14:25 RTP Congestion Control: Circuit Breakers for Unicast = SessionsColin Perkins=20
draft-perkins-avtcore-rtp-circuit-breakers-00
14:40 RTP Topology Considerations for = Offer/Answer-Initiated SessionsJonathan Lennox
draft-lennox-avtcore-rtp-topo-offer-answer-00
15:00 Break (if needed)
15:10 RTCP for inter-destination media synchronizationRay van Brandenburg
draft-ietf-a= vtcore-idms-03
15:20 RTP Clock Source SignallingRay van = Brandenburg
draft-= williams-avtcore-clksrc-00
15:30 Duplicating RTP StreamsBegen
= draft-begen-avtcore-rtp-duplication-01
15:40 Multipath RTP Varun Singh
draft-singh-av= t-mprtp-04
15:50 End
------=_NextPart_000_00E3_01CD00FA.D6BA25C0-- From keith.drage@alcatel-lucent.com Tue Mar 13 04:26:13 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8962921F87AD for ; Tue, 13 Mar 2012 04:26:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.493 X-Spam-Level: X-Spam-Status: No, score=-110.493 tagged_above=-999 required=5 tests=[AWL=1.756, BAYES_00=-2.599, GB_I_INVITATION=-2, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WpnzpXJCHXVI for ; Tue, 13 Mar 2012 04:26:13 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id B717F21F87EA for ; Tue, 13 Mar 2012 04:26:12 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q2DBPc0K027785 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 13 Mar 2012 12:26:08 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Tue, 13 Mar 2012 12:26:07 +0100 From: "DRAGE, Keith (Keith)" To: Roni even , "payload@ietf.org" Date: Tue, 13 Mar 2012 12:26:05 +0100 Thread-Topic: Agenda for AVTEXT in Paris Thread-Index: Ac0AqZuiyvvVGVIxTpCh6fNEZaS12wAO9o+aAAmheUA= Message-ID: References: In-Reply-To: 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 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Subject: Re: [payload] Agenda for AVTEXT in Paris X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 11:26:13 -0000 And the invitation to bash the agenda does extend to the payload members as= well. Keith > -----Original Message----- > From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behal= f > Of Roni even > Sent: 13 March 2012 06:51 > To: payload@ietf.org > Subject: [payload] FW: Agenda for AVTEXT in Paris >=20 > Hi, > Note that the payload WG will have two presentations during this time > slots > Roni Even >=20 > ________________________________________ > From: avtext-bounces@ietf.org [avtext-bounces@ietf.org] on behalf of > DRAGE, Keith (Keith) [keith.drage@alcatel-lucent.com] > Sent: Tuesday, March 13, 2012 1:41 > To: avtext@ietf.org > Subject: [avtext] Agenda for AVTEXT in Paris >=20 > (As WG cochair) >=20 > I've uploaded an initial agenda for the Paris meeting of AVTEXT and I als= o > include it below. Note we are hosting a short session of PAYLOAD within > our time. >=20 > Feel free to bash it now rather than waiting for the start of the meeting > in Paris. >=20 > Draft Agenda for AVTEXT > Tuesday 27th March 2012 > 15:20 - 17:00 >=20 > Chairs: > Keith Drage > Magnus Westerlund > (Note we will invite the PAYLOAD chairs to join us at the front when we > get to the PAYLOAD drafts) >=20 > 15 (15:20 - 15:35) > Agenda bash; working group draft status; future work > Chairs >=20 > 5 (15:35 - 15:40) > IEEE 1588/802.1AS Synchronisation for RTP Streams > Aidan Williams > draft-williams-avtext-absync-02 >=20 > 30 (15:40 - 16:10) > Codec Operation Point RTCP Extension > Bo Burman > draft-westerlund-avtext-codec-operation-point-00 >=20 > [As PAYLOAD working group] >=20 > 10 (16:10 - 16:20) > RTP Payload Format for High Efficiency Video Coding > Thomas Schierl > draft-schierl-payload-rtp-h265-00 >=20 > 10 (16:20 - 16:30) > Offer/Answer Considerations for G.723 Annex A and G.729 Annex B > Muthu A M. Perumal > draft-muthu-payload-offer-answer-g723-g729-00 >=20 > (16:30 - 17:00 Unallocated) > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload From weix@avaya.com Wed Mar 14 20:38:18 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DC1511E8074 for ; Wed, 14 Mar 2012 20:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3YZipO0Q8lh2 for ; Wed, 14 Mar 2012 20:38:16 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 6A12721F8725 for ; Wed, 14 Mar 2012 20:38:16 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAKNjYU+HCzI1/2dsb2JhbABDgkWzc4EHghASG14BFWsmAQQbGodomgaEG5w7kBxjBJtnihuDAg X-IronPort-AV: E=Sophos;i="4.73,588,1325480400"; d="scan'208,217";a="337031073" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 14 Mar 2012 23:38:06 -0400 Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 14 Mar 2012 23:22:44 -0400 Received: from DC-US1MBEX1.global.avaya.com ([169.254.1.94]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Wed, 14 Mar 2012 23:38:05 -0400 From: "Wei, Xiaohui (Joanne)" To: "payload@ietf.org" Date: Wed, 14 Mar 2012 23:38:04 -0400 Thread-Topic: Incorrect equation in max-dpb definition in RFC6184 Thread-Index: Ac0CXQdnhrIvrX9DSriC8IfCNcQxRg== Message-ID: <165016AFA648BC4CB0242BC2D39EC2C2F26E752804@DC-US1MBEX1.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_165016AFA648BC4CB0242BC2D39EC2C2F26E752804DCUS1MBEX1glo_" MIME-Version: 1.0 Subject: [payload] Incorrect equation in max-dpb definition in RFC6184 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 03:39:39 -0000 --_000_165016AFA648BC4CB0242BC2D39EC2C2F26E752804DCUS1MBEX1glo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear All, I just found the equation in max-dpb definition in RFC6184 is incorrect: On page 46 in RFC6184: max-dpb: The value of max-dpb is an integer indicating the maximum decoded picture buffer size in units of 8/3 macroblocks. The max-dpb parameter signals that the receiver has more memory than the minimum amount of decoded picture buffer memory required by the signaled highest level conveyed in the value of the profile-level-id parameter or the max-recv-level parameter. When max-dpb is signaled, the receiver MUST be able to decode NAL unit streams that conform to the signaled highest level, with the exception that the MaxDpbMbs value in Table A-1 of [1] for the signaled highest level is replaced with the value of max-dpb * 3 / 8. Consequently, a receiver that signals max-dpb MUST be capable of storing the following number of decoded frames, complementary field pairs, and non-paired fields in its decoded picture buffer: Min(max-dpb * 3 / 8 / ( PicWidthInMbs * FrameHeightInMbs), 16) I understand this definition needs to be backwards compatible to RFC 3984. = I think to be backwards compatible to RFC 3984, the decoded picture buffer should be Min(max-dpb * 8 / 3 /( PicWidthInMbs * FrameHeightInMbs), 16) instead of Min(max-dpb * 3 / 8 /( PicWidthInMbs * FrameHeightInMbs), 16) in= RFC6184. And "When max-dpb is signaled, the receiver MUST be able to decode NAL unit streams that conform to the signaled highest level, with the exception that the MaxDpbMbs value in Table A-1 of [1] for the signaled highest level is replaced with the value of max-dpb * 3 / 8." Should be changed to "...the MaxDpbMbs value in Table A-1 of [1] for the signaled highest level is replaced with the value of max-dpb * 8 / 3." Thanks! Best regards, Xiaohui Wei (Joanne) --_000_165016AFA648BC4CB0242BC2D39EC2C2F26E752804DCUS1MBEX1glo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear All,

 

I ju= st found the equation in max-dpb definition in RFC6184 is incorrect:

 

On p= age 46 in RFC6184:

max-dpb: The value of ma= x-dpb is an integer indicating the maximum

         decoded picture buff= er size in units of 8/3 macroblocks.

=          The max-dpb parameter sign= als that the receiver has more memory

         than the minimum amount o= f decoded picture buffer memory

 = ;        required by the signaled highes= t level conveyed in the value of

&nbs= p;        the profile-level-id parameter= or the max-recv-level parameter.

&nb= sp;        When max-dpb is signaled, the= receiver MUST be able to decode

&nbs= p;        NAL unit streams that conform = to the signaled highest level,

 =         with the exception that the MaxD= pbMbs value in Table A-1 of [1]

 = ;        for the signaled highest level = is replaced with the value of

=  &= nbsp;       max-dpb * 3 / 8. Consequently, a = receiver that signals max-dpb

=  &= nbsp;       MUST be capable of storing the fo= llowing number of decoded

  = ;       frames, complementary field pairs, an= d non-paired fields in its

 &nbs= p;       decoded picture buffer:

         = Min(max-dpb * 3 / 8 / ( PicWidthInMbs * FrameHeightInMbs), 16)

 

 

I understand this definition needs= to be backwards compatible to RFC 3984. I think to

<= p class=3DMsoPlainText>be backwards compatible to RFC 3984, the decoded picture bu= ffer should be

 

Min(max-dpb * 8 / 3 /( PicWidthInMbs * Frame= HeightInMbs), 16)

 <= /span>

instead of Min(max-dpb * 3 / 8 /( PicWidt= hInMbs * FrameHeightInMbs), 16) in RFC6184.

 

And “When max-d= pb is signaled, the receiver MUST be able to decode

     NAL unit streams that conform to th= e signaled highest level,

  = ;   with the exception that the MaxDpbMbs value in Table A-1 of [= 1]

     for the s= ignaled highest level is replaced with the value of

     max-dpb * 3 / 8.” Shou= ld be changed to “…the MaxDpbMbs value in

     Table A-1 of [1]  for = the signaled highest level is replaced with

     the value of max-dpb * 8 / 3.= ”

 

<= p class=3DMsoPlainText>Thanks!

 

Best regards,

Xiaohui Wei (Joanne)

=  

 

= --_000_165016AFA648BC4CB0242BC2D39EC2C2F26E752804DCUS1MBEX1glo_-- From yekuiw@qualcomm.com Wed Mar 14 22:05:23 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9405A21F8753 for ; Wed, 14 Mar 2012 22:05:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S8L2ddElG-RB for ; Wed, 14 Mar 2012 22:05:20 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 71B8A21F874F for ; Wed, 14 Mar 2012 22:05:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=yekuiw@qualcomm.com; q=dns/txt; s=qcdkim; t=1331787920; x=1363323920; h=from:to:subject:thread-topic:thread-index:date: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: x-originating-ip:content-type:mime-version; z=From:=20"Wang,=20Ye-Kui"=20|To:=20" Wei,=20Xiaohui=20(Joanne)"=20,=20"payload @ietf.org"=0D=0A=09|Subject:=20RE:=20In correct=20equation=20in=20max-dpb=20definition=20in=20RFC 6184|Thread-Topic:=20Incorrect=20equation=20in=20max-dpb =20definition=20in=20RFC6184|Thread-Index:=20Ac0CXQdnhrIv rX9DSriC8IfCNcQxRgADAGnQ|Date:=20Thu,=2015=20Mar=202012 =2005:05:17=20+0000|Message-ID:=20<8BA7D4CEACFFE04BA2D902 BF11719A831EBB8222@nasanexd02c.na.qualcomm.com> |References:=20<165016AFA648BC4CB0242BC2D39EC2C2F26E75280 4@DC-US1MBEX1.global.avaya.com>|In-Reply-To:=20<165016AFA 648BC4CB0242BC2D39EC2C2F26E752804@DC-US1MBEX1.global.avay a.com>|Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|x-originating-ip: =20[199.106.114.10]|Content-Type:=20multipart/alternative =3B=0D=0A=09boundary=3D"_000_8BA7D4CEACFFE04BA2D902BF1171 9A831EBB8222nasanexd02cnaqu_"|MIME-Version:=201.0; bh=qxG9XgKgB79yRkjQQ+Pel4Xt0/cjYHfqaVrrwSosLUk=; b=O0Pitjb8wt11VRW8W/w3k8oS71uRhcY5ZZ4rKIyDMKW1g9Puh6aZe8EI ujW3IZi1KDMVwGHthgqKd3ru8rBnjFUsuwWgxqLNTJKeQzctu84swplL+ /PKw42R4P39bZs8Dnmk6Fppeey5LARnjDM4l55OmHWTaVnEFb7tswktD3 w=; X-IronPort-AV: E=McAfee;i="5400,1158,6649"; a="172616419" Received: from ironmsg02-l.qualcomm.com ([172.30.48.16]) by wolverine01.qualcomm.com with ESMTP; 14 Mar 2012 22:05:19 -0700 X-IronPort-AV: E=Sophos;i="4.73,587,1325491200"; d="scan'208,217";a="119720014" Received: from nasanexhc06.na.qualcomm.com ([172.30.48.21]) by ironmsg02-L.qualcomm.com with ESMTP/TLS/AES128-SHA; 14 Mar 2012 22:05:19 -0700 Received: from NASANEXD02C.na.qualcomm.com ([169.254.4.194]) by nasanexhc06.na.qualcomm.com ([172.30.48.21]) with mapi id 14.01.0339.001; Wed, 14 Mar 2012 22:05:19 -0700 From: "Wang, Ye-Kui" To: "Wei, Xiaohui (Joanne)" , "payload@ietf.org" Thread-Topic: Incorrect equation in max-dpb definition in RFC6184 Thread-Index: Ac0CXQdnhrIvrX9DSriC8IfCNcQxRgADAGnQ Date: Thu, 15 Mar 2012 05:05:17 +0000 Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A831EBB8222@nasanexd02c.na.qualcomm.com> References: <165016AFA648BC4CB0242BC2D39EC2C2F26E752804@DC-US1MBEX1.global.avaya.com> In-Reply-To: <165016AFA648BC4CB0242BC2D39EC2C2F26E752804@DC-US1MBEX1.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [199.106.114.10] Content-Type: multipart/alternative; boundary="_000_8BA7D4CEACFFE04BA2D902BF11719A831EBB8222nasanexd02cnaqu_" MIME-Version: 1.0 Subject: Re: [payload] Incorrect equation in max-dpb definition in RFC6184 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 05:05:23 -0000 --_000_8BA7D4CEACFFE04BA2D902BF11719A831EBB8222nasanexd02cnaqu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I believe it is indeed a bug, and should be corrected. Chairs, what is the best way to make a corrigendum for this? BR, YK From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf = Of Wei, Xiaohui (Joanne) Sent: Wednesday, March 14, 2012 8:38 PM To: payload@ietf.org Subject: [payload] Incorrect equation in max-dpb definition in RFC6184 Dear All, I just found the equation in max-dpb definition in RFC6184 is incorrect: On page 46 in RFC6184: max-dpb: The value of max-dpb is an integer indicating the maximum decoded picture buffer size in units of 8/3 macroblocks. The max-dpb parameter signals that the receiver has more memory than the minimum amount of decoded picture buffer memory required by the signaled highest level conveyed in the value of the profile-level-id parameter or the max-recv-level parameter. When max-dpb is signaled, the receiver MUST be able to decode NAL unit streams that conform to the signaled highest level, with the exception that the MaxDpbMbs value in Table A-1 of [1] for the signaled highest level is replaced with the value of max-dpb * 3 / 8. Consequently, a receiver that signals max-dpb MUST be capable of storing the following number of decoded frames, complementary field pairs, and non-paired fields in its decoded picture buffer: Min(max-dpb * 3 / 8 / ( PicWidthInMbs * FrameHeightInMbs), 16) I understand this definition needs to be backwards compatible to RFC 3984. = I think to be backwards compatible to RFC 3984, the decoded picture buffer should be Min(max-dpb * 8 / 3 /( PicWidthInMbs * FrameHeightInMbs), 16) instead of Min(max-dpb * 3 / 8 /( PicWidthInMbs * FrameHeightInMbs), 16) in= RFC6184. And "When max-dpb is signaled, the receiver MUST be able to decode NAL unit streams that conform to the signaled highest level, with the exception that the MaxDpbMbs value in Table A-1 of [1] for the signaled highest level is replaced with the value of max-dpb * 3 / 8." Should be changed to "...the MaxDpbMbs value in Table A-1 of [1] for the signaled highest level is replaced with the value of max-dpb * 8 / 3." Thanks! Best regards, Xiaohui Wei (Joanne) --_000_8BA7D4CEACFFE04BA2D902BF11719A831EBB8222nasanexd02cnaqu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I believe it is indeed= a bug, and should be corrected.

 

Chairs, what is the be= st way to make a corrigendum for this?

 

BR, YK

 

From: payload-= bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf Of Wei, Xiaohui (Joanne)
Sent: Wednesday, March 14, 2012 8:38 PM
To: payload@ietf.org
Subject: [payload] Incorrect equation in max-dpb definition in RFC61= 84

 

Dear All,

 

I just found the equation in max-dpb definition in R= FC6184 is incorrect:

 

On page 46 in RFC6184:

max-dpb: The value of max-dpb is an = integer indicating the maximum

      =    decoded picture buffer size in units of 8/3 macroblocks.<= /o:p>

      =    The max-dpb parameter signals that the receiver has more memor= y

      =    than the minimum amount of decoded picture buffer memory<= /o:p>

      =    required by the signaled highest level conveyed in the value o= f

      =    the profile-level-id parameter or the max-recv-level parameter= .

      =    When max-dpb is signaled, the receiver MUST be able to decode<= o:p>

      =    NAL unit streams that conform to the signaled highest level,

      =    with the exception that the MaxDpbMbs value in Table A-1 of [1= ]

      =    for the signaled highest level is replaced with the value of

      =    max-dpb * 3 / 8. Consequently, a receiver that signals max-dpb=

      =    MUST be capable of storing the following number of decoded

      =    frames, complementary field pairs, and non-paired fields in it= s

      =    decoded picture buffer:

      =    Min(max-dpb * 3 / 8 / ( PicWidthInMbs * FrameHeightInMbs), 16)=

 

 

I understand this definition needs t= o be backwards compatible to RFC 3984. I think to

be backwards compatible to RFC 3984,= the decoded picture buffer should be

 

Min(max-dpb * 8 / 3 /( PicWidthInMbs * FrameHeightInMbs), 16)

 

instead of Min(max-dpb * 3 / 8 /( PicWidthInMbs * FrameHeightInMbs), 16) in RFC6184.

 

And “When max-dpb is signaled,= the receiver MUST be able to decode

     NAL unit st= reams that conform to the signaled highest level,

     with the ex= ception that the MaxDpbMbs value in Table A-1 of [1]

     for the sig= naled highest level is replaced with the value of

     max-dpb * 3 / 8.” Should be changed to “…the MaxDpbMbs value= in

     Table = A-1 of [1]  for the signaled highest level is replaced with

     the va= lue of max-dpb * 8 / 3.”

 

Thanks!

 

Best regards,

Xiaohui Wei (Joanne)

 

 

--_000_8BA7D4CEACFFE04BA2D902BF11719A831EBB8222nasanexd02cnaqu_-- From glenzorn@gmail.com Wed Mar 14 22:26:48 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEFA121F85BB for ; Wed, 14 Mar 2012 22:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.886 X-Spam-Level: X-Spam-Status: No, score=-2.886 tagged_above=-999 required=5 tests=[AWL=-0.287, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r5mLyF2sbX3u for ; Wed, 14 Mar 2012 22:26:47 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id C69F321F85B9 for ; Wed, 14 Mar 2012 22:26:47 -0700 (PDT) Received: by iazz13 with SMTP id z13so3875649iaz.31 for ; Wed, 14 Mar 2012 22:26:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=4WXxmOP34cEFbyPOT3JW9p2T3CGMNqJKxYj761pm4sY=; b=Y4iU6IZGRo4y4il0noL0q3zH01J6TShaOJSWuQfrm1QsVnEgEAdHJbAw8LLJcXRMhM Lqlm4wrSIZeRgF8BsYbCgMPXMJbBu3WhfK8riKqJzyE1Vd51TCicFTLCkaiLY8qW8O2Z nALC3tU62uFu/yIaX5yYajhXgA5TQ/U3V1BFhsgpEhxBHcm/W4kH1VUhmiZ2V62QhOan sNTLxTjiTp3sZKxW5M/3osJDjj5p4WoLp1en3a5Arhe4zqC0rB9sXeg2VWxGsXiCzZEd ffd+sRTIyaSLfOEWCnOpFj5rxm7GF1WY7W9WFI6qSislLic5Q3l6GxhdIvgO7aInIjel R4Pg== Received: by 10.50.104.137 with SMTP id ge9mr600486igb.0.1331789207283; Wed, 14 Mar 2012 22:26:47 -0700 (PDT) Received: from [192.168.1.98] (ppp-124-122-164-236.revip2.asianet.co.th. [124.122.164.236]) by mx.google.com with ESMTPS id gh8sm710387igb.16.2012.03.14.22.26.41 (version=SSLv3 cipher=OTHER); Wed, 14 Mar 2012 22:26:44 -0700 (PDT) Message-ID: <4F617D8A.7000503@gmail.com> Date: Thu, 15 Mar 2012 12:26:34 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "Wang, Ye-Kui" References: <165016AFA648BC4CB0242BC2D39EC2C2F26E752804@DC-US1MBEX1.global.avaya.com> <8BA7D4CEACFFE04BA2D902BF11719A831EBB8222@nasanexd02c.na.qualcomm.com> In-Reply-To: <8BA7D4CEACFFE04BA2D902BF11719A831EBB8222@nasanexd02c.na.qualcomm.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: "payload@ietf.org" Subject: Re: [payload] Incorrect equation in max-dpb definition in RFC6184 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 05:26:48 -0000 On 3/15/2012 12:05 PM, Wang, Ye-Kui wrote: > I believe it is indeed a bug, and should be corrected. > > > > Chairs, what is the best way to make a corrigendum for this? http://www.rfc-editor.org/errata.php > > > > BR, YK > > > > *From:*payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] *On > Behalf Of *Wei, Xiaohui (Joanne) > *Sent:* Wednesday, March 14, 2012 8:38 PM > *To:* payload@ietf.org > *Subject:* [payload] Incorrect equation in max-dpb definition in RFC6184 > > > > Dear All, > > > > I just found the equation in max-dpb definition in RFC6184 is incorrect: > > > > On page 46 in RFC6184: > > max-dpb: The value of max-dpb is an integer indicating the maximum > > decoded picture buffer size in units of 8/3 macroblocks. > > The max-dpb parameter signals that the receiver has more memory > > than the minimum amount of decoded picture buffer memory > > required by the signaled highest level conveyed in the value of > > the profile-level-id parameter or the max-recv-level parameter. > > When max-dpb is signaled, the receiver MUST be able to decode > > NAL unit streams that conform to the signaled highest level, > > with the exception that the MaxDpbMbs value in Table A-1 of [1] > > for the signaled highest level is replaced with the value of > > max-dpb * 3 / 8. Consequently, a receiver that signals max-dpb > > MUST be capable of storing the following number of decoded > > frames, complementary field pairs, and non-paired fields in its > > decoded picture buffer: > > Min(max-dpb * 3 / 8 / ( PicWidthInMbs * FrameHeightInMbs), 16) > > > > > > I understand this definition needs to be backwards compatible to RFC > 3984. I think to > > be backwards compatible to RFC 3984, the decoded picture buffer should be > > > > Min(max-dpb * *8 / 3* /( PicWidthInMbs * FrameHeightInMbs), 16) > > > > instead of Min(max-dpb * *3 / 8* /( PicWidthInMbs * FrameHeightInMbs), > 16) in RFC6184. > > > > And “When max-dpb is signaled, the receiver MUST be able to decode > > NAL unit streams that conform to the signaled highest level, > > with the exception that the MaxDpbMbs value in Table A-1 of [1] > > for the signaled highest level is replaced with the value of > > max-dpb * *3 / 8.*” Should be changed to “…the MaxDpbMbs value in > > Table A-1 of [1] for the signaled highest level is replaced with > > the value of max-dpb * *8 / 3*.” > > > > Thanks! > > > > Best regards, > > Xiaohui Wei (Joanne) > > > > > > > > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload From ron.even.tlv@gmail.com Sun Mar 18 09:34:59 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB5A21F8692; Sun, 18 Mar 2012 09:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.445 X-Spam-Level: X-Spam-Status: No, score=-2.445 tagged_above=-999 required=5 tests=[AWL=-0.609, BAYES_00=-2.599, HTML_MESSAGE=0.001, MISSING_SUBJECT=1.762, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zntuRD14Lhu4; Sun, 18 Mar 2012 09:34:58 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id E00F321F8691; Sun, 18 Mar 2012 09:34:57 -0700 (PDT) Received: by werb10 with SMTP id b10so6451507wer.31 for ; Sun, 18 Mar 2012 09:34:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:mime-version:content-type :x-mailer:thread-index:content-language; bh=81D9B9PeMZ2cnywBaACdBByRNS3yaS97Y//+cQcDBBs=; b=D65PbNn7VBxZv8LIVM5J/oAVPJTUjCEwF5Iej/VSCKQyoTT352zS/SpPnrPjiIaDTi ilJARBWQvr3D0nbq5lc7NEipZv2qnAQ95gM7ALLBs17L/rqQp+ygrchsRnS2oXTPP7FO 94CNRya/tfy08OlYumR3+2NUYwLtvNJ9Ai8x7kHH7ZHZS3YFdW3lBzHyRADpH2X+DFWO pahoWgr1utPU6EN1h/u6caa45EtVu6Rx/CSNrxCrXlxdhc3LeDNfL/vxLXQs/IyUUmSO rzzpI2gezUysYPulZQWWfSsPbAsnISP13TWqCjwSCL22WE4ssGy2vjZEm91VXqld0cbA 0KoQ== Received: by 10.180.19.37 with SMTP id b5mr13396043wie.9.1332088497093; Sun, 18 Mar 2012 09:34:57 -0700 (PDT) Received: from windows8d787f9 (bzq-79-179-219-130.red.bezeqint.net. [79.179.219.130]) by mx.google.com with ESMTPS id gg2sm28987438wib.7.2012.03.18.09.34.53 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 18 Mar 2012 09:34:54 -0700 (PDT) From: "Roni Even" To: "'IETF AVTCore WG'" , Date: Sun, 18 Mar 2012 18:33:53 +0200 Message-ID: <4f660eae.c268b40a.715b.144d@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0032_01CD0535.AD9DADD0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0FJOf8d1X5yg9QTUyRIpxgxIHRlQ== Content-Language: en-us Subject: [payload] (no subject) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Mar 2012 16:34:59 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0032_01CD0535.AD9DADD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, The document write-up template for sending documents to publication has changed. In particular, we need to poll authors on their compliance with IETF IPR rules prior to moving a document to the publication in the WG process. See http://www.ietf.org/iesg/template/doc-writeup.html question 7. We plan to send the following email when a WG document goes to WG last call. Please let us know if you have any comments on this plan. Roni Even AVTCore and Payload co-chair ----------------------------------------------------------------- To: Cc: AD; AVTcore/Payload WG Subject: Regarding IPR on Are you aware of any IPR that applies to ? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author and listed contributor. If you are on the AVTcore/payload WG email list but are not listed as an author or contributor, we remind you of your obligations under the IETF IPR rules which encourages you to notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribution or discussion related to your undisclosed IPR. For more information, please see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. ------=_NextPart_000_0032_01CD0535.AD9DADD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
Hi,
 
The document write-up template for sending documents to =
publication has changed.  In particular, we need to poll authors on =
their compliance with IETF IPR rules prior to moving a document to the =
publication in the WG process. See http://www.ie=
tf.org/iesg/template/doc-writeup.html question =
7.
 
We plan to send the =
following email when a WG document goes to WG last =
call.
 
 <=
/pre>
 
Please let us know if you have any =
comments on this =
plan.
 
Roni =
Even
AVTCore and Payload =
co-chair
 
---------------=
--------------------------------------------------
<=
o:p> 
To: <list all authors and =
contributors>
Cc: AD; AVTcore/Payload =
WG
 
Subject: Regarding =
IPR on <insert document =
name>
 
Are you aware =
of any IPR that applies to <insert document name>? If =
so,
has this IPR been disclosed in compliance with =
IETF IPR rules (see RFCs
3979, 4879, 3669 and 5378 =
for more details)?
 
If =
you are listed as a document author or contributor please answer =
the
above by responding to this email regardless of =
whether or not you are
aware of any relevant =
IPR.  This document will not advance to the =
next
stage until a response has been received from =
each author and =
listed
contributor.
 =

If you are on the AVTcore/payload WG email list but are =
not listed as an author or contributor, we remind you of your =
obligations under the IETF IPR rules which encourages you to notify the =
IETF if you are aware of IPR of others on an IETF contribution, or to =
refrain from participating in any contribution or discussion related to =
your undisclosed IPR.  For more information, please see the RFCs =
listed above and
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty=
.
 
 
------=_NextPart_000_0032_01CD0535.AD9DADD0-- From stewe@stewe.org Sun Mar 18 10:03:22 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 487C021F8674; Sun, 18 Mar 2012 10:03:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.765 X-Spam-Level: X-Spam-Status: No, score=-3.765 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJniC3satWZH; Sun, 18 Mar 2012 10:03:21 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by ietfa.amsl.com (Postfix) with ESMTP id 3C2E321F865E; Sun, 18 Mar 2012 10:03:21 -0700 (PDT) Received: from mail197-va3-R.bigfish.com (10.7.14.239) by VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id 14.1.225.23; Sun, 18 Mar 2012 17:03:17 +0000 Received: from mail197-va3 (localhost [127.0.0.1]) by mail197-va3-R.bigfish.com (Postfix) with ESMTP id 872FB3A0373; Sun, 18 Mar 2012 17:03:16 +0000 (UTC) X-SpamScore: -14 X-BigFish: PS-14(zzc85fhzz1202h1082kzz1033IL8275bh8275dhz2fh2a8h668h839hbe3k) X-Forefront-Antispam-Report: CIP:157.56.240.133; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0710HT005.namprd07.prod.outlook.com; RD:none; EFVD:NLI Received-SPF: pass (mail197-va3: domain of stewe.org designates 157.56.240.133 as permitted sender) client-ip=157.56.240.133; envelope-from=stewe@stewe.org; helo=BL2PRD0710HT005.namprd07.prod.outlook.com ; .outlook.com ; Received: from mail197-va3 (localhost.localdomain [127.0.0.1]) by mail197-va3 (MessageSwitch) id 1332090193489214_8926; Sun, 18 Mar 2012 17:03:13 +0000 (UTC) Received: from VA3EHSMHS026.bigfish.com (unknown [10.7.14.254]) by mail197-va3.bigfish.com (Postfix) with ESMTP id 70E01C0065; Sun, 18 Mar 2012 17:03:13 +0000 (UTC) Received: from BL2PRD0710HT005.namprd07.prod.outlook.com (157.56.240.133) by VA3EHSMHS026.bigfish.com (10.7.99.36) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sun, 18 Mar 2012 17:03:13 +0000 Received: from BL2PRD0710MB349.namprd07.prod.outlook.com ([169.254.1.131]) by BL2PRD0710HT005.namprd07.prod.outlook.com ([10.255.102.40]) with mapi id 14.16.0123.000; Sun, 18 Mar 2012 17:03:09 +0000 From: Stephan Wenger To: Roni Even , 'IETF AVTCore WG' , "payload@ietf.org" Thread-Topic: [AVTCORE] (no subject) Thread-Index: Ac0FJOf8d1X5yg9QTUyRIpxgxIHRlQADHcSA Date: Sun, 18 Mar 2012 17:03:09 +0000 Message-ID: In-Reply-To: <4f660eae.c268b40a.715b.144d@mx.google.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.102.5] Content-Type: multipart/alternative; boundary="_000_CB8BD29E848D4stewesteweorg_" MIME-Version: 1.0 X-OriginatorOrg: stewe.org Subject: Re: [payload] [AVTCORE] (no subject) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Mar 2012 17:03:22 -0000 --_000_CB8BD29E848D4stewesteweorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, There are many cases, where the answer to the first question is Yes, the an= swer to the second question is No, and people would still be in compliance = with the assorted policy RFCs. The reason is that disclosure is not requir= ed in many cases; for example, when the IPR in question is not owned by the= m or their employers. Suggest that the second question should be something like: " If so, has this IPR been disclosed when so required for in compliance with IETF IP= R rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? " Stephan From: Roni Even > Date: Sun, 18 Mar 2012 18:33:53 +0200 To: 'IETF AVTCore WG' >, > Cc: 'Magnus Westerlund' > Subject: [AVTCORE] (no subject) Hi, The document write-up template for sending documents to publication has cha= nged. In particular, we need to poll authors on their compliance with IETF= IPR rules prior to moving a document to the publication in the WG process.= See http://www.ietf.org/iesg/template/doc-writeup.html question 7. We plan to send the following email when a WG document goes to WG last call= . Please let us know if you have any comments on this plan. Roni Even AVTCore and Payload co-chair ----------------------------------------------------------------- To: Cc: AD; AVTcore/Payload WG Subject: Regarding IPR on Are you aware of any IPR that applies to ? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author and listed contributor. If you are on the AVTcore/payload WG email list but are not listed as an au= thor or contributor, we remind you of your obligations under the IETF IPR r= ules which encourages you to notify the IETF if you are aware of IPR of oth= ers on an IETF contribution, or to refrain from participating in any contri= bution or discussion related to your undisclosed IPR. For more information= , please see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. _______________________________________________ Audio/Video Transport Core = Maintenance avt@ietf.org https://www.ietf.org/mailman/= listinfo/avt --_000_CB8BD29E848D4stewesteweorg_ Content-Type: text/html; charset="us-ascii" Content-ID: <85DBCABF6445EF43BBDE035D934DC527@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Hi,
There are many cases, where the answer to the first question is Yes, t= he answer to the second question is No, and people would still be in compli= ance with the assorted policy RFCs.  The reason is that disclosure is = not required in many cases; for example, when the IPR in question is not owned by them or their employers.  

Suggest that the second question should be something like:
"
If so,
has this IPR been disclosed when so re=
quired for in compliance with IETF IPR rules (see RFCs=

3979, 4879, 3669 and 5378 for more details)?
"

Stephan

From: Roni Even <ron.even.tlv@gmail.com>
Date: Sun, 18 Mar 2012 18:33:53 = 3;0200
To: 'IETF AVTCore WG' <avt@ietf.org>, <payload@ietf.org>
Cc: 'Magnus Westerlund' <magnus.westerlund@ericsson.com>
Subject: [AVTCORE] (no subject)

Hi,
 
The document write-up template for sending documents to publication ha=
s changed.  In particular, we need to poll authors on their compliance=
 with IETF IPR rules prior to moving a document to the publication in the W=
G process. See http://www.ietf.org/iesg/template/doc-writeup.html question 7.<=
/o:p>
 
We plan to send the following email when a WG document goes to WG last=
 call.
 
 
 
Please let us know if you have any comments on this plan.

 


Roni Even


AVTCore and Payload co-chair


 


-----------------------------------------------------------------=



 


To: <list all authors and contributors>


Cc: AD; AVTcore/Payload WG


 


Subject: Regarding IPR on <insert document name>

 


Are you aware of any IPR that applies to <insert document name>?=
 If so,


has this IPR been disclosed in compliance with IETF IPR rules (see RFC=
s


3979, 4879, 3669 and 5378 for more details)?


 


If you are listed as a document author or contributor please answer th=
e


above by responding to this email regardless of whether or not you are=



aware of any relevant IPR.  This document will not advance to the=
 next


stage until a response has been received from each author and listed


contributor.


 


If you are on the AVTcore/payload WG email list but are not listed as =
an author or contributor, we remind you of your obligations under the IETF =
IPR rules which encourages you to notify the IETF if you are aware of IPR o=
f others on an IETF contribution, or to refrain from participating in any c=
ontribution or discussion related to your undisclosed IPR.  For more i=
nformation, please see the RFCs listed above and


http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProp=
erty.


 


 
_______________________________________________ Audio/Video Transport Core = Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt --_000_CB8BD29E848D4stewesteweorg_-- From ron.even.tlv@gmail.com Sun Mar 18 15:53:50 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B4D321F8498; Sun, 18 Mar 2012 15:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.279 X-Spam-Level: X-Spam-Status: No, score=-3.279 tagged_above=-999 required=5 tests=[AWL=0.319, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7zSUHdVHslwy; Sun, 18 Mar 2012 15:53:49 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id C114A21F849B; Sun, 18 Mar 2012 15:53:48 -0700 (PDT) Received: by wibhq7 with SMTP id hq7so2456301wib.13 for ; Sun, 18 Mar 2012 15:53:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language; bh=7qbs8yQBpHnxKYL4f3V95kAPlIr2RO16u2ldcQbOD1U=; b=Ttq0qV312GpyEjeFKwoDRFlnPT1aSqFnIOr4YctwwNUSIbF3Q6TlSVHGytGtk4GSH8 02Tjqq+o0dpZr5S29RMqnp/k5gPFhNrr4oJ91hepoyeMVwPqD5AkxVjUZa1ltR0+CFgy VCSv9LSO3vNopJNtRhfVg10CvwbyIQ66NOLYA/y9UpMTDCpCbdf7k/BKY9Sski6xx3sy 4gqQbFUbQ6p4bNQQHCar9vU0aG0GaJXkfR1z3+AC1VZwCVR19h8bJW9qjc2N1si5+x2Z l4VcTFS0AcWhu/X54i51o+mULBn27p5ClVcyyFe2GjIrpAIodOufCvZgHpDMiC4TOEU1 GtVQ== Received: by 10.180.78.225 with SMTP id e1mr14916732wix.0.1332111227870; Sun, 18 Mar 2012 15:53:47 -0700 (PDT) Received: from windows8d787f9 (bzq-79-179-219-130.red.bezeqint.net. [79.179.219.130]) by mx.google.com with ESMTPS id ff2sm33011850wib.9.2012.03.18.15.53.45 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 18 Mar 2012 15:53:47 -0700 (PDT) From: "Roni Even" To: "'Stephan Wenger'" , "'IETF AVTCore WG'" , References: <4f660eae.c268b40a.715b.144d@mx.google.com> In-Reply-To: Date: Mon, 19 Mar 2012 00:52:45 +0200 Message-ID: <4f66677b.6265b40a.5afc.ffff8f1b@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0046_01CD056A.9ADE8900" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0FJOf8d1X5yg9QTUyRIpxgxIHRlQADHcSAAAn/RCA= Content-Language: en-us Subject: Re: [payload] [AVTCORE] IPR requirements in document write-up X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Mar 2012 22:53:50 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0046_01CD056A.9ADE8900 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Stephan, Thanks for the text, I will use it. Roni From: Stephan Wenger [mailto:stewe@stewe.org] Sent: Sunday, March 18, 2012 7:03 PM To: Roni Even; 'IETF AVTCore WG'; payload@ietf.org Cc: 'Magnus Westerlund' Subject: Re: [AVTCORE] (no subject) Hi, There are many cases, where the answer to the first question is Yes, the answer to the second question is No, and people would still be in compliance with the assorted policy RFCs. The reason is that disclosure is not required in many cases; for example, when the IPR in question is not owned by them or their employers. Suggest that the second question should be something like: " If so, has this IPR been disclosed when so required for in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? " Stephan From: Roni Even Date: Sun, 18 Mar 2012 18:33:53 +0200 To: 'IETF AVTCore WG' , Cc: 'Magnus Westerlund' Subject: [AVTCORE] (no subject) Hi, The document write-up template for sending documents to publication has changed. In particular, we need to poll authors on their compliance with IETF IPR rules prior to moving a document to the publication in the WG process. See http://www.ietf.org/iesg/template/doc-writeup.html question 7. We plan to send the following email when a WG document goes to WG last call. Please let us know if you have any comments on this plan. Roni Even AVTCore and Payload co-chair ----------------------------------------------------------------- To: Cc: AD; AVTcore/Payload WG Subject: Regarding IPR on Are you aware of any IPR that applies to ? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author and listed contributor. If you are on the AVTcore/payload WG email list but are not listed as an author or contributor, we remind you of your obligations under the IETF IPR rules which encourages you to notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribution or discussion related to your undisclosed IPR. For more information, please see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. _______________________________________________ Audio/Video Transport Core Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt ------=_NextPart_000_0046_01CD056A.9ADE8900 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Stephan,

Thanks for the text, I = will use it.

Roni

 

From:= = Stephan Wenger [mailto:stewe@stewe.org]
Sent: Sunday, March = 18, 2012 7:03 PM
To: Roni Even; 'IETF AVTCore WG'; = payload@ietf.org
Cc: 'Magnus Westerlund'
Subject: = Re: [AVTCORE] (no subject)

 

Hi,

There are many cases, where the = answer to the first question is Yes, the answer to the second question = is No, and people would still be in compliance with the assorted policy = RFCs.  The reason is that disclosure is not required in many cases; = for example, when the IPR in question is not owned by them or their = employers.  

 

=

Suggest that the second question = should be something like:

"

= 
If =
so,
has this IPR =
been disclosed when so required for in compliance with =
IETF IPR rules (see RFCs
3979, 4879, 3669 and 5378 for more =
details)?

"

=

 

=

Stephan

 

=

From: = Roni Even <ron.even.tlv@gmail.com>
= Date: Sun, 18 Mar 2012 18:33:53 +0200
To: 'IETF AVTCore = WG' <avt@ietf.org>, <payload@ietf.org>
Cc: = 'Magnus Westerlund' <magnus.westerlund@ericsson= .com>
Subject: [AVTCORE] (no = subject)

 

= 
Hi,
 
The document write-up template for sending =
documents to publication has changed.  In particular, we need to =
poll authors on their compliance with IETF IPR rules prior to moving a =
document to the publication in the WG process. See http://www.ie=
tf.org/iesg/template/doc-writeup.html question =
7.
 
We plan to send the following email when a WG =
document goes to WG last call.
 
 
 
Please let us know if you have any comments on =
this plan.
 
Roni Even
AVTCore and Payload =
co-chair
 
---------------------------------------------------=
--------------
 
To: <list all authors and =
contributors>
Cc: AD; AVTcore/Payload =
WG
 
Subject: Regarding IPR on <insert document =
name>
 
Are you aware of any IPR that applies to =
<insert document name>? If so,
has this IPR been disclosed in compliance with =
IETF IPR rules (see RFCs
3979, 4879, 3669 and 5378 for more =
details)?
 
If you are listed as a document author or =
contributor please answer the
above by responding to this email regardless of =
whether or not you are
aware of any relevant IPR.  This document =
will not advance to the next
stage until a response has been received from each =
author and listed
contributor.
 
If you are on the AVTcore/payload WG email list =
but are not listed as an author or contributor, we remind you of your =
obligations under the IETF IPR rules which encourages you to notify the =
IETF if you are aware of IPR of others on an IETF contribution, or to =
refrain from participating in any contribution or discussion related to =
your undisclosed IPR.  For more information, please see the RFCs =
listed above and
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty=
.
 

 

__________________________________= _____________ Audio/Video Transport Core Maintenance avt@ietf.org https://www.ietf.org/m= ailman/listinfo/avt

------=_NextPart_000_0046_01CD056A.9ADE8900-- From abegen@cisco.com Tue Mar 20 20:34:14 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6157021F847F for ; Tue, 20 Mar 2012 20:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.417 X-Spam-Level: X-Spam-Status: No, score=-10.417 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IE7Egg+QU5lr for ; Tue, 20 Mar 2012 20:34:13 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 9C33821F847E for ; Tue, 20 Mar 2012 20:34:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=2700; q=dns/txt; s=iport; t=1332300853; x=1333510453; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=NlvpjpOSxFmkavuyc5iNJhbpnHFMzyjbfbil5HXsq8U=; b=jmTPWvJwzZI/noeFSJA4tpkA3lk+UthXlgvguRWDd2XOszcMUIuO3v7Q gEaGJjSa+lNBVOOfirxlMajvRmV7KZhyNvcvzm2SvgVqZJpBQQ9Cu0si8 RU7VvlY7hschojwcOtXrKUTUYXzojrzw7tGwxAxs6Ad7alle9epTZdkpt Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABNLaU+rRDoH/2dsb2JhbABEtnaBB4IJAQEBBAEBAQ8BWwsMBAIBCBEEAQELHQchBgsUCQgBAQQOBQgah2cBC5gJnycEiWyGMmMEoQyDEYFogmc X-IronPort-AV: E=Sophos;i="4.73,621,1325462400"; d="scan'208";a="36999025" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 21 Mar 2012 03:34:13 +0000 Received: from xht-rcd-x02-p.cisco.com (xht-rcd-x02-p.cisco.com [173.37.178.213]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2L3YDbC016407; Wed, 21 Mar 2012 03:34:13 GMT Received: from xmb-rcd-x01-p.cisco.com ([169.254.3.120]) by xht-rcd-x02-p.cisco.com ([173.37.178.213]) with mapi id 14.02.0283.003; Tue, 20 Mar 2012 20:34:12 -0700 From: "Ali C. Begen (abegen)" To: "draft-ietf-payload-vp8@tools.ietf.org" Thread-Topic: [payload] WGLC for draft-ietf-payload-vp8-03 ending March 1st Thread-Index: AczrRVxjReHrfWv2TROUTdcmKeO0cAOt+NyQAKIVnyACo2IoUA== Date: Wed, 21 Mar 2012 03:34:12 +0000 Message-ID: References: <4f535b8d.0b5f0e0a.0445.ffffd49a@mx.google.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.37.178.200] x-tm-as-product-ver: SMEX-10.0.0.4211-6.800.1017-18786.001 x-tm-as-result: No--47.496700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "payload@ietf.org" Subject: Re: [payload] WGLC for draft-ietf-payload-vp8-03 ending March 1st X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 03:34:14 -0000 Authors,=20 There were comments from Roni and Stephan. Could you please address them in= the list? WG, authors, I expect a few more reviews before we can send this to publication. Please = provide your reviews. Thanks. -acbegen > -----Original Message----- > From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behal= f Of Ali C. Begen (abegen) > Sent: Thursday, March 08, 2012 4:15 AM > To: Roni Even; payload@ietf.org > Subject: Re: [payload] WGLC for ending March 1st >=20 > Thanks Roni, are there any other reviews? I will extend the review period= till the 21st. Please provide your comments to the > list. >=20 > -acbegen >=20 > > -----Original Message----- > > From: Roni Even [mailto:ron.even.tlv@gmail.com] > > Sent: Sunday, March 04, 2012 7:09 AM > > To: Ali C. Begen (abegen); payload@ietf.org > > Subject: RE: [payload] WGLC for draft-ietf-payload-vp8-03 ending March = 1st > > > > Hi, > > Sorry for the late review. > > I have some comments. > > > > 1. In section 4.2 the PictureID definition talk about the msb being a f= lag. > > Why not show it in figure 2. > > > > 2. The first paragraph in section 4.3 talk about 10 octets version of t= he > > uncompressed data chunk, I could not find where the 10 octet version is > > specified. The example in 4.5.1 has the 3 octets version. > > > > > > 3. In the example in 4.5.2 is this a discardable packet in which case N > > should be 1. > > > > 4. In section 6.2.1 the reference to SDP should be RFC 4566. Also in pa= yload > > specification we typically use the media subtype and not MIME subtype. > > > > Roni Even > > As individual > > > > > -----Original Message----- > > > From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On > > > Behalf Of Ali C. Begen (abegen) > > > Sent: Tuesday, February 14, 2012 8:35 PM > > > To: payload@ietf.org > > > Subject: [payload] WGLC for draft-ietf-payload-vp8-03 ending March 1s= t > > > > > > WG, > > > > > > This is to start the WGLC for the VP8 draft. > > > https://datatracker.ietf.org/doc/draft-ietf-payload-vp8/ > > > > > > Please send your comments and approvals to the payload list by March > > > 1st. > > > > > > Authors, you need to separate the references as informative vs. > > > normative but please wait till the WGLC ends for a revision. > > > > > > -acbegen > > > _______________________________________________ > > > payload mailing list > > > payload@ietf.org > > > https://www.ietf.org/mailman/listinfo/payload >=20 > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload From pwestin@google.com Wed Mar 21 08:47:11 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1D7E21F85FC for ; Wed, 21 Mar 2012 08:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QHhPdPnhdgwg for ; Wed, 21 Mar 2012 08:47:10 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id DF46E21F865B for ; Wed, 21 Mar 2012 08:47:09 -0700 (PDT) Received: by mail-yw0-f44.google.com with SMTP id k25so1156245yhk.31 for ; Wed, 21 Mar 2012 08:47:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-system-of-record; bh=V3kdYOn8+/uSb5SO3EagKjIGDmFU47Wta8TAvooBjaA=; b=lU0HmN+DzppFyfXSO72cMuBL+YTsY5u2XiWlJZJ8aAqT3Mk1DCjy+JIA0T7AzvbdoT zmmmaMrIUBH2Y0kP3HLriMRM61gob71ar+ZkY9KgcZRvhbuE4vz5654P4i44j5m5Y4Ti hROTvujfHYQ/PZEmkJWBDnvj+MGKk6Qd60v+F2Dj0s3MULGS6CojnwuBDZyrtrkTZeA9 HtdEfcRF0NSBctiL05BSEWtLFW6HXE+wN6hOltVVEkvdVFmG6K2/LBgxJ7omxuHoWU1T mrjxwNfVyDXbzHFaOpYWiv7N1Iw/ILO1ruxoD7TTl4BBF2tvpZAsdOae8fRDxGyDjA0N CKzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-system-of-record:x-gm-message-state; bh=V3kdYOn8+/uSb5SO3EagKjIGDmFU47Wta8TAvooBjaA=; b=AGSOaRDEG4LnVsBnl6jkQz5THYI3W+RTQKLGNhbwLuPC7Vaucy234PBQSuatQLdv3/ y6POXdGtfmrXcA0hNAEerA1aaWnSfZeX/XqA2zCxTTim/dp6XNd1qrYksq7yqKgRUL8/ FphcZSzz25z1VPiCnSg9QuhMqbbiIzSQfwB6Cs0Q9c90QAmw4VWL6YsWVdLwVf22EO7h tfBVnRwlglntXlIMxk8TgIQr70PZzR8GMmHUN2aaMlUafJmPdLAUuX5aeXJ0P6OYd/aX jZPtN2HV0LIXNEIe3K1ELMOstr4X8QrmI5N3aONkxzny0gRM4gb1051UwpqOwR0rXJUd ZJQg== Received: by 10.236.182.67 with SMTP id n43mr4358453yhm.75.1332344829604; Wed, 21 Mar 2012 08:47:09 -0700 (PDT) Received: by 10.236.182.67 with SMTP id n43mr4358438yhm.75.1332344829468; Wed, 21 Mar 2012 08:47:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.16.6 with HTTP; Wed, 21 Mar 2012 08:46:49 -0700 (PDT) From: Patrik Westin Date: Wed, 21 Mar 2012 16:46:49 +0100 Message-ID: To: payload@ietf.org, ron.even.tlv@gmail.com, abegen@cisco.com, stewe@stewe.org Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQl6/c9Xl08ld4oc+G7w2mfk3zi/g5E1TEqq5PpwaKiXaqO/VFjPFBXD5lBek5SFjnjXYI4rJrsknT4RYc8R/CwRgeZt10SNmWPiedmksSHE5/vwPTPHqhsH2xHlaU7SI2SAbk+B Subject: Re: [payload] WGLC for draft-ietf-payload-vp8-03 ending March 1st X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 15:50:21 -0000 Answers to questions regarding draft-ietf-payload-vp8-03. Answers to question from Stephan Wenger The decoder does not exhibit a significant non-uniformity computational complexity, we assume that the call set up process will provide a method for negotiating the max received resolution. Given that this is a commonly needed feature, we do not define any codec-specific way of doing this negotiation here. We will add a note about the need for it. Answers to questions from Roni Even 1. Good idea, we will add it to figure 2. 2. We will reformulate the paragraph so that it is clear that it's only summarizing information from RFC 6386. 3. The packet does not belong to a discardable frame, will add a note about it. 4. Will change to reference RFC 4566 -Patrik Westin From barryleiba@gmail.com Wed Mar 21 09:03:08 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D64E121E801A; Wed, 21 Mar 2012 09:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.99 X-Spam-Level: X-Spam-Status: No, score=-102.99 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fposVTJssx7O; Wed, 21 Mar 2012 09:03:05 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id C6C0A21F85CF; Wed, 21 Mar 2012 09:03:04 -0700 (PDT) Received: by ggmi1 with SMTP id i1so1193053ggm.31 for ; Wed, 21 Mar 2012 09:03:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ne/2CVIMcy4X9ovMfAf/9Y+Z3GBbdCCRG5aRC4d7XkU=; b=ex3q8lc19TevoW41zvwktVbkpnbKI+mluAg+Jx9HY6uOAhvPSyj/hHtCA25WtadJmB 4id62BhDzrNtBqgq7qDPaH4bqVRs5aJQ299oPsI1nwkDCJ7+fXlQck3ZJI3yEYKxiSkl W91e9ZN9x67dV01BrUKkOmCVAzYPk17Yrz5vzCNE+dMX2uRyBW5zO+q/TDSsgzK589Wa RAeWYr1YJcsi8aNBQgLvYW2ejd7P/DeL8xZb9Tqb83TaA/TkS5kwrJoQFHMZHKoewDLP 3P0kOiEsUKw4ycd8epAFAn3LoJZIhFizi5Dt8/INUjNi3rmyyea4Fgy5+J1nifTDrP8m UqXw== MIME-Version: 1.0 Received: by 10.182.12.6 with SMTP id u6mr5531823obb.12.1332345784345; Wed, 21 Mar 2012 09:03:04 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.60.165.72 with HTTP; Wed, 21 Mar 2012 09:03:04 -0700 (PDT) In-Reply-To: <4F68E88F.70009@nostrum.com> References: <4f66677b.6265b40a.5afc.ffff8f1b@mx.google.com> <4F68E88F.70009@nostrum.com> Date: Wed, 21 Mar 2012 12:03:04 -0400 X-Google-Sender-Auth: ywdnc-rUABhz9fGTTqT_yHEQ9D8 Message-ID: From: Barry Leiba To: Roni Even , Stephan Wenger Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: avt@ietf.org, payload@ietf.org, iesg@ietf.org Subject: Re: [payload] [AVTCORE] IPR requirements in document write-up X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 16:03:09 -0000 > Thanks for the text, I will use it. > > Roni I recommend you do not, for a few reasons: 1. You may not rewrite the PROTO template; that belongs to the IESG. 2. The question was worded as it is for a reason, and it should be left that way. The IESG wants to know whether there are any known IPR claims, whether declarations have been made to and considered by the working group, and whether formal IPR statements have been filed in the system. The middle one is as important as the last. 3. Stephan is incorrect when he says this: > The reason is that disclosure is not > required in many cases; for example, when the IPR in question is not owne= d > by them or their employers. If you are aware of IPR that you do not own, you may and you should make a third-party disclosure. You may, of course, ask the question of your working group in any way you like. But I suggest you ask it in a way that allows you to accurately answer the question asked in the PROTO template. Barry, incoming Applications AD > -------- Original Message -------- > From: Stephan Wenger [mailto:stewe@stewe.org] > Sent: Sunday, March 18, 2012 7:03 PM > To: Roni Even; 'IETF AVTCore WG'; payload@ietf.org > Cc: 'Magnus Westerlund' > Subject: Re: [AVTCORE] (no subject) > > Hi, > > There are many cases, where the answer to the first question is Yes, the > answer to the second question is No, and people would still be in complia= nce > with the assorted policy RFCs. =A0The reason is that disclosure is not > required in many cases; for example, when the IPR in question is not owne= d > by them or their employers. > > > > Suggest that the second question should be something like: > > " > > If so, > > has this IPR been disclosed when so required for in compliance with IETF > IPR rules (see RFCs > > 3979, 4879, 3669 and 5378 for more details)? > > " > > > > Stephan > > > > From: Roni Even > Date: Sun, 18 Mar 2012 18:33:53 +0200 > To: 'IETF AVTCore WG' , > Cc: 'Magnus Westerlund' > Subject: [AVTCORE] (no subject) > > > > Hi, > > > > The document write-up template for sending documents to publication has > changed.=A0 In particular, we need to poll authors on their compliance wi= th > IETF IPR rules prior to moving a document to the publication in the WG > process. See http://www.ietf.org/iesg/template/doc-writeup.html question = 7. > > > > We plan to send the following email when a WG document goes to WG last > call. > > > > > > > > Please let us know if you have any comments on this plan. > > > > Roni Even > > AVTCore and Payload co-chair > > > > ----------------------------------------------------------------- > > > > To: > > Cc: AD; AVTcore/Payload WG > > > > Subject: Regarding IPR on > > > > Are you aware of any IPR that applies to ? If so, > > has this IPR been disclosed in compliance with IETF IPR rules (see RFCs > > 3979, 4879, 3669 and 5378 for more details)? > > > > If you are listed as a document author or contributor please answer the > > above by responding to this email regardless of whether or not you are > > aware of any relevant IPR.=A0 This document will not advance to the next > > stage until a response has been received from each author and listed > > contributor. > > > > If you are on the AVTcore/payload WG email list but are not listed as an > author or contributor, we remind you of your obligations under the IETF I= PR > rules which encourages you to notify the IETF if you are aware of IPR of > others on an IETF contribution, or to refrain from participating in any > contribution or discussion related to your undisclosed IPR.=A0 For more > information, please see the RFCs listed above and > > http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. > > > > > > _______________________________________________ Audio/Video Transport Cor= e > Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt From stewe@stewe.org Wed Mar 21 10:27:34 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7912F21F85F6 for ; Wed, 21 Mar 2012 10:27:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.749 X-Spam-Level: X-Spam-Status: No, score=-3.749 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kwroSUbyx6e4 for ; Wed, 21 Mar 2012 10:27:33 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id AB34A21F85F1 for ; Wed, 21 Mar 2012 10:27:33 -0700 (PDT) Received: from mail115-ch1-R.bigfish.com (10.43.68.241) by CH1EHSOBE015.bigfish.com (10.43.70.65) with Microsoft SMTP Server id 14.1.225.23; Wed, 21 Mar 2012 17:27:26 +0000 Received: from mail115-ch1 (localhost [127.0.0.1]) by mail115-ch1-R.bigfish.com (Postfix) with ESMTP id 03DD14004A4; Wed, 21 Mar 2012 17:27:26 +0000 (UTC) X-SpamScore: -26 X-BigFish: PS-26(zz1432N98dKzz1202h1082kzz1033IL8275bh8275dhz2fh2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:157.56.240.133; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0710HT003.namprd07.prod.outlook.com; RD:none; EFVD:NLI Received-SPF: pass (mail115-ch1: domain of stewe.org designates 157.56.240.133 as permitted sender) client-ip=157.56.240.133; envelope-from=stewe@stewe.org; helo=BL2PRD0710HT003.namprd07.prod.outlook.com ; .outlook.com ; Received: from mail115-ch1 (localhost.localdomain [127.0.0.1]) by mail115-ch1 (MessageSwitch) id 133235084454073_30703; Wed, 21 Mar 2012 17:27:24 +0000 (UTC) Received: from CH1EHSMHS022.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.243]) by mail115-ch1.bigfish.com (Postfix) with ESMTP id ED75FE0077; Wed, 21 Mar 2012 17:27:23 +0000 (UTC) Received: from BL2PRD0710HT003.namprd07.prod.outlook.com (157.56.240.133) by CH1EHSMHS022.bigfish.com (10.43.70.22) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 21 Mar 2012 17:27:23 +0000 Received: from BL2PRD0710MB349.namprd07.prod.outlook.com ([169.254.1.100]) by BL2PRD0710HT003.namprd07.prod.outlook.com ([10.255.102.38]) with mapi id 14.16.0135.002; Wed, 21 Mar 2012 17:27:29 +0000 From: Stephan Wenger To: Patrik Westin , "payload@ietf.org" , "ron.even.tlv@gmail.com" , "abegen@cisco.com" Thread-Topic: [payload] WGLC for draft-ietf-payload-vp8-03 ending March 1st Thread-Index: AQHNB3nTReHrfWv2TROUTdcmKeO0cJZ1EZqA Date: Wed, 21 Mar 2012 17:27:28 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.102.4] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: stewe.org Subject: Re: [payload] WGLC for draft-ietf-payload-vp8-03 ending March 1st X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 17:27:34 -0000 Hi Patrick, On 3.21.2012 16:46 , "Patrik Westin" wrote: >Answers to questions regarding draft-ietf-payload-vp8-03. > >Answers to question from Stephan Wenger > >The decoder does not exhibit a significant non-uniformity >computational complexity, we assume that the call set up process will >provide a method for negotiating the max received resolution. Given >that this is a commonly needed feature, we do not define any >codec-specific way of doing this negotiation here. We will add a note >about the need for it. Sorry, but I do not think this is sufficient. A simple note will not do, as it, in practice, renders the VP8 payload close to unusable and insecure in heterogenous environments, for reasons I mentioned in my previous email. A normative reference to a resolution negotiation document would help somewhat, but AFAIK, there is no document in the IETF space that you could reference today. If there were one, please normatively reference it. Beyond the payload format: I'm not quite sure whether a generic (SDP-) code point for resolution negotiation, independent from other properties, would be such a great idea. For example, think in MPEG terms, profiles and levels. Profiles select coding tools based on (among other things) complexity and application requirements. Levels are selected in units roughly representing to picture size and frame rate, something like macroblocks per second. What one should shoot for, if one were trying to create a single-dimension resolution negotiation draft, would be the rough equivalent of signaling a level, not just a spatial resolution. And even with that, while in VP8 the complexity should be roughly proportional to the MB/sec measure, this is not true for other codecs that have a developed profile system. If one were creating a generic solution for resolution signaling, profile specific complexity behavior (which, quite obviously, is highly codec dependent) would have to be taken care of. Also, please take a look at the HEVC-type parallelization tools. (A very preliminary description of the problem with parallelization tools can be found in http://tools.ietf.org/html/draft-schierl-payload-rtp-h265-00, section 1.) Briefly put, with HEVC, you can sometimes decode a bitstream even if a single core or CPU could not bear the load--if your bitstream is tailored to support parallel decoding and if you have multiple cores. It's an HEVC specific thing, so it has to live in the HEVC payload. But how would this be compatible with a hypothetical generic resolution negotiation mechanism? To summarize, I think you should consider the inclusion of code points allowing to negotiate decoding complexity (macroblocks per second, decoding memory requirements (maximum picture size), and perhaps also maximum framerate. Stephan > > >Answers to questions from Roni Even > >1. Good idea, we will add it to figure 2. > >2. We will reformulate the paragraph so that it is clear that it's >only summarizing information from RFC 6386. > >3. The packet does not belong to a discardable frame, will add a note >about it. > >4. Will change to reference RFC 4566 > > > >-Patrik Westin > From stewe@stewe.org Wed Mar 21 11:09:27 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92EE021F847F; Wed, 21 Mar 2012 11:09:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.735 X-Spam-Level: X-Spam-Status: No, score=-3.735 tagged_above=-999 required=5 tests=[AWL=-0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aj1hdzaxc4Qr; Wed, 21 Mar 2012 11:09:26 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe003.messaging.microsoft.com [213.199.154.141]) by ietfa.amsl.com (Postfix) with ESMTP id 1C16121F847E; Wed, 21 Mar 2012 11:09:25 -0700 (PDT) Received: from mail101-db3-R.bigfish.com (10.3.81.238) by DB3EHSOBE005.bigfish.com (10.3.84.25) with Microsoft SMTP Server id 14.1.225.23; Wed, 21 Mar 2012 18:09:18 +0000 Received: from mail101-db3 (localhost [127.0.0.1]) by mail101-db3-R.bigfish.com (Postfix) with ESMTP id 91DC54A0357; Wed, 21 Mar 2012 18:09:17 +0000 (UTC) X-SpamScore: -43 X-BigFish: PS-43(zz9371I1503M542M1432N98dK4015I1447Mzz1202h1082kzz1033IL8275bh8275dhz2fh2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:157.56.240.133; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0710HT004.namprd07.prod.outlook.com; RD:none; EFVD:NLI Received-SPF: pass (mail101-db3: domain of stewe.org designates 157.56.240.133 as permitted sender) client-ip=157.56.240.133; envelope-from=stewe@stewe.org; helo=BL2PRD0710HT004.namprd07.prod.outlook.com ; .outlook.com ; Received: from mail101-db3 (localhost.localdomain [127.0.0.1]) by mail101-db3 (MessageSwitch) id 1332353355317821_29063; Wed, 21 Mar 2012 18:09:15 +0000 (UTC) Received: from DB3EHSMHS004.bigfish.com (unknown [10.3.81.238]) by mail101-db3.bigfish.com (Postfix) with ESMTP id 46568100049; Wed, 21 Mar 2012 18:09:15 +0000 (UTC) Received: from BL2PRD0710HT004.namprd07.prod.outlook.com (157.56.240.133) by DB3EHSMHS004.bigfish.com (10.3.87.104) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 21 Mar 2012 18:09:14 +0000 Received: from BL2PRD0710MB349.namprd07.prod.outlook.com ([169.254.1.100]) by BL2PRD0710HT004.namprd07.prod.outlook.com ([10.255.102.39]) with mapi id 14.16.0135.002; Wed, 21 Mar 2012 18:09:09 +0000 From: Stephan Wenger To: Barry Leiba Thread-Topic: [AVTCORE] IPR requirements in document write-up Thread-Index: AQHNB4223QfN1LwTdkiObOrmg6aoSw== Date: Wed, 21 Mar 2012 18:09:09 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.102.4] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: stewe.org Cc: "ipr@ietf.org" , IETF , "avt@ietf.org" , "payload@ietf.org" , "iesg@ietf.org" Subject: Re: [payload] [AVTCORE] IPR requirements in document write-up X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 18:09:27 -0000 Hi Barry, Adding the IPRWG and ietf@ietf. For the benefit if "new" readers: This is about an updated proto shepherd writeup template, asking two questions about IPR that, IMO may not be in compliance with the IETF's IPR policy. I was not aware that the proto template had IESG blessing. Still, I believe that the template text does not ask the right question, or, more specifically, is a suggestive question in that it appears (at least to me) to interpret the IETF's patent policy in a considerably more strict way than it is set out in the policy RFCs. I believe the IESG should reconsider the proto writeup. A few more comments inline On 3.21.2012 17:03 , "Barry Leiba" wrote: >> Thanks for the text, I will use it. >> >> Roni > >I recommend you do not, for a few reasons: > >1. You may not rewrite the PROTO template; that belongs to the IESG. Agreed (now that I'm aware of that this is an IESG-sanctioned template). >2. The question was worded as it is for a reason, and it should be >left that way. The IESG wants to know whether there are any known IPR >claims, whether declarations have been made to and considered by the >working group, and whether formal IPR statements have been filed in >the system. The middle one is as important as the last. Also agreed (with caveats, see below). > >3. Stephan is incorrect when he says this: >> The reason is that disclosure is not >> required in many cases; for example, when the IPR in question is not >>owned >> by them or their employers. > >If you are aware of IPR that you do not own, you may and you should >make a third-party disclosure. Barry, please read my language carefully. Perhaps I should have capitalized REQUIRED, but the text is clear and inline with yours. It's MAY and SHOULD for third party disclosures. But you are NOT *required* to do so by policy; there is no MUST. There are many good and valid reasons why there is no MUST (beyond that it's not in the policy docs). And, third party disclosures are not even a widely used current practice. Just look at the (comparatively low) number of third party disclosures. Look, I do patent work as my day job. I also do standards work In my current and previous job roles, I have looked at hundreds of patents of my current or previous employers, as well as occasionally at third party patents. Now, with this background, let's look at the template text again (numerals by me): (1) Are you aware of any IPR that applies to ? (2) If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979,=20 4879, 3669 and 5378 for more details)? For the majority of the documents I am working on, the answer to question (1) would be yes. The answer to question (2) would be quite often no. Based on my interpretation of the policy RFCs, I am in full compliance with language and spirit of the policy. I'm not doing anything fishy. I just don't talk about third party IPR, which is my right under the IETF's IPR policy. However, by providing answers to questions (1) and (2), the IESG would receive a signal that it is not entitled to receive (more precisely: that I'm not required to send, and not willing to send voluntarily, as it could get me personally into trouble), namely that there may be patents related to a document which the discloser is not willing, AND not obligated, to talk about. This is a policy change through the backdoor. Policy changes through the backdoor are bad. My suggestion was aimed to bring the template in compliance with what I believe is language and spirit of the policy. Thanks, Stephan > >You may, of course, ask the question of your working group in any way >you like. But I suggest you ask it in a way that allows you to >accurately answer the question asked in the PROTO template. > >Barry, incoming Applications AD > >> -------- Original Message -------- >> From: Stephan Wenger [mailto:stewe@stewe.org] >> Sent: Sunday, March 18, 2012 7:03 PM >> To: Roni Even; 'IETF AVTCore WG'; payload@ietf.org >> Cc: 'Magnus Westerlund' >> Subject: Re: [AVTCORE] (no subject) >> >> Hi, >> >> There are many cases, where the answer to the first question is Yes, the >> answer to the second question is No, and people would still be in >>compliance >> with the assorted policy RFCs. The reason is that disclosure is not >> required in many cases; for example, when the IPR in question is not >>owned >> by them or their employers. >> >> >> >> Suggest that the second question should be something like: >> >> " >> >> If so, >> >> has this IPR been disclosed when so required for in compliance with IETF >> IPR rules (see RFCs >> >> 3979, 4879, 3669 and 5378 for more details)? >> >> " >> >> >> >> Stephan >> >> >> >> From: Roni Even >> Date: Sun, 18 Mar 2012 18:33:53 +0200 >> To: 'IETF AVTCore WG' , >> Cc: 'Magnus Westerlund' >> Subject: [AVTCORE] (no subject) >> >> >> >> Hi, >> >> >> >> The document write-up template for sending documents to publication has >> changed. In particular, we need to poll authors on their compliance >>with >> IETF IPR rules prior to moving a document to the publication in the WG >> process. See http://www.ietf.org/iesg/template/doc-writeup.html >>question 7. >> >> >> >> We plan to send the following email when a WG document goes to WG last >> call. >> >> >> >> >> >> >> >> Please let us know if you have any comments on this plan. >> >> >> >> Roni Even >> >> AVTCore and Payload co-chair >> >> >> >> ----------------------------------------------------------------- >> >> >> >> To: >> >> Cc: AD; AVTcore/Payload WG >> >> >> >> Subject: Regarding IPR on >> >> >> >> Are you aware of any IPR that applies to ? If so, >> >> has this IPR been disclosed in compliance with IETF IPR rules (see RFCs >> >> 3979, 4879, 3669 and 5378 for more details)? >> >> >> >> If you are listed as a document author or contributor please answer the >> >> above by responding to this email regardless of whether or not you are >> >> aware of any relevant IPR. This document will not advance to the next >> >> stage until a response has been received from each author and listed >> >> contributor. >> >> >> >> If you are on the AVTcore/payload WG email list but are not listed as an >> author or contributor, we remind you of your obligations under the IETF >>IPR >> rules which encourages you to notify the IETF if you are aware of IPR of >> others on an IETF contribution, or to refrain from participating in any >> contribution or discussion related to your undisclosed IPR. For more >> information, please see the RFCs listed above and >> >> http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. >> >> >> >> >> >> _______________________________________________ Audio/Video Transport >>Core >> Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt > From harald@alvestrand.no Thu Mar 22 02:18:59 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17DCF21F85CD for ; Thu, 22 Mar 2012 02:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.517 X-Spam-Level: X-Spam-Status: No, score=-110.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fhkXKdwmMnCK for ; Thu, 22 Mar 2012 02:18:58 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id EFF4121F85A5 for ; Thu, 22 Mar 2012 02:18:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id AFADA39E18F; Thu, 22 Mar 2012 10:18:56 +0100 (CET) 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 JifV1ed9t8nH; Thu, 22 Mar 2012 10:18:47 +0100 (CET) Received: from hta-dell.lul.corp.google.com (unknown [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 84EBB39E01E; Thu, 22 Mar 2012 10:18:46 +0100 (CET) Message-ID: <4F6AEE75.7000308@alvestrand.no> Date: Thu, 22 Mar 2012 10:18:45 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: Stephan Wenger References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "payload@ietf.org" Subject: Re: [payload] WGLC for draft-ietf-payload-vp8-03 ending March 1st X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 09:18:59 -0000 On 03/21/2012 06:27 PM, Stephan Wenger wrote: > Hi Patrick, > > On 3.21.2012 16:46 , "Patrik Westin" wrote: > >> Answers to questions regarding draft-ietf-payload-vp8-03. >> >> Answers to question from Stephan Wenger >> >> The decoder does not exhibit a significant non-uniformity >> computational complexity, we assume that the call set up process will >> provide a method for negotiating the max received resolution. Given >> that this is a commonly needed feature, we do not define any >> codec-specific way of doing this negotiation here. We will add a note >> about the need for it. > Sorry, but I do not think this is sufficient. > > A simple note will not do, as it, in practice, renders the VP8 payload > close to unusable and insecure in heterogenous environments, for reasons I > mentioned in my previous email. A normative reference to a resolution > negotiation document would help somewhat, but AFAIK, there is no document > in the IETF space that you could reference today. If there were one, > please normatively reference it. I don't understand this objection, but I may be dense. An implementation can be written as: negotiated resolution in pixels = negotiate, draw conclusion about resolution negotiated if (negotiated resolution in pixels * negotiated max frame rate > my maximum supported rate) report failure else process with decoding endif I do not see how this is either unusable or insecure, and I don't think it's appropriate for the payload format to specify normatively a single negotiation method. > Beyond the payload format: > > I'm not quite sure whether a generic (SDP-) code point for resolution > negotiation, independent from other properties, would be such a great > idea. For example, think in MPEG terms, profiles and levels. Profiles > select coding tools based on (among other things) complexity and > application requirements. Levels are selected in units roughly > representing to picture size and frame rate, something like macroblocks > per second. What one should shoot for, if one were trying to create a > single-dimension resolution negotiation draft, would be the rough > equivalent of signaling a level, not just a spatial resolution. And even > with that, while in VP8 the complexity should be roughly proportional to > the MB/sec measure, this is not true for other codecs that have a > developed profile system. The need for negotiating vertical and horizontal resolution has been identified in a *lot* of other contexts. Indeed, it's hard to find an application where the need does not exist. In the main, the need exists independently of the need to determine decoder complexity requirements. In VP8, the need for a "developed profile system" has not been identified, and we're eager to avoid having to develop one; after looking at the factors that drive decoder complexity for VP8, we think that knowing the resolution is information enough. The fact that other codecs have other needs should not impact VP8. > If one were creating a generic solution for > resolution signaling, profile specific complexity behavior (which, quite > obviously, is highly codec dependent) would have to be taken care of. > Also, please take a look at the HEVC-type parallelization tools. (A very > preliminary description of the problem with parallelization tools can be > found in http://tools.ietf.org/html/draft-schierl-payload-rtp-h265-00, > section 1.) Briefly put, with HEVC, you can sometimes decode a bitstream > even if a single core or CPU could not bear the load--if your bitstream is > tailored to support parallel decoding and if you have multiple cores. > It's an HEVC specific thing, so it has to live in the HEVC payload. But > how would this be compatible with a hypothetical generic resolution > negotiation mechanism? > > To summarize, I think you should consider the inclusion of code points > allowing to negotiate decoding complexity (macroblocks per second, > decoding memory requirements (maximum picture size), and perhaps also > maximum framerate. > > Stephan > >> >> Answers to questions from Roni Even >> >> 1. Good idea, we will add it to figure 2. >> >> 2. We will reformulate the paragraph so that it is clear that it's >> only summarizing information from RFC 6386. >> >> 3. The packet does not belong to a discardable frame, will add a note >> about it. >> >> 4. Will change to reference RFC 4566 >> >> >> >> -Patrik Westin >> > > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload > From mperumal@cisco.com Thu Mar 22 03:17:28 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D167821F864C for ; Thu, 22 Mar 2012 03:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.365 X-Spam-Level: X-Spam-Status: No, score=-9.365 tagged_above=-999 required=5 tests=[AWL=0.633, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FApka5Uo3HH8 for ; Thu, 22 Mar 2012 03:17:24 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 74CB421F865E for ; Thu, 22 Mar 2012 03:17:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=25439; q=dns/txt; s=iport; t=1332411444; x=1333621044; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=L5RBWyoda6JKFfyktpO2ZspgRrELc7fGed4Nim/uVko=; b=TiZknnUgIXPG33zNm8riTM5np68FtIo8BrcMyo21NVOXze5cPJrQzYjj 6ix5cZ0ZmypLFW+NjDwNpW6My/Mpx6eHTp1UV1Y1pWZLJ5J0f++9ht0i+ 5xPsh+Th1g37M8pzAwx7og+0QZYH6r/FT0sLbvVVQAI/DPbJc8GBzeZtW s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAED7ak+rRDoG/2dsb2JhbABEgka0aoEHggkBAQEEEgEJEQNJDAQCAQgRBAEBAQoGBQsHAQYBICUIAQgBAQQLCAgah2cBmTafFYltaAmCWIJLYwSIVJg6gxGBaIJvgUwB X-IronPort-AV: E=Sophos;i="4.73,629,1325462400"; d="scan'208,217";a="34085478" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 22 Mar 2012 10:17:21 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2MAH46d030360; Thu, 22 Mar 2012 10:17:20 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Mar 2012 15:47:15 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD0814.F4275352" Date: Thu, 22 Mar 2012 15:47:15 +0530 Message-ID: <1D062974A4845E4D8A343C653804920207F1D5FD@XMB-BGL-414.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [payload] FW: I-D Action:draft-muthu-payload-offer-answer-g723-g729-00.txt Thread-Index: Acz9NGRNlzRDLmfFTteXgC7xjn3xTAK25CAA References: <1D062974A4845E4D8A343C653804920207ABB1E1@XMB-BGL-414.cisco.com><4F4BB973.4060508@alum.mit.edu> <4F4D06B6.6020905@digium.com><4F4D17C8.7070201@alum.mit.edu> <4F4D26AE.5070009@digium.com><4F4D40A3.6030309@digium.com><4F4E44C3.4080803@alum.mit.edu><387F9047F55E8C42850AD6B3A7A03C6C0E06BEC7@inba-mail01.sonusnet.com><387F9047F55E8C42850AD6B3A7A03C6C0E1F7F40@inba-mail01.sonusnet.com> From: "Muthu Arul Mozhi Perumal (mperumal)" To: "David R Oran" , "Chhatwal, Harprit S" X-OriginalArrivalTime: 22 Mar 2012 10:17:15.0460 (UTC) FILETIME=[F44BF840:01CD0814] Cc: payload@ietf.org Subject: Re: [payload] FW: I-D Action:draft-muthu-payload-offer-answer-g723-g729-00.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 10:17:28 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD0814.F4275352 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable [Resending as my previous message exceeded 120 KB and got blocked] =20 Thanks for everyone's inputs.. =20 Asymmetric bandwidth is typical for DSL links I think, where the downstream bandwidth is typically higher compared to the upstream bandwidth. So, while a user may want to receive HD quality video, the user may want send only SD quality video because of the upstream bandwidth constraints. =20 However, I agree that the problem of asymmetric codec negotiation is a more general O/A problem and needs to be solved more generically before applying it for specific codecs. =20 For G.723/G.729, the source of the interop issue is not asymmetric behavior. Instead, even when both ends want symmetric behavior, one end considers the Annex B (or Annex A) flavor of the codec as incompatible with the non-Annex B (or non-Annex A) flavor of the same codec, while the other end expects the least common denominator to be used. =20 Describing the symmetric behavior for these codecs unambiguously (which is what the draft tries to do) would help implementers achieve pragmatic end results I think. =20 Muthu =20 From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf Of David R Oran Sent: Thursday, March 08, 2012 7:34 PM To: Chhatwal, Harprit S Cc: payload@ietf.org Subject: Re: [payload] FW: I-D Action:draft-muthu-payload-offer-answer-g723-g729-00.txt =20 =20 On Mar 8, 2012, at 8:13 AM, Chhatwal, Harprit S wrote: I didn't fully understand your network. My guess is that in case of bandwidth constrained in one direction of the session, then the low-bandwidth codec has to be negotiated in that direction. ISTM, asymmetric annexb parameter negotiation is not going to solve the bandwidth issue. Please let me know how asymmetric annexb will solve bandwidth issue.=20 =20 Perhaps I have not explained this clearly enough previously, so allow me to try again. The bandwidth in the customer's network is sufficiently constrained in one direction that the customer wishes to use G.729/G.729A with G.729B active (ie using VAD/DTX) to allow the speech codec bandwidth requirements in this direction to fit within the network bandwidth envelope. In the other direction, the network bandwidth available is somewhat less constrained, so the customer would like to use G.729/G.729A without G.729B active to get slightly better quality. =20 Well, even if you've negotiated it, it doesn't mean you actually have to use it. If the endpoint is smart enough to know whether to negotiate it or not, I suspect it's smart enough to know not to bother using it when the bandwidth is sufficient. =20 Seems like a corner case, although the general problem of how to do asymmetric codec negotiation probably has more compelling use cases. However, even in this direction, the network bandwidth is still limited enough that a higher-rate codec such as G.711 will not work. =20 For the second part of your question, please see the earlier mails on this thread as this has been covered previously. =20 Regards. Harprit. =20 Harprit S. Chhatwal InnoMedia =20 On 8 March 2012 10:12, Ravindran, Parthasarathi wrote: Hi Harpit, =20 Sorry for the delay reply. =20 I didn't fully understand your network. My guess is that in case of bandwidth constrained in one direction of the session, then the low-bandwidth codec has to be negotiated in that direction. ISTM, asymmetric annexb parameter negotiation is not going to solve the bandwidth issue. Please let me know how asymmetric annexb will solve bandwidth issue. =20 AFAIK, answerer expectation of asymmetric annexb will leads to the interop issue in case of offerer mentions as "annexb=3Dno" but answerer mandates to have "annexb=3Dyes". Please let me know your opinion on the same. Thanks Partha From: Chhatwal, Harprit S [mailto:hschhatwal@gmail.com]=20 Sent: Thursday, March 01, 2012 4:59 PM To: Ravindran, Parthasarathi Cc: Paul Kyzivat; Kevin P. Fleming; payload@ietf.org Subject: Re: [payload] FW: I-D Action: draft-muthu-payload-offer-answer-g723-g729-00.txt =20 =20 On 1 March 2012 06:13, Ravindran, Parthasarathi wrote: I'm not very clear on the bandwidth optimization based on asymmetric annexb parameter negotiation. Could you please elaborate. =20 This is for a network where the bandwidth is severely constrained in one direction, so the operator wishes to use G.729B to minimise bandwidth usage in one direction, while not using G.729B in the other direction where bandwidth is less constrained. =20 Regards. Harprit. =20 Harprit S. Chhatwal InnoMedia =20 On 1 March 2012 06:13, Ravindran, Parthasarathi wrote: Hi Harpit, Thanks for looking into the draft. I agree with you that asymmetric annexb negotiation is not taken into the account in the draft currently. In fact, I come across the scenario wherein annexb is not supported by offerer ,mentioned in offer SDP as annexb=3Dno and answerer assumes = about annexb support (no annexb parameter in answer) in offerer side which leads to the call failure. I'm not very clear on the bandwidth optimization based on asymmetric annexb parameter negotiation. Could you please elaborate. Thanks Partha >-----Original Message----- >From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On >Behalf Of Paul Kyzivat >Sent: Wednesday, February 29, 2012 9:01 PM >To: Chhatwal, Harprit S >Cc: payload@ietf.org >Subject: Re: [payload] FW: I-D Action: draft-muthu-payload-offer-answer- >g723-g729-00.txt > >On 2/29/12 9:34 AM, Chhatwal, Harprit S wrote: >> On 28 February 2012 21:01, Kevin P. Fleming > > wrote: >> >> >> That requirement is counter to what the draft proposes. We can't >> have it both ways: either the G.729 'annexb' format parameter is a >> negotiated parameter (in which case its usage is symmetrical by >> definition) or it is a declarative parameter (in which case the >> usage can be, but is not required to be, asymmetrical). >> >> >> Yes, I concur that the draft (as it currently stands) cannot >> accommodate an asymmetric use of G.729B. However, if we agree that >> both scenarios are true, real-world scenarios that need addressing, ie >> (a) the negotiated case where the use of G.729B is symmetric and (b) >> the declarative case where the use of G.729B can be asymmetric (and, >> in my opinion, both are valid scenarios), then I would suggest that we >> need to come up with a way of handling both situations (perhaps >> through the use of an extra fmtp parameter indicating whether the use >> is declarative or negotiated - or any other suggestions the group >might have). >> >> If not, and we are only to allow the negotiated, symmetric use, then >> I'd appreciate any suggestions from the group for how my organisation >> might deal with the requirement of an asymmetric use of G.729B >mentioned below. > >There is one way that is available right now: > >Negotiate two separate one way m-lines. >But this might be too weird for common use. > > Thanks, > Paul > >> Regards. Harprit. >> >> ------_=_NextPart_001_01CD0814.F4275352 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

[Resending as my = previous message exceeded 120 KB and got = blocked]

 

Thanks for = everyone's inputs..

 

Asymmetric = bandwidth is typical for DSL links I think, where the downstream = bandwidth is typically higher compared to the upstream bandwidth. So, = while a user may want to receive HD quality video, the user may want = send only SD quality video because of the upstream bandwidth = constraints.

 

However, I agree = that the problem of asymmetric codec negotiation is a more general O/A = problem and needs to be solved more generically before applying it for = specific codecs.

 

For G.723/G.729, = the source of the interop issue is not asymmetric behavior. Instead, = even when both ends want symmetric behavior, one end considers the Annex = B (or Annex A) flavor of the codec as incompatible with the non-Annex B = (or non-Annex A) flavor of the same codec, while the other end expects = the least common denominator to be used.

 

Describing the = symmetric behavior for these codecs unambiguously (which is what the = draft tries to do) would help implementers achieve pragmatic end results = I think.

 

Muthu

 

From:= = payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf = Of David R Oran
Sent: Thursday, March 08, 2012 7:34 = PM
To: Chhatwal, Harprit S
Cc: = payload@ietf.org
Subject: Re: [payload] FW: I-D = Action:draft-muthu-payload-offer-answer-g723-g729-00.txt

 

 

On = Mar 8, 2012, at 8:13 AM, Chhatwal, Harprit S = wrote:



I didn’t fully understand your network. My guess is that  = in case of bandwidth constrained in one direction of the session, then = the low-bandwidth codec has to be negotiated in that direction. ISTM, = asymmetric annexb parameter negotiation is not going to solve the = bandwidth issue. Please let me know how asymmetric annexb will solve = bandwidth issue. 

 

Perhaps I have not explained this clearly enough = previously, so allow me to try again.  The bandwidth in the = customer's network is sufficiently constrained in one direction that the = customer wishes to use G.729/G.729A with G.729B active (ie using = VAD/DTX) to allow the speech codec bandwidth requirements in this = direction to fit within the network bandwidth envelope. In the other = direction, the network bandwidth available is somewhat less = constrained, so the customer would like to use G.729/G.729A without = G.729B active to get slightly better quality. =  

Well, even if you've = negotiated it, it doesn't mean you actually have to use it. If the = endpoint is smart enough to know whether to negotiate it or not, I = suspect it's smart enough to know not to bother using it when the = bandwidth is sufficient.

 

Seems like a corner case, although the general problem = of how to do asymmetric codec negotiation probably has more compelling = use cases.



However, even in this direction, the network bandwidth = is still limited enough that a higher-rate codec such as G.711 will = not work.

 

For the second part of your question, please see the = earlier mails on this thread as this has been covered = previously.

 

Regards.  Harprit.

 

Harprit S. Chhatwal

InnoMedia

 

On 8 March 2012 10:12, Ravindran, Parthasarathi <pravindran@sonusnet.com> = wrote:

Hi Harpit,

 

Sorry for the delay reply.

 

I didn’t fully understand your network. My guess is that  = in case of bandwidth constrained in one direction of the session, then = the low-bandwidth codec has to be negotiated in that direction. ISTM, = asymmetric annexb parameter negotiation is not going to solve the = bandwidth issue. Please let me know how asymmetric annexb will solve = bandwidth issue.

 

AFAIK, answerer expectation of asymmetric annexb will leads to the = interop issue in case of offerer mentions as “annexb=3Dno” = but answerer mandates to have “annexb=3Dyes”.  Please = let me know your opinion on the same.

Thanks
Partha

 From:= = Chhatwal, Harprit S [mailto:hschhatwal@gmail.com]
Sent: Thursday, = March 01, 2012 4:59 PM
To: Ravindran, = Parthasarathi
Cc: Paul Kyzivat; Kevin P. Fleming; payload@ietf.org


Subject: Re: [payload] FW: I-D Action: = draft-muthu-payload-offer-answer-g723-g729-00.txt

 

 <= /o:p>

On 1 March = 2012 06:13, Ravindran, Parthasarathi <pravindran@sonusnet.com> wrote:<= /p>

I'm not very = clear on the bandwidth optimization based on asymmetric annexb parameter = negotiation. Could you please elaborate.

 <= /o:p>

This is for = a network where the bandwidth is severely constrained in one direction, = so the operator wishes to use G.729B to minimise bandwidth usage in one = direction, while not using G.729B in the other direction where bandwidth = is less constrained.

 <= /o:p>

Regards. =  Harprit.

 <= /o:p>

Harprit S. = Chhatwal

InnoMedia

 <= /o:p>

On 1 March = 2012 06:13, Ravindran, Parthasarathi <pravindran@sonusnet.com> = wrote:

Hi = Harpit,

Thanks for looking into the draft. I agree with you that = asymmetric annexb negotiation is not taken into the account in the draft = currently. In fact, I come across the scenario wherein annexb is not = supported by offerer ,mentioned in offer SDP as annexb=3Dno and answerer = assumes about annexb support (no annexb parameter in answer) in offerer = side which leads to the call failure.

I'm not very clear on the = bandwidth optimization based on asymmetric annexb parameter negotiation. = Could you please = elaborate.

Thanks
Partha


>-----Original Message-----
>From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On
>Behalf Of Paul = Kyzivat
>Sent: Wednesday, February 29, 2012 9:01 PM
>To: = Chhatwal, Harprit S
>Cc: payload@ietf.org
>Subject: Re: [payload] FW: = I-D Action: = draft-muthu-payload-offer-answer-
>g723-g729-00.txt
>
>= On 2/29/12 9:34 AM, Chhatwal, Harprit S wrote:
>> On 28 = February 2012 21:01, Kevin P. Fleming <kpfleming@digium.com
>> <mailto:kpfleming@digium.com>> = wrote:
>>
>>
>>     That = requirement is counter to what the draft proposes. We can't
>> =     have it both ways: either the G.729 'annexb' format = parameter is a
>>     negotiated parameter (in which = case its usage is symmetrical by
>>     definition) = or it is a declarative parameter (in which case the
>>   =   usage can be, but is not required to be, = asymmetrical).
>>
>>
>> Yes, I concur that = the draft (as it currently stands) cannot
>> accommodate an = asymmetric use of G.729B.  However, if we agree that
>> = both scenarios are true, real-world scenarios that need addressing, = ie
>> (a) the negotiated case where the use of G.729B is = symmetric and (b)
>> the declarative case where the use of = G.729B can be asymmetric (and,
>> in my opinion, both are valid = scenarios), then I would suggest that we
>> need to come up = with a way of handling both situations (perhaps
>> through the = use of an extra fmtp parameter indicating whether the use
>> is = declarative or negotiated - or any other suggestions the = group
>might have).
>>
>> If not, and we are = only to allow the negotiated, symmetric use, then
>> I'd = appreciate any suggestions from the group for how my = organisation
>> might deal with the requirement of an = asymmetric use of G.729B
>mentioned below.
>
>There is = one way that is available right now:
>
>Negotiate two = separate one way m-lines.
>But this might be too weird for common = use.
>
>       Thanks,
>     =   Paul
>
>> Regards. =  Harprit.
>>
>>

------_=_NextPart_001_01CD0814.F4275352-- From tharper@logitech.com Thu Mar 22 09:20:43 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 541C921F8624 for ; Thu, 22 Mar 2012 09:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uviS3Y+hhEt8 for ; Thu, 22 Mar 2012 09:20:42 -0700 (PDT) Received: from na3sys009aog120.obsmtp.com (na3sys009aog120.obsmtp.com [74.125.149.140]) by ietfa.amsl.com (Postfix) with ESMTP id 0B3BA21F8638 for ; Thu, 22 Mar 2012 09:20:41 -0700 (PDT) Received: from mail-gx0-f171.google.com ([209.85.161.171]) (using TLSv1) by na3sys009aob120.postini.com ([74.125.148.12]) with SMTP ID DSNKT2tRWS3iYBZMwoCuM4LESyxfyDzDKiVF@postini.com; Thu, 22 Mar 2012 09:20:42 PDT Received: by mail-gx0-f171.google.com with SMTP id s5so3085176ggc.16 for ; Thu, 22 Mar 2012 09:20:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:subject :content-type:content-transfer-encoding:x-gm-message-state; bh=ZQmIXWjYydasEQiupfihue/5WQCG/O0K28Zfo6V2+WI=; b=SxCUXafVHDQVALeLK7HEQXJvY/M11d1tWaG0qu+whwwVG9qxfQVfQreV0rOc5jWi+R fR+tv378FPNth8y23q+rmRCNTVYM9f4Il8CDtWELLxHvstGEA3wTVs1K7gC0Zzp/cem4 ea6gsyGBQZItxbbS3yNSCWdDCwkqeOFJAWzItxil7p54TFSp3k2vU6Z/DbwJGfGh104x hYfKkl/FJwRCohDNril0WLPSAU2qNER3lGEaLzv7EeaTrlXnckFCNj7Vkg+OHqbFAm0h rGtgqSv8Nh/jTVKY99RCjKXA92OxbBBINiY/LU+iLd/HZoYVVc9uaZXlmpwAONfwzInD 9X5Q== Received: by 10.68.217.97 with SMTP id ox1mr21592763pbc.81.1332433240956; Thu, 22 Mar 2012 09:20:40 -0700 (PDT) Received: from [172.19.173.134] (c-76-126-8-251.hsd1.ca.comcast.net. [76.126.8.251]) by mx.google.com with ESMTPS id w10sm4078983pbb.20.2012.03.22.09.20.39 (version=SSLv3 cipher=OTHER); Thu, 22 Mar 2012 09:20:39 -0700 (PDT) Message-ID: <4F6B5150.9030709@logitech.com> Date: Thu, 22 Mar 2012 09:20:32 -0700 From: tom harper User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: payload@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmItytao9ojCeIQoKUeIf4LvtSlfmiFgnhpeSTpJEuHc5J9EK4JjkZr9oizDxNVnorDa+jG Subject: [payload] WGLC for draft-ietf-payload-vp8-03 ending March 1st X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: tharper@logitech.com List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 16:20:43 -0000 Hi to all, It looks like I am a little late to the party here. However, after implementing the current VP8 payload RFC, I would like to clarify some details regarding several of the bit fields in the rtp header before this is finalized. Also, I have one question about the current data layout choice. So first I want to discuss the current bit field usage intent. My main use case for vp8 over rtp would involve making occasional use of the alt-ref and golden frames as references, in a similar manner to how LTR frames can be used in h264. The method for determining if your frame actually references or updates a LTR in H264 is opaque and not addressed in rtp, but rather in the nalu header, and I was hoping that something similar could be avoided here such that it would be easier for a muxer/demuxer to know what sort of data is in the packet without having to delve too deeply into the specific codec. I am also wondering if my usage can coexist with the temporal layers technique currently used within chrome, as it appears very similar in many manners below the surface. So my first thought is that it should be possible to use TID & TL0PICIDX to signal if you are referencing an altref or golden frame- From the rfc, it states that I can set TID=0 and increment TL0PICIDX whenever I send a frame that updates alt/gld. Then when I reference an alt/gld, I would set TID = 0 and then just set the TLOPICIDX to the TL0PICIDX of the altref or golden frame id I am referencing. In my case I don't want to send TL0PICIDX with every base layer frame, only ones I care about referencing later. It isn't called out as required that I increment TL0PICIDX when TID it isn't sent, and for my use I would rather not send it all the time. If this usage will break something in terms of what it was intended to do it would be good to clarify this area more. Alternately, to support my use case, I could just avoid using TLOPICIDX altogether and just use the existence of the rotating KEYIDX when I have a frame that references a golden or altref. This method is not ideal because of lacking a reference Id, the two sides could theoretically be out of synch due to lost back channel messages. Second, the rules surrounding KEYIDX update are not identified with absolute certainty so my usage would theoretically be non-interoperable. It seems like I could just include it and increment it whenever I have a key frame or a frame that references a previous good frame, and not include it otherwise. This usage isn't explicit, so it seems that some clarification around KEYIDX usage would be good. The last point I was hoping to clarify was surrounding the header bit fields. Given the late date, I would guess that the fields are past the point of discussion, but I am wondering why the TID/Y fields weren't put into the RSV bit space? For temporal layering this would allow for the last octet to be skipped most of the time, as the current specification doesn't require that the KEYIDX always be sent. In the most recent chrome/rtc code I noted that KEYIDX was always set to 0, so it seems only beneficial to drop it. A RSV 3 bit space could just be moved to coexist with KEYIDX instead. Alternately, you could also increase the size of KEYIDX to make it more useful. It seems a minor point I guess but why send an extra byte all the time when it isn't needed? Proposal Data layout: +-+-+-+-+-+-+-+-+ |X|R|N|S|PartID | (REQUIRED) +-+-+-+-+-+-+-+-+ X: |I|L|T|K|TID|Y|R (OPTIONAL) +-+-+-+-+-+-+-+-+ I: | PictureID | (OPTIONAL) +-+-+-+-+-+-+-+-+ L: | TL0PICIDX | (OPTIONAL) +-+-+-+-+-+-+-+-+ K:RSV| KEYIDX | (OPTIONAL) +-+-+-+-+-+-+-+-+ Thanks for your consideration, Tom From pwestin@google.com Thu Mar 22 10:17:23 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88F8021F8607 for ; Thu, 22 Mar 2012 10:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.62 X-Spam-Level: X-Spam-Status: No, score=-102.62 tagged_above=-999 required=5 tests=[AWL=-0.243, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29XJDzXoPgau for ; Thu, 22 Mar 2012 10:17:23 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id C8C5221F863C for ; Thu, 22 Mar 2012 10:17:22 -0700 (PDT) Received: by yhkk25 with SMTP id k25so2175946yhk.31 for ; Thu, 22 Mar 2012 10:17:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=TB7xerHar95641PRTskhLmHzDybVFcTQfmjM56nQf9U=; b=LJ7R8DogRyJK+A5znt97OFc07PbxmLDOJBQTJMRd/NAduhkzRVJlj21c7B5vSwSUh0 GO21wouydt528RwzB9azRG/LqX9XAb5i5m/Qs1KsO64LkMYQEQ5KKNYqJrlkAM8hlv6D SvKL6/tq2d7WTZOKpofQSVKgN6DGs0Dyqfrqe/sHcCSooiykLCwgO3T3zIiXIvRe1mZh A19saHWCalcGVEejIlAgrGIuijDWQp7pNHWBz6wRP43+VI/K7lessiaOqvVTX4qZrJl9 6ukOw96x77qjQUudLhyrzDkuYFdSx5Di850vhQNdVCWuJLqhHiSRDpEZ8aVtwSDu3YXk Xw4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=TB7xerHar95641PRTskhLmHzDybVFcTQfmjM56nQf9U=; b=Q64n2N3wCUSM078Ej6ZN3AT8NHrYmyEIHNJqzfYNr9UrbY12U/qpbrw5JwQtJx9ufy Qz2SLQQSqtIxNwnVZSEt05GRACSiqMHOSs1QKOqk5KSx0KgLDD3IediT1JN+WIsa7kR+ dCOUj8egqbtEDGVfaIk8zbWinGsaKkapkuewzIlf4gFeqJCr4iDYfI7GvBdC4XzfTVFU jMw0URuGfbCYVnhF5gLQ26xE+d7Ajux0sFH3uY4qsmtM2LNY+CI/RJ6w6wPYTWG7anpp gW0UZhnQtZ/r+vBg7fZ5WZjh0H2RnpMNWKLJr8XRBw3SOD4qdnkXULQADC7CTFtgnuDR cTtg== Received: by 10.236.72.195 with SMTP id t43mr8633441yhd.126.1332436642446; Thu, 22 Mar 2012 10:17:22 -0700 (PDT) Received: by 10.236.72.195 with SMTP id t43mr8633428yhd.126.1332436642333; Thu, 22 Mar 2012 10:17:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.16.6 with HTTP; Thu, 22 Mar 2012 10:17:02 -0700 (PDT) In-Reply-To: <4F6B5150.9030709@logitech.com> References: <4F6B5150.9030709@logitech.com> From: Patrik Westin Date: Thu, 22 Mar 2012 18:17:02 +0100 Message-ID: To: tharper@logitech.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQmlpvXcY0U4QYqLZi07hY3vHi7Ve2PWyWKonW4J6hu+/NxB8sQirzR65v4MMjJ8cirL228t01hF937DACcq4fPUSLRQwL/nrbNXUvAjmVEEyu1Usby/n1emX86o4nkpmOkZQ7DO Cc: payload@ietf.org Subject: Re: [payload] WGLC for draft-ietf-payload-vp8-03 ending March 1st X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 17:17:23 -0000 I will contact you direct to better understand your use-case to see if I can help you. -patrik On Thu, Mar 22, 2012 at 5:20 PM, tom harper wrote: > Hi to all, > > It looks like I am a little late to the party here. =A0However, after > implementing the current VP8 payload RFC, =A0I would like to clarify some > details regarding several of the bit fields in the rtp header before this= is > finalized. =A0Also, I have one question about the current data layout cho= ice. > > So first I want to discuss the current bit field usage intent. > > My main use case for vp8 over rtp would involve making occasional use of = the > alt-ref and golden frames as references, in a similar manner to how LTR > frames can be used in h264. =A0The method for determining if your frame > actually references or updates a LTR in H264 is opaque and not addressed = in > rtp, but rather in the nalu header, and I was hoping that something simil= ar > could be avoided here such that it would be easier for a muxer/demuxer to > know what sort of data is in the packet without having to delve too deepl= y > into the specific codec. =A0I am also wondering if my usage can coexist w= ith > the temporal layers technique currently used within chrome, as it appears > very similar in many manners below the surface. > > So my first thought is that it should be possible to use TID & TL0PICIDX = to > signal if you are referencing an altref or golden frame- From the rfc, it > states that I can set TID=3D0 and increment TL0PICIDX =A0whenever I send = a frame > that updates alt/gld. =A0Then when I reference an alt/gld, I would set TI= D =3D 0 > and then just set the TLOPICIDX to the TL0PICIDX of the altref or golden > frame id I am referencing. =A0In my case I don't want to send TL0PICIDX = =A0with > every base layer frame, only ones I care about referencing later. =A0It i= sn't > called out as required that I increment TL0PICIDX when TID it isn't sent, > and for my use I would rather not send it all the time. =A0If this usage = will > break something in terms of what it was intended to do it would be good t= o > clarify this area more. > > Alternately, to support my use case, I could just avoid using TLOPICIDX > altogether and just use the existence of the rotating KEYIDX when I have = a > frame that references a golden or altref. =A0This method is not ideal bec= ause > of lacking a reference Id, the two sides could theoretically be out of sy= nch > due to lost back channel messages. =A0Second, the rules surrounding KEYID= X > update are not identified with absolute certainty so my usage would > theoretically be non-interoperable. =A0It seems like I could just include= it > and increment it whenever I have a key frame or a frame that references a > previous good frame, and not include it otherwise. =A0This usage isn't > explicit, so it seems that some clarification around KEYIDX usage would b= e > good. > > The last point I was hoping to clarify was surrounding the header bit > fields. =A0Given the late date, I would guess that the fields are past th= e > point of discussion, but I am wondering why the TID/Y fields weren't put > into the RSV bit space? For temporal layering this would allow for the la= st > octet to be skipped most of the time, as the current specification doesn'= t > require that the KEYIDX always be sent. =A0In the most recent chrome/rtc = code > I noted that KEYIDX was always set to 0, so it seems only beneficial to d= rop > it. =A0A RSV 3 bit space could just be moved to coexist with KEYIDX inste= ad. > Alternately, you could also increase the size of KEYIDX to make it more > useful. =A0It seems a minor point I guess but why send an extra byte all = the > time when it isn't needed? > > Proposal Data layout: > +-+-+-+-+-+-+-+-+ > |X|R|N|S|PartID | (REQUIRED) > +-+-+-+-+-+-+-+-+ > X: |I|L|T|K|TID|Y|R (OPTIONAL) > +-+-+-+-+-+-+-+-+ > I: | PictureID | (OPTIONAL) > +-+-+-+-+-+-+-+-+ > L: | TL0PICIDX | (OPTIONAL) > +-+-+-+-+-+-+-+-+ > K:RSV| =A0KEYIDX =A0 =A0 =A0 | (OPTIONAL) > +-+-+-+-+-+-+-+-+ > > Thanks for your consideration, > > Tom > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload From abegen@cisco.com Thu Mar 22 16:16:06 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88D5921F84D8 for ; Thu, 22 Mar 2012 16:16:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.145 X-Spam-Level: X-Spam-Status: No, score=-10.145 tagged_above=-999 required=5 tests=[AWL=-0.146, BAYES_00=-2.599, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NSOKtu3dmyRM for ; Thu, 22 Mar 2012 16:16:05 -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 A132B21F84D5 for ; Thu, 22 Mar 2012 16:16:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=5115; q=dns/txt; s=iport; t=1332458165; x=1333667765; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ZXOFX9AwSm/NiP+a99DEr8t2yOOzC0hd2Bjq3WFcDAk=; b=HlppRy9IVseux6tiZyiU8Z8/plE1d0BeYWnbhXrSnch5rGDDGyWEjMrH +p6m5ojthCUGlbk/zGiPgCMb4zUC9tA29+2pj6wTg2p/Ibs52Hgvbxe1V w9eDJQw2FawPT9u/v7SHWYJkaY682pkpIbtrB2qT7Y7x9iQdMtQP6Bu9p Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADKxa0+tJXG9/2dsb2JhbABEtz6BB4IJAQEBBAEBAQ8BWwsMBAIBCA4DBAEBAQodBycLFAkIAgQBDQUIGodoC5kWnwkEkAFjBKQfgWiCZ4FUBw X-IronPort-AV: E=Sophos;i="4.73,633,1325462400"; d="scan'208";a="68531664" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-1.cisco.com with ESMTP; 22 Mar 2012 23:16:05 +0000 Received: from xht-rcd-x02-p.cisco.com (xht-rcd-x02-p.cisco.com [173.37.178.213]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2MNG5oA022364; Thu, 22 Mar 2012 23:16:05 GMT Received: from xmb-rcd-x01-p.cisco.com ([169.254.3.120]) by xht-rcd-x02-p.cisco.com ([173.37.178.213]) with mapi id 14.02.0283.003; Thu, 22 Mar 2012 16:16:04 -0700 From: "Ali C. Begen (abegen)" To: Patrik Westin , "tharper@logitech.com" Thread-Topic: [payload] WGLC for draft-ietf-payload-vp8-03 ending March 1st Thread-Index: AQHNCE+qVVLfdqJGs0KzalBmkXNJZ5Z28rdQ Date: Thu, 22 Mar 2012 23:16:04 +0000 Message-ID: References: <4F6B5150.9030709@logitech.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.37.178.200] x-tm-as-product-ver: SMEX-10.0.0.4211-6.800.1017-18790.000 x-tm-as-result: No--64.144600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "payload@ietf.org" Subject: Re: [payload] WGLC for draft-ietf-payload-vp8-03 ending March 1st X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 23:16:06 -0000 Please keep the list up to date about the developments and changes you are = planning to make if any. -acbegen > -----Original Message----- > From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behal= f Of Patrik Westin > Sent: Friday, March 23, 2012 4:17 AM > To: tharper@logitech.com > Cc: payload@ietf.org > Subject: Re: [payload] WGLC for draft-ietf-payload-vp8-03 ending March 1s= t >=20 > I will contact you direct to better understand your use-case to see if > I can help you. >=20 > -patrik >=20 > On Thu, Mar 22, 2012 at 5:20 PM, tom harper wrote: > > Hi to all, > > > > It looks like I am a little late to the party here. =A0However, after > > implementing the current VP8 payload RFC, =A0I would like to clarify so= me > > details regarding several of the bit fields in the rtp header before th= is is > > finalized. =A0Also, I have one question about the current data layout c= hoice. > > > > So first I want to discuss the current bit field usage intent. > > > > My main use case for vp8 over rtp would involve making occasional use o= f the > > alt-ref and golden frames as references, in a similar manner to how LTR > > frames can be used in h264. =A0The method for determining if your frame > > actually references or updates a LTR in H264 is opaque and not addresse= d in > > rtp, but rather in the nalu header, and I was hoping that something sim= ilar > > could be avoided here such that it would be easier for a muxer/demuxer = to > > know what sort of data is in the packet without having to delve too dee= ply > > into the specific codec. =A0I am also wondering if my usage can coexist= with > > the temporal layers technique currently used within chrome, as it appea= rs > > very similar in many manners below the surface. > > > > So my first thought is that it should be possible to use TID & TL0PICID= X to > > signal if you are referencing an altref or golden frame- From the rfc, = it > > states that I can set TID=3D0 and increment TL0PICIDX =A0whenever I sen= d a frame > > that updates alt/gld. =A0Then when I reference an alt/gld, I would set = TID =3D 0 > > and then just set the TLOPICIDX to the TL0PICIDX of the altref or golde= n > > frame id I am referencing. =A0In my case I don't want to send TL0PICIDX= =A0with > > every base layer frame, only ones I care about referencing later. =A0It= isn't > > called out as required that I increment TL0PICIDX when TID it isn't sen= t, > > and for my use I would rather not send it all the time. =A0If this usag= e will > > break something in terms of what it was intended to do it would be good= to > > clarify this area more. > > > > Alternately, to support my use case, I could just avoid using TLOPICIDX > > altogether and just use the existence of the rotating KEYIDX when I hav= e a > > frame that references a golden or altref. =A0This method is not ideal b= ecause > > of lacking a reference Id, the two sides could theoretically be out of = synch > > due to lost back channel messages. =A0Second, the rules surrounding KEY= IDX > > update are not identified with absolute certainty so my usage would > > theoretically be non-interoperable. =A0It seems like I could just inclu= de it > > and increment it whenever I have a key frame or a frame that references= a > > previous good frame, and not include it otherwise. =A0This usage isn't > > explicit, so it seems that some clarification around KEYIDX usage would= be > > good. > > > > The last point I was hoping to clarify was surrounding the header bit > > fields. =A0Given the late date, I would guess that the fields are past = the > > point of discussion, but I am wondering why the TID/Y fields weren't pu= t > > into the RSV bit space? For temporal layering this would allow for the = last > > octet to be skipped most of the time, as the current specification does= n't > > require that the KEYIDX always be sent. =A0In the most recent chrome/rt= c code > > I noted that KEYIDX was always set to 0, so it seems only beneficial to= drop > > it. =A0A RSV 3 bit space could just be moved to coexist with KEYIDX ins= tead. > > Alternately, you could also increase the size of KEYIDX to make it more > > useful. =A0It seems a minor point I guess but why send an extra byte al= l the > > time when it isn't needed? > > > > Proposal Data layout: > > +-+-+-+-+-+-+-+-+ > > |X|R|N|S|PartID | (REQUIRED) > > +-+-+-+-+-+-+-+-+ > > X: |I|L|T|K|TID|Y|R (OPTIONAL) > > +-+-+-+-+-+-+-+-+ > > I: | PictureID | (OPTIONAL) > > +-+-+-+-+-+-+-+-+ > > L: | TL0PICIDX | (OPTIONAL) > > +-+-+-+-+-+-+-+-+ > > K:RSV| =A0KEYIDX =A0 =A0 =A0 | (OPTIONAL) > > +-+-+-+-+-+-+-+-+ > > > > Thanks for your consideration, > > > > Tom > > _______________________________________________ > > payload mailing list > > payload@ietf.org > > https://www.ietf.org/mailman/listinfo/payload > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload From internet-drafts@ietf.org Mon Mar 26 05:32:17 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8348B21F8650; Mon, 26 Mar 2012 05:32:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NLDUD7ZxSe+z; Mon, 26 Mar 2012 05:32:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DC5A21F8645; Mon, 26 Mar 2012 05:32:17 -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: 4.00 Message-ID: <20120326123217.20076.58008.idtracker@ietfa.amsl.com> Date: Mon, 26 Mar 2012 05:32:17 -0700 Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-vp8-04.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 12:32:17 -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 Payloads Workin= g Group of the IETF. Title : RTP Payload Format for VP8 Video Author(s) : Patrik Westin Henrik F Lundin Michael Glover Justin Uberti Frank Galligan Filename : draft-ietf-payload-vp8-04.txt Pages : 28 Date : 2012-03-26 This memo describes an RTP payload format for the VP8 video codec. The payload format has wide applicability, as it supports applications from low bit-rate peer-to-peer usage, to high bit-rate video conferences. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-payload-vp8-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-payload-vp8-04.txt From stewe@stewe.org Mon Mar 26 08:51:18 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ECB621E80A3 for ; Mon, 26 Mar 2012 08:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.224 X-Spam-Level: X-Spam-Status: No, score=-5.224 tagged_above=-999 required=5 tests=[AWL=1.375, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0kuK1JGLvxv7 for ; Mon, 26 Mar 2012 08:51:17 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by ietfa.amsl.com (Postfix) with ESMTP id 1294C21F8613 for ; Mon, 26 Mar 2012 08:51:13 -0700 (PDT) Received: from mail167-tx2-R.bigfish.com (10.9.14.251) by TX2EHSOBE001.bigfish.com (10.9.40.21) with Microsoft SMTP Server id 14.1.225.23; Mon, 26 Mar 2012 15:51:00 +0000 Received: from mail167-tx2 (localhost [127.0.0.1]) by mail167-tx2-R.bigfish.com (Postfix) with ESMTP id 57F5D120501; Mon, 26 Mar 2012 15:51:00 +0000 (UTC) X-SpamScore: -37 X-BigFish: PS-37(zz936eK1432N98dK14ffO4015Izz1202h1082kzz1033IL8275dhz2fh2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:157.56.240.133; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0710HT004.namprd07.prod.outlook.com; RD:none; EFVD:NLI Received-SPF: pass (mail167-tx2: domain of stewe.org designates 157.56.240.133 as permitted sender) client-ip=157.56.240.133; envelope-from=stewe@stewe.org; helo=BL2PRD0710HT004.namprd07.prod.outlook.com ; .outlook.com ; Received: from mail167-tx2 (localhost.localdomain [127.0.0.1]) by mail167-tx2 (MessageSwitch) id 1332777058153132_1238; Mon, 26 Mar 2012 15:50:58 +0000 (UTC) Received: from TX2EHSMHS025.bigfish.com (unknown [10.9.14.247]) by mail167-tx2.bigfish.com (Postfix) with ESMTP id 155691A004C; Mon, 26 Mar 2012 15:50:58 +0000 (UTC) Received: from BL2PRD0710HT004.namprd07.prod.outlook.com (157.56.240.133) by TX2EHSMHS025.bigfish.com (10.9.99.125) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 26 Mar 2012 15:50:56 +0000 Received: from BL2PRD0710MB349.namprd07.prod.outlook.com ([169.254.2.108]) by BL2PRD0710HT004.namprd07.prod.outlook.com ([10.255.102.39]) with mapi id 14.16.0135.002; Mon, 26 Mar 2012 15:51:08 +0000 From: Stephan Wenger To: "payload@ietf.org" Thread-Topic: [payload] I-D Action: draft-ietf-payload-vp8-04.txt Thread-Index: AQHNC0x+9WKb3w+1Hk20qx8i6TyLv5Z87DSA Date: Mon, 26 Mar 2012 15:51:08 +0000 Message-ID: In-Reply-To: <20120326123217.20076.58008.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.102.5] Content-Type: text/plain; charset="us-ascii" Content-ID: <8605F3C132CDF34D81DCE23ECED0901A@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: stewe.org Subject: Re: [payload] I-D Action: draft-ietf-payload-vp8-04.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 15:51:18 -0000 Hi all, I had a chat with Harald on the subject of "level" negotiation for VP8. Harald pointed me to RFC 6236, which goes a long way in alleviating my concerns about the lack of a mechanism that limits the decoding complexity of an VP8 bitstream. Here is what I think should be sufficient (subject to wordsmithing): 1. In section 6, add the "note" Patrick was talking about. "Note: Parameters for picture size and frame rate are not included herein, and are expected to be negotiated using, for example, RFC 6232 for the (maximum) picture size and RFC xxxx for the maximum framerate." 2. The example in 6.2.1.1 would benefit from the inclusion of an RFC 6236 codepoint. 3. This is the important change. The O/A section 6.2.2 needs to be updated indicating that a system design using O/A MUST include at least one x=3D and at least one y=3D parameter according to RFC 6236, and MUST al= so limit the framerate (I don't recall off the top of my head how). A normative reference to 6236 needs to be included. Finally, let me suggest you split the references into normative and informative soon. Thanks, Stephan On 3.26.2012 14:32 , "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 >Payloads Working Group of the IETF. > > Title : RTP Payload Format for VP8 Video > Author(s) : Patrik Westin > Henrik F Lundin > Michael Glover > Justin Uberti > Frank Galligan > Filename : draft-ietf-payload-vp8-04.txt > Pages : 28 > Date : 2012-03-26 > > This memo describes an RTP payload format for the VP8 video codec. > The payload format has wide applicability, as it supports > applications from low bit-rate peer-to-peer usage, to high bit-rate > video conferences. > > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-payload-vp8-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-payload-vp8-04.txt > >_______________________________________________ >payload mailing list >payload@ietf.org >https://www.ietf.org/mailman/listinfo/payload > From abegen@cisco.com Tue Mar 27 00:53:28 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8870B21F87B0 for ; Tue, 27 Mar 2012 00:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.446 X-Spam-Level: X-Spam-Status: No, score=-10.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0QX-r+uKs7yR for ; Tue, 27 Mar 2012 00:53:27 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB5C21F877C for ; Tue, 27 Mar 2012 00:53:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=3312; q=dns/txt; s=iport; t=1332834807; x=1334044407; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Fslr1Z7wBTO8v0Nm71b7kJxd2VzOvMXAIerLe/5Sl1I=; b=lQIVE8Rq5EBhRJY2CSdQa/mMB9eF44DFC7IlmXnwm9YGaFgoZiEjcrVo KjD9NTBvRJDSylVeuGWuM/d/8Qrjyz4eW9+Q5hehdt6D75HI50RstOIZD L0u7spHMoLKs2/SkkKbOhQJeuDk+zgcwsPt3iPi3ivHtIYajG5xtDj0UG g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHJxcU+rRDoJ/2dsb2JhbABCuFGBB4IJAQEBBAEBAQ8BVQYXBAIBCA4DBAEBAQodBycLFAkIAgQBEggBGYdnAQuedZcyimOFSWMEpCaBaIJngVU X-IronPort-AV: E=Sophos;i="4.73,656,1325462400"; d="scan'208";a="35238487" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 27 Mar 2012 07:53:27 +0000 Received: from xht-rcd-x02-p.cisco.com (xht-rcd-x02-p.cisco.com [173.37.178.213]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2R7rQ94029932; Tue, 27 Mar 2012 07:53:26 GMT Received: from xmb-rcd-x01-p.cisco.com ([169.254.3.120]) by xht-rcd-x02-p.cisco.com ([173.37.178.213]) with mapi id 14.02.0283.003; Tue, 27 Mar 2012 00:53:26 -0700 From: "Ali C. Begen (abegen)" To: Stephan Wenger , "payload@ietf.org" Thread-Topic: [payload] I-D Action: draft-ietf-payload-vp8-04.txt Thread-Index: AQHNC0x9ykC8AhM3eUq3txMQqn/vRJZ9L0QAgACXM2A= Date: Tue, 27 Mar 2012 07:53:25 +0000 Message-ID: References: <20120326123217.20076.58008.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.37.178.200] x-tm-as-product-ver: SMEX-10.0.0.4211-6.800.1017-18800.005 x-tm-as-result: No--46.008500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [payload] I-D Action: draft-ietf-payload-vp8-04.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 07:53:28 -0000 Thanks Stephan. Given that there is still some work that needs to be done, I will ask the a= uthors to address these and other existing comments. I will restart the WGL= C after the outstanding issues are addressed. -acbegen > -----Original Message----- > From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behal= f Of Stephan Wenger > Sent: Monday, March 26, 2012 5:51 PM > To: payload@ietf.org > Subject: Re: [payload] I-D Action: draft-ietf-payload-vp8-04.txt >=20 > Hi all, >=20 > I had a chat with Harald on the subject of "level" negotiation for VP8. > Harald pointed me to RFC 6236, which goes a long way in alleviating my > concerns about the lack of a mechanism that limits the decoding complexit= y > of an VP8 bitstream. >=20 > Here is what I think should be sufficient (subject to wordsmithing): >=20 > 1. In section 6, add the "note" Patrick was talking about. "Note: > Parameters for picture size and frame rate are not included herein, and > are expected to be negotiated using, for example, RFC 6232 for the > (maximum) picture size and RFC xxxx for the maximum framerate." >=20 > 2. The example in 6.2.1.1 would benefit from the inclusion of an RFC 6236 > codepoint. >=20 > 3. This is the important change. The O/A section 6.2.2 needs to be > updated indicating that a system design using O/A MUST include at least > one x=3D and at least one y=3D parameter according to RFC 6236, and MUST = also > limit the framerate (I don't recall off the top of my head how). A > normative reference to 6236 needs to be included. >=20 > Finally, let me suggest you split the references into normative and > informative soon. >=20 > Thanks, > Stephan >=20 >=20 > On 3.26.2012 14:32 , "internet-drafts@ietf.org" > wrote: >=20 > > > >A New Internet-Draft is available from the on-line Internet-Drafts > >directories. This draft is a work item of the Audio/Video Transport > >Payloads Working Group of the IETF. > > > > Title : RTP Payload Format for VP8 Video > > Author(s) : Patrik Westin > > Henrik F Lundin > > Michael Glover > > Justin Uberti > > Frank Galligan > > Filename : draft-ietf-payload-vp8-04.txt > > Pages : 28 > > Date : 2012-03-26 > > > > This memo describes an RTP payload format for the VP8 video codec. > > The payload format has wide applicability, as it supports > > applications from low bit-rate peer-to-peer usage, to high bit-rate > > video conferences. > > > > > >A URL for this Internet-Draft is: > >http://www.ietf.org/internet-drafts/draft-ietf-payload-vp8-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-payload-vp8-04.txt > > > >_______________________________________________ > >payload mailing list > >payload@ietf.org > >https://www.ietf.org/mailman/listinfo/payload > > >=20 >=20 > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload From simon@josefsson.org Wed Mar 21 11:59:59 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B190821F8564; Wed, 21 Mar 2012 11:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.9 X-Spam-Level: X-Spam-Status: No, score=-102.9 tagged_above=-999 required=5 tests=[AWL=-0.991, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id On8Y+BGwvQxg; Wed, 21 Mar 2012 11:59:59 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id D34DD21F8555; Wed, 21 Mar 2012 11:59:57 -0700 (PDT) Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q2LIxDpc006028 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 21 Mar 2012 19:59:14 +0100 From: Simon Josefsson To: Stephan Wenger References: OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120321:stewe@stewe.org::Vzbh9oFczpoonGjO:JlV X-Hashcash: 1:22:120321:iesg@ietf.org::1t4rL2u8gTq2lgYm:2+Gr X-Hashcash: 1:22:120321:ipr@ietf.org::25ffxsWrf5VX2wtv:A4+6 X-Hashcash: 1:22:120321:barryleiba@computer.org::1OqKn1j+wkJ0m70i:G+/I X-Hashcash: 1:22:120321:payload@ietf.org::e5Jf6SPh3OYwi0qT:ZhLs X-Hashcash: 1:22:120321:avt@ietf.org::xxWzSK0ZStnqfbZt:qVwu X-Hashcash: 1:22:120321:ietf@ietf.org::wz6szIOpPs/uFY/j:sE4R Date: Wed, 21 Mar 2012 19:59:13 +0100 In-Reply-To: (Stephan Wenger's message of "Wed, 21 Mar 2012 18:09:09 +0000") Message-ID: <87wr6dye4e.fsf@latte.josefsson.org> User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/24.0.94 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean X-Mailman-Approved-At: Tue, 27 Mar 2012 08:00:56 -0700 Cc: "ipr@ietf.org" , "avt@ietf.org" , "payload@ietf.org" , "iesg@ietf.org" , Barry Leiba , IETF Subject: Re: [payload] [AVTCORE] IPR requirements in document write-up X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 18:59:59 -0000 Stephan Wenger writes: > (1) Are you aware of any IPR that applies to ? > (2) If so, > has this IPR been disclosed in compliance with IETF IPR rules (see RFCs > 3979, > 4879, 3669 and 5378 for more details)? > > > For the majority of the documents I am working on, the answer to question > (1) would be yes. The answer to question (2) would be quite often no. > > Based on my interpretation of the policy RFCs, I am in full compliance > with language and spirit of the policy. I'm not doing anything fishy. I > just don't talk about third party IPR, which is my right under the IETF's > IPR policy. RFC 3669 section 5.7: https://tools.ietf.org/html/rfc3669#section-5.7 says for example It is good to notify the IETF of relevant IPR claims even when they are not one's own, and [6] says to do so "as soon as possible". My interpretation has always been that partcipants are strongly encouraged to notify about third party patents. Withholding such information seems contrary to the spirit even if not the letter of the guidelines. There are additional advice given here: https://tools.ietf.org/html/rfc3669#section-5.7.1 /Simon