From hhhansen@MAYAH.com Wed Feb 1 04:02: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 C2B7321F8692 for ; Wed, 1 Feb 2012 04:02:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.389 X-Spam-Level: X-Spam-Status: No, score=-0.389 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] 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 QoMEU5tBFISQ for ; Wed, 1 Feb 2012 04:02:11 -0800 (PST) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.29.28]) by ietfa.amsl.com (Postfix) with ESMTP id 0CFC121F859E for ; Wed, 1 Feb 2012 04:02:10 -0800 (PST) Received: from [217.91.215.225] (helo=mayah-sbs.MAYAH.COM) by smtprelay03.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1RsYt6-00082O-Lo for payload@ietf.org; Wed, 01 Feb 2012 13:02:08 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCE0D9.51D8D00F" Date: Wed, 1 Feb 2012 13:02:07 +0100 Message-ID: <031C6AD0F5FEAB449C77DF4E9D047A5C403E03@mayah-sbs.mayah.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Mail regarding draft-rea-payload-rtp-aptx Thread-Index: AczgdAEVTIKb+LsfTjuTY3cJ3FXTaw== From: "Hans-Heinrich Hansen" To: X-Df-Sender: MzI2MjQx Subject: Re: [payload] draft-rea-payload-rtp-aptx-01 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, 01 Feb 2012 12:02:11 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCE0D9.51D8D00F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello aptX group, MAYAH have already implemented a different version of "RTP Payload = Format for Standard apt-X and Enhanced apt-X Codecs", but we support = this new RFC draft and will adapt our firmware asap! I think that two types of = Standard apt-X modes are available: "with sync" and "without sync". How = these modes will be signalled or could one type ignored? Best regards, Hans-Heinrich Hansen Dipl.-Ing., Senior Development Engineer MAYAH Communications GmbH Lise-Meitner-Strasse 2 24941 Flensburg, Germany =20 ------_=_NextPart_001_01CCE0D9.51D8D00F Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello aptX = group,

MAYAH have already=20 implemented a different=20 version of "RTP Payload Format = for Standard=20 apt-X and Enhanced apt-X Codecs", but we=20 support this new RFC draft and=20 will adapt our firmware asap!

I think that two types of Standard apt-X = modes are=20 available: "with sync" and "without sync". How these modes will be=20 signalled or could one type=20 ignored?

Best regards,
Hans-Heinrich=20 Hansen
Dipl.-Ing., Senior Development Engineer

MAYAH Communications GmbH
Lise-Meitner-Strasse 2
24941 = Flensburg,=20 Germany

 
------_=_NextPart_001_01CCE0D9.51D8D00F-- From internet-drafts@ietf.org Wed Feb 1 11:56:21 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 2940111E80E4; Wed, 1 Feb 2012 11:56:21 -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=[AWL=0.000, 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 kG-lstEPdSub; Wed, 1 Feb 2012 11:56:20 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC7A211E80BE; Wed, 1 Feb 2012 11:56:20 -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: 3.64p1 Message-ID: <20120201195620.22288.98724.idtracker@ietfa.amsl.com> Date: Wed, 01 Feb 2012 11:56:20 -0800 Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-rtp-klv-03.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: Wed, 01 Feb 2012 19:56:21 -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-03.txt Pages : 12 Date : 2012-02-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-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-payload-rtp-klv-03.txt From quaix@digigram.com Thu Feb 2 07:01: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 CC4DB21F85AF for ; Thu, 2 Feb 2012 07:01:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.487 X-Spam-Level: X-Spam-Status: No, score=-1.487 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, 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 UveCugLnf47x for ; Thu, 2 Feb 2012 07:01:13 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF1521F8526 for ; Thu, 2 Feb 2012 07:01:02 -0800 (PST) Received: by qafi29 with SMTP id i29so28856qaf.10 for ; Thu, 02 Feb 2012 07:01:01 -0800 (PST) Received: by 10.224.116.201 with SMTP id n9mr4464290qaq.16.1328194861641; Thu, 02 Feb 2012 07:01:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.32.2 with HTTP; Thu, 2 Feb 2012 07:00:21 -0800 (PST) From: Michel Quaix Date: Thu, 2 Feb 2012 16:00:21 +0100 Message-ID: To: payload@ietf.org Content-Type: multipart/alternative; boundary=20cf3074b64aebafbf04b7fc7643 Subject: [payload] draft-rea-payload-rtp-aptx-01 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, 02 Feb 2012 15:01:14 -0000 --20cf3074b64aebafbf04b7fc7643 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello, This is Michel Quaix from Digigram. Here are the comments from Digigram: - At the end of paragraph 3, you wrote "The bit rate of the auxiliary data channel is 1/4 of the sample frequency." which is 12kbps @ 48kHz. Then you give an example @ 48kHz in which the auxiliary data bit rate is 16kbps (8 bits every 24 left channel samples @ 48kHz =3D 16kbps). - In paragraph 6, LSB is defined as the Most Significant Byte instead of being defined as the Least Significant Byte. Except for these minor issues, we have implemented this draft, it works and therefore we support the approval of the draft as an RFC. Best Regards, Michel QUAIX *Software Development Manager* *Phone: 33 (0)4 76 52 47 47 Fax: 33 (0)4 76 52 18 44 mailto: **quaix@digigram.com* *http://www.digigram.com* *Digigram** *** *INOVALLEE, **82/84 All=E9e Galil=E9e** **38330 MONTBONNOT-SAINT-MARTIN** * *FRANCE* --20cf3074b64aebafbf04b7fc7643 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hello,


This is Michel Quaix from Digigram.
Here are the comments from Digigram:
- At the end of paragraph 3, you wrote "The bit rate=A0of the auxiliary data channel is 1= /4 of the sample frequency." which is 12kbps @ 48kHz. Then you give an= example @ 48kHz in which the auxiliary data bit rate is 16kbps (8 bits eve= ry 24 left channel samples @ 48kHz =3D 16kbps).
- In paragraph 6, LSB is defined as the Most Sign= ificant Byte instead of being defined as the Least Significant Byte.=

Except for these minor issues, we have implemente= d this draft, it works and therefore we support the approval of the draft a= s an RFC.

Best=20 Regards,

Michel=20 QUAIX
= Software Development Manager

Phone:=20 33 (0)4 76 52 47 47
Fax: 33 (0)4 76 52 18= 44
mailto:=20 quaix@digigram.com=
= http://www.digigram.com

Digigram

INOVALLEE,=20 82/84=20 All=E9e Galil=E9e=20
38330=20 MONTBONNOT-SAINT-MARTIN

FRANCE


--20cf3074b64aebafbf04b7fc7643-- From kari.maenpaa@yle.fi Thu Feb 2 10:51: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 33A9921F85FC for ; Thu, 2 Feb 2012 10:51:13 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Header field occurs more than once: "MIME-Version" occurs 3 times X-Spam-Flag: NO X-Spam-Score: -0.781 X-Spam-Level: X-Spam-Status: No, score=-0.781 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, DC_IMAGE_SPAM_HTML=0.001, DC_IMAGE_SPAM_TEXT=0.001, DC_PNG_UNO_LARGO=0.558, HTML_IMAGE_ONLY_12=2.46, HTML_IMAGE_RATIO_02=0.383, HTML_MESSAGE=0.001, 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 KCuPaa3DR-aC for ; Thu, 2 Feb 2012 10:51:12 -0800 (PST) Received: from ns.yle.fi (ns.yle.fi [193.65.105.161]) by ietfa.amsl.com (Postfix) with ESMTP id 138D221F85EF for ; Thu, 2 Feb 2012 10:51:11 -0800 (PST) Received: from yle.fi (thaxpau.yle.fi [193.65.107.6]) by ns-fw1.yle.fi with ESMTP id q12IpAQa026129 for ; Thu, 2 Feb 2012 20:51:10 +0200 (EET) Received: from ylehkim1.yle.fi (ylehkim1.yle.fi [172.27.102.8]) by yle.fi (8.13.8/8.13.8) with ESMTP id q12Ip8ju010490 for ; Thu, 2 Feb 2012 20:51:08 +0200 In-Reply-To: Message-ID: <624219B0-720E-44CC-9390-7C823669DE11@yle.fi> Date: Thu, 2 Feb 2012 20:51:07 +0200 To: "payload@ietf.org" From: kari.maenpaa@yle.fi MIME-Version: 1.0 X-MIMETrack: Itemize by Notes Server on YLETRA01/YLE_EXT(Release 8.5.3|September 15, 2011) at 02.02.2012 20:51:06, Serialize by Router on YLEHKIM1/YLE(Release 8.5.3|September 15, 2011) at 02.02.2012 20:51:10 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=Apple-Mail-8553AAB1-BA13-48E4-8463-ED75B513B5D8 Subject: [payload] draft-rea-payload-rtp-aptx-01 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, 02 Feb 2012 18:54:10 -0000 --Apple-Mail-8553AAB1-BA13-48E4-8463-ED75B513B5D8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > L=C3=A4hett=C3=A4j=C3=A4: "Kari M=C3=A4enp=C3=A4=C3=A4" > P=C3=A4iv=C3=A4ys: 1. helmikuuta 2012 10.37.41 UTC+2.00 > Vastaanottaja: payload@ietf.org > Aihe: [payload] draft-rea-payload-rtp-aptx-01 >=20 > Page 11 on txt - version; >=20 > Should LSB be different from MSB ? >=20 >=20 > bw > Kari > Kari M=C3=A4enp=C3=A4=C3=A4 > Production Systems Architect > Production Platforms > +358 - (0)9 - 1480 2567 > +358 - (0)40 - 869 1121 >=20 >=20 > Yleisradio Oy > Finnish Broadcasting Company > P.O Box 66 > 00024 Yleisradio > Helsinki, Finland. = --Apple-Mail-8553AAB1-BA13-48E4-8463-ED75B513B5D8 Content-Type: multipart/related; type="text/html"; boundary=Apple-Mail-EC74279A-4DF5-4220-92C1-0160A05C34D0 --Apple-Mail-EC74279A-4DF5-4220-92C1-0160A05C34D0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


<= /div>
L=C3=A4hett=C3=A4j=C3=A4: "Kari = M=C3=A4enp=C3=A4=C3=A4" <kari.mae= npaa@yle.fi>
P=C3=A4iv=C3=A4ys: 1. helmikuuta 2012 10.37.4= 1 UTC+2.00
Vastaanottaja: pay= load@ietf.org
Aihe: [payload] draft-rea-payload-rtp-aptx-0= 1

Page 11 on txt - version;

Sh= ould LSB be different from MSB ?


bw
KariKari M=C3=A4enp=C3=A4=C3=A4
Production Systems Architect
Production = Platforms
+358 - (0)9 - 1480 2567
+358 - (0)40 - 869 1121


= Yleisradio Oy
Finnish Broadcasting Company
P.O Box 66
00024 Yleisr= adio
Helsinki, Finland.
= = --Apple-Mail-EC74279A-4DF5-4220-92C1-0160A05C34D0 Content-Type: image/png; name="Kuvankaappaus 2012-2-1 kello 10.40.40.png" Content-Disposition: inline; filename="Kuvankaappaus 2012-2-1 kello 10.40.40.png" Content-Id: <7A6EBEC7-5655-4EE1-B909-2807FEE346E0> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAecAAAGsCAYAAADnkm/7AAAKh2lDQ1BJQ0MgUHJvZmlsZQAAeAGt lndUU0kbxufe9EZJAtIJvSOdANJr6L3ZCAkdQgwdrMjiCq4FERFQlrIgouCqFFkrFmyLgAULuiCL grIuFkRFzd6ED3bP+b7975ucmfnNc99578zcyTkPAGQmm89PhaUASONlCoI9XRiRUdEM3AiAABpQ AR2YsTkZfOfAQF/wr+XDfSQaKXeMRLn+Nex/P5DmxmVwAIACkcex3AxOGsKnkMrg8AWZAMB3EV0z J5Mv4o8I0wXIAgFAkUWcsMAMEccusIU4JjTYFYnxAgBPZrMFCQCQQhGdkc1JQPKQkApMeNwkHsKN CDtwEtlchH9H2DAtLR1hMnIiQDf2H3kS/sFsduxSTjY7YYkX9oLMRF7slpTBT2XniQf/zyYtNQs5 L3GRRVoyP9MlGOnxyJnJJWWyRPsUc2KWV9gi5yeGRiwyL9Y/YJE5Ga7IWS7Ep6T7LOXhxrm5L+oZ 2SFLnJ/o6r+oJ7O9Rd9M/C62AKH/MD8zcGkNvFR/0b0Rx8QLPJbyx2W4hyzqmYLQJT0+yYO1qPNT xXdOPFeQFby0lzhe2NJcLtvNZzEemAEL5GeSGZcr+r7ANZ2fJ0hKSMxkOCO3Ms6QweJxjA0ZZiam ZkB0x0UxALy7Lb67kJzo+jDEEmAbAGCxAjnPgr+1dFMAzqQDIMn7W9POR8bIunrdOFmC7IW5aFGH AUQgifx35IEK0AC6wAhZmxWwA07AHXiDABAKosAawAGJIA0IQA5YD7aAYlAKdoN9oArUggZwGBwD J0AXOAMugqvgJhgA98BjMAomwCswAz6AeQiCcBAFokHykCqkBRlAZhATcoDcIV8oGIqCYqAEiAdl QeuhrVApVAZVQXVQC/QzdBq6CF2HBqGH0Bg0Bb2FPsMomAzTYWVYG14OM2Fn2AcOhVfDCfA6OB8u gnfClXA9fBTuhC/CN+F78Cj8Cp5FARQJJYtSQxmhmChXVAAqGhWPEqA2okpQFah6VBuqB9WHuoMa RU2jPqGxaBqagTZC26G90GFoDnodeiN6B7oKfRjdib6MvoMeQ8+gv2EoGCWMAcYWw8JEYhIwOZhi TAWmCdOBuYK5h5nAfMBisbJYHaw11gsbhU3GFmB3YA9i27EXsIPYcewsDoeTxxng7HEBODYuE1eM O4A7ijuPG8JN4D7iSXhVvBneAx+N5+EL8RX4I/hz+CH8C/w8QYqgRbAlBBC4hDzCLkIjoYdwmzBB mCdKE3WI9sRQYjJxC7GS2Ea8QhwhviORSOokG1IQKYm0mVRJOk66RhojfSJTyfpkV/IqchZ5J7mZ fIH8kPyOQqFoU5wo0ZRMyk5KC+US5SnlowRNwliCJcGV2CRRLdEpMSTxWpIgqSXpLLlGMl+yQvKk 5G3JaSmClLaUqxRbaqNUtdRpqWGpWWmatKl0gHSa9A7pI9LXpSepOKo21Z3KpRZRG6iXqOM0FE2D 5krj0LbSGmlXaBN0LF2HzqIn00vpx+j99BkZqoyFTLhMrky1zFmZUVmUrLYsSzZVdpfsCdn7sp+X KS9zXha3bPuytmVDy+bkFOWc5OLkSuTa5e7JfZZnyLvLp8jvke+Sf6KAVtBXCFLIUTikcEVhWpGu aKfIUSxRPKH4SAlW0lcKVipQalC6pTSrrKLsqcxXPqB8SXlaRVbFSSVZpVzlnMqUKk3VQTVJtVz1 vOpLhgzDmZHKqGRcZsyoKal5qWWp1an1q82r66iHqReqt6s/0SBqMDXiNco1ejVmNFU1/TTXa7Zq PtIiaDG1ErX2a/VpzWnraEdob9Pu0p7UkdNh6eTrtOqM6FJ0HXXX6dbr3tXD6jH1UvQO6g3ow/qW +on61fq3DWADK4Mkg4MGg4YYQxtDnmG94bAR2cjZKNuo1WjMWNbY17jQuMv49XLN5dHL9yzvW/7N xNIk1aTR5LEp1dTbtNC0x/Stmb4Zx6za7K45xdzDfJN5t/kbCwOLOItDFg8saZZ+ltssey2/Wllb CazarKasNa1jrGush5l0ZiBzB/OaDcbGxWaTzRmbT7ZWtpm2J2z/tDOyS7E7Yje5QmdF3IrGFeP2 6vZs+zr7UQeGQ4zDjw6jjmqObMd6x2dOGk5cpyanF856zsnOR51fu5i4CFw6XOZcbV03uF5wQ7l5 upW49btT3cPcq9yfeqh7JHi0esx4WnoWeF7wwnj5eO3xGmYpszisFtaMt7X3Bu/LPmSfEJ8qn2e+ +r4C3x4/2M/bb6/fiL+WP8+/KwAEsAL2BjwJ1AlcF/hLEDYoMKg66HmwafD64L4QWsjakCMhH0Jd QneFPg7TDcsK6w2XDF8V3hI+F+EWURYxGrk8ckPkzSiFqKSo7mhcdHh0U/TsSveV+1ZOrLJcVbzq /mqd1bmrr69RWJO65uxaybXstSdjMDERMUdivrAD2PXs2VhWbE3sDMeVs5/ziuvELedOxdnHlcW9 iLePL4ufTLBP2JswleiYWJE4neSaVJX0JtkruTZ5LiUgpTlFmBqR2p6GT4tJO82j8lJ4l9NV0nPT B/kG/GL+6DrbdfvWzQh8BE0ZUMbqjO5MOmImbmXpZn2XNZbtkF2d/TEnPOdkrnQuL/dWnn7e9rwX +R75PxWgCzgFvevV1m9ZP7bBeUPdRmhj7MbeTRqbijZNbPbcfHgLcUvKll8LTQrLCt9vjdjaU6Rc tLlo/DvP71qLJYoFxcPb7LbVfo/+Pun7/u3m2w9s/1bCLblRalJaUfplB2fHjR9Mf6j8Qbgzfmf/ Lqtdh3Zjd/N239/juOdwmXRZftn4Xr+9neWM8pLy9/vW7rteYVFRu5+4P2v/aKVvZfcBzQO7D3yp Sqy6V+1S3V6jVLO9Zu4g9+DQIadDbbXKtaW1n39M+vFBnWddZ712fUUDtiG74XljeGPfT8yfWpoU mkqbvjbzmkcPBx++3GLd0nJE6ciuVrg1q3Xq6KqjA8fcjnW3GbXVtcu2lx4Hx7OOv/w55uf7J3xO 9J5knmw7pXWqpoPWUdIJdeZ1znQldo12R3UPnvY+3dtj19Pxi/EvzWfUzlSflTm76xzxXNE54fn8 87MX+BemLyZcHO9d2/v4UuSlu5eDLvdf8bly7arH1Ut9zn3nr9lfO3Pd9vrpG8wbXTetbnbesrzV 8avlrx39Vv2dt61vdw/YDPQMrhg8N+Q4dPGO252rd1l3b97zvzd4P+z+g+FVw6MPuA8mH6Y+fPMo +9H8480jmJGSJ1JPKp4qPa3/Te+39lGr0bNjbmO3noU8ezzOGX/1e8bvXyaKnlOeV7xQfdEyaTZ5 ZspjauDlypcTr/iv5qeL/5D+o+a17utTfzr9eWsmcmbijeCN8O2Od/Lvmt9bvO+dDZx9+iHtw/xc yUf5j4c/MT/1fY74/GI+5wvuS+VXva8933y+jQjThEI+W8AWewEU0sLx8QC8bQaAEgUAbQAAosSC BxVHQAu+GWGRfxZ76P/mBZ8qjrcCoMEJIOYBgLDNAFQjVRsZSyC9yIohtgs2N1+qiCIqGfHmZmKA yAqINbkgFL4VAoCLAeBrv1A4XykUfq1AvPJ7AM77L3hfUTRmHLHdTgBYUa77hV4TKf8sfwETTNN0 BtbwDwAAAAlwSFlzAAALEwAACxMBAJqcGAAAIABJREFUeAHtvV2vJFl2nhen6tRnd/V393Szhxxy OJwZUhRByRTlC41oXgiQLFiAAQsC/Bt84xsD/gUGfGMIkgz4XjeCLQgQYMsGDdMjm4BF0zIpkdRw hhyR1Aynp7unu6uqu75OVR2tN0+9Xat27YiMyBOZGZHxBCpq7b322muv/ezIWBlxIjOPTmNr2CAA AQhAAAIQmAyBC5OJhEAgAAEIQAACEFgRIDlzIEAAAhCAAAQmRoDkPLEFIRwIQAACEIAAyZljAAIQ gAAEIDAxAiTniS0I4UAAAhCAAARIzhwDEIAABCAAgYkRIDlPbEEIBwIQgAAEIEBy5hiAAAQgAAEI TIwAyXliC0I4EIAABCAAAZIzxwAEIAABCEBgYgRIzhNbEMKBAAQgAAEIkJw5BiAAAQhAAAITI0By ntiCEA4EIAABCECA5MwxAAEIQAACEJgYAZLzxBaEcCAAAQhAAAIkZ44BCEAAAhCAwMQIkJwntiCE AwEIQAACECA5cwxAAAIQgAAEJkaA5DyxBSEcCEAAAhCAAMmZYwACEIAABCAwMQIk54ktCOFAAAIQ gAAESM4cAxCAAAQgAIGJESA5T2xBCAcCEIAABCBAcuYYgAAEIAABCEyMAMl5YgtCOBCAAAQgAAGS M8cABCAAAQhAYGIESM4TWxDCgQAEIAABCBwbwdHRUXN6eupqU9Y/b+hROE/fHu5Xsckux9vWT7Hk rU+fbE95OwTKddEo51mbbR9zbRTGGrfNT5u+jEd25bYpz+wr+2jTa9xanF32ZazUd0ugXJtcVyR5 3XcRWe340bg1fY5113HugoXH+Dw5WzF1mRcrl7vizgvYt0+XP9rGIZDX5bwex/R13lg26T9G/NlH PoENiad8fbhuaV+5rnK55Xa1lfXSnvruCeTjRaPn+i7Xq3b8KJ42veNsa1ffQ9jWJudykVzPUiBK YAZnvWysq9nLzu25j2zbtr52bf09ntqzr6wv29p8oR+HgNiXa6G69V6b0qZcp2yXy7Jzva1PqVe9 7ybfjld9HKfHXNfWd5zSzuOU+qH1Pn48F/ku5+vx+vixLXLaBPJ6K1KvbR+9bdtm2Hb8tOnb/Byi /pnkXMJeN2EDlJ3LWgyXc/9S57rtXc99amXbr1v0Wt+sK8dz3dK2qrNth0Bm6/XM61tbC9vlNvfJ UVqX7dTeVm/TZ59l2X0s3Z7rLrfFoz5uc//zSo+5DT/2LalNsa/b3GedHe3TI1Cundd9iL7rGGlr a9NPj9D2InomOWcgXoSuobN9l53bunz29eWDwtK+u2QeN4+T9V39adsOgbwWeQTpa+vbZp/7luVa n9q6e0z1V7nWr/TdVu/q29XW5m8f+hr/mm5dbJv0WeeT9u0QyK+L8xyn2c92Il2G12eS87anfJ4F L2OTL7/wLUsb17OtdZJjxpP9Up42gbZ1t37d8aTZ+QSUpfvvc/Z9Yl8XX5uPofNr87NufNr3Q2Do +rZFOZafNv9L0Q/6KJVPREPgtPVp0w/xrYOg7wnAtm3+a/HUdG390Y9HwGu6C/4ew1KzWHeseKay 827dVKXml+fYFqdsNKfzbmP5OW8c9B+PQNvx06bXyF1t40V2mJ7WXjnnE1Uud+HIdn6hZ536Wu/F k7Sur2/7GdpX47TFk/W53BUTbZsR8Nq7t3lLaivr2d427iuZjwPbZp1s7FNlbfbTpj+zGva/x87+ rSvjyZ7b2tr0ue+YZcdqn2LTxifbumymrmc/LiPnQSCv+9CyZuhjoW22+RhxOY+jflnf5ucQ9UcB 4vxvkw+RDHOaFAG9QOdwqE45zinHNqmDbQHBjH0sjO2vzxLsY8w+cY1ls/bKeayB8AMBCOyPwKGf yPZHdrkj65jyNoc3zo51LpIr57msFHFCAAIQGInAnBPrnGMfsnwk5yG0sIUABCAAAQjsgMCgp7V3 EA9DQAACEIAABBZPgOS8+EMAABCAAAQgMDUCJOeprQjxQAACEIDA4gmQnBd/CAAAAhCAAASmRoDk PLUVIR4IQAACEFg8AZLz4g8BAEAAAhCAwNQIkJyntiLEAwEIQAACiydAcl78IQAACEAAAhCYGgGS 89RWhHggAAEIQGDxBEjOiz8EAAABCEAAAlMjQHKe2ooQDwQgAAEILJ4AyXnxhwAAIAABCEBgagRI zlNbEeKBAAQgAIHFEyA5L/4QAAAEIAABCEyNAMl5aitCPBCAAAQgsHgCJOfFHwIAgAAEIACBqREg OU9tRYgHAhCAAAQWT4DkvPhDAAAQgAAEIDA1AiTnqa0I8UAAAhCAwOIJkJwXfwgAAAIQgAAEpkaA 5Dy1FSEeCEAAAhBYPAGS8+IPAQBAAAIQgMDUCJCcp7YixAMBCEAAAosnQHJe/CEAAAhAAAIQmBoB kvPUVoR4IAABCEBg8QRIzos/BAAAAQhAAAJTI0ByntqKEA8EIAABCCyeAMl58YcAACAAAQhAYGoE SM5TWxHigQAEIACBxRMgOS/+EAAABCAAAQhMjcBxDujo6Ojz6unp6efltoLs+9i19d9UP2TcoXNa F5P95XkPiWedf9rHIzBkXUrbsl5Gpfa8+Xgo9bJRW6m3ffaRy6W9/WSbbZU19rr4tjU2fvdHIB9z fdZ/6HHS5r9NLxJtY7Tp90dv/JGfSc4+ifRZmPFD2Z5Hz+e8C3re/tubIZ73QcDHlcb2sWGd6zku t2X73F6Ws33ZRh0CYxIoj9eyft6xSn+uW9p/rqtc29r0Nds5655JzrWJGJaB+IThuqX18mGdytZb p3pZLnXqp812Kpd+3Ga9bNZtHsdS9mVZOvtWWVu2cZt02ly3tH7VyH+jEjBjO/W6WEpv/ra1tN59 S2kfWZY2U6l7TorH87LO8but1Nte7W5TWVvu67Zsf2bF/0sj4GNB8/bxYJ2l9W1s1rWrn325rD5Z 16VX26Fta5OzJixAhuuywVlvMG4v67Yv29v8l3au2085rsfrK+3Hft2vVleb7ctx2/T2hxyHQNu6 yHtuc3mTddmkzzizq3vRXLz5uPP8rHfdsbvudkm31aTtPFa2cRtyuQTK48n18xwn9pGpWiepTf5r W5u+Zjt3Xa/kPBSIAdfg1HzVdOrb5afmexNd29ib+KLPfgjsaw3z8dknhqH2fXyWxDfpU/qgDoE2 Auc9vvQaKH3UdG3jL0nfKzkPBVLCH9rf9kP85BPfJv3dB3nYBLqOE58kLNeR0PHZ11a+hhzP68am HQJzI9D2WuF1UV/J0T5KJfC1rU1fs+3StfmxXgtc7qU/2Q45EOy79NNV36RPlz/aniewCWP3KY8R Hw9qd1nS9s+P/qxmiO2zPadT65prV9t0ZkAkuyLQdjy06R2X2v36sg7ZTeCZK2cD7gsyn5gMPus0 tPXn8Z39uGx/9i9921aztU4y+8jx53Kbb+mzXfbV1Ye2YQRKxl4/ecnlzL/sM2zE/tYeJ4/dv/cw S4/lXh7TDMrj2XalzH5yWXa5bv9lf+qHRSCvuWbmdW/T28bHne27qNjWNurT5j/bulzaZr19HpI8 ignX//J+SLNkLgdLQC9QDuGDXV4mBoHFEhjttvZiCTJxCEAAAhCAwMgESM4jA8Xdbglw1bxb3owG AQjshgDJeTecGQUCEIAABCDQmwDJuTcqDCEAAQhAAAK7IUBy3g1nRoEABCAAAQj0JkBy7o0KQwhA AAIQgMBuCJCcd8OZUSAAAQhAAAK9CZCce6PCEAIQgAAEILAbAiTn3XBmFAhAAAIQgEBvAiTn3qgw hAAEIAABCOyGAMl5N5wZBQIQgAAEINCbAMm5NyoMIQABCEAAArshQHLeDWdGgQAEIAABCPQmQHLu jQpDCEAAAhCAwG4IkJx3w5lRIAABCEAAAr0JkJx7o8IQAhCAAAQgsBsCJOfdcGYUCEAAAhCAQG8C JOfeqDCEAAQgAAEI7IYAyXk3nBkFAhCAAAQg0JsAybk3KgwhAAEIQAACuyFAct4NZ0aBAAQgAAEI 9CZAcu6NCkMIQAACEIDAbgiQnHfDmVEgAAEIQAACvQmQnHujwhACEIAABCCwGwIk591wZhQIQAAC EIBAbwIk596oMIQABCAAAQjshgDJeTecGQUCEIAABCDQmwDJuTcqDCEAAQhAAAK7IUBy3g1nRoEA BCAAAQj0JkBy7o0KQwhAAAIQgMBuCJCcd8OZUSAAAQhAAAK9CZCce6PCEAIQgAAEILAbAiTn3XBm FAhAAAIQgEBvAqMn56Ojo6bce0fT01D+y62mK23mUB9rHl6DXc55zNjLuMfyvc7vtsYpx920vml8 m/brG+em/st+Zb3v+NluDB/ZX1mu+a/pyn67qG8jjprPmm7d/Dbps87nIbcfb2Nyp6en23CLz54E 9CJgDXrCKszgVgDpWR2L21h+eoaNGQQmS2Aryblttvmdk1+E1qmey+t8tNnW9NbJp8dt8y99zV66 3DfXs736l3Mpbct29enasv8cQ62PbS2zvXXqZ711ZUyl3vbq6zaVteW+bsv2Z1b9/nd/y9JPTW+d Y1k3UrbPtta3jWlbt9s+662TTS7LxvUue/u2TZu0r2xvnfpk/Tof2V4+ct+yXvPlcWv92tr6+pGd fahcjiGdN7XZ1rLNvo/efrO0X8vsR3Y1vXVqL+2lK7eavXXqn8vq6/p5/ZT9s2+PUcZf01tnfzlm t5V+bIt8SmArydkLoGG8CNK5LL3rXjjX1da12T77sn324bJlzca6LNvs87jZJpflR3VvffqU/d3X smwv67azzGNaJ1n2c932ruc+bqtJ26mftmzjtk1kl58co8uWHqusW29ZtqvuzWO7Ltlm36a3j1q7 2rzVxnXfbGf7LLNvly1tV9attyzby7rt+kjHXdpmny5b2lZ1bzU/NXvbZU72U2uT/yF+sl/HZtnm vxzD41m6f1m33rJsd93jut5lr7Y2uzY/9ldK20uWWx7DZUvbqq6ty49tkc8S2Epyri3ks8M+X9uk T+mlzYcPkNK+rd5mP9YB1hbn0Hja7DfRD41pkzHO26ctxrb1Ou945+nfFut5fLpvm+8xOchX2ziO Y508b/+a//P4rPGRP+tVPo//tr72X5vPUF3bGDU/XeMO8VPzLd0YPtp8o2+arSTnqYEdehANtd/2 fKcWz7bnO9Q/fM6IwaH7yGnjY72Smcvdnoa1bsNnnwj2NW6f2LBZT2D0p7XXDzmuRde7w9pI57H3 i7fNR5u+Fsemul2M0Te2rljKNtVLXZ9xhvYZYj/EVrG22bfp2+Y31L7NT5d+0zF0QlffLLvGOU/b JjHW+tR0jqutzXpL2XvO7ttH5v7bsO/j0zZdsXS1uX8fOcRPl21XW584lmCzsyvn8sBXXZsXSdK6 deCzr3V9sq38bmqf47NPSZft2/PpmkO2qcVTG8v+avZu65I5TtnZj2PJY/b1U/Npf/bf5autLftd 5yfbyt8Q+7Kv48kssk2fsueffTgut2U/HnOItB/7tazps98cUxmD6ufdsv82X3ncXM722U9p4ziz PpflJ9dr9raxXMdNdnmr+c/tuZxtpXc82SaX2+wdY2Zjf27LfXPZdpK2Lf2orW3LvlTu2kpbj6c+ ZVuXH9pirQJYN20ojUpgyIti1IEn4OyQ537Ic5vAoUMIEFgcgZ1dOS+OLBN+hsAhJi/NyRvvcU0C CQEIjEGAK+cxKOIDAhCAAAQgMCKB2T8QNiILXEEAAhCAAAQmQYDkPIllIAgIQAACEIDAUwIk56cs KEEAAhCAAAQmQWByyTk/ZNOH0Dr7de21MTbpU/MzZ915GfTt39dOLIfYdrGv+anpunxsu22TeDbp M9Y8xh67r7++dl3zHMNHl/8x2xTrlOKdUixjcp6CL57WnsIqLDgGnnJe8OKPMPUlHT9KhEua7wiH x6xdbCU553dT+WDqo880h9rnvmXZvhyP6i7L1nXbWZY29ttHb9tS2rf18mVdWZaN21TO46pebrKt +ZBd9qO6fWW9dWr3Zp+57nK2z37c3iVtX/pQvWxz3bLs43Gy3ros3d+ytK/prZOf0j77Vlm2snGf bG+d+7gt662zTfZpXc3eOsuaH/fPPmv21tlevqTLPsu6bbPMfsq+2c5t2T63t5Vt7/6yc1y1tpof 21mWvtzH+mzXVba9Yyr9uF6T9qs2+7HO0vpaf+tsm/2onPVus05+VbZ/l3O7+nRttpWN/XTZ01Yn MHpy9mJ6ONct++hlM9Tefmsy+8rlmm15cNqm7Oe6ZZud9ZY1e7V53Fp7PsDLdvvNMtu4bGk71bXV 9F3jtdnX9B6rTXrOZXv25bJtc2zq53b7KOvWW7b5UXvu67Kl+5d167PMNi5b2k51bTV9nmPf9q55 ecxSZt8uW9pW9U22mp9ajPZfs183rv2VdtlXLpd2qtuHZN7Kfq7b3vXcx201abtaP7dJlu2uZ5/Z vq3sfm533TLrXc5jZLu2svtlmW2lL+vZlnI3gdGTczmcFnzTTQs7xlaLoe1A7BqvFo/9qJ/KtbG6 fJZttf61cct+uV7zkdu7yrlv2wtraDxd49Xacgy19m3p2sYdOt82P33izn23zT+PtS422Toey3V9 9tU+ZF5dMXate98xzE3jqNy3X1dcfdrGHHdozF3c+sSOzRmBrSfn84AeelCcZ6w+fdvisX5bJy37 7xPjmDYatzanfcUz5tyG+NrXfOE/ZJXGtx1r3e2n9loaP+qnHvc97tNIKG1CYOtPaw95F9VlW2ur 6YZAaDv5ZR9tY1hvqT72l/t3lXPfLrvctkmf3F/lLh9l27o5lfbr/JexbFqvjbuJr6F+htrXYury UbZtwl9jln5qcazTlT4ci+QYW+nfPtv0bt+mbBu7Tb8ultzP/Nb1GaO9z7jZZowxaz52MUZt3EPQ jX7lXB6AfiH30WebXBbomp/Spm1B8gFiP222Hst9bF+OtU7f5j/7yWWPJ2nfZSyut/m23r6yfR6r rZzt7cs6x5X7us3S45Y22VetbN+1tqzLflXWlnWurxo6/st97KfNPNv29W8O2T77aStn+xyP7SVd drvq3nJb1ru9lEPiLPvW6nkdcyyydTxZ36dcG6fU5XHLtj71Mg71yTrXJc2s75htfuSrtg21r/mQ rs1P1udymx/pPWeV1afcMovSZ82+7E+9TmDR362dD6o6nvlpD3FOc1qFufDfJM5N+sxp7Yj1eQKs +fNMdqXZ+m3tXU1k6DgcdEOJYb9kArxelrz6zH0fBBZ95bwP4IwJAQhAAAIQWEdgsVfO68DQDgEI QAACENgXAZLzvsgzLgQgAAEIQKCFAMm5BQxqCEAAAhCAwL4IjJ6c9eDI0G2TPvsaoy1W6WttNd3Q 2Kdk73lmqfjGnqf995172/ht+r5+bTeWH/tbJ9vGa9Ov8ze0fcg4XbZdbUNjOmR7OB3y6m42t9E/ 57xZGNvvNdbn7Wp+9MKq6TWrNv32Z7ydETyfrjmfd+Rt+t40Ns970/5z6zfWfMfyMzd+xAuB8xLY WnL2O0G/OMsTruu2s7S9Jmadylmvem1rs7e+9GG9faldOkvpcx/b13RdbdlePm3b5l96bY7D0rpV Y/zXx085tvtuSzqmPK51GjPrazHY1jLbW9fHT823dTU/0pVjuW571+XH9m1tHksy98t6l+3D9Wzv tqyTXanP9VzOtirbj2xcto3rZX+1a7P+rPb0+Mxt9tGmy3qVbe94PIb1bfbSt2324Xb5sq4sy8Zt KudxVS832WabXG/z00dfjkMdAltJzuUBmw/mErlfLKVN9qE+Zb30U7bnusfIfXK7/bs9t+VyzY91 Zfzy5Tb7lcz+cr2md7/c5rJladOmt902ZR7bZUuPW9attzSzkmfZr6y7/zpZ9ivrtf6OqWzLfV22 tK3qXVuXfW5bV3aM2U7jrqvXYrOv3Fbzo3bbSpab27K+5sd9c5vLlvZR1q23LNtV1+ZYau0eX3Zl u3R9trKf65b24bpl1ruMhIAIbCU554PdmP3iyNJtbVIHcN/NfmWvsvZNt/P0HTpmn7GG2gzhNjTe Lvu2OPcVT1esbW3lSbPNTvq2+Xb1GdLW5r9N3xZTjb98eK6WQ2Lbhm1tXo7Tc6vZDIml1r/GZ4hP x2Y/GiOPY/1Qn9gvm8BWkvNYSPMB3sen7adysukT8zZszGEbvjfxObV4NpnDnPvMnb/j39br2v7P u8b2U8Zp/Xn9039ZBEZ/WrsLnw7S8sAt7dVe29r0ts3tHsdt62Tuu8527Pba2DXdunHb+pR61Uvd Ot9jtu9z7K55+JjJssu+T9vQuQ617xNDaZPH2HSu2UeX/7Jtk3oey/H29ZP7bqNP9p/LXXFmO8fU pqvp3Qd5+AS2cuWcDyodqOu2fDDbPuvU3/o2X33sFZf9ZPtcbvOf9dlP1reVs3051qbx9PGjeOy/ LbZt69viHDpuHz+Zc/af9X385L65nP1kfS5n/7mcbXI52+SybDSeN7V5q+mtK2MsfWY/9tcms6/s J5fVN9dr/tv8uG/b+G733Fzva5/jso8ci/25zfVN/Oexsp8++tKma3zalkNgp9+tXb4wpoR5yrFN iROxDCPAcTWMF9YQgMAZga1cOdfgTvEkpZi86d0rGwTGIMBxNQZFfEBg2QR2euW8bNTMHgIQgAAE INCPwE4fCOsXElYQgAAEIACBZRMgOS97/Zk9BCAAAQhMkADJeYKLQkgQgAAEILBsAiTnZa8/s4cA BCAAgQkSIDlPcFEICQIQgAAElk2A5Lzs9Wf2EIAABCAwQQIk5wkuCiFBAAIQgMCyCZCcl73+zB4C EIAABCZIgOQ8wUUhJAhAAAIQWDYBkvOy15/ZQwACEIDABAmQnCe4KIQEAQhAAALLJkByXvb6M3sI QAACEJggAZLzBBeFkCAAAQhAYNkESM7LXn9mDwEIQAACEyRAcp7gohASBCAAAQgsmwDJednrz+wh AAEIQGCCBEjOE1wUQoIABCAAgWUTOJ7q9I+OjprT09PPw8t1lb3ZJuvUZr3tkBCAAAQgAIG5EJhs chZAJ+SceK0z4FzPCTnrbYuEAAQgAAEIzIHA7G9r54TcBVzJWjsbBCAAAQhAYOoEJn3lrMTrK2An VusMNidn26gt622LhAAEIAABCMyBwKSTswDWkmzWOXmXtllftqnOBgEIQAACEJgqgdnf1p4qWOKC AAQgAAEIbEpgdsk537oeMmn127TvkHGwhQAEIAABCJyXwORva5cT1C3tnGTLW9y2z3rrkBCAAAQg AIE5EDiKJPb0w8RziJgYIQABCEAAAgdOYHa3tQ98PZgeBCAAAQhAoCE5cxBAAAIQgAAEJkaA5Dyx BSEcCEAAAhCAAMmZYwACEIAABCAwMQIk54ktCOFAAAIQgAAEJpuc88eltExlfcjSDe0re+/lOEN9 lf1db/Oz7XE9fpZtsWQblx2fpfVdcoj/Lj9dbUPi6fJTa7Pvtnm06bOvdTa19pou+xyzPHSsofZj xpp9TSWOHBNlCIxBYNKfc9YLT5/02uUL0GMablkf65NnNT/lWI5Bsmaf23dZzrF0xbyrmLYZQ+m7 Vh9jnpnpGP7wAQEIzJvApJNzG1qdIL3lk1pNb51ltrePLpnt23xYbz/qI52l9Ov82IflOnv5tG2b f+m1OQ5L6yTtwzKPq/a+m/rnvq7br2VpY/9Zb10p7UN621tnaX3ZN9dta11Xn642+VF76c9+a9K2 2W+XrtZW8yudbVWu+e/Sq81bHz+27ZJ9/WSGLjt++bBOY1m/ybhdfWiDwNQITDo5+0VpKXh+sRqk 65al3n37vKjV1/b2k/uVbbKpjeu+uS2Xa36sy+PZj9tcl8z+cr2md7/c5rJ918Z1v1Kqr7d1/dr8 e3z7KevWW5btrrf5d79Sup/1qvfdct9cPm9/zyH7sU6yz1bG47qlfbhumfUq1/S1WGTXtW3iJ4+T +7eVa+NnW7WX9VofdBCYIoFJJ2cB63ty8gvbffr2qy1K7nueF3f2UxtnTF2fsfrY9Ikp+zEf6Vy2 XOdLdnPZanPK8dfay7llbmXb2PXzjJXntWlcPh7UX+XzxDO07xjxbzpv+kFgLAKTT85DJuoXcZ8T 5RC/2G6HgNdrO97H81o7nnLsub2WGLLteFFtz9NY8dpP5rO9qJ969rhPNZQgMD8Ck31aeyjKfFLU izPXs682vW3WtduuJs/Tt+ZviK42dk23zucmfezT3LtOjm3+2/T2vQ3ZZ0zZdM2njEu25V7abFLv E2v2O8S+y7bWVtPlsVXONuKR67at6dw2ltzFGGPFih8IZAKzu3IuX+iqa2vTl222X3Wq/Nflx+Z6 wdtPts9l23bJ7KfLzm3ZvhzrPPFkX/bjMWsyn/D62Nf8Z53GWOdnqH0tbo/j+EufbX1s7/Z1sdqu lNlPzYfasz7Hl/WlX9WzreuWtXGzfVvZ/S3tJ9urrbaVNqpry/pcrvmwzuO6v/WWmVvp0+PaFgmB uRDgV6lGXql8ohjZ9eTdLXnuk1+cmQbIMTXThSPscxOY3ZXzuWe8BQc6gXhb6jt1TqI+ApAQgAAE zk+AK+fzM8QDBCAAAQhAYFQCB/NA2KhUcAYBCEAAAhDYIwGS8x7hMzQEIAABCECgRoDkXKOCDgIQ gAAEILBHAiTnPcJnaAhAAAIQgECNAMm5RgUdBCAAAQhAYI8ESM57hM/QEIAABCAAgRoBknONCjoI QAACEIDAHgmQnPcIn6EhAAEIQAACNQIk5xoVdBCAAAQgAIE9EiA57xE+Q0MAAhCAAARqBEjONSro IAABCEAAAnskQHLeI3yGhgAEIAABCNQIkJxrVNBBAAIQgAAE9kiA5LxH+AwNAQhAAAIQqBEgOdeo oIMABCAAAQjskQDJeY/wGRoCEIAABCBQI0ByrlFBBwEIQAACENgjgckm56Ojo2ewuC6Z92eMqEAA AhCAAAQOgMBkk7PY5oScWZ+ebaqPAAAgAElEQVSenjbebZPbKUMAAhCAAATmTGDSyXkTsL6q3qQv fSAAAQhAAAJTIHA8hSDaYtDVsZKtpe3y1bLa2CAAAQhAAAKHRGDSyVmga8k365y8vSi5zTokBCAA AQhAYE4EDu629pzgEysEIAABCECgRuDgkjN/c64tMzoIQAACEJgTgcnf1q7B5G/ONSroIAABCEDg UAgcxd9oeaLqUFaTeUAAAhCAwEEQOLjb2gexKkwCAhCAAAQWTYDkvOjlZ/IQgAAEIDBFAiTnKa4K MUEAAhCAwKIJkJwXvfxMHgIQgAAEpkiA5DzFVSEmCEAAAhBYNIHJJuf8cSmt0Lp6uYqlvdtLfVm3 XV+p/nnv0++8Y/YdY1vjrJtvn3HX2dTaa7o+LDaxGTrWUPtNYurTZypx9IkVGwhAoJ3ApD/nrBON PulVO+FM6RNgORbH3I58+y3bjKH0XauPMcPMdAx/+IAABCAwJwKTTs5tIJUQtJUncOvLfm360s71 bF+OYZt1Uj5yX9ft27K0sd+st66U9iG97a2ztL7sm+u2ta6rT1eb/Ki99Ge/NWnb7LdLV2ur+ZXO tirX/Hfp1eatjx/bdsm+fjJDlx2/fFinsazfZNyuPrRBAAL7JTDp5OyTkKVRlXXpfdKyjU+EbXrb lbJmv+4E6LHka52tYy/tho7bZt/mv5yn6zU/blsnc99cXtfP7blPLnsOtpO0ruSWbXI5+5PedUvb um6Z9blf1tdiUf+ureZ/nZ/cnvu3lWvjZ1u1l/VaH3QQgMD+CUw6OQtP35PxmCh1Ahuy5Rh98ms7 sXb5HTpul69tt3meeZwcf60926qcuZVtY9fPM1ae16Zx+XhQf5XPE8/QvmPEv+m86QcBCGxGYPLJ ebNpna/X0JPf+UZ72ntf4z6NoF+plnhz7Lm9lhiybb8R92s1Vrz2k/nsYmYedxdjMQYEIDAOgck+ rX2e6dUSgvy16bvG2qSP/emkuO5E3Oa/TW/f25B9xlw3nzIuMSj30maTep9Ys98h9l22tbaaLo+t crbxcdFlU7aNVc9xjOUTPxCAwPgEZn3lrBONTnTa8gmvTzmjbPNjv9m2Vs4nPMdTs7OujE/6rHPd 9jU51L7mw+M4/tJnWx/bu139Ntmyn5oPtWd9ji/ra2NnW7Xbvo8+2+Rym5/SZtN4+viR7yHcSp+q s0EAAtMnwK9SbXGNyuSyxaFwvRACHFMLWWimuXgCB3lbewqrykl0CqtADBCAAATmSYAr53muG1FD AAIQgMABE+DK+YAXl6lBAAIQgMA8CZCc57luRA0BCEAAAgdMgOR8wIvL1CAAAQhAYJ4ESM7zXDei hgAEIACBAyZAcj7gxWVqEIAABCAwTwIk53muG1FDAAIQgMABEyA5H/DiMjUIQAACEJgnAZLzPNeN qCEAAQhA4IAJkJwPeHGZGgQgAAEIzJMAyXme60bUEIAABCBwwARIzge8uEwNAhCAAATmSYDkPM91 I2oIQAACEDhgAiTnA15cpgYBCEAAAvMkQHKe57oRNQQgAAEIHDABkvMBLy5TgwAEIACBeRI4nmfY RD0qgUePmubBg6a5dy/k/bPyfcknZbWpfCIZ+8OHIU/O6ieST/ZHoX/8+Kz+MHzKr3Xqo7J0alvV o5/Kp6fRL3bJ0+gf4kxaF/JR6NWwspNNlI+OYo/3lxdCNrFfjPJKJ/2TtlXTE73spD++GLaXQsbh vyqrrnLsF8JW5YuhU9ulsLNO5c/3y01z+YmPy1G+pPqV2CWflK+4HvLq1TO9/LJBAAIQWEPg6DS2 NTY0T5WAEtxnnzXNndjv3gmpPZfvnunvhrwX+53Y7z+R98L2biRc6eWHbTcE9Abg6rWmuaaEfb1p rkf5SuySK73anuivh1yVX4j2VH4h6vLDBgEIHCyBySbno7jCaXvfoDZvtsk6tVlvu8lLXbXevhX7 7aa5dbNpPg356adndZXVpvpn1kUSvh992JZJ4Epcib8YSfrGjaZ54cUox37jpZBRl051lV96+ayu Nl29s0EAArMgMLvkXCZt1y1Nvaxbv1Op27ifRKL95OOz/eYnTXPzSf3j0N1SPZKu9LqNvK8tbrU+ iluxj+OW7aNj7cdRjj1u/Uqu6tLH7d7Hcav3Udzmfax6vEl6HLpHcTv5NPqcXrjYPJYubjWfhk7l U/WRLm4pq/101a66bh+f2Z/GLenT1R1nvSELCLIN3WoNo6o+umut/87sLsTd8UfRPfzFbfCj1b2f +C/+xQG9MtWbM3nRbXB1X9XVHroLGiT6X4hb8Cqv+jxW/aztKNZtpY9b6RfC/6oc7Udxh+GidNF+ MfpdeHjSXJSPuDV/UX1UD5sLJ7E/OllJ1S+G/kLc+r+oPwnotv6+Nt1mf/mV2CNRvxTy1Veb5pXY X44ELr3Kqz3qurXPBgEI7I3A7JOzyZXJuFaX7WhX1DrJfvxR03z0o6b5UewffRgy9g+j/EnoJXUF rESwpU2J71FcDT2M/eRKJNfLIePvoA9DPoz6Sfwd9GEk3IeReB9Gon0YifZh6B5Jp0Ss5BhJ9qES VGQw7drKcpfObZLlZn/S9ymX/V3Pfa1rk33WN9v0KeexbF+T63RqPw7GqyQex8+xEnbsx/G3/ONI 6MeR0I8jgUt/Sbr7sT+411yKv+9fkFQ97rBcjF1vILa26TjQFfcbr0eyfu1Mvv5G07wW++uhey32 V0Mfxw8bBCCwHQKzS87CkE/WPiFmnWysV1mb20v9Wevz/8vuSLeQ3/9h07z3XtN88H7sUf4gErB0 H4aMq6mxtsdKoPF3xQfXrjUn8bfIk5W82tyPh4wexBXPSfxd8sFVJdwrkXgj+SrB6uozNs1t3W47 y5r9hfA3RG9f7ue6fHSV3VaTq47xn324nm2zzuXaupY610spH9JlfVv5cVwpl23uK+n2rOvSq83j W5Z9y7rsjiMOJfHj+NPGpZP7zeV7DyJ5320uxx2YK/Hw3qVI4JfiWYNL8WzB5ZDH8TzCBV25j7XF XZDmjUjWb32had4M+abkW03z9tsr3Wncaq+t4VjD4wcCh05glsk5L4pOADp5WbqtrFv/nNTt5B9G 8v3Bnz3Zv38mlZD1sNV5tjiBncTfBe/HierBC9eb+1ejHAn4fiTe+5GA74V8EA8BPYzkq0SrmLU7 2eW6wnDdUnbepdNtXtftw3W157Lr2ZfHsFRbLpd1t62M4r/cPlRX2rs+hnQCzL6ss1Sby5Z9dLaV 9O5+uU26nLjLsuuSZVl13caXP7fbxmN6rFKf66uEHsf75XgI8Gok7CuRuK9IRuK+cu+z5vJnIeMN 6aVP47g/7xtPPbSmRP3Oj8X+7hMZ5S+ETrfX2SAAgU4Cy0nOug2tBPzv/rRpvvfvnsgovx9XxE+u XjpJlY2RGE9uvNjce+FGcz8ewLkXD+DcuRbJNx7CuRNP2D6IJHwSt5vlWkkrJ0vVS50Tp6SSbE60 Lluqby7bn6XHcl2hu2wpG+tXhSf/qb3cajrbdLUNsbFtl+way8mpq3+ftj5+umxqbaXO9Zw4pbPe ZcmajfU5YassW0uXc106+7O0ryx1COjK+3Ik7evxKYAr8UDi9bufNVfjgcQr8cDi1c9uN5dux12l 8Dd4k/O34gr7iz/RND8e+xd//EwqiXObfDBOOhwugdklZ52gdSLx5rrlSh9/j/srr73W/N//5B83 zR9/t2n+5I+bk29/p7m0+jyse66X+nvuvVdeae7G39/uaI/Eezeugu9EQn4QVwZ60MmJUDKXFY8S qJOo5HE8NOV6Llvn/urrsmVN5xmozVsuS7euXrOxL+T4BPKxa++lrque21R2krXs0snGyVryYTys Zp3KuU3l0pfHkNRDcpfjztL1SNTX4mr7uhJ4PGNxLfarn3yy+ru459dLxrMPzU9+qWm+9JMhv9w0 X/5KJO1I3DyY1gsfRodHYNLJucTtE1NOODpR6G/D//nXvtr8yjtfaP5SPMTy86++0lx+cmVY+niu HreelYDvxJOrn8WTqp9GEv40nmS9+9JLqweqNJYSpHYl0Vx3gpXULptL8bdg2Xl33yzlI/tRmzfp tVn2La868d9iCPi1oAmvK+d2vV68S6/d9SyVnL2fxN+21aYE7iTuxC69fDixu64H2q7dutW8GJ9I eDES9gvxiYXr8QkFJe7et8zjOYzmyz/dNF/5mab52s82zVe/1vC37MUc4ouf6GSTc9vK6ERwpG+r +ta3muZf/3bT/O6/PrtF3dYh6U/i1vNn8dDKrXja9HYk4tsvv9rcjcQc6f3zK1onYCdXJ14lXZfV prKkk67LSqq5rOGdaNtktknhUoTAqAT02vHmcpdUos1X0DkBq5wTtcpK4pLWu6/7ScaH7JprkaBv 3Py4uREJ+6X4tMML8bDlJX2Gv8+mW+E//+eb5s//YtN8/evNaTww6ddVn+7YQGAuBGaRnFcJWZ8F /v9/q2l+8zeb5vd/d+23Wp3Ele+tSMQ34ynSm6+90dyKj37owSslUyVPJ1BJJ97L8U5dSdd1lUt7 1yW16cTgk0Mp3b4y5D8IzISAE7bCdTlLl528JV12InaSdsJ+EE+KO4HbRtLl43hQ7aX4aOLL8ZHE l+NTES8pYceVd+cWr8/m536+aX75l5vmL/xScxqf1fZrsLMfjRCYAYHJJmedAI70DVj/779omv/r m5GQf6/9wa24Nf3pm282n7z9TvNxJOOPIymfxENZOQk76SrxKglbSu8kbOl+Trx+wbfJGawzIUJg VAJO0DUpnfacfJWYlcCdtJWslbgtncRzkr8UD6O9Gkn61UjWr7z3g+bFDz5ovyWuPwf93J9rmm/8 StP8pb/cnMbHDf16HXXiOIPAjghMLjnrRX2kjzb92v/aNN/89fj+5/ju58p2N74U4Udxi+tHb/9Y 80l8PEPfbKWk6mTr5KtE7F062+jKV7aqa8uJOL+oc7kSBioIQKAg4IQttRO1pXRK2jlZq+5ErWTt 3QlbtrLRN629EueG19/7s+b1+NTFNX3pT22Ljyg2v/KrTfPX/npzGucGXsM1SOimTmAyyXmVlD+M d8b/5H+MK+V//vzHNCKJ3nz3x5sf/MSXmg+++KXmJJ6WdqJ1Ir4aT1dfiVvXTsZqzwm5TMB+0VpO fbGIDwJzJ+DE7WSdpZOwkrKSsZP0/bjlfS8+2uWrbNtdiqfF3/zenzTv/OmfNC9/Pz4eGX2e2fSn p2/81ab5T/92c/rGmyTpZ+BQmTqBvSfnVVLWdyD/s/+5af6nf/Tcd0zf/rF3m+9/5avN+/Hxikfx 8IeSrXYlYSVj7U7G0vvKWVfGZTLWYpCIp35IEt/SCLQl7HwbPF9ZK1FrV9KWXvvFeEj0rfjY5Lt/ +O3mxp/FFwnlLc4VzX/2d5rmb/zNONM8fUYkm1CGwNQI7DU5r16U8QI7+vv/XTzs9S8/Z3MaV7z/ 8Dt/1Hz1v/qvmzvxVLWS7je+8Y3md37nd5prcctKu5Kyk7Gkkm5OyHLmRCzpE8Dng3QU3E8mZb+h vtqGafPjsbc1bi2etljabLO+jDO3uTzEv/sMlW3chvqp2du32mrz7TO/dTa19pquFt8YuqFjDbUf GqM5S2pXopZUItaVs6QS9I/HZ6F1XshX1tfjKfAv/Zvfbb7wrd+P7yBPV9N/4S82p//Ff7n6hjLF zwaBKRPYa3J+rF/y+W//m/g41L/6nNEHX/168+3/4Jebv/Kf/K2V7rd/+7ebX/zF+NhEbB9++OHq itl/K25Lxivj9N+QE0lpW9aT29GLuxwrBz9k3NK2rGe/Lvexse0mcpv+S9+1umJ2MmmLv+zXZpf1 m/TJ/YeUh4411H5ILDVb85XU7gfH9EZd5wUl57vxfMpncatbUlfVx/Ezq1/9/36zefPb8bFLbz// C83jeNN/gS83MRHkRAns9XfhTn/tf/s8MT+Oh7N+/1f/WvNRfDOQroq9vftufC/vk+3l+Gk7JWQ/ xCW1X7Qq64ThzXrrLK233TqZ7dt8WG9f6iOdpfTr/NiH5Tp7+bRtm3/ptTkOS+sk7cMyj6v2vpv6 576u269laWP/WW9dKe1DettbZ2l92TfXbWtdV5+uNvlRe+nPfmvSttlvl67WVvMrnW1Vrvnv0qvN Wx8/tu2Sff1khi47fvlQWa97bdarrjfp2nReeDG+w8BX02/GJze8ffOb32x++KWfan7u138tfg0s fskrLgRW552//jdtgoTAJAnsNTkf/R//++dQvvWNX21uxVXz6/FC04tNm94FvxAPfuk2Vr5a9gtU Nn7xWkqnzXXZunzW0v2/7W2VxyrbZFP6Vt1bbsvlmh/r8nj24zbXJbO/XK/p3S+3uWzftXHdr5Tq 621dvzb/Ht9+yrr1lmW7623+3a+U7me96n233DeXz9vfc8h+rJPss5XxuG5pH65bZr3KNX0tFtl1 bZv4yePk/rVyHl9v1v1w6I34nnudN3TlLKnb3r/xG7/RfCvOIUrQ2lbnHZJz1/LRNgEC+03O+tzi k+2zr/9so3e8r8bXaCoha9MVtG5f+YVo+aTLM8IvbClV1r7plvvmE8NQf9nP0L5D7fuM1cemz7jZ j/lI57LlOl+ym8tWm1OOv9Zezi1zK9vGrp9nrDyvTePy8aD+Kp8nnnV9Ha/vqPn84dh1Xvkkzi+N k3M679gGCYGpETi7V7SnqB7EV2d6ezd+Meq1+LGKl+KbvfQktjb/Tdk266RPAn6xrrOnfb8EvF6W +42mffRa4nXMktosZVvu7Z6n2ZLn5nltEqn97Pr1qHH9N2ldQeu8ovOLt3zesQ4JgakR2Gtyfv8X zh70EpR3/pd/2tz41u+tbk9t8mLOffTizPUMvU1vm3XttqvJ8/St+Ruiq41d063zuUkf+zR3ybat zX+bvs3PGPo+Y8qmaz5lHLIt99Jmk3qfWLPfIfZdtrW2mi6PrXK2EY9ct21N57bzSvnWrjf6Oq/o /OItn3esQ0JgagT2mpxvxdfsfaLfdY3tKL4Z6PJ///eai//DP2iO2r75J+z8QveLT3Vtbfqyzfar TpX/uvzYPJ9Usv063+5vmf1Y1yWzfR5Xeo+d9dZ1+VTb0D4az3ufMWr+sy7H3xbrUPs+fvrELj+e q2Wb73V692+br/R5y3NeF2u2zf776LPvofY53lwey498DuGWx/3K1SvN6T/4u6vzis4v2j6JbxXU eYcNAlMnsNePUn33u99tPogvDPiZeFf7Wvzm8uebnsL8j341vn7vbzSn735x9eL8vG3ihXxinHio o4e35LmPDhOHKwJDj6lVcv7+9+Lrf/9Z0/yfv/7MD+R8FL8V/Z3/+G81b8YXG335y1+GMAQmTWCv yVmfT3z//febj+PXaL7wL3+r+fJv/YuzjztkZPod17/6K/HLM/9hcxo/ZqEX69S2HJNODkvchp5E l8iIOQ8n0Oe4WiXk+JGM5jf/n6b5599smj/4N88MpI9pfveX/nLzw7/4S/HA6WvNW2+91bzxxhvP 2FCBwNQI7DU564sDbt682fzoRz9qPtGPsMdvu34lfhbyLX1pQDyl/cwWH5do/lz8jqt+Hu4X4pt+ 4iGPnBSfsaUCAQgcNIFVQv7oo6b5V/HNgvoZ2d+L33XP3wam2cdnod+Pj2f+YfycZBO/4f5KPID6 +uuvrz6qmb9L4aBBMbnZEthrcvav0XwaP7T+8ccfrxL1nTt3mktxJf0T8ZvN73znW82FeNqyuulH 1/XNYT8bv+f6tfjR9Sv8RFyVE0oIHACBVTLWT8j+Qbxxj6/mbOKbA5v4Zara9jgeAvvBz3y9+dP4 reeTuFK+fv36KiHrY5r6shJ93a8/dlXrjw4CUyCw1+SsF5x2fcmIvnLv9u3bn++6qo5vEmje+Ld/ 2Lz7R9+OX52JL7Nvu2Ucv+fcfPmnIknHLfCf+VrsX+WH16dwdBEDBDYksErGN+Nu2ne+HfsfnN2q /u6/7fw955vxbYLf/+mvNh/+1FdW35+tq2N9KYl3fdWnvsxId9y467bhwtBtZwT2mpw1S70Itfkq WklZ3+yjq2lJ1fVTccd34ufh/vSPVz8P91L8PNwzX2i/8lD8p78p/XS8SLXHL1o1P/GTzWm8a+ZF WXCiCoE9E1gl4ni9N/H6buKXpZo/+sOzPZ5J6dr0Azm3/DOy8fp+eP2F1S/UKSnri0h0lSyper5a 5hzQRZW2qRDYe3I2CL1AtStJ60paXx6gq2nd5s5JWt+fe6QfXf/BD5o3/+x7zWuxt/7oup1bvv5a 08T37K72L36xafQxrrffaeLttC2QEIDANgnEa7t57wdN8724Jf297zXNn8TVsPYfxd+Pe2x3X3+j +ejHvth8EPsn77zTnB6f/YSsfjbWSVm3sXWVrM84+2t/uVruAReTSRGYTHI2FSdpfcOPdl01K1Hr ClrJWruvppXElcyP47dcX3nvvea1D95rXn7/vebFeAL8SCeBPptuiceLvNEPbMQLfpWs46MWzRe+ 0Jy+wJV2H4TYQCATWF0JfxZXwj/8YdPot5WVjONNdKM/TcWb6uZx+hnH3LEon8ab5k/jyeqbb73d fPTm280nb7/dPIzfdPf3aDshKxFrV3JWQpZe3y7obxjkSrkAS3UWBCaXnE1NL3BtvppWotZVsxJ1 TthO1GrzVfdR2F6Ph8pe+fCD5uWPPmxuhLweT4QfxU9UDtriltgqcX/h7UjWkcD1azdvxC4ZT382 /OzcIJwYHxABvZbi0xWNvqc6Xl8r+cNIvD987ywBx5+khmyn8Vq6E09S347X183X3mg+CXknHuY6 ffLrU0rIujXthJwTsRKy2pSMZedkbDkkDmwhMBUCk03OGVBO1L6i1lWzErJ2J2slbidvX1UrYWuP iTbX4kfYb6z2j5ob8XT4Cx9/2Fy+eav9QbMcRFmOE0Gj2+SvvxUJOxJ13G6Lz2lE0g6pxP3Kq018 Ubi+3qjsSR0C0yZwGh9jvHU7vk7r47MEHG9w4/OOsYf8UPL9s9vQ8SZ48Bavhwcvv9R89uobze14 evr2K6/F/mpzN/bTaFNy9a5b0krGSr7eVVci1q72fIWsWEjIg1eEDhMlMIvknNnlRK1yTtZKyDlp O1EreSuJq032TtgqX4zEffXWzeZG/DD7C/F06Iu3PmmuReK+GuWLkezPtemW+WuRpJWs40QUH7SM H5+VjJ/EfOlJXQn8Ruxx0mGDwFYJxOugieO8uRW7vlfgViTfT242zc2QccyvdLoa/ijKPW89t8X7 KBLqvZdfae7Gcf/pS680n0X5dhzn9156uXkUCdhXuUrEKivR+srYCTknYbWXydiJ2LItFvQQmCOB 2SXnEnKZrFXX7itnJ2xLJ2pL2znJK3GrLB+X4mR2TUn701vN9fiY1/VPbzdXb9+MZH6ruRz1MCzD 2bwefy9r4gQWH8g8S9Yv3WiaF2OPj4Ks5IuRwF+M2+zSxVOp8eHN1cdFNh+QnrMmoDeO8bBkE59i aOK4bD6VjKSrso5NSV39KhnHF/00+liSPp441hYJ9UEcm/fizeW9Gy83d+K41P5ZJOC7sZ/Em00l TSdhX+EqGedE7ITs5GtpO/nIu8InGY+1iPiZMoHZJ+ca3LaErcSrZKzk66TspO0ra98qd7v6yJ+T t2Xc1G4uxYnx2p1Pm6uf3WmuR/mqknd8JORKlJW8j/WVgtF3a1s8qdrceLFp4sG1+NxI/AD2tShH 0nbyXsnQXYldbdfiDUB8BWo8OXO2xxe3NFfiip2/nW9tiZ5zrL/V3o8rWH2hhpKldh0nd1W+G/rY 72iPZOvkG8fXqk0fN9KDVrdjj08sbG2LhPgwjhMl3/txDN2LY+uekq/KcXzdvf5icxJlvTV10rVU 4sy3pfPVr8pl8lU/6dQnJ2EnYMutzRXHEJgogYNMzjXWbQnbide3ui2dwJ28LZW8bSMpO/vIZeku xH4cT5dfjZPvtTjxXo6T7ZV7scfJd5XAo3wpdJfCxr+aU4t967o4Mcbjrk8TdvyaT6PEreSvsm65 x1OyKxkn2OaS6rFfio+gyWalCxkn2VWilz8l/IvxFkZl2ax0Kj/R65a/bI5Dxgn96R59Vn+mz7oo X5DyiTzSW6Mnm/4++lhvgGKX1Jsh79LFv0Y21kk+jKeFlSR16/ZRtMUbtljUs11Jb1UOvWxW5ZCy ibVf7bI5ibpuE59oj7rK8amBlbwXUjarBBxlJ+JY55U/x75jeRprdhLrfBJ3XR5cvb5KvPevX2vu R/lB6O7GG7h7kZQfhs3jJ1esSp5KkDn5quwELJmTrpOvZGknW/sjEe948RludgQWk5zbVqZM2rKT zrsTseq5nK+snbjVnvVO3k7a9um6pfT62/flOIlfjtuVVyKRX3oQ5TjJW3cpdMfSx1WXEr7+Hn5B iYFtkQQexxsk/V1XifQk7n48jMR6EvuD0D2IN1YP4k3VyeWrkXif6vS3XidFJ0nLrC+Tqq9snXid mFVXP9fLsn1qgcryIheNSUNgAIHFJ+c2VkqY3pxUVc9lJVftSsLSu+yk62SuupN2Ljt5W9qHpMey L4+b5cW4kLwYCfxSXLEdx5WaEvelh5G84ypO+6VI3qtyXOUdP9FfCP1FtUf96P5JczFs1n7b2ioa /huDgL7V6lEk1tMrl5qHx5Fg42r2cewPtUf9YdyNUPkkbFY6lUO/SsBxB+Ik7mA8isT7KA4RJ7xS OuEqXrW57qRrqaSar3BzWW3uq7J9uKy6/cuuLLu+auA/CEBgMAGS82BkZx1yApWmra7k6l02Lluq r8pO0C6Xdevlw232J+ld/rS5XpO5XWWdZi/EbdvjeJOhq3Fdxa/2SPhn5YfNhbjFe/Ek9HEr+ELE K/tVOW4RX1A/7dF2pPaIRwn/KG4Zq9w8fhj6KMdt55U+ymd2IR+e3XLW6V2xHqVb0atT/koXjbr9 HG1Het/i29RKCnGL+8wCzkUAAA3mSURBVHRlGP/FbfTV25rQn8mzW+TyqgTyedvxhbhtG7Zxa12f o1XCfBy3zVVuLhyvbumeypf06hd2j7Wrrj1uxT9SPa4cH0cflR9dUttxPImsPeqRSFdS9kq0q35h H+FrUzxlUrMuyzPrp/Zqc6J0kpXOSdPSbWXdSVUy7/ZrnWPsIx0jEgIQGI8AyXk8ls95UrLx5nKb lJ0TtmxUlszlrLM+93HSzjr3sU6yHMvjSGpz3eWV8ok+67J9aZPt+pbto5Qep9TX6koy67Zss2nZ /UqpsbOuLKuuPSdBlyXdZuk2JdlSp7r3sq9tLdXuTTptbTK3rQz5DwIQ2DkBkvPOkdcHzAmoVq7p 5El67U7Crq+Ttb72oTaX23zn/rWxcrvLktps7/JK+UTvsqVs81bW1eYkY7uyXtq4XdLlbJP1Ltek ++Q2J0npnBBdzlLlWn/p2/bse9U5/rMf+8qyq6w2NghAYLoESM7TXRsigwAEIACBhRKIz7KMv+V3 87UrnfFHxOOuCWiNWdtdU9/NeLx+d8N5X6OwvvsiP2zc0ZNzedIu68PCw3qKBPKLe4rxEdPmBMrX a1nf3DM9p0CgXM+yPoUYieGMwNOnRLZARAvPdlgEeDEf1nqWs+FuSEnksOqs73zWc2vJmZP4fA6C IZHy4h5Ca962vIbnvX5d0WttWd8uQvtv20pyZtH3v7BEAIHzEOA1fB560++rN9natc5s0ySwleTM 1dU0F5uoINCHAIm5DyVsILBdAltJztsNGe8QgMC2CJCYt0V2Gn65Up7GOvSJYiufc84HAFfRfZZh PjZ5bR01a2wS85es7/zXcN0M8hrz2l1Ha3/tW0nO+5sOI0MAAhCAAATmT4Db2vNfQ2YAAQhAAAIH RoDkfGALynQgAAEIQGD+BEjO819DZgABCEAAAgdGgOR8YAvKdCAAAQhAYP4ESM7zX0NmAAEIQAAC B0Zg9B++EJ9NHtVXn76P9Q/1P9Tea9wnpuzb/frMw/3W2drOviWH9FlnK395jG3Ye4w+vm0rqa1P n6Hxn3k+m/c6/9m3+63rIzv3W2drO/uWHNJnna385TG2Ye8x+vi2raS2Pn2Gxn/mmfU1h1JuwlN9 +qxVORb1zQmMnpzLRSzrtVDzwVJrz7rSX1nPtiqX7WW9tHdddn23oQdt3xg8fva/Lq7Sd1m3T8uy vazbzrJsL+u2y1I2fbfSX1kv/ZTtZb20d112fbfMv0+fvjHYV/a/Lq7Sd1m3T8uyvazbzrJsL+u2 y1I2fbfSX1kv/ZTtZb20d112fbfMv0+fvjHYV/a/Lq7Sd1m3T8uyvazbzrJsL+u2y1I2bLsnsNXb 2n0Wtc/BkbHkAz3r28pD7eVnaExtY9f0Q31vEn9t3G3oWN/nqbK+zzPJmqHH81B7jTV0DXJ868pD fW8S/7oYxmrfxut3rNjw0zSjXzkbqg/idQfAeQ5ej+Exu6TjWDfeEJ8ez75VX+dfNkPt1Udbn9g0 /qb+z0bp979jyWPVevbhUesnncdoa896x7FuvCE+7d++VV/nXzZD7dVHW5/YWN/TM1gt//dhWHYd ul5D7T1en9gOaX09b+RmBLaSnPschJuF+7TX0DF8Uu3TTzbe+tjbt/psw96x9JHl+GW99FGeDMr2 Wn2dz1qfobqhY3gN+vSTjbc+9vatPtuwdyx9ZDl+WS99sL7r/1bK+pZHDfUpENhKcs4H+zYmue6E dJ4xc+x9xsn25xl3Xd8+sazz0dae56Bx1m3Zfp3tJu27nOu6uaxr32R+tT67nHNt/Kzb9px3Odd1 c1nXnrmcp7zLOa+Lc1dzXhcH7d0Etvo35+6hN2sdepDLnq0fgaFs+3kdZjU0Bta3P9+hbPt77m85 NAbWd3ts+3vGch8EtvLDF/kFte5dWrY1gK4+Q+3lM/fp8u3xLdVvnX32rX7r7GWT+/Sxd58htuqj rU8fx9PHVj5t38d/tpW9tq5xhtrLX+7T5Vu2eVO/dfbZt/qus5dN7tPH3n2G2KqPtj59HE8fW/m0 fR//2Vb22rrGGWovf7lPl2/Z5k391tln3+q7zl42uU8fe/cZYqs+2vr0cTx9bOXT9n38Z1vZa+s7 zpk1/29KYCvJedNg6AcBCEAAAhCAQNPM7rY2iwYBCEAAAhA4dAIk50NfYeYHAQhAAAKzI0Bynt2S ETAEIAABCBw6AZLzoa8w84MABCAAgdkRIDnPbskIGAIQgAAEDp0AyfnQV5j5QQACEIDA7AiQnGe3 ZAQMAQhAAAKHToDkfOgrzPwgAAEIQGB2BLaWnGvfLNNFB/suOs9+q0+35VkrPLspwQc+mQDHQ6bx fHnbfJ4fEc3WkjNoIQABCEAAAhDYjMDoX99Ze4el72JFf/adtHCAg1+qvC7OSMDh8Dn4mEf2JzB6 cvbQSkJDviAde5OrS/jUuVgLH5OoS/jUuVgLH5Ooy23zqY+6bC23tZe9/sweAhCAAAQmSGBrV84T nCshQQACEIAABGZBgCvnWSwTQUIAAhCAwJIIkJyXtNrMFQIQgAAEZkGA5DyLZSJICEAAAhBYEgGS 85JWm7lCAAIQgMAsCGwtOevRe7b9EYD//thrZPjDf78E9js6x//5+R+f38U8PejgyZ/DzvV8YNkm 6zRj6+c5++lGnddBUboO/3HXzFxrXjNrH+dZpz7W1/qjgwAEzk9gsclZ6HyCyice64w21/MJKett ixyHgNlK5g3+mcZ2ymZv77kOf1NBQmD7BLZ2W3v7oe9mhHxC2s2IjAKB6RDg+J/OWhDJsggs+spZ Jx5fGfgqzTofBvnkZBu1Zb1tkeMQ8BpY2iv8TWJ7smSej3P4b487niFQElh0chaMfPIxnKzTCcl1 S9llvfshxyOQWdtr1sHfVMaXbZzb9ONHgEcIQIDb2hwDEIAABCAAgYkRIDkXC5Jv3RVNVCFw8AQ4 /g9+iZngTAgs/rZ2uU66dZdPUOWtPNtnvXXI7RJoW5ftjnq43jNPzVLHNMf/4a43M5sXgcUm5zK5 5nouezlrOrchxyNQcnbdcryRlu2pi2etraZbNkFmD4HtEuAnI7fLF+8QgAAEIACBwQT4m/NgZHSA AAQgAAEIbJcAyXm7fPEOAQhAAAIQGEyA5DwYGR0gAAEIQAAC2yVAct4uX7xDAAIQgAAEBhMgOQ9G RgcIQAACEIDAdgmQnLfLF+8QgAAEIACBwQRIzoOR0QECEIAABCCwXQJbS87ltw+tmwb23YTgA59M gOMh03i+DJ/nmWTN1Pjk2CifEdhacgYwBCAAAQhAAAKbERj9G8Jq78j01X/oz767GA5w8EuV18UZ CTgcPgcf88j+BEZPzh5aSWjI9/Fib3J1CZ86F2vhYxJ1CZ86F2vhYxJ1uW0+9VGXreW29rLXn9lD AAIQgMAECWztynmCcyUkCEAAAhCAwCwIcOU8i2UiSAhAAAIQWBIBkvOSVpu5QgACEIDALAiQnGex TAQJAQhAAAJLIkByXtJqM1cIQAACEJgFAZLzLJaJICEAAQhAYEkESM5LWm3mCgEIQAACsyBAcp7F MhEkBCAAAQgsiQDJeUmrzVwhAAEIQGAWBEjOs1gmgoQABCAAgSURIDkvabWZKwQgAAEIzIIAyXkW y0SQEIAABCCwJAIk5yWtNnOFAAQgAIFZECA5z2KZCBICEIAABJZEgOS8pNVmrhCAAAQgMAsCJOdZ LBNBQgACEIDAkgiQnJe02swVAhCAAARmQYDkPItlIkgIQAACEFgSAZLzklabuUIAAhCAwCwIkJxn sUwECQEIQAACSyJAcl7SajNXCEAAAhCYBQGS8yyWiSAhAAEIQGBJBEjOS1pt5goBCEAAArMgQHKe xTIRJAQgAAEILIkAyXlJq81cIQABCEBgFgRIzrNYJoKEAAQgAIElESA5L2m1mSsEIAABCMyCAMl5 FstEkBCAAAQgsCQCJOclrTZzhQAEIACBWRAgOc9imQgSAhCAAASWRIDkvKTVZq4QgAAEIDALAiTn WSwTQUIAAhCAwJIIkJyXtNrMFQIQgAAEZkGA5DyLZSJICEAAAhBYEgGS85JWm7lCAAIQgMAsCJCc Z7FMBAkBCEAAAksiQHJe0mozVwhAAAIQmAUBkvMslokgIQABCEBgSQRIzktabeYKAQhAAAKzIEBy nsUyESQEIAABCCyJAMl5SavNXCEAAQhAYBYESM6zWCaChAAEIACBJREgOS9ptZkrBCAAAQjMggDJ eRbLRJAQgAAEILAkAiTnJa02c4UABCAAgVkQIDnPYpkIEgIQgAAElkSA5Lyk1WauEIAABCAwCwIk 51ksE0FCAAIQgMCSCJCcl7TazBUCEIAABGZBgOQ8i2UiSAhAAAIQWBIBkvOSVpu5QgACEIDALAiQ nGexTAQJAQhAAAJLIkByXtJqM1cIQAACEJgFAZLzLJaJICEAAQhAYEkESM5LWm3mCgEIQAACsyBA cp7FMhEkBCAAAQgsiQDJeUmrzVwhAAEIQGAWBEjOs1gmgoQABCAAgSURIDkvabWZKwQgAAEIzIIA yXkWy0SQEIAABCCwJAIk5yWtNnOFAAQgAIFZECA5z2KZCBICEIAABJZEgOS8pNVmrhCAAAQgMAsC JOdZLBNBQgACEIDAkgiQnJe02swVAhCAAARmQYDkPItlIkgIQAACEFgSAZLzklabuUIAAhCAwCwI kJxnsUwECQEIQAACSyJAcl7SajNXCEAAAhCYBQGS8yyWiSAhAAEIQGBJBP49nZ3ZxXRhT6MAAAAA SUVORK5CYII= --Apple-Mail-EC74279A-4DF5-4220-92C1-0160A05C34D0-- --Apple-Mail-8553AAB1-BA13-48E4-8463-ED75B513B5D8-- From finlayson@live555.com Fri Feb 3 01:46: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 7655C21F85FC for ; Fri, 3 Feb 2012 01:46:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bAS3u2gwQTt8 for ; Fri, 3 Feb 2012 01:46:33 -0800 (PST) Received: from ns.live555.com (ns.live555.com [4.79.217.242]) by ietfa.amsl.com (Postfix) with ESMTP id EF69621F85F4 for ; Fri, 3 Feb 2012 01:46:32 -0800 (PST) Received: from [127.0.0.1] (localhost.live555.com [127.0.0.1]) by ns.live555.com (8.14.4/8.14.4) with ESMTP id q139kVtN059955 for ; Fri, 3 Feb 2012 01:46:31 -0800 (PST) (envelope-from finlayson@live555.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: Ross Finlayson In-Reply-To: <624219B0-720E-44CC-9390-7C823669DE11@yle.fi> Date: Fri, 3 Feb 2012 01:46:31 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <2F892495-3F68-4E90-8D48-6CAAB7FB688F@live555.com> References: <624219B0-720E-44CC-9390-7C823669DE11@yle.fi> To: payload@ietf.org X-Mailer: Apple Mail (2.1251.1) Subject: Re: [payload] draft-rea-payload-rtp-aptx-01 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: Fri, 03 Feb 2012 09:46:33 -0000 IMHO, the "aux=3Dout-of-bound-aux" and "aux-port: " = mechanism - for specifying a separate port number on which an "auxiliary = data stream" should be sent - needs closer scrutiny. I don't know of = another RTP payload format that uses a separate port number that's = specified in a SDP "a=3D" parameter line, rather than on the "m=3D" = line. This raises lots of questions - for example, do packets on the = "auxiliary data stream" share the same RTP sequence number and timestamp = space as the 'main stream'? And what about RTCP? Does anyone actually implement sending the "auxiliary data stream" on a = separate port number? If not, then perhaps this feature should be = removed from the specification... Ross. From Rea@worldcastsystems.com Fri Feb 3 08:42:30 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 DEC9C21F848B for ; Fri, 3 Feb 2012 08:42:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=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 blECRw9w3EzA for ; Fri, 3 Feb 2012 08:42:30 -0800 (PST) Received: from mailgate.aptcodecs.com (mailgate.aptcodecs.com [217.33.179.85]) by ietfa.amsl.com (Postfix) with ESMTP id 51C2021F846F for ; Fri, 3 Feb 2012 08:42:28 -0800 (PST) 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_01CCE292.D04420AF" Date: Fri, 3 Feb 2012 16:42:25 -0000 Message-ID: <8C4E0C2409735E4FBC22D754A238F94D02A4BE9C@APTSBS.apt.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [payload] draft-rea-payload-rtp-aptx-01 Thread-Index: AczikrMEI1VzEmkaRf+SJgC8FA5MOw== From: "Derrick Rea" To: Subject: Re: [payload] draft-rea-payload-rtp-aptx-01 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: Fri, 03 Feb 2012 16:42:31 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCE292.D04420AF Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks for the comments. I've grouped the answers together into this = post. Derrick _________________________________________________________________________= _________________________________________________________ Answer to Ross Finlayson, Sent: 03 February 2012 01:46, Subject: Re: = [payload] draft-rea-payload-rtp-aptx-01 =20 >> IMHO, the "aux=3Dout-of-bound-aux" and "aux-port: " = mechanism - for specifying a separate port number on which an=20 >> "auxiliary data stream" should be sent - needs closer scrutiny. I = don't know of another RTP payload format that uses a separate port=20 >> number that's specified in a SDP "a=3D" parameter line, rather than = on the "m=3D" line. =20 >> This raises lots of questions - for example, do packets on the = "auxiliary data stream" share the same RTP sequence number and=20 >> timestamp space as the 'main stream'? And what about RTCP? =20 >> Does anyone actually implement sending the "auxiliary data stream" on = a separate port number? If not, then perhaps this feature should=20 >> be removed from the specification... =20 Ross, =20 I now see that defining the "aux=3Dout-of-bound-aux" and "aux-port: = " mechanism as a media type attribute is not correct. = Definitely makes more sense to define any out of band aux stream in the = session using the current media type definitions i.e. = "m=3Dtext","m=3Dapplication", or "m=3Dmessage". I will update this in = the next version of the draft. Thanks Ross! _________________________________________________________________________= _________________________________________________________ Answer to Kari M=E4enp=E4=E4, Sent: 02 February 2012 12:02, Subject: Re: = [payload] draft-rea-payload-rtp-aptx-01 Thanks kari, I will fix this in the next version of the draft. _________________________________________________________________________= _________________________________________________________ Answer to Michel Quaix, Sent: 02 February 2012 12:02, Subject: Re: = [payload] draft-rea-payload-rtp-aptx-01 Thanks Michael, I will fix these mistakes in the next version of the = draft. _________________________________________________________________________= _______________________________________________________ =20 Answer to Hans-Heinrich Hansen, Sent: 01 February 2012 12:02, Subject: = Re: [payload] draft-rea-payload-rtp-aptx-01 =20 >> I think that two types of Standard apt-X modes are available: "with = sync"and "without sync". How these modes will be signalled or could one = type ignored? Answer - Yes, Standard apt-X and E apt-X do have "with sync"and "without = sync" configurations. I've also not included the ability to embedded = auxilliary data into the left, right or both configuration that Standard = apt-X allows. I propose adding =20 1) A media type attribute embedded-sync =3D off/on that applies to both = variants of apt-X=20 2) Media type attributes embedded-aux-left=3Doff/on and = embedded-aux-right=3Doff/on that apply to the Standard apt-X variant = only. 3) A Media type attributes embedded-aux=3Doff/on that applies to the = Enhanced apt-X variant only. If there are no objections I'll update section 7 of internet draft with = these changes. I will also update section 8 "IANA Considerations" with = these new attribute registrations (Roni Even comments on = draft-gmassey-avt-rtp-aptx-01, 6th May 2008 - = http://www.ietf.org/mail-archive/web/avt/current/msg09586.html). = _________________________________________________________________________= _________________________________________________________ I think there needs to be more discussion on whether synchronisation and = auxilliary data should either hard configured into an agreed = configuration for the internet-draft i.e. embedded-sync and embedded-aux = always on, or whether they should be signalled in an accompanying SDP = media type definition, i.e. as above. I personally prefer the = flexibility of signalling but does this break the aims of RTP? >> Colin Perkins wrote Apr 21 2008 = (http://www.ietf.org/mail-archive/web/avt/current/msg09533.html) >> I had two areas of concern from my initial review of the draft. = Firstly, the draft notes: =20 >> The apt-X and enhanced apt-X algorithms can carry an >> ancillary data stream and synchronisation information within the >> compressed audio stream without additional overhead. The ancillary >> data stream can be used to transport data or timecode data for >> synchronisation with video. =20 >> It's generally not desirable to include information within the = payload that's redundant with the RTP headers, and I wonder if the = ancillary >> data can be elided for RTP transmission (following the guidelines in = RFC 2736)?=20 =20 Does anyone have any options on this? Colin? =20 Thanks Hans-Heinrich! =20 =20 =20 ------_=_NextPart_001_01CCE292.D04420AF Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Thanks for the comments. I've grouped = the answers together into this post.

Derrick

______________________________________= _________________________________________________________________________= ___________________

Answer to Ross Finlayson, = Sent: 03 February 2012 01:46, Subject: Re: [payload] = draft-rea-payload-rtp-aptx-01

 

>> IMHO, the = "aux=3Dout-of-bound-aux" and "aux-port: = <port-number>" mechanism - for specifying a separate port = number on which an

>> "auxiliary data stream" = should be sent - needs closer scrutiny.=A0 I don't know of another RTP = payload format that uses a separate port

>> number that's = specified in a SDP "a=3D" parameter line, rather than on the = "m=3D" line.

 

>> This raises lots of questions - = for example, do packets on the "auxiliary data stream" share = the same RTP sequence number and

>> timestamp space as the 'main = stream'?=A0 And what about RTCP?

 

>> Does anyone actually implement = sending the "auxiliary data stream" on a separate port = number?=A0 If not, then perhaps this feature should

>> be removed from = the specification...

 

Ross,

 

I now see that defining = the "aux=3Dout-of-bound-aux" and "aux-port: = <port-number>" mechanism as a media type = attribute is not correct. Definitely makes more sense to define any out = of band aux stream in the session using the current media type = definitions i.e. "m=3Dtext","m=3Dapplication", or = "m=3Dmessage". I will update this in the next version of the = draft. Thanks Ross!

____________________________________________________________= ______________________________________________________________________

Answer to = Kari M=E4enp=E4=E4, Sent: 02 = February 2012 12:02, Subject: Re: [payload] = draft-rea-payload-rtp-aptx-01

Thanks kari, I = will fix this in the next version of the draft.

____________________________________________________________= ______________________________________________________________________

Answer to = Michel Quaix, Sent: 02 February 2012 12:02, Subject: Re: [payload] = draft-rea-payload-rtp-aptx-01

Thanks Michael, I = will fix these mistakes in the next version of the = draft.

____________________________________________________________= ____________________________________________________________________=

 

Answer to = Hans-Heinrich Hansen, Sent: 01 = February 2012 12:02, Subject: Re: [payload] = draft-rea-payload-rtp-aptx-01

 

>> I think = that two types of Standard apt-X modes are available: "with = sync"and "without sync". How these modes will be = signalled or could one type ignored?

Answer - = Yes, Standard apt-X and E apt-X do have = "with sync"and "without sync" configurations. I've = also not included the ability to embedded auxilliary data into the left, = right or both configuration that Standard apt-X allows. I propose = adding=A0

1) A media type = attribute embedded-sync =3D off/on that applies to both variants of = apt-X

2) Media type = attributes embedded-aux-left=3Doff/on and embedded-aux-right=3Doff/on = that apply to the Standard apt-X variant only.

3) A Media type = attributes embedded-aux=3Doff/on that applies to the Enhanced apt-X = variant only.

If there are no = objections I'll update section 7 of internet draft with these changes. I = will also update section 8 "IANA Considerations" with these = new attribute registrations (Roni Even comments on = draft-gmassey-avt-rtp-aptx-01, 6th May 2008 - = http://www.ietf.org/mail-archive/web/avt/current/msg09586.html). = _________________________________________________________________________= _________________________________________________________

I think there = needs to be more discussion on whether synchronisation and auxilliary = data should either hard configured into an agreed configuration for the = internet-draft i.e. embedded-sync and embedded-aux always on, or whether = they should be signalled in an accompanying SDP media type definition, = i.e. as above. I personally prefer the flexibility of signalling but = does this break the aims of RTP?

>> Colin = Perkins wrote Apr 21 2008 = (http://www.ietf.org/mail-archive/web/avt/current/msg09533.html)

>> = I had two areas of concern from my initial review of the draft. Firstly, = the draft notes:

 

>>         =       The apt-X and enhanced apt-X algorithms can carry = an

>>   ancillary data stream = and synchronisation information within the

>>   = compressed audio stream without additional overhead.  The = ancillary

>>   data stream can be = used to transport data or timecode data for

>>   = synchronisation with video.

 

>> It's generally not desirable to = include information within the payload that's redundant with the RTP = headers, and I wonder if the ancillary

>> data can be = elided for RTP transmission (following the guidelines in RFC = 2736)? 

 

Does anyone have any options on this? = Colin?

 

Thanks = Hans-Heinrich!

 

 

 

------_=_NextPart_001_01CCE292.D04420AF-- From glenzorn@gmail.com Mon Feb 13 21:27: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 6BBF621E805B for ; Mon, 13 Feb 2012 21:27:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.48 X-Spam-Level: X-Spam-Status: No, score=-3.48 tagged_above=-999 required=5 tests=[AWL=0.119, 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 LRC0+lk89NfI for ; Mon, 13 Feb 2012 21:27:13 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id CFC9621E804C for ; Mon, 13 Feb 2012 21:27:12 -0800 (PST) Received: by obbwd15 with SMTP id wd15so9017038obb.31 for ; Mon, 13 Feb 2012 21:27:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=RzMopnr9DfQN9cvh+DlczorGrnYyU8KC0L+/em2B9as=; b=vqT05XoWDbEjo89Ih9E8h+C4vswB07EQrsUHYlIkQKnKStPK2HbWHYXrrWt+Fi+DS1 jP9AEue9BvSaJ2oYD3jRr2qdXRm4W1t5wO34GPk2GDL2dRvbIZ7ppjnqApQv/yQpAo2H 2l+VipvYGisINFTdi0GfCZaYAB+tdIgnAPYcI= Received: by 10.182.222.102 with SMTP id ql6mr14466209obc.2.1329197232172; Mon, 13 Feb 2012 21:27:12 -0800 (PST) Received: from [192.168.1.98] (ppp-124-120-58-89.revip2.asianet.co.th. [124.120.58.89]) by mx.google.com with ESMTPS id z3sm7925442obx.5.2012.02.13.21.27.07 (version=SSLv3 cipher=OTHER); Mon, 13 Feb 2012 21:27:09 -0800 (PST) Message-ID: <4F39F0A8.2000400@gmail.com> Date: Tue, 14 Feb 2012 12:27:04 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: In-Reply-To: Content-Type: multipart/mixed; boundary="------------040103080909090501020402" Cc: "draft-ietf-payload-rtp-g718@tools.ietf.org" , "payload@ietf.org" , "payload-chairs@tools.ietf.org" Subject: Re: [payload] Mail regarding draft-ietf-payload-rtp-g718 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, 14 Feb 2012 05:27:13 -0000 This is a multi-part message in MIME format. --------------040103080909090501020402 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 2/14/2012 3:25 AM, Ali C. Begen (abegen) wrote: > Authors, > > We need to update the milestones for the payload wg. The current milestone is march 2011, which we passed way over. What is the status of this draft and when do you expect to make it final? The status is that I am waiting for a decision from the Chairs as to whether or not to include G718B in this document or not. If so, I will need somebody to supply text (or at least a copy of the G718B spec) -- see attachment. As far as I'm concerned, the draft (constrained to its original scope) has been ready for WGLC for at least a year. > > Thanks. > -acbegen --------------040103080909090501020402 Content-Type: message/rfc822; name="Attached Message" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Attached Message" X-Account-Key: account1 X-Mozilla-Keys: Received: (qmail 2915 invoked from network); 7 Jul 2011 02:30:29 -0000 Received: from unknown (HELO p3pismtp01-034.prod.phx3.secureserver.net) ([10.6.12.61]) (envelope-sender ) by p3plsmtp01-03.prod.phx3.secureserver.net (qmail-1.03) with SMTP for ; 7 Jul 2011 02:30:29 -0000 X-IronPort-Anti-Spam-Result: Ap8BAOkWFU5AqmIqnGdsb2JhbABThEKjUBQBAQEBAQgUCTmIerIJkGGFKoENBIdEhhSKAIsy Received: from zinfandel.tools.ietf.org ([64.170.98.42]) by p3pismtp01-034.prod.phx3.secureserver.net with ESMTP; 06 Jul 2011 19:30:29 -0700 Received: from p3plsmtpa06-05.prod.phx3.secureserver.net ([173.201.192.106]) by zinfandel.tools.ietf.org with smtp (Exim 4.76) (envelope-from ) id 1QeeMF-0004Yl-Qr for draft-ietf-payload-rtp-g718@tools.ietf.org; Wed, 06 Jul 2011 19:30:28 -0700 Received: (qmail 25542 invoked from network); 7 Jul 2011 02:30:19 -0000 Received: from unknown (124.120.168.67) by p3plsmtpa06-05.prod.phx3.secureserver.net (173.201.192.106) with ESMTP; 07 Jul 2011 02:30:19 -0000 Message-ID: <4E151A34.4000104@net-zen.net> Date: Thu, 07 Jul 2011 09:30:12 +0700 From: Glen Zorn Organization: Network Zen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" CC: draft-ietf-payload-rtp-g718@tools.ietf.org, payload-chairs@tools.ietf.org References: <04CAD96D4C5A3D48B1919248A8FE0D540F6926F0@xmb-sjc-215.amer.cisco.com> <4E145BBF.7080806@net-zen.net> <04CAD96D4C5A3D48B1919248A8FE0D540F69274D@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540F69274D@xmb-sjc-215.amer.cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: multipart/mixed; boundary="------------060204000506030407090206" X-SA-Exim-Connect-IP: 173.201.192.106 X-SA-Exim-Rcpt-To: draft-ietf-payload-rtp-g718@tools.ietf.org X-SA-Exim-Mail-From: gwz@net-zen.net X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on zinfandel.tools.ietf.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.1 Subject: Re: Mail regarding draft-ietf-payload-rtp-g718 X-SA-Exim-Version: 4.2.1 (built Mon, 22 Mar 2010 06:51:10 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) List-ID: X-Nonspam: None This is a multi-part message in MIME format. --------------060204000506030407090206 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 7/6/2011 10:17 PM, Ali C. Begen (abegen) wrote: >> On 7/6/2011 6:27 PM, Ali C. Begen (abegen) wrote: >>> Authors, >>> >>> Where are we with this draft? Are there any outstanding issues or are we getting close to a point to ask for a WG review >> and last call? >> >> I was under the impression that this was in an indefinite holding >> pattern waiting from some progress on the part of ISO. The attached >> message was the last activity AFAIK; I don't believe that there was any >> response. > > Who would know the story on the ISO side? I have no idea; I've never been involved w/ISO, nor do I have access to their working documents. > > BTW, I got a bounce from ari.lakaniemi@nokia.com ... Yes. This would seem not to bode well for participation from Ari. --------------060204000506030407090206 Content-Type: text/x-vcard; charset=utf-8; name="gwz.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="gwz.vcf" begin:vcard fn:Glen Zorn n:Zorn;Glen org:Network Zen adr:;;;Seattle;WA;;USA email;internet:gwz@net-zen.net tel;cell:+66 87 040 4617 note:PGP Key Fingerprint: DAD3 F5D3 ACE6 4195 9C5C 2EE1 6E17 B5F6 5953 B45F version:2.1 end:vcard --------------060204000506030407090206-- --------------040103080909090501020402-- From abegen@cisco.com Tue Feb 14 10:34:36 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 8254221E80A1 for ; Tue, 14 Feb 2012 10:34:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[AWL=1.000, 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 bD54oiOmXGpR for ; Tue, 14 Feb 2012 10:34:35 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id D2A0021F85E0 for ; Tue, 14 Feb 2012 10:34:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=334; q=dns/txt; s=iport; t=1329244476; x=1330454076; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=8qfQOE3t4fR8PGGHTtzunM+Omfi7M+gwUCQ1ELuO57M=; b=Uro5A1pkozIaD4eLHbvUgffP+DQRPDKNgiVzwXvnWKtMdvg4tvpIcrh+ Gg281iB/Kvw91Kc5dvw+AUFgIL/NaGnJzu4ycoC3xeqdKpAaqxuEockBW hfaZzOpwHqKIIUyHMJfY+GtjurAqnfz9DOG41US1FqPOQX6NdygczZgkK E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAASoOk+tJXHA/2dsb2JhbABDsEyBB4F0AQQSAXgBKlYmAQQbGodjmQCBJwGeYQSLZBEPHAgBAQIEAwIBAQMKBAcDGgECAQICg3MIgxZjBIgXn38 X-IronPort-AV: E=Sophos;i="4.73,417,1325462400"; d="scan'208";a="58880294" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-8.cisco.com with ESMTP; 14 Feb 2012 18:34:35 +0000 Received: from xht-rcd-x01-p.cisco.com (xht-rcd-x01-p.cisco.com [173.37.178.212]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id q1EIYZP4025597 for ; Tue, 14 Feb 2012 18:34:35 GMT Received: from xmb-rcd-x01-p.cisco.com ([169.254.3.213]) by xht-rcd-x01-p.cisco.com ([173.37.178.212]) with mapi id 14.02.0247.003; Tue, 14 Feb 2012 10:34:35 -0800 From: "Ali C. Begen (abegen)" To: "payload@ietf.org" Thread-Topic: WGLC for draft-ietf-payload-vp8-03 ending March 1st Thread-Index: AczrRVxjReHrfWv2TROUTdcmKeO0cA== Date: Tue, 14 Feb 2012 18:34:35 +0000 Message-ID: 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-18708.006 x-tm-as-result: No--33.211400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 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, 14 Feb 2012 18:34:36 -0000 WG, This is to start the WGLC for the VP8 draft.=20 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 b= ut please wait till the WGLC ends for a revision. -acbegen From chung.cheung.chu@ericsson.com Wed Feb 15 06:49: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 6BB8B21E8018 for ; Wed, 15 Feb 2012 06:49:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001, 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 fRdQcXPFKB57 for ; Wed, 15 Feb 2012 06:49:22 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0298121F8605 for ; Wed, 15 Feb 2012 06:49:21 -0800 (PST) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q1FEnJc9009414; Wed, 15 Feb 2012 08:49:21 -0600 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.135]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 15 Feb 2012 09:49:19 -0500 From: Chung Cheung Chu To: "payload@ietf.org" , "Fang, Zheng" Date: Wed, 15 Feb 2012 09:49:18 -0500 Thread-Topic: Comments to "draft-ietf-avt-rtp-evrc-nw-05" Thread-Index: Aczr8P6xhrNUyUn1ThSZWyOLVQQldQ== Message-ID: <26490BBDEEACA14EA1A0070367B3ADBDBDDE752422@EUSAACMS0702.eamcs.ericsson.se> 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_26490BBDEEACA14EA1A0070367B3ADBDBDDE752422EUSAACMS0702e_" MIME-Version: 1.0 Subject: [payload] Comments to "draft-ietf-avt-rtp-evrc-nw-05" 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, 15 Feb 2012 14:49:27 -0000 --_000_26490BBDEEACA14EA1A0070367B3ADBDBDDE752422EUSAACMS0702e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Background "draft-ietf-avt-rtp-evrc-nw-05" for EVRC-NW codec payload format specificat= ion defines the SDP attribute "mode-set-recv" and the "MMM" mode change req= uest field in the interleaved/bundled payload format for media type EVRCNW.= The attribute "mode-set-recv" presents a list of modes which could includ= e mode-0 for wideband support and/or mode-1 through mode-7 for narrowband s= upport. A communication entity can send the SDP attribute "mode-set-recv" = to inform its communication partner at the far end of the entity's preferen= ce of incoming traffic for the call session. Absence of this parameter sig= nals the preference of mode set {1,2,3,4,5,6,7} for narrowband incoming tra= ffic only. The "MMM" mode change request field in the interleaved/bundled = payload format is a dynamic mechanism reflecting a specific incoming mode t= ype preferred by a communication entity during a call session. This contribution presents three change proposals to clarify the interpreta= tions and usage of these two mode preference specification mechanisms. Proposal 1 When a communication entity receives from the far end partner a mode change= request indicating a preference for narrowband traffic, "draft-ietf-avt-rt= p-evrc-nw-05" recommends the communication entity to operate its EVRC-NW en= coder in narrowband mode and transmit narrowband traffic to the far end par= tner. It is proposed that the draft mandates a communication entity to ope= rate its EVRC-NW encoder in narrowband mode and transmit narrowband traffic= to the far end partner in the event of receiving a MMM mode change request= for narrowband traffic. This change is necessary because the SDP attribute "mode-set-recv" may not = be updated during a call session. In an exemplary configuration, a mobile-= mobile EVRC-NW wideband communication is established between System A and S= ystem B where the two systems sent mode-set-recv=3D{0,1,2,3,4,5,6,7} to eac= h other at call setup and MMM =3D 0 during the call. System A is hard hand= overed to System C which supports EVRC-NW narrowband modes only. System C = does not send "mode-set-recv" to System B during the handover. After hando= ver, System C sends MMM with its value set to one of the narrowband modes t= o System B. Upon receiving the MMM mode change request with narrowband dec= oding preference, System B must switch to operate in narrowband mode to tra= nsmit narrowband encoded traffic to System C. Otherwise, System C's failur= e to decode wideband traffic will lead to communication failure. Original text (section 10) "A mode request with MMM=3D1, 2, ..., or 7 from a communication partner is = an implicit indication of the partner's EVRCNW narrowband decoding preferen= ce. The encoder of an EVRCNW node receiving the request should honor the r= equest and operate in narrowband mode." Modified text (section 10) "A mode request with MMM=3D1, 2, ..., or 7 from a communication partner is = an implicit indication of the partner's EVRC-NW narrowband decoding prefere= nce. The encoder of an EVRC-NW node receiving the request shall honor the = request and operate in narrowband mode." Proposal 2 This proposal suggests editorial changes to further clarify the roles of th= e SDP attribute "mode-set-recv" and the "MMM" mode change request field to = avoid potential mis-interpretation and mis-use of the two mechanisms and to= ensure proper EVRC-NW decoding preference communication. Original text (section 10) Conversely, if mode 0 is not preferred, then there is no indication that mo= de 0 is supported. Modified text (section 10) Conversely, If mode 0 is not preferred for media type EVRCNW0 or EVRCNW1, t= hen there is no indication that mode 0 is supported. However absence of th= is parameter or absence of mode 0 in this parameter for media type EVRCNW s= hall not preclude mode 0 support during a call where mode 0 may be requeste= d via the MMM field. Original text (section 10) Note, during an active call session using the interleaved/bundled packet fo= rmat, the MMM mode request received from a communication partner complement= s the mode set information in mode-set-recv. A mode request with MMM=3D0 f= rom a communication partner is an implicit indication of the partner's EVRC= NW wideband decoding capability and preference. Modified text (section 10) Note, during an active call session using the interleaved/bundled packet fo= rmat, the MMM mode request received from a communication partner can contai= n a mode request different than the values in the last mode-set-recv attrib= ute. The partner's EVRC-NW wideband decoding capability is determined by t= he latest mode-set-recv attribute or MMM mode request field. For example, a= complements the mode set information in mode-set-recv. A mode request wit= h MMM=3D0 from a communication partner is an implicit indication of the par= tner's EVRC-NW wideband decoding capability and preference. Proposal 3 The MMM mode change request field in the interleaved/bundled payload format= provides a means for an EVRC-NW receiver to specify the preferred wideband= /narrowband operating mode types. This facilitates the support of the EVRC= -NW codec design principle to allow a trade-off between subjective quality = performance and system capacity consideration. This proposal suggests an a= ddition of a section to the draft with a guideline for mode change request = handling in consideration of the EVRC-NW codec design principle. This guid= eline is recommended to ensure end-to-end call performance, for example whe= n there is a mismatch between the local mode support capability/preference = and the MMM mode change requests received from the far end. Suggested new text Mode Change Request/Response Considerations The Interleaved/Bundled packet format for the EVRC family of vocoders suppo= rts a 3-bit field (MMM) that a communication node can use to indicate its p= referred compression mode to an opposite node. The concept of the compressi= on mode (also known as Capacity Operating Point) was introduced to allow a = controlled trade-off between voice quality and channel capacity. The notion= makes it possible to exercise vocoders at the highest possible (average) b= it-rate (hence, highest voice quality) when the network is lightly loaded. = Conversely, once the network load increases the vocoders can be requested t= o operate at lower average bit-rates so as to absorb the additional network= load without causing an undue increase in the frame-erasure rates; the und= erlying premise is that while a higher bit-rate improves the vocoder perfor= mance, it also increases the network loading, risking a sharp decline in vo= ice quality should the frame-erasure rate be too high. By contrast, a lower= bit-rate mode of operation can result in accommodation of the additional n= etwork load without causing unduly high frame-erasure rates, resulting in b= etter overall quality despite the inherently lower voice quality of the low= er bit-rate mode of the vocoder. Accordingly, the MMM field should be used to request the far-end to transmi= t compressed-speech using a mode that provides the best balance between voi= ce quality and capacity. However, in the case of mobile-mobile calls, for e= xample, there are two wireless sides involved, each with a potentially diff= erent network load level and hence a different preferred mode. In such case= s, achieving optimal end-to-end performance depends on coherent management = of the operative mode by the two sides. This requires that even if the loca= l node prefers a higher bit-rate vocoder mode, it should adjust to a lower = bit-rate mode if requested by the far end, in order to avoid potentially-hi= gh frame erasure rates due to heavy load at the far end network. For simila= r reasons, in cases where a mode requested by the far end should not be sup= ported, it might still be beneficial to consider switching to a supported v= ocoder mode corresponding to a lower average bit-rate than requested. It is= recommended that the next lower average bit-rate supported vocoder mode is= used for encoding when a mode requested by the far end is not supported. A wideband-capable endpoint can use the information conveyed by the C-bit o= f the RTP payload header to determine the optimal mode to request of the fa= r end. If the far end cannot provide Mode0 packets (C-bit=3D1), then the ch= oice of MMM can be based strictly on the local network load. If the C-bit i= ndicates remote end's Mode0 encoding capability (C-bit=3D0), then even if t= he local network load is not light, Mode0 can be requested knowing definiti= vely that it will be supported. This will permit operators to treat wideban= d-capable mobiles preferentially, should they wish to adopt such policy. The three proposed changes above are for media type EVRCNW using interleave= d/bundled payload format only. They are not applicable to media type EVRCN= W0 and EVRCNW1 payload formats where the MMM mode change request field is n= ot supported. Thanks, CC Chung-Cheung Chu Ericsson ECN: 810-16713 External: +514-461-6713 or +514 345-7900 x46489 This Communication is Confidential. We only send and receive email on the = basis of the terms set out at www.ericsson.com/email_disclaimer. --_000_26490BBDEEACA14EA1A0070367B3ADBDBDDE752422EUSAACMS0702e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Background
 
"draft-ietf-avt-rtp-= evrc-nw-05" for EVRC-NW codec payload= format specification defines the SDP attribute "mode-set-recv" a= nd the "MMM" mode change request field in the interleaved/bundled payload format for media type EVRCNW.  The attribute "mode-set-re= cv" presents a list of modes which could include mode-0 for wideband s= upport and/or mode-1 through mode-7 for narrowband support.  A communi= cation entity can send the SDP attribute "mode-set-recv" to inform its communication partner at the far end of the entity's preferen= ce of incoming traffic for the call session.  Absence of this paramete= r signals the preference of mode set {1,2,3,4,5,6,7} for narrowband incomin= g traffic only.  The "MMM" mode change request field in the interleaved/bundled payload format is a dynamic mechan= ism reflecting a specific incoming mode type preferred by a communication e= ntity during a call session.
 
This contribution presents three change proposals to = clarify the interpretations and usage of these two mode preference specific= ation mechanisms.
 
Proposal 1
 
When a communication entity receives from the far end= partner a mode change request indicating a preference for narrowband traff= ic, "draft-ietf-avt-rtp-evrc-nw-05&q= uot; recommends the communication entity to operate its EVRC-NW encoder in narrowband mode and transmit narrowband t= raffic to the far end partner.  It is proposed that the draft mandates= a communication entity to operate its EVRC-NW encoder in narrowband mode a= nd transmit narrowband traffic to the far end partner in the event of receiving a MMM mode change request for nar= rowband traffic. 
 
This change is necessary because the SDP attribute &q= uot;mode-set-recv" may not be updated during a call session.  In = an exemplary configuration, a mobile-mobile EVRC-NW wideband communication = is established between System A and System B where the two systems sent mode-set-recv=3D{0,1,2,3,4,5,6,7} to each other at cal= l setup and MMM =3D 0 during the call.  System A is hard handovered to= System C which supports EVRC-NW narrowband modes only.  System C does= not send "mode-set-recv" to System B during the handover.  After handover, System C sends MMM with its value set to on= e of the narrowband modes to System B.  Upon receiving the MMM mode ch= ange request with narrowband decoding preference, System B must switch to o= perate in narrowband mode to transmit narrowband encoded traffic to System C.  Otherwise, System C's failure to decode = wideband traffic will lead to communication failure.
 
Original text (section= 10)
 
"A mode request = with MMM=3D1, 2, …, or 7 from a communication partner is an implicit = indication of the partner's EVRCNW narrowband decoding preference.  Th= e encoder of an EVRCNW node receiving the request should honor the request and operate in narrowband mode."
 
Modified text (section 10)
 
"A mode request = with MMM=3D1, 2, …, or 7 from a communication partner is an implicit = indication of the partner's EVRC-NW narrowba= nd decoding preference.  The encoder of an EVRC-NW node receiving the request shall honor the r= equest and operate in narrowband mode."
 
 
Proposal 2
 
This proposal suggests editorial changes to further c= larify the roles of the SDP attribute "mode-set-recv" and the &qu= ot;MMM" mode change request field to avoid potential mis-interpretatio= n and mis-use of the two mechanisms and to ensure proper EVRC-NW decoding preference communication.
 
Original text (section 10)
 
Conversely, if mode 0= is not preferred, then there is no indication that mode 0 is supported.
 
Modified text (section 10)
 
Conversely, If mode 0 is not preferre= d for media type EVRCNW0 or EVRCNW1, then th= ere is no indication that mode 0 is supported.  However absence of this parameter or absence of mode 0 in this param= eter for media type EVRCNW shall not preclude mode 0 support during a call = where mode 0 may be requested via the MMM field.
 
 
 
Original text (section 10)
 
Note, during an activ= e call session using the interleaved/bundled packet format, the MMM mode re= quest received from a communication partner complements the mode set inform= ation in mode-set-recv.  A mode request with MMM=3D0 from a communication partner is an implicit indication of the = partner's EVRCNW wideband decoding capability and preference.
 
Modified text (section 10)
 
Note, during an activ= e call session using the interleaved/bundled packet format, the MMM mode re= quest received from a communication partner can con= tain a mode request different than the values in the last mode-set-recv attribute.  The partner’s EVRC-= NW wideband decoding capability is determined by the latest mode-set-recv a= ttribute or MMM mode request field. For example, a complements the mode set information in mode-set-recv.  A mode request with MMM=3D0 from a = communication partner is an implicit indication of the partner's EVRC-NW wideband decoding capability and preference.
 
 
Proposal 3
 
 
The MMM mode change request field in the interleaved/= bundled payload format provides a means for an EVRC-NW receiver to specify = the preferred wideband/narrowband operating mode types.  This facilita= tes the support of the EVRC-NW codec design principle to allow a trade-off between subjective quality performance and s= ystem capacity consideration.  This proposal suggests an addition of a= section to the draft with a guideline for mode change request handling in = consideration of the EVRC-NW codec design principle.  This guideline is recommended to ensure end-to-end call pe= rformance, for example when there is a mismatch between the local mode supp= ort capability/preference and the MMM mode change requests received from th= e far end.
 
Suggested new text
 
Mode Change Request/Response Consid= erations
The Interleaved/Bundled packet= format for the EVRC family of vocoders supports a 3-bit field (MMM) that a= communication node can use to indicate its preferred compression mode to an opposite node. The concept of the comp= ression mode (also known as Capacity Operating Point) was introduced to all= ow a controlled trade-off between voice quality and channel capacity. The n= otion makes it possible to exercise vocoders at the highest possible (average) bit-rate (hence, highest voice q= uality) when the network is lightly loaded. Conversely, once the network lo= ad increases the vocoders can be requested to operate at lower average bit-= rates so as to absorb the additional network load without causing an undue increase in the frame-erasure rates; = the underlying premise is that while a higher bit-rate improves the vocoder= performance, it also increases the network loading, risking a sharp declin= e in voice quality should the frame-erasure rate be too high. By contrast, a lower bit-rate mode of operation can resul= t in accommodation of the additional network load without causing unduly hi= gh frame-erasure rates, resulting in better overall quality despite the inh= erently lower voice quality of the lower bit-rate mode of the vocoder.
Accordingly, the MMM field sho= uld be used to request the far-end to transmit compressed-speech using a mo= de that provides the best balance between voice quality and capacity. However, in the case of mobile-mobile calls, fo= r example, there are two wireless sides involved, each with a potentially d= ifferent network load level and hence a different preferred mode. In such c= ases, achieving optimal end-to-end performance depends on coherent management of the operative mode by the two= sides. This requires that even if the local node prefers a higher bit-rate= vocoder mode, it should adjust to a lower bit-rate mode if requested by th= e far end, in order to avoid potentially-high frame erasure rates due to heavy load at the far end network. For similar r= easons, in cases where a mode requested by the far end should not be suppor= ted, it might still be beneficial to consider switching to a supported voco= der mode corresponding to a lower average bit-rate than requested. It is recommended that the next lower aver= age bit-rate supported vocoder mode is used for encoding when a mode reques= ted by the far end is not supported.
A w= ideband-capable endpoint can use the information conveyed by the C-bit of t= he RTP payload header to determine the optimal mode to request of the far e= nd. If the far end cannot provide Mode0 packets (C-bit=3D1), then the choice of MMM can be based strictly on the lo= cal network load. If the C-bit indicates remote end’s Mode0 encoding = capability (C-bit=3D0), then even if the local network load is not light, M= ode0 can be requested knowing definitively that it will be supported. This will permit operators to treat wideband-cap= able mobiles preferentially, should they wish to adopt such policy.<= /div>
 
 
The three proposed changes above are for media type E= VRCNW using interleaved/bundled payload format only.  They are not app= licable to media type EVRCNW0 and EVRCNW1 payload formats where the MMM mod= e change request field is not supported.
 
 
 
Thanks,
 
CC
 
Chung-Cheung Chu
Ericsson
ECN:       810-16713
External: +514-461-6713   or  = ; +514 345-7900 x46489
 
This Communication= is Confidential.  We only send and receive email on the basis of the = terms set out at www.ericsson.com/email_disclaimer<= i>.
 
 
 
 --_000_26490BBDEEACA14EA1A0070367B3ADBDBDDE752422EUSAACMS0702e_-- From stewe@stewe.org Wed Feb 15 14:32:57 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 AAC1921F85A4 for ; Wed, 15 Feb 2012 14:32:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001, 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 lBBNILLT1Pgz for ; Wed, 15 Feb 2012 14:32:54 -0800 (PST) Received: from DB3EHSOBE001.bigfish.com (db3ehsobe003.messaging.microsoft.com [213.199.154.141]) by ietfa.amsl.com (Postfix) with ESMTP id A614821F8570 for ; Wed, 15 Feb 2012 14:32:53 -0800 (PST) Received: from mail67-db3-R.bigfish.com (10.3.81.251) by DB3EHSOBE001.bigfish.com (10.3.84.21) with Microsoft SMTP Server id 14.1.225.23; Wed, 15 Feb 2012 22:32:52 +0000 Received: from mail67-db3 (localhost [127.0.0.1]) by mail67-db3-R.bigfish.com (Postfix) with ESMTP id 0F40A340440 for ; Wed, 15 Feb 2012 22:32:52 +0000 (UTC) X-SpamScore: 3 X-BigFish: PS3(zzzz1202h1082kzzz2fh2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:157.56.240.133; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0710HT001.namprd07.prod.outlook.com; RD:none; EFVD:NLI Received-SPF: pass (mail67-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=BL2PRD0710HT001.namprd07.prod.outlook.com ; .outlook.com ; Received: from mail67-db3 (localhost.localdomain [127.0.0.1]) by mail67-db3 (MessageSwitch) id 1329345169238514_7055; Wed, 15 Feb 2012 22:32:49 +0000 (UTC) Received: from DB3EHSMHS016.bigfish.com (unknown [10.3.81.226]) by mail67-db3.bigfish.com (Postfix) with ESMTP id 2D0E410004A for ; Wed, 15 Feb 2012 22:32:49 +0000 (UTC) Received: from BL2PRD0710HT001.namprd07.prod.outlook.com (157.56.240.133) by DB3EHSMHS016.bigfish.com (10.3.87.116) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 15 Feb 2012 22:32:48 +0000 Received: from BL2PRD0710MB349.namprd07.prod.outlook.com ([169.254.1.128]) by BL2PRD0710HT001.namprd07.prod.outlook.com ([10.255.102.36]) with mapi id 14.16.0117.001; Wed, 15 Feb 2012 22:32:48 +0000 From: Stephan Wenger To: "payload@ietf.org" Thread-Topic: [payload] WGLC for draft-ietf-payload-vp8-03 ending March 1st Thread-Index: AQHM7DG+J0rYbeQeSU+9HRpTEmhoPw== Date: Wed, 15 Feb 2012 22:32:47 +0000 Message-ID: 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: <28078B53FB5BCA4DA4A4114C5EAC6E6D@namprd07.prod.outlook.com> 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, 15 Feb 2012 22:32:57 -0000 Hi, >From the draft: " 6. Payload Format Parameters This payload format has no parameters. " I would suggest that, as the very minimum, some indication of computational complexity of the bitstream ought to be signaled. My understanding of VP8 is that it can support bitstream that differ in decoding complexity by several orders of magnitude (different picture sizes and frame rates). The more complex bitstreams cannot practically be decoded on lower end architectures (cell phones without HW acceleration). AFAIK, the most common way to signal decoding complexity is in units of macro blocks per second. Ranges of MBS/sec are sometime classified into "levels". In the light of this discussion I would argue that the second to last sentence of the security considerations section may be incorrect. The sentence reads=20 " This RTP payload format and its media decoder do not exhibit any significant non-uniformity in the receiver-side computational complexity for packet processing, and thus are unlikely to pose a denial-of-service threat due to the receipt of pathological Data. "=20 I would argue that VP8 carried inside the payload format as proposed does exhibit such a non-uniformity. I think I could trivially crash (or at least "freeze") a system including a VP8 decoder by modifying just a few packets of a complex packet stream, namely the packets containing the frame size. With previous standards, such an exploit was not easy, as it was trivially possible to reject bitstreams of too high complexity, and equally trivially possible to identify a non-compliant bitstream (in the sense of non-conformannt to a negotiated maximum "level"). There were some initial discussions about some of these topics a while back on the rtcweb list. Harald mentioned at the time that the VP8 payload relies on non-payload specified signaling for picture size. If that's your choice, the payload format should explain so, and how picture size ties into complexity signaling. If parameters are going to be included, I would suggest to also address the profile/version thing. VP8 contains hooks to support different versions and profiles (which, I believe, are not used at present). While I understand that it is possible to issue a new RFC for updated versions/added profiles of the payload spec and negotiate based on payload document number, it would IMO be cleaner and likely more future proof to signal profile and version (or simply the three bits representing both). Stephan =20 From zfang@qualcomm.com Wed Feb 22 09:59:00 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 3783821F883E for ; Wed, 22 Feb 2012 09:59:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.398 X-Spam-Level: X-Spam-Status: No, score=-105.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_OEM_S_DOL=1.2, 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 tNxBixMU5y3c for ; Wed, 22 Feb 2012 09:58:54 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id B479B21F8833 for ; Wed, 22 Feb 2012 09:58:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=zfang@qualcomm.com; q=dns/txt; s=qcdkim; t=1329933534; x=1361469534; 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"Fang,=20Zheng"=20|To:=20Chu ng=20Cheung=20Chu=20,=20"p ayload@ietf.org"=0D=0A=09|Subject:=20RE :=20Comments=20to=20"draft-ietf-avt-rtp-evrc-nw-05" |Thread-Topic:=20Comments=20to=20"draft-ietf-avt-rtp-evrc -nw-05"|Thread-Index:=20Aczr8P6xhrNUyUn1ThSZWyOLVQQldQFmm j7Q|Date:=20Wed,=2022=20Feb=202012=2017:58:53=20+0000 |Message-ID:=20|References:=20<26490BBDEEACA 14EA1A0070367B3ADBDBDDE752422@EUSAACMS0702.eamcs.ericsson .se>|In-Reply-To:=20<26490BBDEEACA14EA1A0070367B3ADBDBDDE 752422@EUSAACMS0702.eamcs.ericsson.se>|Accept-Language: =20en-US|Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|x-originating-ip:=20[172.30.39.5] |Content-Type:=20multipart/alternative=3B=0D=0A=09boundar y=3D"_000_E23CE350F3C94C4A834B4E7069CA56790D4D3EE4nasanex d01anaqu_"|MIME-Version:=201.0; bh=g3xcqZ2olBA5FSFBMFZTMOFynSlWo8fS03V4/5bYm8E=; b=w2bRE0Cw9riHjdc5P8hSc8ameIat1MoWLuW6zZvdnnVa9vVsdSwDuNBL okx8W5ETzd/L5WZI38xg5/XpPa1hYa53FMNcaAloetHuVCDjL/v86WVYc XWceqbHwepTQgxLhQfUXqybg7fwiyP6v5P73AYKCJmWJ3NTTz1h6LntrF M=; X-IronPort-AV: E=McAfee;i="5400,1158,6628"; a="163072501" Received: from ironmsg02-l.qualcomm.com ([172.30.48.16]) by wolverine02.qualcomm.com with ESMTP; 22 Feb 2012 09:58:53 -0800 X-IronPort-AV: E=Sophos;i="4.73,464,1325491200"; d="scan'208,217";a="119400076" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by ironmsg02-L.qualcomm.com with ESMTP/TLS/AES128-SHA; 22 Feb 2012 09:58:53 -0800 Received: from NASANEXD01A.na.qualcomm.com ([169.254.1.165]) by nasanexhc04.na.qualcomm.com ([172.30.48.17]) with mapi id 14.01.0339.001; Wed, 22 Feb 2012 09:58:53 -0800 From: "Fang, Zheng" To: Chung Cheung Chu , "payload@ietf.org" Thread-Topic: Comments to "draft-ietf-avt-rtp-evrc-nw-05" Thread-Index: Aczr8P6xhrNUyUn1ThSZWyOLVQQldQFmmj7Q Date: Wed, 22 Feb 2012 17:58:53 +0000 Message-ID: References: <26490BBDEEACA14EA1A0070367B3ADBDBDDE752422@EUSAACMS0702.eamcs.ericsson.se> In-Reply-To: <26490BBDEEACA14EA1A0070367B3ADBDBDDE752422@EUSAACMS0702.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.39.5] Content-Type: multipart/alternative; boundary="_000_E23CE350F3C94C4A834B4E7069CA56790D4D3EE4nasanexd01anaqu_" MIME-Version: 1.0 Subject: Re: [payload] Comments to "draft-ietf-avt-rtp-evrc-nw-05" 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, 22 Feb 2012 17:59:00 -0000 --_000_E23CE350F3C94C4A834B4E7069CA56790D4D3EE4nasanexd01anaqu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Chung-Cheung, Thank you for the proposal. These changes look good to me. I will incorpora= te these changes in the next version of this draft. Thanks, Zheng From: Chung Cheung Chu [mailto:chung.cheung.chu@ericsson.com] Sent: Wednesday, February 15, 2012 6:49 AM To: payload@ietf.org; Fang, Zheng Subject: Comments to "draft-ietf-avt-rtp-evrc-nw-05" Background "draft-ietf-avt-rtp-evrc-nw-05" for EVRC-NW codec payload format specificat= ion defines the SDP attribute "mode-set-recv" and the "MMM" mode change req= uest field in the interleaved/bundled payload format for media type EVRCNW.= The attribute "mode-set-recv" presents a list of modes which could includ= e mode-0 for wideband support and/or mode-1 through mode-7 for narrowband s= upport. A communication entity can send the SDP attribute "mode-set-recv" = to inform its communication partner at the far end of the entity's preferen= ce of incoming traffic for the call session. Absence of this parameter sig= nals the preference of mode set {1,2,3,4,5,6,7} for narrowband incoming tra= ffic only. The "MMM" mode change request field in the interleaved/bundled = payload format is a dynamic mechanism reflecting a specific incoming mode t= ype preferred by a communication entity during a call session. This contribution presents three change proposals to clarify the interpreta= tions and usage of these two mode preference specification mechanisms. Proposal 1 When a communication entity receives from the far end partner a mode change= request indicating a preference for narrowband traffic, "draft-ietf-avt-rt= p-evrc-nw-05" recommends the communication entity to operate its EVRC-NW en= coder in narrowband mode and transmit narrowband traffic to the far end par= tner. It is proposed that the draft mandates a communication entity to ope= rate its EVRC-NW encoder in narrowband mode and transmit narrowband traffic= to the far end partner in the event of receiving a MMM mode change request= for narrowband traffic. This change is necessary because the SDP attribute "mode-set-recv" may not = be updated during a call session. In an exemplary configuration, a mobile-= mobile EVRC-NW wideband communication is established between System A and S= ystem B where the two systems sent mode-set-recv=3D{0,1,2,3,4,5,6,7} to eac= h other at call setup and MMM =3D 0 during the call. System A is hard hand= overed to System C which supports EVRC-NW narrowband modes only. System C = does not send "mode-set-recv" to System B during the handover. After hando= ver, System C sends MMM with its value set to one of the narrowband modes t= o System B. Upon receiving the MMM mode change request with narrowband dec= oding preference, System B must switch to operate in narrowband mode to tra= nsmit narrowband encoded traffic to System C. Otherwise, System C's failur= e to decode wideband traffic will lead to communication failure. Original text (section 10) "A mode request with MMM=3D1, 2, ..., or 7 from a communication partner is = an implicit indication of the partner's EVRCNW narrowband decoding preferen= ce. The encoder of an EVRCNW node receiving the request should honor the r= equest and operate in narrowband mode." Modified text (section 10) "A mode request with MMM=3D1, 2, ..., or 7 from a communication partner is = an implicit indication of the partner's EVRC-NW narrowband decoding prefere= nce. The encoder of an EVRC-NW node receiving the request shall honor the = request and operate in narrowband mode." Proposal 2 This proposal suggests editorial changes to further clarify the roles of th= e SDP attribute "mode-set-recv" and the "MMM" mode change request field to = avoid potential mis-interpretation and mis-use of the two mechanisms and to= ensure proper EVRC-NW decoding preference communication. Original text (section 10) Conversely, if mode 0 is not preferred, then there is no indication that mo= de 0 is supported. Modified text (section 10) Conversely, If mode 0 is not preferred for media type EVRCNW0 or EVRCNW1, t= hen there is no indication that mode 0 is supported. However absence of th= is parameter or absence of mode 0 in this parameter for media type EVRCNW s= hall not preclude mode 0 support during a call where mode 0 may be requeste= d via the MMM field. Original text (section 10) Note, during an active call session using the interleaved/bundled packet fo= rmat, the MMM mode request received from a communication partner complement= s the mode set information in mode-set-recv. A mode request with MMM=3D0 f= rom a communication partner is an implicit indication of the partner's EVRC= NW wideband decoding capability and preference. Modified text (section 10) Note, during an active call session using the interleaved/bundled packet fo= rmat, the MMM mode request received from a communication partner can contai= n a mode request different than the values in the last mode-set-recv attrib= ute. The partner's EVRC-NW wideband decoding capability is determined by t= he latest mode-set-recv attribute or MMM mode request field. For example, a= complements the mode set information in mode-set-recv. A mode request wit= h MMM=3D0 from a communication partner is an implicit indication of the par= tner's EVRC-NW wideband decoding capability and preference. Proposal 3 The MMM mode change request field in the interleaved/bundled payload format= provides a means for an EVRC-NW receiver to specify the preferred wideband= /narrowband operating mode types. This facilitates the support of the EVRC= -NW codec design principle to allow a trade-off between subjective quality = performance and system capacity consideration. This proposal suggests an a= ddition of a section to the draft with a guideline for mode change request = handling in consideration of the EVRC-NW codec design principle. This guid= eline is recommended to ensure end-to-end call performance, for example whe= n there is a mismatch between the local mode support capability/preference = and the MMM mode change requests received from the far end. Suggested new text Mode Change Request/Response Considerations The Interleaved/Bundled packet format for the EVRC family of vocoders suppo= rts a 3-bit field (MMM) that a communication node can use to indicate its p= referred compression mode to an opposite node. The concept of the compressi= on mode (also known as Capacity Operating Point) was introduced to allow a = controlled trade-off between voice quality and channel capacity. The notion= makes it possible to exercise vocoders at the highest possible (average) b= it-rate (hence, highest voice quality) when the network is lightly loaded. = Conversely, once the network load increases the vocoders can be requested t= o operate at lower average bit-rates so as to absorb the additional network= load without causing an undue increase in the frame-erasure rates; the und= erlying premise is that while a higher bit-rate improves the vocoder perfor= mance, it also increases the network loading, risking a sharp decline in vo= ice quality should the frame-erasure rate be too high. By contrast, a lower= bit-rate mode of operation can result in accommodation of the additional n= etwork load without causing unduly high frame-erasure rates, resulting in b= etter overall quality despite the inherently lower voice quality of the low= er bit-rate mode of the vocoder. Accordingly, the MMM field should be used to request the far-end to transmi= t compressed-speech using a mode that provides the best balance between voi= ce quality and capacity. However, in the case of mobile-mobile calls, for e= xample, there are two wireless sides involved, each with a potentially diff= erent network load level and hence a different preferred mode. In such case= s, achieving optimal end-to-end performance depends on coherent management = of the operative mode by the two sides. This requires that even if the loca= l node prefers a higher bit-rate vocoder mode, it should adjust to a lower = bit-rate mode if requested by the far end, in order to avoid potentially-hi= gh frame erasure rates due to heavy load at the far end network. For simila= r reasons, in cases where a mode requested by the far end should not be sup= ported, it might still be beneficial to consider switching to a supported v= ocoder mode corresponding to a lower average bit-rate than requested. It is= recommended that the next lower average bit-rate supported vocoder mode is= used for encoding when a mode requested by the far end is not supported. A wideband-capable endpoint can use the information conveyed by the C-bit o= f the RTP payload header to determine the optimal mode to request of the fa= r end. If the far end cannot provide Mode0 packets (C-bit=3D1), then the ch= oice of MMM can be based strictly on the local network load. If the C-bit i= ndicates remote end's Mode0 encoding capability (C-bit=3D0), then even if t= he local network load is not light, Mode0 can be requested knowing definiti= vely that it will be supported. This will permit operators to treat wideban= d-capable mobiles preferentially, should they wish to adopt such policy. The three proposed changes above are for media type EVRCNW using interleave= d/bundled payload format only. They are not applicable to media type EVRCN= W0 and EVRCNW1 payload formats where the MMM mode change request field is n= ot supported. Thanks, CC Chung-Cheung Chu Ericsson ECN: 810-16713 External: +514-461-6713 or +514 345-7900 x46489 This Communication is Confidential. We only send and receive email on the = basis of the terms set out at www.ericsson.com/email_disclaimer. --_000_E23CE350F3C94C4A834B4E7069CA56790D4D3EE4nasanexd01anaqu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Chung-Cheung,

 <= /p>

Thank you for the proposa= l. These changes look good to me. I will incorporate these changes in the n= ext version of this draft.

 <= /p>

Thanks,=

Zheng

 <= /p>

 <= /p>

From: Chung Ch= eung Chu [mailto:chung.cheung.chu@ericsson.com]
Sent: Wednesday, February 15, 2012 6:49 AM
To: payload@ietf.org; Fang, Zheng
Subject: Comments to "draft-ietf-avt-rtp-evrc-nw-05"<= /o:p>

 

 

Background

 

"draft-ietf-avt-rtp-evrc-nw-05"= ; for EVRC-NW codec payload format specification defines = the SDP attribute "mode-set-recv" and the "MMM" mode change request fiel= d in the interleaved/bundled payload format for media type EVRCNW.  Th= e attribute "mode-set-recv" presents a list of modes which could = include mode-0 for wideband support and/or mode-1 through mode-7 for narrowband support.  A communication entity can send the SDP attribut= e "mode-set-recv" to inform its communication partner at the far = end of the entity's preference of incoming traffic for the call session.&nb= sp; Absence of this parameter signals the preference of mode set {1,2,3,4,5,6,7} for narrowband incoming traffic only.  Th= e "MMM" mode change request field in the interleaved/bundled payl= oad format is a dynamic mechanism reflecting a specific incoming mode type = preferred by a communication entity during a call session.

 

This contribution presents three change p= roposals to clarify the interpretations and usage of these two mode prefere= nce specification mechanisms.

 

Proposal 1

 

When a communication entity receives from= the far end partner a mode change request indicating a preference for narr= owband traffic, "draft-ietf-avt-rtp-evrc-nw-05" recommends the communication entity to operate its EVRC-NW encoder in n= arrowband mode and transmit narrowband traffic to the far end partner.  It is propos= ed that the draft mandates a communication entity to operate its EVRC-NW en= coder in narrowband mode and transmit narrowband traffic to the far end par= tner in the event of receiving a MMM mode change request for narrowband traffic. 

 

This change is necessary because the SDP = attribute "mode-set-recv" may not be updated during a call sessio= n.  In an exemplary configuration, a mobile-mobile EVRC-NW wideband communication is established between System A and System B where the two s= ystems sent mode-set-recv=3D{0,1,2,3,4,5,6,7} to each other at call setup a= nd MMM =3D 0 during the call.  System A is hard handovered to System C= which supports EVRC-NW narrowband modes only.  System C does not send "mode-set-recv" to System B d= uring the handover.  After handover, System C sends MMM with its value= set to one of the narrowband modes to System B.  Upon receiving the M= MM mode change request with narrowband decoding preference, System B must switch to operate in narrowband mode to transmit narrowband = encoded traffic to System C.  Otherwise, System C's failure to decode = wideband traffic will lead to communication failure.

 

Original text (section 10)= <= /o:p>

 

"A mode request with MMM=3D1, 2, …, or 7 from a= communication partner is an implicit indication of the partner's EVRCNW na= rrowband decoding preference.  The encoder of an EVRCNW node receiving the request should honor the request and operate in narrowband m= ode."

 

Modified text (section 10)<= span style=3D"font-family:"Arial","sans-serif"">

 

"A mode request with MMM=3D1, 2, …, or 7 from a= communication partner is an implicit indication of the partner's EVRC-NW narrowband decoding preference.  The encoder of an EVRC-NW node receivin= g the request shall honor the request and operate in n= arrowband mode."

 

 

Proposal 2

 

This proposal suggests editorial changes = to further clarify the roles of the SDP attribute "mode-set-recv"= and the "MMM" mode change request field to avoid potential mis-i= nterpretation and mis-use of the two mechanisms and to ensure proper EVRC-NW decoding pr= eference communication.

 

Original text (section 10)<= span style=3D"font-family:"Arial","sans-serif"">

 

Conversely, if mode 0 is not preferred, then there is no i= ndication that mode 0 is supported.

 

Modified text (section 10)<= span style=3D"font-family:"Arial","sans-serif"">

 

Conversely, If mode 0 is not preferred for media type EVRCNW0 or EVRCNW1, then there is no indication that mode 0 is supported.  However absence of this parameter or absence of mode 0 in this= parameter for media type EVRCNW shall not preclude mode 0 support during a= call where mode 0 may be requested via the MMM field.

 

 

 

Original text (section 10)<= span style=3D"font-family:"Arial","sans-serif"">

 

Note, during an active call session using the interleaved/= bundled packet format, the MMM mode request received from a communication p= artner complements the mode set information in mode-set-recv.  A mode request with MMM=3D0 from a communication part= ner is an implicit indication of the partner's EVRCNW wideband decoding cap= ability and preference.

 

Modified text (section 10)<= span style=3D"font-family:"Arial","sans-serif"">

 

Note, during an active call session using the interleaved/= bundled packet format, the MMM mode request received from a communication p= artner can contain a mode request different than the v= alues in the last mode-set-recv attribute.  The partner’s EVRC-N= W wideband decoding capability is determined by the latest mode-set-recv at= tribute or MMM mode request field. For example, a complements the mode set information in mode-set-recv.  A mode request with MMM=3D0 from a communication partner is an implicit = indication of the partner's EVRC-NW wide= band decoding capability and preference.

 

 

Proposal 3

 

 

The MMM mode change request field in the = interleaved/bundled payload format provides a means for an EVRC-NW receiver= to specify the preferred wideband/narrowband operating mode types.  This facilitates the support of the EVRC-NW codec design= principle to allow a trade-off between subjective quality performance and = system capacity consideration.  This proposal suggests an addition of = a section to the draft with a guideline for mode change request handling in consideration of the EVRC-NW codec design = principle.  This guideline is recommended to ensure end-to-end call pe= rformance, for example when there is a mismatch between the local mode supp= ort capability/preference and the MMM mode change requests received from the far end.

 

Suggested new text

 

Mode Change Request/Response = Considerations

The Interleaved/Bundled packet format for the = EVRC family of vocoders supports a 3-bit field (MMM) that a communication n= ode can use to indicate its preferred compression mode to an opposite node. The concept of the compression mode (also known = as Capacity Operating Point) was introduced to allow a controlled trade-off= between voice quality and channel capacity. The notion makes it possible t= o exercise vocoders at the highest possible (average) bit-rate (hence, highest voice quality) when the networ= k is lightly loaded. Conversely, once the network load increases the vocode= rs can be requested to operate at lower average bit-rates so as to absorb t= he additional network load without causing an undue increase in the frame-erasure rates; the underlying premi= se is that while a higher bit-rate improves the vocoder performance, it als= o increases the network loading, risking a sharp decline in voice quality s= hould the frame-erasure rate be too high. By contrast, a lower bit-rate mode of operation can result in ac= commodation of the additional network load without causing unduly high fram= e-erasure rates, resulting in better overall quality despite the inherently= lower voice quality of the lower bit-rate mode of the vocoder.

Accordingly, the MMM field should be used to r= equest the far-end to transmit compressed-speech using a mode that provides= the best balance between voice quality and capacity. However, in the case of mobile-mobile calls, for example, there are two wi= reless sides involved, each with a potentially different network load level= and hence a different preferred mode. In such cases, achieving optimal end= -to-end performance depends on coherent management of the operative mode by the two sides. This requires that even= if the local node prefers a higher bit-rate vocoder mode, it should adjust= to a lower bit-rate mode if requested by the far end, in order to avoid po= tentially-high frame erasure rates due to heavy load at the far end network. For similar reasons, in cases wh= ere a mode requested by the far end should not be supported, it might still= be beneficial to consider switching to a supported vocoder mode correspond= ing to a lower average bit-rate than requested. It is recommended that the next lower average bit-rate sup= ported vocoder mode is used for encoding when a mode requested by the far e= nd is not supported.

A wideband-capable endpoint can use the inform= ation conveyed by the C-bit of the RTP payload header to determine the opti= mal mode to request of the far end. If the far end cannot provide Mode0 packets (C-bit=3D1), then the choice of MMM can b= e based strictly on the local network load. If the C-bit indicates remote e= nd’s Mode0 encoding capability (C-bit=3D0), then even if the local ne= twork load is not light, Mode0 can be requested knowing definitively that it will be supported. This will permit operators= to treat wideband-capable mobiles preferentially, should they wish to adop= t such policy.

 

 

The three proposed changes above are for = media type EVRCNW using interleaved/bundled payload format only.  They= are not applicable to media type EVRCNW0 and EVRCNW1 payload formats where the MMM mode change request field is not supported.

 

 

 

Thanks,

 

CC

 

Chung-Cheung Chu

Ericsson

ECN:       = 810-16713

External: +514-461-6713   o= r   +514 345-7900 x46489

 

This Communicati= on is Confidential.  We only send and receive email on the basis of th= e terms set out at www.ericsson.com/email_disclaimer.<= span style=3D"font-family:"Arial","sans-serif"">

 <= /span>

 <= /span>

 

--_000_E23CE350F3C94C4A834B4E7069CA56790D4D3EE4nasanexd01anaqu_-- From internet-drafts@ietf.org Wed Feb 22 21:25:42 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 F357421E8035; Wed, 22 Feb 2012 21:25:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id smsKPr5weq7E; Wed, 22 Feb 2012 21:25:40 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9430121E802E; Wed, 22 Feb 2012 21:25:17 -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: 3.64p2 Message-ID: <20120223052517.15109.88087.idtracker@ietfa.amsl.com> Date: Wed, 22 Feb 2012 21:25:17 -0800 Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-avt-rtp-evrc-nw-06.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, 23 Feb 2012 05:25:42 -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 Enhanced Variable Rate Narrowband= -Wideband Codec (EVRC-NW) Author(s) : Zheng Fang Filename : draft-ietf-avt-rtp-evrc-nw-06.txt Pages : 32 Date : 2012-02-22 This document specifies real-time transport protocol (RTP) payload formats to be used for the Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW). Three media type registrations are included for EVRC-NW RTP payload formats. In addition, a file format is specified for transport of EVRC-NW speech data in storage mode applications such as e-mail. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-evrc-nw-06.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-avt-rtp-evrc-nw-06.txt From zfang@qualcomm.com Wed Feb 22 21:52: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 59FE221F85D9 for ; Wed, 22 Feb 2012 21:52:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.998 X-Spam-Level: X-Spam-Status: No, score=-105.998 tagged_above=-999 required=5 tests=[AWL=0.600, 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 2E8If-OtxYtp for ; Wed, 22 Feb 2012 21:52:43 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id E3C0B21F85B7 for ; Wed, 22 Feb 2012 21:52:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=zfang@qualcomm.com; q=dns/txt; s=qcdkim; t=1329976362; x=1361512362; 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"Fang,=20Zheng"=20|To:=20"pa yload@ietf.org"=20|Subject:=20RE:=20[pa yload]=20I-D=20Action:=20draft-ietf-avt-rtp-evrc-nw-06.tx t|Thread-Topic:=20[payload]=20I-D=20Action:=20draft-ietf- avt-rtp-evrc-nw-06.txt|Thread-Index:=20AQHM8eutekrz1oHzNU +Y/CPHACo7uJZJ+D2g|Date:=20Thu,=2023=20Feb=202012=2005:52 :25=20+0000|Message-ID:=20|References:=20<20 120223052517.15109.88087.idtracker@ietfa.amsl.com> |In-Reply-To:=20<20120223052517.15109.88087.idtracker@iet fa.amsl.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:=20mul tipart/alternative=3B=0D=0A=09boundary=3D"_000_E23CE350F3 C94C4A834B4E7069CA56790D4D5799nasanexd01anaqu_" |MIME-Version:=201.0; bh=hQ5VyUHIm1NMzEP/CWnsJRdLnL0Vxdb+AMkZ/HlL3zs=; b=II6MWRrgEuJiGoZMRjGQ10xcFUFRzJfx5TVFIQkmkyFIdRIkOcBli2N/ pGXoQaPxQfOgir0CvphKeqyDIS7jyK22VHfe/6H/S52TdEr8KpJNIfIwS IzFY0CuTWsLiyRzqjRCeYs5WTCksYfX9NwhLJUXt/H6pqkC7ENymMLprB A=; X-IronPort-AV: E=McAfee;i="5400,1158,6628"; a="165666087" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine01.qualcomm.com with ESMTP; 22 Feb 2012 21:52:27 -0800 X-IronPort-AV: E=Sophos;i="4.73,467,1325491200"; d="scan'208,217";a="186412992" Received: from nasanexhc12.na.qualcomm.com ([172.30.39.187]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/AES128-SHA; 22 Feb 2012 21:52:27 -0800 Received: from NASANEXD01A.na.qualcomm.com ([169.254.1.165]) by nasanexhc12.na.qualcomm.com ([172.30.39.187]) with mapi id 14.01.0339.001; Wed, 22 Feb 2012 21:52:26 -0800 From: "Fang, Zheng" To: "payload@ietf.org" Thread-Topic: [payload] I-D Action: draft-ietf-avt-rtp-evrc-nw-06.txt Thread-Index: AQHM8eutekrz1oHzNU+Y/CPHACo7uJZJ+D2g Date: Thu, 23 Feb 2012 05:52:25 +0000 Message-ID: References: <20120223052517.15109.88087.idtracker@ietfa.amsl.com> In-Reply-To: <20120223052517.15109.88087.idtracker@ietfa.amsl.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_E23CE350F3C94C4A834B4E7069CA56790D4D5799nasanexd01anaqu_" MIME-Version: 1.0 Subject: Re: [payload] I-D Action: draft-ietf-avt-rtp-evrc-nw-06.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, 23 Feb 2012 05:52:48 -0000 --_000_E23CE350F3C94C4A834B4E7069CA56790D4D5799nasanexd01anaqu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I just submitted a new version of this draft. Changes from version 05 to 06= : 1) Adopted changes proposed by Chung-Cheung: - Clarification on the usage of the "mode-set-recv" SDP attribute and t= he MMM field in RTP payload header. - Add a new section (Section 11) to define the mode change request/response= behavior. 2) Fix a typo "prefers"->"prefers" in Section 10. Diff can be found at http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-avt-rt= p-evrc-nw-06.txt Thanks, Zheng -----Original Message----- From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf = Of internet-drafts@ietf.org Sent: Wednesday, February 22, 2012 9:25 PM To: i-d-announce@ietf.org Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-avt-rtp-evrc-nw-06.txt 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 Enhanced Variable = Rate Narrowband-Wideband Codec (EVRC-NW) Author(s) : Zheng Fang Filename : draft-ietf-avt-rtp-evrc-nw-06.txt Pages : 32 Date : 2012-02-22 This document specifies real-time transport protocol (RTP) payload formats to be used for the Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW). Three media type registrations are included for EVRC-NW RTP payload formats. In addition, a file format is specified for transport of EVRC-NW speech data in storage mode applications such as e-mail. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-evrc-nw-06.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-avt-rtp-evrc-nw-06.txt _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload --_000_E23CE350F3C94C4A834B4E7069CA56790D4D5799nasanexd01anaqu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I just submitted a new version of this draft. Cha= nges from version 05 to 06:

1) Adopted changes proposed by Chung-Cheung:=

    - Clarification on the usage o= f the "mode-set-recv" SDP attribute and the MMM field in RTP payl= oad header.

- Add a new section (= Section 11) to define the mode change request/response behavior.

2) Fix a typo “prefers”->”pr= efers” in Section 10.

 

Diff can be found at http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-avt-rtp-evrc-nw-06.txt<= o:p>

 

Thanks,

Zheng

 

-----Original Message-----
From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf = Of internet-drafts@ietf.org
Sent: Wednesday, February 22, 2012 9:25 PM
To: i-d-announce@ietf.org
Cc: payload@ietf.org
Subject: [payload] I-D Action: draft-ietf-avt-rtp-evrc-nw-06.txt

 

 

A New Internet-Draft is available from the on-lin= e Internet-Drafts directories. This draft is a work item of the Audio/Video= Transport Payloads Working Group of the IETF.

 

        &= nbsp;       Title    &nbs= p;      : RTP payload format for Enhanced Variable= Rate Narrowband-Wideband Codec (EVRC-NW)

        &= nbsp;       Author(s)    =    : Zheng Fang

        &= nbsp;       Filename    &= nbsp;   : draft-ietf-avt-rtp-evrc-nw-06.txt

        &= nbsp;       Pages    &nbs= p;      : 32

        &= nbsp;       Date     = ;       : 2012-02-22

 

   This document specifies real-time tr= ansport protocol (RTP) payload

   formats to be used for the Enhanced = Variable Rate Narrowband-Wideband

   Codec (EVRC-NW).  Three media t= ype registrations are included for

   EVRC-NW RTP payload formats.  I= n addition, a file format is specified

   for transport of EVRC-NW speech data= in storage mode applications

   such as e-mail.

 

 

A URL for this Internet-Draft is:

http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-evrc-nw-= 06.txt

 

Internet-Drafts are also available by anonymous F= TP at:

<= span style=3D"color:windowtext;text-decoration:none">ftp://ftp.ietf.org/int= ernet-drafts/

 

This Internet-Draft can be retrieved at:

ftp://ftp.ietf.org/internet-drafts/draft-ietf-avt-rtp-evrc-nw-06= .txt

 

_______________________________________________

payload mailing list

payload@ietf.org=

https://www.= ietf.org/mailman/listinfo/payload

--_000_E23CE350F3C94C4A834B4E7069CA56790D4D5799nasanexd01anaqu_-- From thomas.schierl@hhi.fraunhofer.de Mon Feb 27 00:34: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 5DFA621F8469; Mon, 27 Feb 2012 00:34:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.8 X-Spam-Level: X-Spam-Status: No, score=-4.8 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HTML_MESSAGE=0.001, 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 jyiLCsKMfwYh; Mon, 27 Feb 2012 00:34:42 -0800 (PST) Received: from mailgw.hhi.fraunhofer.de (mail.HHI.FRAUNHOFER.DE [193.174.67.45]) by ietfa.amsl.com (Postfix) with ESMTP id B7BAA21F8467; Mon, 27 Feb 2012 00:34:41 -0800 (PST) X-IMSS-DKIM-Authentication-Result: mailgw.hhi.fraunhofer.de; sigcount=0 Received: from [10.2.5.79] (unknown [95.215.121.199]) by mailgw.hhi.fraunhofer.de (Postfix) with ESMTP id 878C9186803A; Mon, 27 Feb 2012 09:34:39 +0100 (CET) Message-ID: <4F4B401F.9080609@hhi.fraunhofer.de> Date: Mon, 27 Feb 2012 09:34:39 +0100 From: Thomas Schierl Organization: Fraunhofer-Institut fuer Nachrichtentechnik Heinrich-Hertz-Institut 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 References: <20120227082031.20300.44145.idtracker@ietfa.amsl.com> In-Reply-To: <20120227082031.20300.44145.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120227082031.20300.44145.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------050509010900080001050308" X-alterMIME: Yes Cc: avt@ietf.org Subject: [payload] RTP Payload Format for High Efficiency Video Coding 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, 27 Feb 2012 08:34:43 -0000 This is a multi-part message in MIME format. --------------050509010900080001050308 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, We just submitted the initial draft of the RTP payload format for HEVC. A presentation is planned for the Paris meeting. Best regards, Thomas Dr.-Ing. Thomas Schierl Head of Multimedia Communications Group Image Processing Department thomas.schierl@hhi.fraunhofer.de Tel. +49 30 31002-227 Fax +49 30 31002-190 Skype thomas.schierl Fraunhofer HHI - Heinrich Hertz Institute Einsteinufer 37, 10587 Berlin, Germany http://www.hhi.fraunhofer.de/ip/mc -------- Original Message -------- Subject: I-D Action: draft-schierl-payload-rtp-h265-00.txt Date: Mon, 27 Feb 2012 00:20:31 -0800 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : RTP Payload Format for High Efficiency Video Coding Author(s) : Thomas Schierl Stephan Wenger Ye-Kui Wang Miska M. Hannuksela Filename : draft-schierl-payload-rtp-h265-00.txt Pages : 43 Date : 2012-02-27 This memo describes an RTP payload format for High Efficiency Video Coding (HEVC) [HEVC], which is currently being developed by the Joint Collaborative Team on Video Coding (JCT-VC). The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload, as well as fragmentation of a NAL unit into multiple RTP packets. Furthermore, it supports transmission of an HEVC stream over a single as well as multiple RTP flows. The payload format has wide applicability in videoconferencing, Internet video streaming, and high bit-rate entertainment-quality video, among others. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-schierl-payload-rtp-h265-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-schierl-payload-rtp-h265-00.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt -------------------- visit us at GSMA Mobile World Congress 27 February - 1 March 2012 / Barcelona, Spain / Hall 2.0, booth 2E41 embedded world 2012 28 February - 1 March 2012 / Nuremberg, Germany / Hall 5, booth 5-228 CeBIT 2012 March 6-10, 2012 / Hannover, Germany www.hhi.fraunhofer.de/events --------------050509010900080001050308 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

We just submitted the initial draft of the RTP payload format for HEVC. A presentation is planned for the Paris meeting.

Best regards,
Thomas

Dr.-Ing. Thomas Schierl

Head of Multimedia Communications Group
Image Processing Department
thomas.schierl@hhi.fraunhofer.de

Tel.	+49 30 31002-227
Fax	+49 30 31002-190
Skype	thomas.schierl

Fraunhofer HHI - Heinrich Hertz Institute
Einsteinufer 37, 10587 Berlin, Germany
http://www.hhi.fraunhofer.de/ip/mc


-------- Original Message --------
Subject: I-D Action: draft-schierl-payload-rtp-h265-00.txt
Date: Mon, 27 Feb 2012 00:20:31 -0800
From: internet-drafts@ietf.org
Reply-To: internet-drafts@ietf.org
To: i-d-announce@ietf.org 


A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : RTP Payload Format for High Efficiency Video Coding
	Author(s)       : Thomas Schierl
                          Stephan Wenger
                          Ye-Kui Wang
                          Miska M. Hannuksela
	Filename        : draft-schierl-payload-rtp-h265-00.txt
	Pages           : 43
	Date            : 2012-02-27

   This memo describes an RTP payload format for High Efficiency Video
   Coding (HEVC) [HEVC], which is currently being developed by the
   Joint Collaborative Team on Video Coding (JCT-VC).  The RTP payload
   format allows for packetization of one or more Network Abstraction
   Layer  (NAL)  units  in  each  RTP  packet  payload,  as  well  as
   fragmentation of a NAL unit into multiple RTP packets.  Furthermore,
   it supports transmission of an HEVC stream over a single as well as
   multiple RTP flows.  The payload format has wide applicability in
   videoconferencing,  Internet  video  streaming,  and  high  bit-rate
   entertainment-quality video, among others.




A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-schierl-payload-rtp-h265-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-schierl-payload-rtp-h265-00.txt

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt



-----
visit us at


GSMA Mobile World Congress
27 February - 1 March 2012 / Barcelona, Spain / Hall 2.0, booth 2E41


embedded world 2012
28 February - 1 March 2012 / Nuremberg, Germany / Hall 5, booth 5-228


CeBIT 2012
March 6-10, 2012 / Hannover, Germany
 

www.hhi.fraunhofer.de/events

--------------050509010900080001050308-- From mperumal@cisco.com Mon Feb 27 03:34:42 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 66FDD21F85DB for ; Mon, 27 Feb 2012 03:34:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.413 X-Spam-Level: X-Spam-Status: No, score=-8.413 tagged_above=-999 required=5 tests=[AWL=2.186, 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 jLPSsBD0s9sD for ; Mon, 27 Feb 2012 03:34:41 -0800 (PST) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id 399A321F85D3 for ; Mon, 27 Feb 2012 03:34:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mperumal@cisco.com; l=2122; q=dns/txt; s=iport; t=1330342481; x=1331552081; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to:cc; bh=BJEJGRPSG4qDylm4IcDn+/heT5uqcVXexD98PMGbrX0=; b=hJ3j/J7veZT9PGJd5UuuL/NurFqu1FPx8lBNq4mrnV0/fMSVn4+7vlO7 iil+hrcJOhDYS6xb6KkHMYCVsiWTqWiBizjhTynrkss8sZDlsFlUTnqXl fxhQAVuJfYD+Q2LZa30rPEksKsWCZP9NzVgmIh3lqTdgp/FPD2So+r1iP 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAJFpS09Io8UY/2dsb2JhbABDtECBcwEBAQQBAQEPAR0KNAsMBgEIEQQBAQsGFwEHJh8HAQEFBAEECwgIARmHZAugXAGWZox4MwJAFQkChQ0DMAMFCQcEAQQBEQIHDoI7YwSITZgKh1w X-IronPort-AV: E=Sophos;i="4.73,490,1325462400"; d="scan'208";a="6473783" Received: from vla196-nat.cisco.com (HELO bgl-core-4.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 27 Feb 2012 11:34:06 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q1RBY48J012673; Mon, 27 Feb 2012 11:34:04 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 27 Feb 2012 17:04:04 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 27 Feb 2012 17:03:57 +0530 Message-ID: <1D062974A4845E4D8A343C653804920207ABB1E1@XMB-BGL-414.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action: draft-muthu-payload-offer-answer-g723-g729-00.txt Thread-Index: Aczy76RuUdH+fAkZQlC7A4SkY3tb3ACKA7GQ From: "Muthu Arul Mozhi Perumal (mperumal)" To: X-OriginalArrivalTime: 27 Feb 2012 11:34:04.0404 (UTC) FILETIME=[B5870340:01CCF543] Cc: Paul Kyzivat Subject: [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: Mon, 27 Feb 2012 11:34:42 -0000 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 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. Muthu -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Friday, February 24, 2012 5:57 PM To: 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 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 -g729-00.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From alvin.hut@live.com.au Mon Feb 27 04:30:46 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 B17C421F86B2 for ; Mon, 27 Feb 2012 04:30:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PrCUbw6S0K4S for ; Mon, 27 Feb 2012 04:30:45 -0800 (PST) Received: from snt0-omc2-s18.snt0.hotmail.com (snt0-omc2-s18.snt0.hotmail.com [65.55.90.93]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE4721F86A5 for ; Mon, 27 Feb 2012 04:30:45 -0800 (PST) Received: from SNT113-W35 ([65.55.90.72]) by snt0-omc2-s18.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 27 Feb 2012 04:30:44 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_d4cbb4af-9ae6-40cd-ad16-8af036ad54fc_" X-Originating-IP: [101.169.138.134] From: alvin hut To: Date: Mon, 27 Feb 2012 23:30:44 +1100 Importance: Normal In-Reply-To: References: MIME-Version: 1.0 X-OriginalArrivalTime: 27 Feb 2012 12:30:44.0522 (UTC) FILETIME=[A027D8A0:01CCF54B] Subject: Re: [payload] payload Digest, Vol 14, Issue 8 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, 27 Feb 2012 12:30:46 -0000 --_d4cbb4af-9ae6-40cd-ad16-8af036ad54fc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Dear Aaron I hope this email finds you fit and well The document in which = you have sent In the last email I sent you=2C if not I will re send it when= I get back to Sydney. Im currently setting up our third store in Brisband.= Kind Regards Leonard Alvin From: payload-request@ietf.org Subject: payload Digest=2C Vol 14=2C Issue 8 To: paylm bretty sure I have signed and enclosed it in theoad@ietf.org Date: Thu=2C 23 Feb 2012 12:00:15 -0800 If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription. To do so=2C go to=20 =20 https://www.ietf.org/mailman/listinfo/payload =20 Click the 'Unsubscribe or edit options' button=2C log in=2C and set "Get MIME or Plain Text Digests?" to MIME. You can set this option globally for all the list digests you receive at this point. =20 =20 =20 Send payload mailing list submissions to payload@ietf.org =20 To subscribe or unsubscribe via the World Wide Web=2C visit https://www.ietf.org/mailman/listinfo/payload or=2C via email=2C send a message with subject or body 'help' to payload-request@ietf.org =20 You can reach the person managing the list at payload-owner@ietf.org =20 When replying=2C please edit your Subject line so it is more specific than "Re: Contents of payload digest..." --Forwarded Message Attachment-- From: internet-drafts@ietf.org CC: payload@ietf.org To: i-d-announce@ietf.org Date: Wed=2C 22 Feb 2012 21:25:17 -0800 Subject: [payload] I-D Action: draft-ietf-avt-rtp-evrc-nw-06.txt =20 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. =20 Title : RTP payload format for Enhanced Variable Rate Narrowband= -Wideband Codec (EVRC-NW) Author(s) : Zheng Fang Filename : draft-ietf-avt-rtp-evrc-nw-06.txt Pages : 32 Date : 2012-02-22 =20 This document specifies real-time transport protocol (RTP) payload formats to be used for the Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW). Three media type registrations are included for EVRC-NW RTP payload formats. In addition=2C a file format is specified for transport of EVRC-NW speech data in storage mode applications such as e-mail. =20 =20 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-evrc-nw-06.txt =20 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ =20 This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-avt-rtp-evrc-nw-06.txt =20 =20 --Forwarded Message Attachment-- From: zfang@qualcomm.com To: payload@ietf.org Date: Thu=2C 23 Feb 2012 05:52:25 +0000 Subject: Re: [payload] I-D Action: draft-ietf-avt-rtp-evrc-nw-06.txt Hi all=2C=20 =20 I just submitted a new version of this draft. Changes from version 05 to 06= : 1) Adopted changes proposed by Chung-Cheung: - Clarification on the usage of the "mode-set-recv" SDP attribute and t= he MMM field in RTP payload header. - Add a new section (Section 11) to define the mode change request/response= behavior. 2) Fix a typo =93prefers=94->=94prefers=94 in Section 10. =20 Diff can be found at=20 http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-avt-rtp-evrc-nw-06.txt =20 Thanks=2C Zheng =20 -----Original Message----- From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf = Of internet-drafts@ietf.org Sent: Wednesday=2C February 22=2C 2012 9:25 PM To: i-d-announce@ietf.org Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-avt-rtp-evrc-nw-06.txt =20 =20 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. =20 Title : RTP payload format for Enhanced Variable = Rate Narrowband-Wideband Codec (EVRC-NW) Author(s) : Zheng Fang Filename : draft-ietf-avt-rtp-evrc-nw-06.txt Pages : 32 Date : 2012-02-22 =20 This document specifies real-time transport protocol (RTP) payload formats to be used for the Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW). Three media type registrations are included for EVRC-NW RTP payload formats. In addition=2C a file format is specified for transport of EVRC-NW speech data in storage mode applications such as e-mail. =20 =20 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-evrc-nw-06.txt =20 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ =20 This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-avt-rtp-evrc-nw-06.txt =20 _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload = --_d4cbb4af-9ae6-40cd-ad16-8af036ad54fc_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Dear Aaron
 =3B
I hope this email finds you fit and well
&nbs= p=3B
The document in which you have sent In the last email =3BI sent=  =3Byou=2C if not I will re send it when =3BI get back to Sydney. I= m currently setting up our third store in Brisband.
 =3B
 =3B=
Kind Regards
 =3B
Leonard Alvin
 =3B
From: payload-request@ietf.org
Subject: p= ayload Digest=2C Vol 14=2C Issue 8
To: paylm bretty sure I have signed a= nd enclosed it in theoad@ietf.orgDate: Thu=2C 23 Feb 2012 12:00:15 -0800

If you have received t=
his digest without all the individual message
attachments you will need =
to update your digest options in your list
subscription.  To do so=2C go=
 to 
 
https://www.ietf.org/mailman/listinfo/payload
 
Cli=
ck the 'Unsubscribe or edit options' button=2C log in=2C and set "Get
MI=
ME or Plain Text Digests?" to MIME.  You can set this option
globally fo=
r all the list digests you receive at this point.
 
 
 
Send pa=
yload mailing list submissions to
	payload@ietf.org
 
To subscribe=
 or unsubscribe via the World Wide Web=2C visit
	https://www.ietf.org/m=
ailman/listinfo/payload
or=2C via email=2C send a message with subje=
ct or body 'help' to
	payload-request@ietf.org
 
You can reach the=
 person managing the list at
	payload-owner@ietf.org
 
When replyi=
ng=2C please edit your Subject line so it is more specific
than "Re: Con=
tents of payload digest..."


--Forwarded Message Attachment= --
From: internet-drafts@ietf.org
CC: payload@ietf.org
To: i-d-ann= ounce@ietf.org
Date: Wed=2C 22 Feb 2012 21:25:17 -0800
Subject: [payl= oad] I-D Action: draft-ietf-avt-rtp-evrc-nw-06.txt

 
A New I=
nternet-Draft is available from the on-line Internet-Drafts directories. Th=
is draft is a work item of the Audio/Video Transport Payloads Working Group=
 of the IETF.
 
	Title           : RTP payload format for Enhanced Va=
riable Rate Narrowband-Wideband Codec (EVRC-NW)
	Author(s)       : Zheng=
 Fang
	Filename        : draft-ietf-avt-rtp-evrc-nw-06.txt
	Pages    =
       : 32
	Date            : 2012-02-22
 
   This document speci=
fies real-time transport protocol (RTP) payload
   formats to be used fo=
r the Enhanced Variable Rate Narrowband-Wideband
   Codec (EVRC-NW).  Th=
ree media type registrations are included for
   EVRC-NW RTP payload for=
mats.  In addition=2C a file format is specified
   for transport of EVR=
C-NW speech data in storage mode applications
   such as e-mail.
  
A URL for this Internet-Draft is:
http://=
www.ietf.org/internet-drafts/draft-ietf-avt-rtp-evrc-nw-06.txt
 
=
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/intern=
et-drafts/
 
This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-avt-rtp-evrc=
-nw-06.txt


--Forwarded Message Attachment--<= br>From: zfang@qualcomm.com
To: payload@ietf.org
Date: Thu=2C 23 Feb = 2012 05:52:25 +0000
Subject: Re: [payload] I-D Action: draft-ietf-avt-rt= p-evrc-nw-06.txt

Hi all=2C

 =3B

I just submitted a new version of this draft. = Changes from version 05 to 06:

1) Adopted changes proposed by Chung-Cheung:

 =3B =3B =3B - Clarification on th= e usage of the "mode-set-recv" SDP attribute and the MMM field in RTP paylo= ad header.

- Add a new sect= ion (Section 11) to define the mode change request/response behavior.

2) Fix a typo =93prefers=94->=3B=94prefers= =94 in Section 10.

 =3B

Diff can be found at http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-avt-rtp-evrc-nw-06.txt<= /p>

 =3B

Thanks=2C

Zheng

 =3B

-----Original Message-----
From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf = Of internet-drafts@ietf.org
Sent: Wednesday=2C February 22=2C 2012 9:25 PM
To: i-d-announce@ietf.org
Cc: payload@ietf.org
Subject: [payload] I-D Action: draft-ietf-avt-rtp-evrc-nw-06.txt

 =3B

 =3B

A New Internet-Draft is available from the on-= line Internet-Drafts directories. This draft is a work item of the Audio/Vi= deo Transport Payloads Working Group of the IETF.

 =3B

 =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B= Title =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B : RTP payload format for Enhanced Variable Rate Narrowband-Wide= band Codec (EVRC-NW)

 =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B= Author(s) =3B =3B =3B =3B =3B =3B : Zheng Fang

 =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B= Filename =3B =3B =3B =3B =3B =3B =3B : draft-i= etf-avt-rtp-evrc-nw-06.txt

 =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B= Pages =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B : 32

 =3B =3B =3B =3B =3B = =3B =3B =3B =3B =3B =3B =3B =3B =3B =3B= Date =3B =3B =3B =3B =3B =3B =3B =3B = =3B =3B =3B : 2012-02-22

 =3B

 =3B =3B This document specifies real-= time transport protocol (RTP) payload

 =3B =3B formats to be used for the En= hanced Variable Rate Narrowband-Wideband

 =3B =3B Codec (EVRC-NW). =3B Thre= e media type registrations are included for

 =3B =3B EVRC-NW RTP payload formats.&= nbsp=3B In addition=2C a file format is specified

 =3B =3B for transport of EVRC-NW spee= ch data in storage mode applications

 =3B =3B such as e-mail.

 =3B

 =3B

A URL for this Internet-Draft is:

http://www.ietf.org/internet-draft= s/draft-ietf-avt-rtp-evrc-nw-06.txt

 =3B

Internet-Drafts are also available by anonymou= s FTP at:

ftp://ftp.ietf.org/internet-drafts/

 =3B

This Internet-Draft can be retrieved at:

ftp://ftp.ietf.org/internet-drafts/= draft-ietf-avt-rtp-evrc-nw-06.txt

 =3B

______________________________________________= _

payload mailing list

payload@ietf.org=

https://www.ietf.org/mailman/listinfo/payload

= --_d4cbb4af-9ae6-40cd-ad16-8af036ad54fc_-- From pravindran@sonusnet.com Mon Feb 27 10:22: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 A1D8021F87C9 for ; Mon, 27 Feb 2012 10:22:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.337 X-Spam-Level: X-Spam-Status: No, score=-2.337 tagged_above=-999 required=5 tests=[AWL=0.262, 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 G5YmRiqI7BK6 for ; Mon, 27 Feb 2012 10:22:24 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 2ACC921F8794 for ; Mon, 27 Feb 2012 10:22:24 -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 q1RIN9lI019214; Mon, 27 Feb 2012 13:23:09 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail04.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 27 Feb 2012 13:21:59 -0500 Received: from INBA-HUB02.sonusnet.com ([10.70.51.87]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 27 Feb 2012 23:51:56 +0530 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; Mon, 27 Feb 2012 23:51:56 +0530 From: "Ravindran, Parthasarathi" To: Paul Kyzivat , "Muthu Arul Mozhi Perumal (mperumal)" Thread-Topic: FW: I-D Action: draft-muthu-payload-offer-answer-g723-g729-00.txt Thread-Index: Aczy76RuUdH+fAkZQlC7A4SkY3tb3ACKA7GQAAtKSIAADaFX0A== Date: Mon, 27 Feb 2012 18:21:55 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E04F128@inba-mail01.sonusnet.com> References: <1D062974A4845E4D8A343C653804920207ABB1E1@XMB-BGL-414.cisco.com> <4F4BB973.4060508@alum.mit.edu> In-Reply-To: <4F4BB973.4060508@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [121.242.142.186] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 27 Feb 2012 18:21:56.0782 (UTC) FILETIME=[B0338CE0:01CCF57C] 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: Mon, 27 Feb 2012 18:22:26 -0000 Paul, I agree with your proposal of (2) for answerer as it makes sure that "annex= a=3Dno" in G.723 or "annexb=3Dno" in G.729 is negotiated in case offerer re= quested for.=20 The issue with (4) in offerer is that offerer may ignore or treat as "no" b= ut answerer treats negotiated parameter as "yes" and answerer exchanges/exp= ects further media packets based on this assumption which leads to call fai= lure or interop issue in reality. I agree with (4) in case we get the opini= on from others that (4) is the best common practice in the industry. Thanks Partha >-----Original Message----- >From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >Sent: Monday, February 27, 2012 10:42 PM >To: Muthu Arul Mozhi Perumal (mperumal) >Cc: payload@ietf.org; Ravindran, Parthasarathi >Subject: Re: FW: I-D Action: draft-muthu-payload-offer-answer-g723-g729- >00.txt > >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 >> >> 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. > > Thanks, > Paul > >> Muthu >> >> -----Original Message----- >> From: i-d-announce-bounces@ietf.org >> [mailto:i-d-announce-bounces@ietf.org] On Behalf Of >> internet-drafts@ietf.org >> Sent: Friday, February 24, 2012 5:57 PM >> To: 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-g >> 72 >> 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-g7 >> 23 >> -g729-00.txt >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html or >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> From abegen@cisco.com Mon Feb 27 12:09: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 4306E21F8850 for ; Mon, 27 Feb 2012 12:09:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 tagged_above=-999 required=5 tests=[AWL=0.400, 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 7Tgr0CeTKzkD for ; Mon, 27 Feb 2012 12:09:05 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id A280321F8842 for ; Mon, 27 Feb 2012 12:09:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=455; q=dns/txt; s=iport; t=1330373345; x=1331582945; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=VFBpDbhXEFrasijILzTNlPNVvmU6iRj1Bg+s9BR7SiU=; b=co94L9Q9Nm1LuhhoxEbYrMg1WbFS39SeoH3n5wIQTLQC8wZxCMzEWe1q u/xRyc7CZdQa0w2uFC2a2jbH5EsoWQZuZWxZQBEYqOZIIbJy+5hywIXNK uC4Lcya9WndDtKUK1Y0+Sc84v1Q7/QVLep9H8dDiHCOXTc4Oi3yHDGuj3 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAEHiS0+rRDoG/2dsb2JhbABDs3eBB4F1AQQSAWYSASpWJgEEDg0ah2MBC6EYAZccBI0rAgQCAwMBAQEEBQEBAgsJAwcBGgMBAgECAoUCD4M0YwSIHKAPgV0 X-IronPort-AV: E=Sophos;i="4.73,493,1325462400"; d="scan'208";a="30722417" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 27 Feb 2012 20:09:05 +0000 Received: from xht-rcd-x01-p.cisco.com (xht-rcd-x01-p.cisco.com [173.37.178.212]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q1RK95LS013282; Mon, 27 Feb 2012 20:09:05 GMT Received: from xmb-rcd-x01-p.cisco.com ([169.254.3.137]) by xht-rcd-x01-p.cisco.com ([173.37.178.212]) with mapi id 14.02.0283.003; Mon, 27 Feb 2012 12:09:04 -0800 From: "Ali C. Begen (abegen)" To: "payload@ietf.org" Thread-Topic: Interest in raft-ietf-avt-rtp-isac Thread-Index: Acz1i1b4a+gUrBqcTuqodNfXQaaKMQ== Date: Mon, 27 Feb 2012 20:09:04 +0000 Message-ID: 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-18740.001 x-tm-as-result: No--38.203000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-avt-rtp-isac@tools.ietf.org" Subject: [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: Mon, 27 Feb 2012 20:09:06 -0000 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/=20 Thanks. -acbegen From alvin.hut@live.com.au Tue Feb 28 04:05: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 B1F6521F859B for ; Tue, 28 Feb 2012 04:05:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYlQ4JIGecoM for ; Tue, 28 Feb 2012 04:05:46 -0800 (PST) Received: from snt0-omc2-s22.snt0.hotmail.com (snt0-omc2-s22.snt0.hotmail.com [65.55.90.97]) by ietfa.amsl.com (Postfix) with ESMTP id 8337321F8621 for ; Tue, 28 Feb 2012 04:05:45 -0800 (PST) Received: from SNT113-W50 ([65.55.90.72]) by snt0-omc2-s22.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 28 Feb 2012 04:05:44 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_40d2564e-056d-47b8-95e5-449c229f9dd9_" X-Originating-IP: [101.171.153.33] From: alvin hut To: Date: Tue, 28 Feb 2012 23:05:44 +1100 Importance: Normal In-Reply-To: References: MIME-Version: 1.0 X-OriginalArrivalTime: 28 Feb 2012 12:05:44.0804 (UTC) FILETIME=[4CAACA40:01CCF611] Subject: Re: [payload] payload Digest, Vol 14, Issue 10 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, 28 Feb 2012 12:05:47 -0000 --_40d2564e-056d-47b8-95e5-449c229f9dd9_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I DONT UNDERSTAND THESE EMILS=20 From: payload-request@ietf.org Subject: payload Digest=2C Vol 14=2C Issue 10 To: payload@ietf.org Date: Mon=2C 27 Feb 2012 12:00:09 -0800 If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription. To do so=2C go to=20 =20 https://www.ietf.org/mailman/listinfo/payload =20 Click the 'Unsubscribe or edit options' button=2C log in=2C and set "Get MIME or Plain Text Digests?" to MIME. You can set this option globally for all the list digests you receive at this point. =20 =20 =20 Send payload mailing list submissions to payload@ietf.org =20 To subscribe or unsubscribe via the World Wide Web=2C visit https://www.ietf.org/mailman/listinfo/payload or=2C via email=2C send a message with subject or body 'help' to payload-request@ietf.org =20 You can reach the person managing the list at payload-owner@ietf.org =20 When replying=2C please edit your Subject line so it is more specific than "Re: Contents of payload digest..." --Forwarded Message Attachment-- From: pravindran@sonusnet.com CC: payload@ietf.org To: pkyzivat@alum.mit.edu=3B mperumal@cisco.com Date: Mon=2C 27 Feb 2012 18:21:55 +0000 Subject: Re: [payload] FW: I-D Action: draft-muthu-payload-offer-answer-g72= 3-g729-00.txt Paul=2C =20 I agree with your proposal of (2) for answerer as it makes sure that "annex= a=3Dno" in G.723 or "annexb=3Dno" in G.729 is negotiated in case offerer re= quested for.=20 =20 The issue with (4) in offerer is that offerer may ignore or treat as "no" b= ut answerer treats negotiated parameter as "yes" and answerer exchanges/exp= ects further media packets based on this assumption which leads to call fai= lure or interop issue in reality. I agree with (4) in case we get the opini= on from others that (4) is the best common practice in the industry. =20 Thanks Partha =20 >-----Original Message----- >From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >Sent: Monday=2C February 27=2C 2012 10:42 PM >To: Muthu Arul Mozhi Perumal (mperumal) >Cc: payload@ietf.org=3B Ravindran=2C Parthasarathi >Subject: Re: FW: I-D Action: draft-muthu-payload-offer-answer-g723-g729- >00.txt > >On 2/27/12 6:33 AM=2C 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=2C >> G.729D and G.729E. This clarification is missing in RFC 4856=2C leading >> to interop issues=2C for e.g: >> http://sipforum.org/pipermail/discussion/2008-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=2C then it will default to yes=2C 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=2C 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"=2C 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"=2C 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=2C 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=2C while >making (4) normative for the offerer=2C and put enough words in so its >very clear what is being specified and why. > > Thanks=2C > Paul > >> Muthu >> >> -----Original Message----- >> From: i-d-announce-bounces@ietf.org >> [mailto:i-d-announce-bounces@ietf.org] On Behalf Of >> internet-drafts@ietf.org >> Sent: Friday=2C February 24=2C 2012 5:57 PM >> To: 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=2C G729D and G729E. However=2C 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-g >> 72 >> 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-g7 >> 23 >> -g729-00.txt >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html or >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> =20 =20 = --_40d2564e-056d-47b8-95e5-449c229f9dd9_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 =3BI DONT UNDERSTAND THESE EMILS =3B

From: payload-request@ietf.org
Subject: payload Di= gest=2C Vol 14=2C Issue 10
To: payload@ietf.org
Date: Mon=2C 27 Feb 2= 012 12:00:09 -0800

If you have received this digest without all=
 the individual message
attachments you will need to update your digest =
options in your list
subscription.  To do so=2C go to 
 
https:=
//www.ietf.org/mailman/listinfo/payload
 
Click the 'Unsubscribe =
or edit options' button=2C log in=2C and set "Get
MIME or Plain Text Dig=
ests?" to MIME.  You can set this option
globally for all the list diges=
ts you receive at this point.
 
 
 
Send payload mailing list s=
ubmissions to
	payload@ietf.org
 
To subscribe or unsubscribe via =
the World Wide Web=2C visit
	https://www.ietf.org/mailman/listinfo/payl=
oad
or=2C via email=2C send a message with subject or body 'help' to=

	payload-request@ietf.org
 
You can reach the person managing the=
 list at
	payload-owner@ietf.org
 
When replying=2C please edit yo=
ur Subject line so it is more specific
than "Re: Contents of payload dig=
est..."


--Forwarded Message Attachment--
From: pravindr= an@sonusnet.com
CC: payload@ietf.org
To: pkyzivat@alum.mit.edu=3B mpe= rumal@cisco.com
Date: Mon=2C 27 Feb 2012 18:21:55 +0000
Subject: Re: = [payload] FW: I-D Action: draft-muthu-payload-offer-answer-g723-g729-00.txt= 

Paul=2C
 
I agree with your proposal of (2) for answerer=
 as it makes sure that "annexa=3Dno" in G.723 or "annexb=3Dno" in G.729 is =
negotiated in case offerer requested for. 
 
The issue with (4) in of=
ferer is that offerer may ignore or treat as "no" but answerer treats negot=
iated parameter as "yes" and answerer exchanges/expects further media packe=
ts based on this assumption which leads to call failure or interop issue in=
 reality. I agree with (4) in case we get the opinion from others that (4) =
is the best common practice in the industry.
 
Thanks
Partha
 <=
br>>=3B-----Original Message-----
>=3BFrom: Paul Kyzivat [mailto:pky=
zivat@alum.mit.edu]
>=3BSent: Monday=2C February 27=2C 2012 10:42 PM>=3BTo: Muthu Arul Mozhi Perumal (mperumal)
>=3BCc: payload@ietf.o=
rg=3B Ravindran=2C Parthasarathi
>=3BSubject: Re: FW: I-D Action: draf=
t-muthu-payload-offer-answer-g723-g729-
>=3B00.txt
>=3B
>=3B=
On 2/27/12 6:33 AM=2C Muthu Arul Mozhi Perumal (mperumal) wrote:
>=3B&=
gt=3B We have submitted an I-D clarifying the offer/answer considerations>=3B>=3B for the Annex A flavor of G.723 and the Annex B flavors of G=
.729=2C
>=3B>=3B G.729D and G.729E. This clarification is missing in=
 RFC 4856=2C leading
>=3B>=3B to interop issues=2C for e.g:
>=
=3B>=3B http://sipforum.org/pipermail/discussion/200=
8-January/004026.html
>=3B>=3B
>=3B>=3B We have a couple =
of open items in the I-D. We expect the WG
>=3B>=3B discussions woul=
d guide us on how to go about them.
>=3B>=3B
>=3B>=3B Comment=
s welcome.
>=3B
>=3BI'm the source of the issues. :-)
>=3B>=3BThe fundamental point is that RFC4856 specifies a *default* value o=
f
>=3B"yes" for annexa and annexb. This means that if annexa/annexb is=
 not
>=3Bspecified in an answer=2C then it will default to yes=2C even=
 if the offer
>=3Bcontained "no".
>=3B
>=3BI see a few ways =
to fix this:
>=3B
>=3B1) revise the IANA registration for annexa =
and annexb to remove the
>=3B    default=2C at least when used with O/=
A. Instead specify the defaulting
>=3B    separately for offers and an=
swers.
>=3B
>=3B2) REQUIRE that the answer contain "no" if the of=
fer contained "no".
>=3B
>=3B3) permit the answer to contain "yes=
" (explicitly or by default)
>=3B    when the offer contained "no"=2C =
and specify that this still means
>=3B    that the annex is *not* to b=
e used.
>=3B
>=3B4) forbid the answer from *explicitly* containin=
g "yes" when the
>=3B    offer contained "no"=2C but allow the answer =
to *implicitly* contain
>=3B    "yes" (via the default) and ignore it/=
treat it as "no".
>=3B
>=3BNone of these are ideal. (1) is proble=
matic because this is used in non-
>=3BO/A contexts=2C such as RSVP. (=
2) begs the question of what should be done
>=3Bif this is violated. (=
3) risks failing to recognize that the two sides
>=3Bdisagree. (4) is =
pragmatic but seems to violate the spirit of defaults.
>=3B
>=3BI=
 guess my preference is to make (2) normative for the answerer=2C while
=
>=3Bmaking (4) normative for the offerer=2C and put enough words in so it=
s
>=3Bvery clear what is being specified and why.
>=3B
>=3B	=
Thanks=2C
>=3B	Paul
>=3B
>=3B>=3B Muthu
>=3B>=3B>=3B>=3B -----Original Message-----
>=3B>=3B From: i-d-announce=
-bounces@ietf.org
>=3B>=3B [mailto:i-d-announce-bounces@ietf.org] On=
 Behalf Of
>=3B>=3B internet-drafts@ietf.org
>=3B>=3B Sent: F=
riday=2C February 24=2C 2012 5:57 PM
>=3B>=3B To: i-d-announce@ietf.=
org
>=3B>=3B Subject: I-D Action: draft-muthu-payload-offer-answer-g=
723-g729-00.txt
>=3B>=3B
>=3B>=3B
>=3B>=3B A New Inter=
net-Draft is available from the on-line Internet-Drafts
>=3B>=3B dir=
ectories.
>=3B>=3B
>=3B>=3B 	Title           : Offer/Answer C=
onsiderations for G.723 Annex A
>=3B>=3B and G.729 Annex B
>=3B=
>=3B 	Author(s)       : Muthu Arul Mozhi Perumal
>=3B>=3B         =
                   Parthasarathi Ravindran
>=3B>=3B 	Filename       =
 :
>=3B>=3B draft-muthu-payload-offer-answer-g723-g729-00.txt
>=
=3B>=3B 	Pages           : 8
>=3B>=3B 	Date            : 2012-02-2=
4
>=3B>=3B
>=3B>=3B     [RFC4856] describes the annexa parame=
ter for G723 and the annexb
>=3B>=3B     parameter for G729=2C G729D=
 and G729E. However=2C the specification
>=3Bdoes
>=3B>=3B     =
not describe the offerer and answerer behavior when the value of
>=3Bt=
he
>=3B>=3B     annexa or annexb parameter does not match in the SDP=
 offer and
>=3B>=3B     answer.  This document provides the offer/an=
swer considerations
>=3Bfor
>=3B>=3B     these parameters.
&=
gt=3B>=3B
>=3B>=3B
>=3B>=3B A URL for this Internet-Draft i=
s:
>=3B>=3B http://www.ietf.org/internet-d=
rafts/draft-muthu-payload-offer-answer-g
>=3B>=3B 72
>=3B&g=
t=3B 3-g729-00.txt
>=3B>=3B
>=3B>=3B Internet-Drafts are also=
 available by anonymous FTP at:
>=3B>=3B ftp://ftp.ietf.org/internet-drafts/<=
/a>
>=3B>=3B
>=3B>=3B This Internet-Draft can be retrieved at=
:
>=3B>=3B ftp://ftp.ietf.org/internet-dra=
fts/draft-muthu-payload-offer-answer-g7
>=3B>=3B 23
>=3B>=
=3B -g729-00.txt
>=3B>=3B
>=3B>=3B __________________________=
_____________________
>=3B>=3B I-D-Announce mailing list
>=3B&g=
t=3B I-D-Announce@ietf.org
>=3B>=3B https://www.ietf.org/mailm=
an/listinfo/i-d-announce
>=3B>=3B Internet-Draft directories: http://www.ietf=
.org/shadow.html or
>=3B>=3B ftp://ftp.ietf.org/ietf/1shadow-sites.=
txt
>=3B>=3B
= --_40d2564e-056d-47b8-95e5-449c229f9dd9_-- From pkyzivat@alum.mit.edu Tue Feb 28 06:36:09 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 8B1E721F8576 for ; Tue, 28 Feb 2012 06:36:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, 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 HxAUfCWNp3FW for ; Tue, 28 Feb 2012 06:36:08 -0800 (PST) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [76.96.59.227]) by ietfa.amsl.com (Postfix) with ESMTP id D052521F8688 for ; Tue, 28 Feb 2012 06:36:07 -0800 (PST) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta12.westchester.pa.mail.comcast.net with comcast id fPgT1i0021swQuc5CSc7E3; Tue, 28 Feb 2012 14:36:07 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta15.westchester.pa.mail.comcast.net with comcast id fSc71i00s07duvL3bSc7ZK; Tue, 28 Feb 2012 14:36:07 +0000 Message-ID: <4F4CE656.4030407@alum.mit.edu> Date: Tue, 28 Feb 2012 09:36:06 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 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] payload Digest, Vol 14, Issue 10 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, 28 Feb 2012 14:36:09 -0000 On 2/28/12 7:05 AM, alvin hut wrote: > I DONT UNDERSTAND THESE EMILS Could you say more about what you are having trouble with? Did you read the draft? Thanks, Paul > From: payload-request@ietf.org > Subject: payload Digest, Vol 14, Issue 10 > To: payload@ietf.org > Date: Mon, 27 Feb 2012 12:00:09 -0800 > > If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. To do so, go to > > https://www.ietf.org/mailman/listinfo/payload > > Click the 'Unsubscribe or edit options' button, log in, and set "Get > MIME or Plain Text Digests?" to MIME. You can set this option > globally for all the list digests you receive at this point. > > > > Send payload mailing list submissions to > payload@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/payload > or, via email, send a message with subject or body 'help' to > payload-request@ietf.org > > You can reach the person managing the list at > payload-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of payload digest..." > > > > --Forwarded Message Attachment-- > From: pravindran@sonusnet.com > CC: payload@ietf.org > To: pkyzivat@alum.mit.edu; mperumal@cisco.com > Date: Mon, 27 Feb 2012 18:21:55 +0000 > Subject: Re: [payload] FW: I-D Action: > draft-muthu-payload-offer-answer-g723-g729-00.txt > > Paul, > > I agree with your proposal of (2) for answerer as it makes sure that "annexa=no" in G.723 or "annexb=no" in G.729 is negotiated in case offerer requested for. > > The issue with (4) in offerer is that offerer may ignore or treat as "no" but answerer treats negotiated parameter as "yes" and answerer exchanges/expects further media packets based on this assumption which leads to call failure or interop issue in reality. I agree with (4) in case we get the opinion from others that (4) is the best common practice in the industry. > > Thanks > Partha > >>-----Original Message----- >>From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>Sent: Monday, February 27, 2012 10:42 PM >>To: Muthu Arul Mozhi Perumal (mperumal) >>Cc: payload@ietf.org; Ravindran, Parthasarathi >>Subject: Re: FW: I-D Action: draft-muthu-payload-offer-answer-g723-g729- >>00.txt >> >>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 >>> >>> 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. >> >> Thanks, >> Paul >> >>> Muthu >>> >>> -----Original Message----- >>> From: i-d-announce-bounces@ietf.org >>> [mailto:i-d-announce-bounces@ietf.org] On Behalf Of >>> internet-drafts@ietf.org >>> Sent: Friday, February 24, 2012 5:57 PM >>> To: 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-g >>> 72 >>> 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-g7 >>> 23 >>> -g729-00.txt >>> >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories:http://www.ietf.org/shadow.html or >>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> > > > > > > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload From pkyzivat@alum.mit.edu Mon Feb 27 09:12:21 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 52EA121F867E for ; Mon, 27 Feb 2012 09:12:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 CKldzrl0tIaD for ; Mon, 27 Feb 2012 09:12:20 -0800 (PST) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by ietfa.amsl.com (Postfix) with ESMTP id 3A5EA21F86BB for ; Mon, 27 Feb 2012 09:12:20 -0800 (PST) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta04.westchester.pa.mail.comcast.net with comcast id f5621i0010mv7h0545CLsE; Mon, 27 Feb 2012 17:12:20 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta11.westchester.pa.mail.comcast.net with comcast id f5CL1i00w07duvL3X5CLZ1; Mon, 27 Feb 2012 17:12:20 +0000 Message-ID: <4F4BB973.4060508@alum.mit.edu> Date: Mon, 27 Feb 2012 12:12:19 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Muthu Arul Mozhi Perumal (mperumal)" References: <1D062974A4845E4D8A343C653804920207ABB1E1@XMB-BGL-414.cisco.com> In-Reply-To: <1D062974A4845E4D8A343C653804920207ABB1E1@XMB-BGL-414.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 28 Feb 2012 08:41:04 -0800 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: Mon, 27 Feb 2012 17:12:21 -0000 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 > > 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. Thanks, Paul > Muthu > > -----Original Message----- > From: i-d-announce-bounces@ietf.org > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Friday, February 24, 2012 5:57 PM > To: 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 > 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 > -g729-00.txt > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > From kpfleming@digium.com Tue Feb 28 08:54: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 404CC21F86A4 for ; Tue, 28 Feb 2012 08:54:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.536 X-Spam-Level: X-Spam-Status: No, score=-106.536 tagged_above=-999 required=5 tests=[AWL=0.063, 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 y1aZ+gIcdTMn for ; Tue, 28 Feb 2012 08:54:17 -0800 (PST) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id 37CC021F86A2 for ; Tue, 28 Feb 2012 08:54:17 -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 1S2QJb-0001ck-1Z; Tue, 28 Feb 2012 10:54:15 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id 0CBEED8002; Tue, 28 Feb 2012 10:54:15 -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 pjskep0zlHIl; Tue, 28 Feb 2012 10:54:14 -0600 (CST) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 753AE1A2001; Tue, 28 Feb 2012 10:54:14 -0600 (CST) Message-ID: <4F4D06B6.6020905@digium.com> Date: Tue, 28 Feb 2012 10:54:14 -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: Paul Kyzivat References: <1D062974A4845E4D8A343C653804920207ABB1E1@XMB-BGL-414.cisco.com> <4F4BB973.4060508@alum.mit.edu> In-Reply-To: <4F4BB973.4060508@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Tue, 28 Feb 2012 16:54:18 -0000 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 >> >> 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 >> [mailto:i-d-announce-bounces@ietf.org] On Behalf Of >> internet-drafts@ietf.org >> Sent: Friday, February 24, 2012 5:57 PM >> To: 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 >> 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 >> -g729-00.txt >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> > > _______________________________________________ > 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 From hschhatwal@gmail.com Tue Feb 28 09:34:19 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 DB71E21F86B4 for ; Tue, 28 Feb 2012 09:34:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.932 X-Spam-Level: X-Spam-Status: No, score=-1.932 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] 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 gxHtG0007n4K for ; Tue, 28 Feb 2012 09:34:18 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id AFAEE21F869D for ; Tue, 28 Feb 2012 09:34:17 -0800 (PST) Received: by wicr5 with SMTP id r5so2002260wic.31 for ; Tue, 28 Feb 2012 09:34:16 -0800 (PST) Received-SPF: pass (google.com: domain of hschhatwal@gmail.com designates 10.180.95.1 as permitted sender) client-ip=10.180.95.1; Authentication-Results: mr.google.com; spf=pass (google.com: domain of hschhatwal@gmail.com designates 10.180.95.1 as permitted sender) smtp.mail=hschhatwal@gmail.com; dkim=pass header.i=hschhatwal@gmail.com Received: from mr.google.com ([10.180.95.1]) by 10.180.95.1 with SMTP id dg1mr40859038wib.21.1330450456893 (num_hops = 1); Tue, 28 Feb 2012 09:34:16 -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=K7fJsA7U8qBVmRKGOmmQCScYr86HNpXdNqsVlIFsGFg=; b=SCDjrBnl8WPv2A8G9o1krtd90j+4bSxBSw45xwHsBLUDyPjv/qTHVSQhgpAfc3iifp 7klICPmhToCTPBur/Az2uXw19ghWgIlyMfPDSq099Ryn9fHSR52s/9Pgf7oMmnygCqz6 /imcXWmBT0ktNMQ21qYSFIrhulfaiB2b0uI58= MIME-Version: 1.0 Received: by 10.180.95.1 with SMTP id dg1mr32423266wib.21.1330450456742; Tue, 28 Feb 2012 09:34:16 -0800 (PST) Received: by 10.180.96.166 with HTTP; Tue, 28 Feb 2012 09:34:16 -0800 (PST) In-Reply-To: <4F4D06B6.6020905@digium.com> References: <1D062974A4845E4D8A343C653804920207ABB1E1@XMB-BGL-414.cisco.com> <4F4BB973.4060508@alum.mit.edu> <4F4D06B6.6020905@digium.com> Date: Tue, 28 Feb 2012 17:34:16 +0000 Message-ID: From: "Chhatwal, Harprit S" To: "Kevin P. Fleming" Content-Type: multipart/alternative; boundary=f46d044303f0dd89c904ba09a2e2 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: Tue, 28 Feb 2012 17:34:20 -0000 --f46d044303f0dd89c904ba09a2e2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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 =91sendrecv=92). 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 =91annexb=92 : 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, =91annexb=92 is more like a parameter in this sense and, in this cas= e, everything is allowed =96 the answer may contain the same fmtp or different= . RFC3264 doesn=92t appear to specify the interpretation. The problem is th= at I don't know of anywhere else where the interpretation is specified either. RFC4856 specifies the parameter =91annexb=92, but doesn=92t say w= hether 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 =91annexb=3Dno=92 indicates that the sender of this SDP is willi= ng to send and receive with silence suppression off. So, according to this, if the offerer sends =91annexb=3Dyes=92 in the offer and the answerer sends ba= ck =91annexb=3Dno=92, then there is a mismatch and the offerer should send a re-INVITE with =91annexb=3Dno=92 to resolve the conflict. According to thi= s 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 an= d >>> 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 >>> >>> 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 indicat= ed > 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 interpr= et > 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/answeri= ng > 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 = ] >>> On Behalf Of >>> internet-drafts@ietf.org >>> Sent: Friday, February 24, 2012 5:57 PM >>> To: i-d-announce@ietf.org >>> Subject: I-D Action: draft-muthu-payload-offer-**answer-g723-g729-00.tx= t >>> >>> >>> 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 >>> 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 >>> -g729-00.txt >>> >>> ______________________________**_________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/**listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.**html >>> or ftp://ftp.ietf.org/ietf/**1shadow-sites.txt >>> >>> >> ______________________________**_________________ >> 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: kpflemin= g > 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 > --f46d044303f0dd89c904ba09a2e2 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Kevin,

First of all, from RFC3264, I agree with you that for thing= s like IP addresses, ports, payload types, ptime, the SDP that one party sends indica= tes the address/port/PT/ptime that the sender would like to receive on.=A0 However, I don't believe this is generally correct for all parameters.= =A0 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 =91sendrecv=92).=A0 As an example, if party A is t= he offerer and sends G.729 & G.711 in its SDP offer, it is saying that it is willi= ng to use either codec.=A0 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.<= /span>

=A0

Turning now to silence su= ppression, the situation does not seem very clear.=A0 This is what RFC3264 = has to say about fmtp parameters such as =91annexb=92 :

=A0

=A0=A0 The interpretation of fmtp parameters in an offer depends on the

=A0=A0 parameters.=A0 In many cases, those parameters describe specific

=A0=A0 configurations of the media format, and should therefore be processed

=A0=A0 as the media format value itself would be.=A0 This means that the same

=A0=A0 fmtp parameters with the same values MUST be present in the answer if

=A0=A0 the media format they describe is present in the answer.=A0 Other fmtp

=A0=A0 parameters are more like parameters, for which it is perfectly

=A0=A0 acceptable for each agent to use different values.=A0 In that case, the

=A0=A0 answer MAY contain fmtp parameters, and those MAY have the same

=A0=A0 values as those in the offer, or they MAY be different.=A0 SDP

=A0=A0 extensions that define new parameters SHOULD specify the proper

=A0=A0 interpretation in offer/answer.

=A0

To me, =91annexb=92 is mo= re like a parameter in this sense and, in this case, everything is allowed =96 the answer may contain the same fmtp or different= . =A0RFC3264 doesn=92t appear to specify the interpretation.=A0 The problem i= s that I don't know of anywhere else where the interpretation is specif= ied either.=A0 RFC4856 =A0specifies the parameter =91annexb=92, but doesn=92t say whether it can be used asymmetrically (or how).=A0 The only other guidance = I can find on this is elsewhere in RFC3264:

=A0

=A0=A0 The list of media formats for each media stream conveys two pieces of

=A0=A0 information, namely the set of formats (codecs and any parameters

=A0=A0 associated with the codec, in the case of RTP) that the offerer is

=A0=A0 capable of sending and/or receiving (depending on the direction

=A0=A0 attributes)...

=A0=A0 ...For a sendrecv stream, the offer SHOULD indicate those

=A0=A0 codecs that the offerer is willing to send and receive with.

=A0

So, this appears to be lu= mping codec parameters with codecs and so both should behave in the same way.=A0 If we take this interpretation, then indicating =91annexb=3Dno=92 indicates that the sender of this SDP is willi= ng to send and receive with silence suppression off.=A0 So, according to this, if the offerer sends =91annexb=3Dyes=92 in the offer and the answerer sends back =91annexb=3Dno=92, then there is a mismatch and the offerer should send a r= e-INVITE with =91annexb=3Dno=92 to resolve the conflict.=A0 According to this interp= retation, we cannot have an asymmetric use of silence suppression.=A0 However, =A0fro= m the discussion we're having, I can see that all of this is somewhat o= pen 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. =A0Harprit.


Harprit S. Chhatwal

InnoMedia


<= div class=3D"gmail_quote">On 28 February 2012 16:54, Kevin P. Fleming <kpfleming@digium.c= om> wrote:
On 02/27/2012 11:12 AM, Paul Kyzivat wrote:<= br>
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-J= anuary/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 &q= uot;no".

3) permit the answer to contain "yes" (explicitly or by default)<= br> when the offer contained "no", and specify that this still means<= br> that the annex is *not* to be used.

4) forbid the answer from *explicitly* containing "yes" when the<= br> offer contained "no", but allow the answer to *implicitly* contai= n
"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 Anne= x B have to be symmetrical? Until I saw this thread, it was always my under= standing that the 'annexb' format parameter for G.729 in SDP indica= ted the preference of the endpoint sending that parameter. Like nearly ever= ything 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 'intero= p' issues are really just very poorly coded implementations. I would in= terpret 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/answeri= ng 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/answerin= g endpoint.

3) An answer's value for the 'annexb' parameter is completely i= ndependent 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] On Behalf Of
internet-draf= ts@ietf.org
Sent: Friday, February 24, 2012 5:57 PM
To: i-d-announce= @ietf.org
Subject: I-D Action: draft-muthu-payload-offer-answer-g723-g729-00.t= xt


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/draf= t-muthu-payload-offer-answer-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
-g729-00.txt

_______________________________________________
I-D-Announce mailing list
I-D-Announce@iet= f.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<= br> https://www.ietf.org/mailman/listinfo/payload


--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kfleming@d= igium.com | SIP: kpfleming@digium.com | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.dig= ium.com & www= .asterisk.org
_______________________________________________
payload mailing list
payload@ietf.org<= br> https://www.ietf.org/mailman/listinfo/payload

--f46d044303f0dd89c904ba09a2e2-- From pkyzivat@alum.mit.edu Tue Feb 28 10:07:07 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 9541521F8573 for ; Tue, 28 Feb 2012 10:07:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, 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 mfBXPbPXclTd for ; Tue, 28 Feb 2012 10:07:06 -0800 (PST) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by ietfa.amsl.com (Postfix) with ESMTP id 1060E21F8498 for ; Tue, 28 Feb 2012 10:07:05 -0800 (PST) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta08.westchester.pa.mail.comcast.net with comcast id fW0n1i0040xGWP858W76MY; Tue, 28 Feb 2012 18:07:06 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta12.westchester.pa.mail.comcast.net with comcast id fW751i00v07duvL3YW75y5; Tue, 28 Feb 2012 18:07:06 +0000 Message-ID: <4F4D17C8.7070201@alum.mit.edu> Date: Tue, 28 Feb 2012 13:07:04 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Chhatwal, Harprit S" References: <1D062974A4845E4D8A343C653804920207ABB1E1@XMB-BGL-414.cisco.com> <4F4BB973.4060508@alum.mit.edu> <4F4D06B6.6020905@digium.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit 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: Tue, 28 Feb 2012 18:07:07 -0000 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. 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 > > > 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 > > [mailto:i-d-announce-bounces@__ietf.org > ] On Behalf Of > internet-drafts@ietf.org > Sent: Friday, February 24, 2012 5:57 PM > To: 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 > > 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 > > -g729-00.txt > > _________________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/__listinfo/i-d-announce > > Internet-Draft directories: > http://www.ietf.org/shadow.__html > > or ftp://ftp.ietf.org/ietf/__1shadow-sites.txt > > > > _________________________________________________ > 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 > > > From kpfleming@digium.com Tue Feb 28 11: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 CAA7A21F8681 for ; Tue, 28 Feb 2012 11:10:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.54 X-Spam-Level: X-Spam-Status: No, score=-106.54 tagged_above=-999 required=5 tests=[AWL=0.059, 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 GFSxm6HSd7Sc for ; Tue, 28 Feb 2012 11:10:44 -0800 (PST) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id F180F21F8674 for ; Tue, 28 Feb 2012 11:10:43 -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 1S2SRe-0003xx-VF; Tue, 28 Feb 2012 13:10:42 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id EB73BD8006; Tue, 28 Feb 2012 13:10:42 -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 6+EIy9pA7QUA; Tue, 28 Feb 2012 13:10:38 -0600 (CST) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id ADDE9D8002; Tue, 28 Feb 2012 13:10:38 -0600 (CST) Message-ID: <4F4D26AE.5070009@digium.com> Date: Tue, 28 Feb 2012 13:10:38 -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: Paul Kyzivat References: <1D062974A4845E4D8A343C653804920207ABB1E1@XMB-BGL-414.cisco.com> <4F4BB973.4060508@alum.mit.edu> <4F4D06B6.6020905@digium.com> <4F4D17C8.7070201@alum.mit.edu> In-Reply-To: <4F4D17C8.7070201@alum.mit.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable 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: Tue, 28 Feb 2012 19:10:49 -0000 On 02/28/2012 12:07 PM, Paul Kyzivat wrote: > Clarification: > > In my comments on the draft I was not questioning the assumption of tha= t > 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=20 intended to be a negotiated parameter. I'm not a codec person (although I'd probably be willing to play one on=20 TV is the need arose ), but there are so many other codec/format=20 parameters that are declarative already that I don't see any need for=20 this one to have to be negotiated. The impact of using Annex B or not is=20 purely on one direction of the media stream, and it's not even mandatory=20 that the encoder use Annex B mode just because 'annexb=3Dyes'. Granted,=20 it's pretty unlikely that an implementation that cannot accept incoming=20 SID frames would also be able to generate them, but I can think of=20 completely reasonable situations for an implementation that can generate=20 them being willing to do so while at the same time disallowing reception=20 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 =91sendrecv=92). = 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 >> =91annexb=92 : >> >> 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, =91annexb=92 is more like a parameter in this sense and, in thi= s >> case, everything is allowed =96 the answer may contain the same fmtp o= r >> different. RFC3264 doesn=92t 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 =91annexb=92, but >> doesn=92t 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 bot= h >> should behave in the same way. If we take this interpretation, then >> indicating =91annexb=3Dno=92 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 =91annexb=3Dyes=92 in the offer and the ans= werer >> sends back =91annexb=3Dno=92, then there is a mismatch and the offerer= should >> send a re-INVITE with =91annexb=3Dno=92 to resolve the conflict. Accor= ding 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 >> >> >> 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 >> ] On Behalf Of >> internet-drafts@ietf.org >> Sent: Friday, February 24, 2012 5:57 PM >> To: 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-answ= er-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-answe= r-g723 >> >> >> >> -g729-00.txt >> >> _________________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/__listinfo/i-d-announce >> >> Internet-Draft directories: >> http://www.ietf.org/shadow.__html >> >> or ftp://ftp.ietf.org/ietf/__1shadow-sites.txt >> >> >> >> _________________________________________________ >> 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 >> >> >> > --=20 Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpflemin= g 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org From hschhatwal@gmail.com Tue Feb 28 12:58:19 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 7D83B21E806B for ; Tue, 28 Feb 2012 12:58:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.932 X-Spam-Level: X-Spam-Status: No, score=-1.932 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] 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 Tv5WYYzz+URs for ; Tue, 28 Feb 2012 12:58:17 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id EF01D21E806A for ; Tue, 28 Feb 2012 12:58:16 -0800 (PST) Received: by werb10 with SMTP id b10so2588843wer.31 for ; Tue, 28 Feb 2012 12:58:16 -0800 (PST) Received-SPF: pass (google.com: domain of hschhatwal@gmail.com designates 10.181.11.227 as permitted sender) client-ip=10.181.11.227; Authentication-Results: mr.google.com; spf=pass (google.com: domain of hschhatwal@gmail.com designates 10.181.11.227 as permitted sender) smtp.mail=hschhatwal@gmail.com; dkim=pass header.i=hschhatwal@gmail.com Received: from mr.google.com ([10.181.11.227]) by 10.181.11.227 with SMTP id el3mr42205381wid.18.1330462696249 (num_hops = 1); Tue, 28 Feb 2012 12:58:16 -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=cICgf8+VK10U502S+VeZRJ3wfKi8spEYLamfCrQNn8M=; b=dzr+hyDC6FlwnxsWe+WhHjIWuN9fudcaabRBFN20tk5SuedCe9Q4v4vAZ5e5Uo9nL5 MsYFATEbwZtQtnWPCuLUlcoiogWCKn6DWOFf0Slh9eeAk5eVdDq1e3phMozwRW66ZvPi 9fK2CrS6KueIQ+2puzKb6NnrDTxd8oqdeZdOw= MIME-Version: 1.0 Received: by 10.181.11.227 with SMTP id el3mr33445692wid.18.1330462696061; Tue, 28 Feb 2012 12:58:16 -0800 (PST) Received: by 10.180.96.166 with HTTP; Tue, 28 Feb 2012 12:58:16 -0800 (PST) In-Reply-To: <4F4D26AE.5070009@digium.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> Date: Tue, 28 Feb 2012 20:58:16 +0000 Message-ID: From: "Chhatwal, Harprit S" To: "Kevin P. Fleming" Content-Type: multipart/alternative; boundary=f46d043be25e62b9d804ba0c7c0b 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: Tue, 28 Feb 2012 20:58:19 -0000 --f46d043be25e62b9d804ba0c7c0b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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. 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 T= V > is the need arose ), but there are so many other codec/format paramete= rs > that are declarative already that I don't see any need for this one to ha= ve > 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 encod= er > use Annex B mode just because 'annexb=3Dyes'. Granted, it's pretty unlike= ly > that an implementation that cannot accept incoming SID frames would also = be > able to generate them, but I can think of completely reasonable situation= s > 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 =91sendrecv=92). A= s 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 >>> =91annexb=92 : >>> >>> 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, =91annexb=92 is more like a parameter in this sense and, in this >>> case, everything is allowed =96 the answer may contain the same fmtp or >>> different. RFC3264 doesn=92t 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 =91annexb=92, but >>> doesn=92t 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 =91annexb=3Dno=92 indicates that the sender of this SDP is w= illing >>> to send and receive with silence suppression off. So, according to >>> this, if the offerer sends =91annexb=3Dyes=92 in the offer and the answ= erer >>> sends back =91annexb=3Dno=92, then there is a mismatch and the offerer = should >>> send a re-INVITE with =91annexb=3Dno=92 to resolve the conflict. Accord= ing 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 >>> >>> > >>> >>> 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 >>> = >] >>> On Behalf Of >>> internet-drafts@ietf.org >>> > >>> Sent: Friday, February 24, 2012 5:57 PM >>> To: 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 >>> >>> >> offer-answer-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 >>> > >>> >>> -g729-00.txt >>> >>> ______________________________**___________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/_**_listinfo/i-d-announce >>> >>> > >>> Internet-Draft directories: >>> http://www.ietf.org/shadow.__**html >>> > >>> or ftp://ftp.ietf.org/ietf/__**1shadow-sites.txt >>> >>> > >>> >>> >>> ______________________________**___________________ >>> 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: kpflemin= g > > 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA > Check us out at www.digium.com & www.asterisk.org > --f46d043be25e62b9d804ba0c7c0b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Speaking as a codec person :-), I think the draft does address a real issue= and is reasonably clear in its content. =A0However, it does not appear to = address (as far as I can see), the case where an asymmetric use of G.729B i= s required. =A0This is an actual issue as we are faced with a customer requ= irement where the use of G.729B is required in one direction and not the ot= her (for bandwidth reasons). =A0Given the current specs do not appear to de= finitively cover this case, it would be good to see if this can be addresse= d through the proposed draft.

Regards. =A0Harprit.

Harprit S. Chh= atwal
InnoMedia=A0

On 28 Februa= ry 2012 19:10, Kevin P. Fleming <kpfleming@digium.com> wrote:
On 02/28/2012 12:07 PM, Pa= ul 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 on= e on TV is the need arose <G>), but there are so many other codec/for= mat parameters that are declarative already that I don't see any need f= or 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 mandato= ry that the encoder use Annex B mode just because 'annexb=3Dyes'. G= ranted, 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 t= hem 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<= br> 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 =91sendrecv=92). 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
=91annexb=92 :

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, =91annexb=92 is more like a parameter in this sense and, in this
case, everything is allowed =96 the answer may contain the same fmtp or
different. RFC3264 doesn=92t appear to specify the interpretation. The
problem is that I don't know of anywhere else where the interpretation<= br> is specified either. RFC4856 specifies the parameter =91annexb=92, but
doesn=92t 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 =91annexb=3Dno=92 indicates that the sender of this SDP is willi= ng
to send and receive with silence suppression off. So, according to
this, if the offerer sends =91annexb=3Dyes=92 in the offer and the answerer=
sends back =91annexb=3Dno=92, then there is a mismatch and the offerer shou= ld
send a re-INVITE with =91annexb=3Dno=92 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<= br> 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:kpflem= ing@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/20= 08-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 &q= uot;no".

3) permit the answer to contain "yes" (explicitly or by default)<= br> when the offer contained "no", and specify that this still means<= br> that the annex is *not* to be used.

4) forbid the answer from *explicitly* containing "yes" when the<= br> offer contained "no", but allow the answer to *implicitly* contai= n
"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<= br> 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<= br> 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-anno= unce-bounces@__iet= f.org
<mailto:i-d-announce-bounces@ietf.org>] On Behalf Of
internet-draf= ts@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>
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-__draft= s/draft-muthu-payload-__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://f= tp.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/d= raft-muthu-payload-offer-answer-g723>

-g729-00.txt

_________________________________________________
I-D-Announce mailing list
I-D-Announce@iet= f.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&g= t;
Internet-Draft directories:
http://www.= ietf.org/shadow.__html
<http://ww= w.ietf.org/shadow.html>
or ftp://ftp.ietf.org/ietf/__1shadow-sites.txt
<ftp://ftp.ietf.org/ietf/1shadow-sites.txt>


_________________________________________________
payload mailing list
payload@ietf.org = <mailto:payload@ie= tf.org>
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@d= igium.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.dig= ium.com <http://= www.digium.com> &
www.asterisk.org = <http://www.asteri= sk.org>
_________________________________________________
payload mailing list
payload@ietf.org = <mailto:payload@ie= tf.org>
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@d= igium.com | SIP: kpfleming@digium.com | Skype: kpfleming

445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.dig= ium.com & www= .asterisk.org

--f46d043be25e62b9d804ba0c7c0b-- From kpfleming@digium.com Tue Feb 28 13:01: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 D494121F8547 for ; Tue, 28 Feb 2012 13:01:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.543 X-Spam-Level: X-Spam-Status: No, score=-106.543 tagged_above=-999 required=5 tests=[AWL=0.056, 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 CXX+Q2-B583V for ; Tue, 28 Feb 2012 13:01:27 -0800 (PST) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id 2B94921F853D for ; Tue, 28 Feb 2012 13:01:27 -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 1S2UAn-0005a5-E3; Tue, 28 Feb 2012 15:01:25 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id 6D089D8006; Tue, 28 Feb 2012 15:01:25 -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 2Yrjq8Y+j6lO; Tue, 28 Feb 2012 15:01:24 -0600 (CST) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 4BD08D8002; Tue, 28 Feb 2012 15:01:24 -0600 (CST) Message-ID: <4F4D40A3.6030309@digium.com> Date: Tue, 28 Feb 2012 15:01:23 -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: "Chhatwal, Harprit S" 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> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable 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: Tue, 28 Feb 2012 21:01:28 -0000 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 wit= h > 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 t= o > see if this can be addressed through the proposed draft. That requirement is counter to what the draft proposes. We can't have it=20 both ways: either the G.729 'annexb' format parameter is a negotiated=20 parameter (in which case its usage is symmetrical by definition) or it=20 is a declarative parameter (in which case the usage can be, but is not=20 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 assumptio= n > 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 nailin= g > 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 on= e > 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 th= em. > > > > 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 thing= s > 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 > =91sendrecv=92). 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 parameter= s > such as > =91annexb=92 : > > The interpretation of fmtp parameters in an offer depends o= n the > > parameters. In many cases, those parameters describe specif= ic > > 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 perfec= tly > > 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 pr= oper > > interpretation in offer/answer. > > To me, =91annexb=92 is more like a parameter in this sense = and, > in this > case, everything is allowed =96 the answer may contain the > same fmtp or > different. RFC3264 doesn=92t 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 > =91annexb=92, but > doesn=92t 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 direc= tion > > 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 =91annexb=3Dno=92 indicates that the sender of t= his SDP > is willing > to send and receive with silence suppression off. So, > according to > this, if the offerer sends =91annexb=3Dyes=92 in the offer = and the > answerer > sends back =91annexb=3Dno=92, then there is a mismatch and = the > offerer should > send a re-INVITE with =91annexb=3Dno=92 to resolve the conf= lict. > According to > this interpretation, we cannot have an asymmetric use of si= lence > 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 wit= h > (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) wro= te: > > 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 > > > > > 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 i= f 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 def= ault) > 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" whe= n 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 wh= at > should be > done if this is violated. (3) risks failing to recognize th= at > 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 answ= erer, > 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 usa= ge 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 complete= ly > independent of the value (if any) present in the offer it i= s > answering. > > > Thanks, > Paul > > Muthu > > -----Original Message----- > From: i-d-announce-bounces@ietf.org > > > > [mailto:i-d-announce-bounces@ > ____ietf.org > >] On Behalf Of > internet-drafts@ietf.org > > > Sent: Friday, February 24, 2012 5:57 PM > To: 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 a= nnexb > 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 > > > > > > 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 > > > > > > -g729-00.txt > > ___________________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > > > https://www.ietf.org/mailman/____listinfo/i-d-announce > > > > Internet-Draft directories: > http://www.ietf.org/shadow.____html > > > > or ftp://ftp.ietf.org/ietf/____1shadow-sites.txt > > > > > > ___________________________________________________ > 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: kpflemi= ng > > 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA > Check us out at www.digium.com & > www.asterisk.org > > --=20 Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpflemin= g 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org From glenzorn@gmail.com Tue Feb 28 19:20:09 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 AA30921E8114 for ; Tue, 28 Feb 2012 19:20:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[AWL=0.102, 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 ghwuIRUd5W9L for ; Tue, 28 Feb 2012 19:20:08 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 45B0421E8117 for ; Tue, 28 Feb 2012 19:20:08 -0800 (PST) Received: by obbeh20 with SMTP id eh20so4157475obb.31 for ; Tue, 28 Feb 2012 19:20:08 -0800 (PST) Received-SPF: pass (google.com: domain of glenzorn@gmail.com designates 10.50.156.225 as permitted sender) client-ip=10.50.156.225; Authentication-Results: mr.google.com; spf=pass (google.com: domain of glenzorn@gmail.com designates 10.50.156.225 as permitted sender) smtp.mail=glenzorn@gmail.com; dkim=pass header.i=glenzorn@gmail.com Received: from mr.google.com ([10.50.156.225]) by 10.50.156.225 with SMTP id wh1mr19215217igb.0.1330485607913 (num_hops = 1); Tue, 28 Feb 2012 19:20:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=zO23aa3tO5lFIinOfkGOstG3JAEUbfrIhrBpcn/rF/0=; b=L/By060FyPRhdr3qS7BmWE+SgksGN33IaA0tTFvvqWeFNz6WN5xgZUKjxbHnKYJ+Fu V0A/nD803tsSqVWtM321MNqp1T1h4hFtNtt/X1WcMVorxkHIAY5R/b72vPAAuy/T/FCC JpDowOYw1ANvaf9hhlDZaJu1Xl/fhuigXQgIc= Received: by 10.50.156.225 with SMTP id wh1mr15670870igb.0.1330485607834; Tue, 28 Feb 2012 19:20:07 -0800 (PST) Received: from [192.168.1.98] (ppp-124-120-184-177.revip2.asianet.co.th. [124.120.184.177]) by mx.google.com with ESMTPS id vr4sm18248765igb.1.2012.02.28.19.20.04 (version=SSLv3 cipher=OTHER); Tue, 28 Feb 2012 19:20:06 -0800 (PST) Message-ID: <4F4D9961.4080109@gmail.com> Date: Wed, 29 Feb 2012 10:20:01 +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: Paul Kyzivat References: <4F4CE656.4030407@alum.mit.edu> In-Reply-To: <4F4CE656.4030407@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: payload@ietf.org Subject: Re: [payload] payload Digest, Vol 14, Issue 10 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, 29 Feb 2012 03:20:09 -0000 On 2/28/2012 9:36 PM, Paul Kyzivat wrote: > On 2/28/12 7:05 AM, alvin hut wrote: >> I DONT UNDERSTAND THESE EMILS > > Could you say more about what you are having trouble with? > Did you read the draft? My guess is that Mr. Hut somehow became accidentally subscribed to this list. > > Thanks, > Paul > >> From: payload-request@ietf.org >> Subject: payload Digest, Vol 14, Issue 10 >> To: payload@ietf.org >> Date: Mon, 27 Feb 2012 12:00:09 -0800 >> >> If you have received this digest without all the individual message >> attachments you will need to update your digest options in your list >> subscription. To do so, go to >> >> https://www.ietf.org/mailman/listinfo/payload >> >> Click the 'Unsubscribe or edit options' button, log in, and set "Get >> MIME or Plain Text Digests?" to MIME. You can set this option >> globally for all the list digests you receive at this point. >> >> >> >> Send payload mailing list submissions to >> payload@ietf.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://www.ietf.org/mailman/listinfo/payload >> or, via email, send a message with subject or body 'help' to >> payload-request@ietf.org >> >> You can reach the person managing the list at >> payload-owner@ietf.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of payload digest..." >> >> >> >> --Forwarded Message Attachment-- >> From: pravindran@sonusnet.com >> CC: payload@ietf.org >> To: pkyzivat@alum.mit.edu; mperumal@cisco.com >> Date: Mon, 27 Feb 2012 18:21:55 +0000 >> Subject: Re: [payload] FW: I-D Action: >> draft-muthu-payload-offer-answer-g723-g729-00.txt >> >> Paul, >> >> I agree with your proposal of (2) for answerer as it makes sure that >> "annexa=no" in G.723 or "annexb=no" in G.729 is negotiated in case >> offerer requested for. >> >> The issue with (4) in offerer is that offerer may ignore or treat as >> "no" but answerer treats negotiated parameter as "yes" and answerer >> exchanges/expects further media packets based on this assumption which >> leads to call failure or interop issue in reality. I agree with (4) in >> case we get the opinion from others that (4) is the best common >> practice in the industry. >> >> Thanks >> Partha >> >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>> Sent: Monday, February 27, 2012 10:42 PM >>> To: Muthu Arul Mozhi Perumal (mperumal) >>> Cc: payload@ietf.org; Ravindran, Parthasarathi >>> Subject: Re: FW: I-D Action: draft-muthu-payload-offer-answer-g723-g729- >>> 00.txt >>> >>> 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 >>>> >>>> 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. >>> >>> Thanks, >>> Paul >>> >>>> Muthu >>>> >>>> -----Original Message----- >>>> From: i-d-announce-bounces@ietf.org >>>> [mailto:i-d-announce-bounces@ietf.org] On Behalf Of >>>> internet-drafts@ietf.org >>>> Sent: Friday, February 24, 2012 5:57 PM >>>> To: 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-g >>>> 72 >>>> 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-g7 >>>> 23 >>>> -g729-00.txt >>>> >>>> _______________________________________________ >>>> I-D-Announce mailing list >>>> I-D-Announce@ietf.org >>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>> Internet-Draft directories:http://www.ietf.org/shadow.html or >>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>> >> >> >> >> >> >> _______________________________________________ >> 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 ron.even.tlv@gmail.com Wed Feb 29 01:20:57 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 4275221F8841 for ; Wed, 29 Feb 2012 01:20:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.418 X-Spam-Level: X-Spam-Status: No, score=-3.418 tagged_above=-999 required=5 tests=[AWL=0.180, 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 Yg+eE0rcG42c for ; Wed, 29 Feb 2012 01:20:56 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2DCCA21F87C8 for ; Wed, 29 Feb 2012 01:20:55 -0800 (PST) Received: by eeke51 with SMTP id e51so1567972eek.31 for ; Wed, 29 Feb 2012 01:20:54 -0800 (PST) Received-SPF: pass (google.com: domain of ron.even.tlv@gmail.com designates 10.213.32.67 as permitted sender) client-ip=10.213.32.67; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ron.even.tlv@gmail.com designates 10.213.32.67 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.213.32.67]) by 10.213.32.67 with SMTP id b3mr345733ebd.75.1330507254439 (num_hops = 1); Wed, 29 Feb 2012 01:20:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:subject:date:message-id:mime-version:content-type:x-mailer :thread-index:content-language; bh=b+spi7Wb1a76nFNuT2XflQBwFZc5QHmYzEIYqFTCbFw=; b=Wz9mQ9yENUKGI5TSzfOjrc5U8C92HEeARaE64nYUYuOBEXmVgZZbciu5FeSAUDfcfF Yl5ECLvVvREga+DDzqFnLvfG/bBFDNAVV2tvUc9r1NgbAX1fhgGu/ehd0RNk0yu3VVqf 4zZvCoj+L0Pls0imBs416grlEt1XyGlRNYbhI= Received: by 10.213.32.67 with SMTP id b3mr285904ebd.75.1330507254315; Wed, 29 Feb 2012 01:20:54 -0800 (PST) Received: from windows8d787f9 (bzq-109-67-208-29.red.bezeqint.net. [109.67.208.29]) by mx.google.com with ESMTPS id u9sm80660017eem.11.2012.02.29.01.20.52 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 29 Feb 2012 01:20:53 -0800 (PST) From: "Roni Even" To: Date: Wed, 29 Feb 2012 11:20:06 +0200 Message-ID: <4f4dedf5.89b90e0a.711a.ffffc89a@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_045B_01CCF6D4.1894DB10" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acz2w1MogSlDCWZWS2auMi+WGB+Cww== Content-Language: en-us Subject: [payload] second WGLC on draft-ietf-avt-rtp-evrc-nw 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, 29 Feb 2012 09:20:57 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_045B_01CCF6D4.1894DB10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, There were some changes in the draft after the WGLC. The changes provide clarification on the usage of the "mode-set-recv" SDP attribute and the MMM field in RTP payload header and add a new section (Section 11) to define the mode change request/response behavior. Even though they are more editorial as can be seen http://tools.ietf.org/rfcdiff?url2=draft-ietf-avt-rtp-evrc-nw-06.txt I would like to start a second Working Group Last Call on draft-ietf-avt-rtp-evrc-nw-06 , RTP payload format for Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW) in order to allow the WG to review the changes and comment. The WGLC will end on March 14th , 2012 Please review the draft and send comments to the list. Roni Even Payload co-chair ------=_NextPart_000_045B_01CCF6D4.1894DB10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

There were some = changes in the draft after the WGLC.

 

The = changes provide clarification on the usage of the = "mode-set-recv" SDP attribute and the MMM field in RTP payload = header and add a new section (Section 11) to define the mode change = request/response behavior.

Even = though they are more editorial as can be seen http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-avt-rtp-evrc-nw-06= .txt

 

I would like to start a second Working Group Last = Call on draft-i= etf-avt-rtp-evrc-nw-06 , RTP payload format for = Enhanced Variable Rate Narrowband-Wideband Codec  (EVRC-NW) in = order to allow the WG to review the changes and = comment.

 

 

The WGLC will end on March 14th , = 2012

Please review the draft = and send comments to the list.

 

 

 

 

Roni = Even

Payload = co-chair

 

 

------=_NextPart_000_045B_01CCF6D4.1894DB10-- From glenzorn@gmail.com Wed Feb 29 04:40: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 3B76F21F8809 for ; Wed, 29 Feb 2012 04:40:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.418 X-Spam-Level: X-Spam-Status: No, score=-2.418 tagged_above=-999 required=5 tests=[AWL=1.181, 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 j7tJJiuI6SGc for ; Wed, 29 Feb 2012 04:40:52 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id A502821F8806 for ; Wed, 29 Feb 2012 04:40:52 -0800 (PST) Received: by ggmi1 with SMTP id i1so80106ggm.31 for ; Wed, 29 Feb 2012 04:40:52 -0800 (PST) Received-SPF: pass (google.com: domain of glenzorn@gmail.com designates 10.50.46.194 as permitted sender) client-ip=10.50.46.194; Authentication-Results: mr.google.com; spf=pass (google.com: domain of glenzorn@gmail.com designates 10.50.46.194 as permitted sender) smtp.mail=glenzorn@gmail.com; dkim=pass header.i=glenzorn@gmail.com Received: from mr.google.com ([10.50.46.194]) by 10.50.46.194 with SMTP id x2mr28436igm.60.1330519252147 (num_hops = 1); Wed, 29 Feb 2012 04:40:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Dv2swzmAqZSRebdNWcIw8dQ2mCtTAiYwd+u0xarhWcc=; b=KXRiETNlTA6/tlbdV2NHaEzpmYbyHM9TfqgoNybsZqXdwXcJwrNv3YDkWOnS3f94pm QeMhCiHyhUp9wWEcYvV3AL7LOVVaZrinUBrvUNeWaPpI1DYF1d3PiO786Pw4EWbR8QxC FYtRPjZ1nbW0Wtk4Qhp7R5kA4D0i9+9b5BkPw= Received: by 10.50.46.194 with SMTP id x2mr22745igm.60.1330519252094; Wed, 29 Feb 2012 04:40:52 -0800 (PST) Received: from [192.168.1.98] (ppp-124-121-210-134.revip2.asianet.co.th. [124.121.210.134]) by mx.google.com with ESMTPS id r1sm15051581igb.0.2012.02.29.04.40.48 (version=SSLv3 cipher=OTHER); Wed, 29 Feb 2012 04:40:50 -0800 (PST) Message-ID: <4F4E1CCA.8070506@gmail.com> Date: Wed, 29 Feb 2012 19:40:42 +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: Roni Even References: <4f4dedf5.89b90e0a.711a.ffffc89a@mx.google.com> In-Reply-To: <4f4dedf5.89b90e0a.711a.ffffc89a@mx.google.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: payload@ietf.org Subject: Re: [payload] second WGLC on draft-ietf-avt-rtp-evrc-nw 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, 29 Feb 2012 12:40:53 -0000 On 2/29/2012 4:20 PM, Roni Even wrote: > Hi, > > There were some changes in the draft after the WGLC. > > > > The changes provide clarification on the usage of the "mode-set-recv" > SDP attribute and the MMM field in RTP payload header and add a new > section (Section 11) to define the mode change request/response behavior. > > Even though they are more editorial as can be seen > http://tools.ietf.org/rfcdiff?url2=draft-ietf-avt-rtp-evrc-nw-06.txt > > > > I would like to start a second Working Group Last Call on > draft-ietf-avt-rtp-evrc-nw-06 > , RTP payload > format for Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW) > in order to allow the WG to review the changes and comment. > > > > > > The WGLC will end on March 14^th , 2012 > > Please review the draft and send comments to the list. Looks good to me. > > > > > > > > > > Roni Even > > Payload co-chair > > > > > > > > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload From hschhatwal@gmail.com Wed Feb 29 06:34: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 C66E221F85EC for ; Wed, 29 Feb 2012 06:34:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.932 X-Spam-Level: X-Spam-Status: No, score=-1.932 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] 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 AJGLzqGvjKsx for ; Wed, 29 Feb 2012 06:34:36 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 52B7C21F85E6 for ; Wed, 29 Feb 2012 06:34:35 -0800 (PST) Received: by wicr5 with SMTP id r5so2747320wic.31 for ; Wed, 29 Feb 2012 06:34:34 -0800 (PST) Received-SPF: pass (google.com: domain of hschhatwal@gmail.com designates 10.180.95.105 as permitted sender) client-ip=10.180.95.105; Authentication-Results: mr.google.com; spf=pass (google.com: domain of hschhatwal@gmail.com designates 10.180.95.105 as permitted sender) smtp.mail=hschhatwal@gmail.com; dkim=pass header.i=hschhatwal@gmail.com Received: from mr.google.com ([10.180.95.105]) by 10.180.95.105 with SMTP id dj9mr1351470wib.18.1330526074586 (num_hops = 1); Wed, 29 Feb 2012 06:34:34 -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=0Sx81Nxp69tosTIkawpBzYFMxQ5zVTho55hMgxBqlvQ=; b=TashI9Q7d1jb+wy8IRcYaz2o2hL0tM5uoaP9ufEJrLhuOHIjZ14twlyp4urKclJ9o6 WbAUOkrgyeufarbxCpaCjdLUPOMgUBtPh3/01+IvkO9kqCxtSwfBHXPnJa9cECYc9e4G cNc07IRyBxD79izdX4NlL0XT3MXYny8EmhVVs= MIME-Version: 1.0 Received: by 10.180.95.105 with SMTP id dj9mr1093476wib.18.1330526074424; Wed, 29 Feb 2012 06:34:34 -0800 (PST) Received: by 10.180.96.166 with HTTP; Wed, 29 Feb 2012 06:34:34 -0800 (PST) In-Reply-To: <4F4D40A3.6030309@digium.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> Date: Wed, 29 Feb 2012 14:34:34 +0000 Message-ID: From: "Chhatwal, Harprit S" To: "Kevin P. Fleming" Content-Type: multipart/alternative; boundary=f46d0442816a07ccd904ba1b3ef4 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: Wed, 29 Feb 2012 14:34:39 -0000 --f46d0442816a07ccd904ba1b3ef4 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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 require= d > 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. 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 require= d > 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 >> =91sendrecv=92). 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 >> =91annexb=92 : >> >> 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 perfectl= y >> >> acceptable for each agent to use different values. In that >> case, the >> >> answer MAY contain fmtp parameters, and those MAY have the sa= me >> >> values as those in the offer, or they MAY be different. SDP >> >> extensions that define new parameters SHOULD specify the prop= er >> >> interpretation in offer/answer. >> >> To me, =91annexb=92 is more like a parameter in this sense an= d, >> in this >> case, everything is allowed =96 the answer may contain the >> same fmtp or >> different. RFC3264 doesn=92t 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 >> =91annexb=92, but >> doesn=92t 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 directi= on >> >> 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 =91annexb=3Dno=92 indicates that the sender of thi= s SDP >> is willing >> to send and receive with silence suppression off. So, >> according to >> this, if the offerer sends =91annexb=3Dyes=92 in the offer an= d the >> answerer >> sends back =91annexb=3Dno=92, then there is a mismatch and th= e >> offerer should >> send a re-INVITE with =91annexb=3Dno=92 to resolve the confli= ct. >> 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 >> >> >> >> 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 o= f >> 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 >> > >>] >> On Behalf Of >> internet-drafts@ietf.org >> > >> > >> >> >> >> Sent: Friday, February 24, 2012 5:57 PM >> To: 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 an= d >> 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 >> > offer-answer-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 >> > offer-answer-g723 >> >> >> >> -g729-00.txt >> >> ______________________________**_____________________ >> >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> *= * >> > >> https://www.ietf.org/mailman/_**___listinfo/i-d-announce >> >> > >> >> >> >> >> >> Internet-Draft directories: >> http://www.ietf.org/shadow.___**_html >> >> > >> >> >> >> >> or ftp://ftp.ietf.org/ietf/____**1shadow-sites.txt >> >> > >> >> >> >> >> >> >> ______________________________**_____________________ >> >> 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: kpflemin= g > 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA > Check us out at www.digium.com & www.asterisk.org > --f46d0442816a07ccd904ba1b3ef4 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On 28 February 2012 21:01, Kevin P. Fleming=A0<kpfleming@digium.com>= =A0wrote:

That requirement is counter to what the draft p= roposes. We can't have it both ways: either the G.729 'annexb' = format parameter is a negotiated parameter (in which case its usage is symm= etrical 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 curre= ntly stands) cannot accommodate an asymmetric use of G.729B. =A0However, if= we agree that both scenarios are true, real-world scenarios that need addr= essing, 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, i= n 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 neg= otiated - or any other suggestions the group might have).

If not, and we are only to allow the negotiated, symmetric u= se, then 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 ment= ioned below.

Regards. =A0Harprit.

Harprit S= . Chhatwal
InnoMedia

On 28= February 2012 21:01, Kevin P. Fleming <kpfleming@digium.com> wrote:
On 02/28/2012 02:58 PM, Ch= hatwal, Harprit S wrote:
Speaking as a codec person :-), I think the draft does address a real
issue and is reasonably clear in its content. =A0However, it does not
appear to address (as far as I can see), the case where an asymmetric
use of G.729B is required. =A0This is an actual issue as we are faced with<= br> a customer requirement where the use of G.729B is required in one
direction and not the other (for bandwidth reasons). =A0Given 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 i= t both ways: either the G.729 'annexb' format parameter is a negoti= ated 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 req= uired to be, asymmetrical).


Regards. =A0Harprit.

Harprit S. Chhatwal
InnoMedia

On 28 February 2012 19:10, Kevin P. Fleming <kpfleming@digium.com
<mailto:kpflem= ing@digium.com>> wrote:

=A0 =A0On 02/28/2012 12:07 PM, Paul Kyzivat wrote:

=A0 =A0 =A0 =A0Clarification:

=A0 =A0 =A0 =A0In my comments on the draft I was not questioning the assum= ption
=A0 =A0 =A0 =A0of that
=A0 =A0 =A0 =A0draft that a common value of this parameter is *negotiated*= via O/A.
=A0 =A0 =A0 =A0*If* you accept that assumption then my comments hopefully = make
=A0 =A0 =A0 =A0sense.

=A0 =A0 =A0 =A0But if there is debate regarding whether the parameter is =A0 =A0 =A0 =A0negotiated or
=A0 =A0 =A0 =A0declarative, then that needs to be settled first, before na= iling
=A0 =A0 =A0 =A0down
=A0 =A0 =A0 =A0clarifications for how the negotiation happens.

=A0 =A0 =A0 =A0Not being a codec person, I don't know what the common = practice
=A0 =A0 =A0 =A0is here.
=A0 =A0 =A0 =A0So I'm going to let those that have the knowledge argue= that.


=A0 =A0Correct on all points; your comments make complete sense if 'an= nexb'
=A0 =A0is intended to be a negotiated parameter.

=A0 =A0I'm not a codec person (although I'd probably be willing to= play one
=A0 =A0on TV is the need arose <G>), but there are so many other
=A0 =A0codec/format parameters that are declarative already that I don'= ;t
=A0 =A0see any need for this one to have to be negotiated. The impact of =A0 =A0using Annex B or not is purely on one direction of the media stream= ,
=A0 =A0and it's not even mandatory that the encoder use Annex B mode j= ust
=A0 =A0because 'annexb=3Dyes'. Granted, it's pretty unlikely t= hat an
=A0 =A0implementation that cannot accept incoming SID frames would also be=
=A0 =A0able to generate them, but I can think of completely reasonable
=A0 =A0situations for an implementation that can generate them being
=A0 =A0willing to do so while at the same time disallowing reception of th= em.



=A0 =A0 =A0 =A0Thanks,
=A0 =A0 =A0 =A0Paul

=A0 =A0 =A0 =A0On 2/28/12 12:34 PM, Chhatwal, Harprit S wrote:

=A0 =A0 =A0 =A0 =A0 =A0Kevin,

=A0 =A0 =A0 =A0 =A0 =A0First of all, from RFC3264, I agree with you that f= or things
=A0 =A0 =A0 =A0 =A0 =A0like IP
=A0 =A0 =A0 =A0 =A0 =A0addresses, ports, payload types, ptime, the SDP tha= t one
=A0 =A0 =A0 =A0 =A0 =A0party sends
=A0 =A0 =A0 =A0 =A0 =A0indicates the address/port/PT/ptime that the sender= would
=A0 =A0 =A0 =A0 =A0 =A0like to
=A0 =A0 =A0 =A0 =A0 =A0receive on. However, I don't believe this is ge= nerally
=A0 =A0 =A0 =A0 =A0 =A0correct for all
=A0 =A0 =A0 =A0 =A0 =A0parameters. For instance, for codecs (again from RF= C3264),
=A0 =A0 =A0 =A0 =A0 =A0the codec(s)
=A0 =A0 =A0 =A0 =A0 =A0included in an SDP offer indicates the codec(s) the= offerer
=A0 =A0 =A0 =A0 =A0 =A0is willing
=A0 =A0 =A0 =A0 =A0 =A0to send AND receive (if the directional attribute i= s
=A0 =A0 =A0 =A0 =A0 =A0=91sendrecv=92). As an
=A0 =A0 =A0 =A0 =A0 =A0example, if party A is the offerer and sends G.729 = & G.711
=A0 =A0 =A0 =A0 =A0 =A0in its SDP
=A0 =A0 =A0 =A0 =A0 =A0offer, it is saying that it is willing to use eithe= r codec.
=A0 =A0 =A0 =A0 =A0 =A0If the
=A0 =A0 =A0 =A0 =A0 =A0answerer replies with G.711, then it is only willin= g to use
=A0 =A0 =A0 =A0 =A0 =A0G.711, and
=A0 =A0 =A0 =A0 =A0 =A0then G.729 will not be used in either direction.
=A0 =A0 =A0 =A0 =A0 =A0Turning now to silence suppression, the situation d= oes not
=A0 =A0 =A0 =A0 =A0 =A0seem very
=A0 =A0 =A0 =A0 =A0 =A0clear. This is what RFC3264 has to say about fmtp p= arameters
=A0 =A0 =A0 =A0 =A0 =A0such as
=A0 =A0 =A0 =A0 =A0 =A0=91annexb=92 :

=A0 =A0 =A0 =A0 =A0 =A0The interpretation of fmtp parameters in an offer d= epends on the

=A0 =A0 =A0 =A0 =A0 =A0parameters. In many cases, those parameters describ= e specific

=A0 =A0 =A0 =A0 =A0 =A0configurations of the media format, and should ther= efore be
=A0 =A0 =A0 =A0 =A0 =A0processed

=A0 =A0 =A0 =A0 =A0 =A0as the media format value itself would be. This mea= ns that
=A0 =A0 =A0 =A0 =A0 =A0the same

=A0 =A0 =A0 =A0 =A0 =A0fmtp parameters with the same values MUST be presen= t in the
=A0 =A0 =A0 =A0 =A0 =A0answer if

=A0 =A0 =A0 =A0 =A0 =A0the media format they describe is present in the an= swer.
=A0 =A0 =A0 =A0 =A0 =A0Other fmtp

=A0 =A0 =A0 =A0 =A0 =A0parameters are more like parameters, for which it i= s perfectly

=A0 =A0 =A0 =A0 =A0 =A0acceptable for each agent to use different values. = In that
=A0 =A0 =A0 =A0 =A0 =A0case, the

=A0 =A0 =A0 =A0 =A0 =A0answer MAY contain fmtp parameters, and those MAY h= ave the same

=A0 =A0 =A0 =A0 =A0 =A0values as those in the offer, or they MAY be differ= ent. SDP

=A0 =A0 =A0 =A0 =A0 =A0extensions that define new parameters SHOULD specif= y the proper

=A0 =A0 =A0 =A0 =A0 =A0interpretation in offer/answer.

=A0 =A0 =A0 =A0 =A0 =A0To me, =91annexb=92 is more like a parameter in thi= s sense and,
=A0 =A0 =A0 =A0 =A0 =A0in this
=A0 =A0 =A0 =A0 =A0 =A0case, everything is allowed =96 the answer may cont= ain the
=A0 =A0 =A0 =A0 =A0 =A0same fmtp or
=A0 =A0 =A0 =A0 =A0 =A0different. RFC3264 doesn=92t appear to specify the<= br> =A0 =A0 =A0 =A0 =A0 =A0interpretation. The
=A0 =A0 =A0 =A0 =A0 =A0problem is that I don't know of anywhere else w= here the
=A0 =A0 =A0 =A0 =A0 =A0interpretation
=A0 =A0 =A0 =A0 =A0 =A0is specified either. RFC4856 specifies the paramete= r
=A0 =A0 =A0 =A0 =A0 =A0=91annexb=92, but
=A0 =A0 =A0 =A0 =A0 =A0doesn=92t say whether it can be used asymmetrically= (or how).
=A0 =A0 =A0 =A0 =A0 =A0The only
=A0 =A0 =A0 =A0 =A0 =A0other guidance I can find on this is elsewhere in R= FC3264:

=A0 =A0 =A0 =A0 =A0 =A0The list of media formats for each media stream con= veys two
=A0 =A0 =A0 =A0 =A0 =A0pieces of

=A0 =A0 =A0 =A0 =A0 =A0information, namely the set of formats (codecs and = any
=A0 =A0 =A0 =A0 =A0 =A0parameters

=A0 =A0 =A0 =A0 =A0 =A0associated with the codec, in the case of RTP) that= the
=A0 =A0 =A0 =A0 =A0 =A0offerer is

=A0 =A0 =A0 =A0 =A0 =A0capable of sending and/or receiving (depending on t= he direction

=A0 =A0 =A0 =A0 =A0 =A0attributes)...

=A0 =A0 =A0 =A0 =A0 =A0...For a sendrecv stream, the offer SHOULD indicate= those

=A0 =A0 =A0 =A0 =A0 =A0codecs that the offerer is willing to send and rece= ive with.

=A0 =A0 =A0 =A0 =A0 =A0So, this appears to be lumping codec parameters wit= h codecs
=A0 =A0 =A0 =A0 =A0 =A0and so both
=A0 =A0 =A0 =A0 =A0 =A0should behave in the same way. If we take this
=A0 =A0 =A0 =A0 =A0 =A0interpretation, then
=A0 =A0 =A0 =A0 =A0 =A0indicating =91annexb=3Dno=92 indicates that the sen= der of this SDP
=A0 =A0 =A0 =A0 =A0 =A0is willing
=A0 =A0 =A0 =A0 =A0 =A0to send and receive with silence suppression off. S= o,
=A0 =A0 =A0 =A0 =A0 =A0according to
=A0 =A0 =A0 =A0 =A0 =A0this, if the offerer sends =91annexb=3Dyes=92 in th= e offer and the
=A0 =A0 =A0 =A0 =A0 =A0answerer
=A0 =A0 =A0 =A0 =A0 =A0sends back =91annexb=3Dno=92, then there is a misma= tch and the
=A0 =A0 =A0 =A0 =A0 =A0offerer should
=A0 =A0 =A0 =A0 =A0 =A0send a re-INVITE with =91annexb=3Dno=92 to resolve = the conflict.
=A0 =A0 =A0 =A0 =A0 =A0According to
=A0 =A0 =A0 =A0 =A0 =A0this interpretation, we cannot have an asymmetric u= se of silence
=A0 =A0 =A0 =A0 =A0 =A0suppression. However, from the discussion we're= having, I
=A0 =A0 =A0 =A0 =A0 =A0can see that
=A0 =A0 =A0 =A0 =A0 =A0all of this is somewhat open to interpretation (sin= ce the
=A0 =A0 =A0 =A0 =A0 =A0specs do not
=A0 =A0 =A0 =A0 =A0 =A0seem to be clear) and I agree with the authors of t= his ID
=A0 =A0 =A0 =A0 =A0 =A0that we need
=A0 =A0 =A0 =A0 =A0 =A0some clarification as to how this issue should be d= ealt with
=A0 =A0 =A0 =A0 =A0 =A0(and
=A0 =A0 =A0 =A0 =A0 =A0whether asymmetric use of annexb should be allowed = and, if
=A0 =A0 =A0 =A0 =A0 =A0so, how).


=A0 =A0 =A0 =A0 =A0 =A0Regards. Harprit.


=A0 =A0 =A0 =A0 =A0 =A0Harprit S. Chhatwal

=A0 =A0 =A0 =A0 =A0 =A0InnoMedia


=A0 =A0 =A0 =A0 =A0 =A0On 28 February 2012 16:54, Kevin P. Fleming
=A0 =A0 =A0 =A0 =A0 =A0<kpfleming@digium.com <mailto:kpfleming@digium.com>
=A0 =A0 =A0 =A0 =A0 =A0<mailto:kpfleming@digium.com <mailto:kpfleming@digium.com>>>

=A0 =A0 =A0 =A0 =A0 =A0wrote:

=A0 =A0 =A0 =A0 =A0 =A0On 02/27/2012 11:12 AM, Paul Kyzivat wrote:

=A0 =A0 =A0 =A0 =A0 =A0On 2/27/12 6:33 AM, Muthu Arul Mozhi Perumal (mperu= mal) wrote:

=A0 =A0 =A0 =A0 =A0 =A0We have submitted an I-D clarifying the offer/answe= r
=A0 =A0 =A0 =A0 =A0 =A0considerations for
=A0 =A0 =A0 =A0 =A0 =A0the Annex A flavor of G.723 and the Annex B flavors= of
=A0 =A0 =A0 =A0 =A0 =A0G.729, G.729D and
=A0 =A0 =A0 =A0 =A0 =A0G.729E. This clarification is missing in RFC 4856, = leading
=A0 =A0 =A0 =A0 =A0 =A0to interop
=A0 =A0 =A0 =A0 =A0 =A0issues, for e.g:
=A0 =A0 =A0 =A0 =A0 =A0http://sipforum.org/pi= permail/____discussion/2008-January/____004026.html
=A0 =A0 =A0 =A0 =A0 =A0<http://sipforum.org/pipermail/__discussion/2008-January/__004026.html>
=A0 =A0 =A0 =A0 =A0 =A0<http://sipforum.org/__= pipermail/discussion/2008-__January/004026.html

=A0 =A0 =A0 =A0 =A0 =A0<http://sipforum.org/pipermail/discussion/2008-January/004026.html>>

=A0 =A0 =A0 =A0 =A0 =A0We have a couple of open items in the I-D. We expec= t the WG
=A0 =A0 =A0 =A0 =A0 =A0discussions
=A0 =A0 =A0 =A0 =A0 =A0would guide us on how to go about them.

=A0 =A0 =A0 =A0 =A0 =A0Comments welcome.


=A0 =A0 =A0 =A0 =A0 =A0I'm the source of the issues. :-)

=A0 =A0 =A0 =A0 =A0 =A0The fundamental point is that RFC4856 specifies a *= default*
=A0 =A0 =A0 =A0 =A0 =A0value of
=A0 =A0 =A0 =A0 =A0 =A0"yes" for annexa and annexb. This means t= hat if
=A0 =A0 =A0 =A0 =A0 =A0annexa/annexb is not
=A0 =A0 =A0 =A0 =A0 =A0specified in an answer, then it will default to yes= , even if the
=A0 =A0 =A0 =A0 =A0 =A0offer
=A0 =A0 =A0 =A0 =A0 =A0contained "no".

=A0 =A0 =A0 =A0 =A0 =A0I see a few ways to fix this:

=A0 =A0 =A0 =A0 =A0 =A01) revise the IANA registration for annexa and anne= xb to
=A0 =A0 =A0 =A0 =A0 =A0remove the
=A0 =A0 =A0 =A0 =A0 =A0default, at least when used with O/A. Instead speci= fy the
=A0 =A0 =A0 =A0 =A0 =A0defaulting
=A0 =A0 =A0 =A0 =A0 =A0separately for offers and answers.

=A0 =A0 =A0 =A0 =A0 =A02) REQUIRE that the answer contain "no" i= f the offer
=A0 =A0 =A0 =A0 =A0 =A0contained "no".

=A0 =A0 =A0 =A0 =A0 =A03) permit the answer to contain "yes" (ex= plicitly or by default)
=A0 =A0 =A0 =A0 =A0 =A0when the offer contained "no", and specif= y that this still means
=A0 =A0 =A0 =A0 =A0 =A0that the annex is *not* to be used.

=A0 =A0 =A0 =A0 =A0 =A04) forbid the answer from *explicitly* containing &= quot;yes" when the
=A0 =A0 =A0 =A0 =A0 =A0offer contained "no", but allow the answe= r to *implicitly*
=A0 =A0 =A0 =A0 =A0 =A0contain
=A0 =A0 =A0 =A0 =A0 =A0"yes" (via the default) and ignore it/tre= at it as "no".

=A0 =A0 =A0 =A0 =A0 =A0None of these are ideal. (1) is problematic because= this is
=A0 =A0 =A0 =A0 =A0 =A0used in
=A0 =A0 =A0 =A0 =A0 =A0non-O/A contexts, such as RSVP. (2) begs the questi= on of what
=A0 =A0 =A0 =A0 =A0 =A0should be
=A0 =A0 =A0 =A0 =A0 =A0done if this is violated. (3) risks failing to reco= gnize that
=A0 =A0 =A0 =A0 =A0 =A0the two
=A0 =A0 =A0 =A0 =A0 =A0sides disagree. (4) is pragmatic but seems to viola= te the
=A0 =A0 =A0 =A0 =A0 =A0spirit of
=A0 =A0 =A0 =A0 =A0 =A0defaults.

=A0 =A0 =A0 =A0 =A0 =A0I guess my preference is to make (2) normative for = the answerer,
=A0 =A0 =A0 =A0 =A0 =A0while
=A0 =A0 =A0 =A0 =A0 =A0making (4) normative for the offerer, and put enoug= h words
=A0 =A0 =A0 =A0 =A0 =A0in so its
=A0 =A0 =A0 =A0 =A0 =A0very clear what is being specified and why.


=A0 =A0 =A0 =A0 =A0 =A0I must *really* be missing something here; why does= the usage of
=A0 =A0 =A0 =A0 =A0 =A0G.729 Annex B have to be symmetrical? Until I saw t= his
=A0 =A0 =A0 =A0 =A0 =A0thread, it
=A0 =A0 =A0 =A0 =A0 =A0was always my understanding that the 'annexb= 9; format
=A0 =A0 =A0 =A0 =A0 =A0parameter for
=A0 =A0 =A0 =A0 =A0 =A0G.729 in SDP indicated the preference of the endpoi= nt
=A0 =A0 =A0 =A0 =A0 =A0sending that
=A0 =A0 =A0 =A0 =A0 =A0parameter. Like nearly everything else in SDP, it i= ndicates what
=A0 =A0 =A0 =A0 =A0 =A0that endpoint is *prepared to accept*, and has noth= ing at
=A0 =A0 =A0 =A0 =A0 =A0all to do
=A0 =A0 =A0 =A0 =A0 =A0with what it will (or could) send.

=A0 =A0 =A0 =A0 =A0 =A0Unless that's a completely broken understanding= , then these
=A0 =A0 =A0 =A0 =A0 =A0'interop' issues are really just very poorl= y coded
=A0 =A0 =A0 =A0 =A0 =A0implementations.
=A0 =A0 =A0 =A0 =A0 =A0I would interpret the current RFC language as follo= ws:

=A0 =A0 =A0 =A0 =A0 =A01) If an offer/answer contains 'annexb=3Dno'= ;, the receiver of that
=A0 =A0 =A0 =A0 =A0 =A0offer/answer MUST NOT send G.729 Annex B SID frames= to the
=A0 =A0 =A0 =A0 =A0 =A0offering/answering endpoint.

=A0 =A0 =A0 =A0 =A0 =A02) If an offer/answer contains 'annexb=3Dyes= 9;, the receiver of
=A0 =A0 =A0 =A0 =A0 =A0that
=A0 =A0 =A0 =A0 =A0 =A0offer/answer SHOULD send G.729 Annex B SID frames t= o the
=A0 =A0 =A0 =A0 =A0 =A0offering/answering endpoint.

=A0 =A0 =A0 =A0 =A0 =A03) An answer's value for the 'annexb' p= arameter is completely
=A0 =A0 =A0 =A0 =A0 =A0independent of the value (if any) present in the of= fer it is
=A0 =A0 =A0 =A0 =A0 =A0answering.


=A0 =A0 =A0 =A0 =A0 =A0Thanks,
=A0 =A0 =A0 =A0 =A0 =A0Paul

=A0 =A0 =A0 =A0 =A0 =A0Muthu

=A0 =A0 =A0 =A0 =A0 =A0-----Original Message-----
=A0 =A0 =A0 =A0 =A0 =A0From: i-d-announce-bounces@ietf.org
=A0 =A0 =A0 =A0 =A0 =A0<mailto:i-d-announce-bounces@ietf.org>
=A0 =A0 =A0 =A0 =A0 =A0<mailto:i-d-announce-bounces@__ietf.org
=A0 =A0 =A0 =A0 =A0 =A0<mailto:i-d-announce-bounces@ietf.org>>=
=A0 =A0 =A0 =A0 =A0 =A0[mailto:i-d-announce-bounces@
=A0 =A0 =A0 =A0 =A0 =A0<mailto:i-d-announce-bounces@>____ietf.org <http://ietf.org>
=A0 =A0 =A0 =A0 =A0 =A0<mailto:i-d-announce-bounces@__ietf.org
=A0 =A0 =A0 =A0 =A0 =A0<mailto:i-d-announce-bounces@ietf.org>>= ] On Behalf Of
=A0 =A0 =A0 =A0 =A0 =A0internet-drafts@ietf.org <mailto:internet-drafts@ietf.org&= gt;
=A0 =A0 =A0 =A0 =A0 =A0<mailto:internet-drafts@ietf.__org
<= br> =A0 =A0 =A0 =A0 =A0 =A0<mailto:internet-drafts@ietf.org>>
=A0 =A0 =A0 =A0 =A0 =A0Sent: Friday, February 24, 2012 5:57 PM
=A0 =A0 =A0 =A0 =A0 =A0To: i-d-announce@ietf.org <mailto:i-d-announce@ietf.org>
=A0 =A0 =A0 =A0 =A0 =A0<mailto:i-d-announce@ietf.org <mailto:i-d-announce@ietf.org>>
=A0 =A0 =A0 =A0 =A0 =A0Subject: I-D Action:
=A0 =A0 =A0 =A0 =A0 =A0draft-muthu-payload-offer-____answer-g723-g7= 29-00.txt



=A0 =A0 =A0 =A0 =A0 =A0A New Internet-Draft is available from the on-line<= br> =A0 =A0 =A0 =A0 =A0 =A0Internet-Drafts
=A0 =A0 =A0 =A0 =A0 =A0directories.

=A0 =A0 =A0 =A0 =A0 =A0Title : Offer/Answer Considerations for G.723 Annex= A
=A0 =A0 =A0 =A0 =A0 =A0and G.729 Annex B
=A0 =A0 =A0 =A0 =A0 =A0Author(s) : Muthu Arul Mozhi Perumal
=A0 =A0 =A0 =A0 =A0 =A0Parthasarathi Ravindran
=A0 =A0 =A0 =A0 =A0 =A0Filename :
=A0 =A0 =A0 =A0 =A0 =A0draft-muthu-payload-offer-____answer-g723-g7= 29-00.txt

=A0 =A0 =A0 =A0 =A0 =A0Pages : 8
=A0 =A0 =A0 =A0 =A0 =A0Date : 2012-02-24

=A0 =A0 =A0 =A0 =A0 =A0[RFC4856] describes the annexa parameter for G723 a= nd the annexb
=A0 =A0 =A0 =A0 =A0 =A0parameter for G729, G729D and G729E. However, the =A0 =A0 =A0 =A0 =A0 =A0specification does
=A0 =A0 =A0 =A0 =A0 =A0not describe the offerer and answerer behavior when= the
=A0 =A0 =A0 =A0 =A0 =A0value of the
=A0 =A0 =A0 =A0 =A0 =A0annexa or annexb parameter does not match in the SD= P offer and
=A0 =A0 =A0 =A0 =A0 =A0answer. This document provides the offer/answer
=A0 =A0 =A0 =A0 =A0 =A0considerations for
=A0 =A0 =A0 =A0 =A0 =A0these parameters.


=A0 =A0 =A0 =A0 =A0 =A0A URL for this Internet-Draft is:
=A0 =A0 =A0 =A0 =A0 =A0http://www.ietf= .org/internet-____drafts/draft-muthu-payload-____offer-answer= -g72
=A0 =A0 =A0 =A0 =A0 =A0<http://www.ietf= .org/internet-__drafts/draft-muthu-payload-__offer-answer-g72= >


=A0 =A0 =A0 =A0 =A0 =A0<http://www.ietf= .org/internet-__drafts/draft-muthu-payload-__offer-answer-g72=
=A0 =A0 =A0 =A0 =A0 =A0<http://www.ietf.org= /internet-drafts/draft-muthu-payload-offer-answer-g72>= >

=A0 =A0 =A0 =A0 =A0 =A03-g729-00.txt

=A0 =A0 =A0 =A0 =A0 =A0Internet-Drafts are also available by anonymous FTP= at:
=A0 =A0 =A0 =A0 =A0 =A0ftp://ftp.ietf.org/internet-____drafts/
=A0 =A0 =A0 =A0 =A0 =A0<ftp://ftp.ietf.org/internet-__drafts/>
=A0 =A0 =A0 =A0 =A0 =A0<ftp://ftp.ietf.org/internet-__drafts/
=A0 =A0 =A0 =A0 =A0 =A0<ftp://ftp.ietf.org/internet-drafts/>>
=A0 =A0 =A0 =A0 =A0 =A0This Internet-Draft can be retrieved at:
=A0 =A0 =A0 =A0 =A0 =A0ftp://ftp.ietf.= org/internet-____drafts/draft-muthu-payload-____offer-answer-= g723
=A0 =A0 =A0 =A0 =A0 =A0<ftp://ftp.ietf.= org/internet-__drafts/draft-muthu-payload-__offer-answer-g723= >


=A0 =A0 =A0 =A0 =A0 =A0<ftp://ftp.ietf.= org/internet-__drafts/draft-muthu-payload-__offer-answer-g723=
=A0 =A0 =A0 =A0 =A0 =A0<ftp://ftp.ietf.org/= internet-drafts/draft-muthu-payload-offer-answer-g723>= >

=A0 =A0 =A0 =A0 =A0 =A0-g729-00.txt

=A0 =A0 =A0 =A0 =A0 =A0____________________________________________= _______

=A0 =A0 =A0 =A0 =A0 =A0I-D-Announce mailing list
=A0 =A0 =A0 =A0 =A0 =A0I-D-Announce@ietf.org <mailto:I-D-Announce@ietf.org>
=A0 =A0 =A0 =A0 =A0 =A0<mailto:I-D-Announce@ietf.org <mailto:I-D-Announce@ietf.org>>
=A0 =A0 =A0 =A0 =A0 =A0https://www.ietf.org/mailman/____l= istinfo/i-d-announce
=A0 =A0 =A0 =A0 =A0 =A0<https://www.ietf.org/mailman/__l= istinfo/i-d-announce>

=A0 =A0 =A0 =A0 =A0 =A0<https://www.ietf.org/mailman/__l= istinfo/i-d-announce
=A0 =A0 =A0 =A0 =A0 =A0<https://www.ietf.org/mailman/listi= nfo/i-d-announce>>
=A0 =A0 =A0 =A0 =A0 =A0Internet-Draft directories:
=A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.org/shadow.____html
=A0 =A0 =A0 =A0 =A0 =A0<http://www.ietf.org/shadow.__html>
=A0 =A0 =A0 =A0 =A0 =A0<http://www.ietf.org/shadow.__html
=A0 =A0 =A0 =A0 =A0 =A0<http://www.ietf.org/shadow.html>>
=A0 =A0 =A0 =A0 =A0 =A0or ftp://ftp.ietf.org/ietf/____1shadow-site= s.txt
=A0 =A0 =A0 =A0 =A0 =A0<ftp://ftp.ietf.org/ietf/__1shadow-sites.t= xt>
=A0 =A0 =A0 =A0 =A0 =A0<ftp://ftp.ietf.org/ietf/__1shadow-sites.t= xt
=A0 =A0 =A0 =A0 =A0 =A0<ftp://ftp.ietf.org/ietf/1shadow-sites.txt>>


=A0 =A0 =A0 =A0 =A0 =A0____________________________________________= _______

=A0 =A0 =A0 =A0 =A0 =A0payload mailing list
=A0 =A0 =A0 =A0 =A0 =A0payload@ietf.org <mailto:payload@ietf.org>
=A0 =A0 =A0 =A0 =A0 =A0<mailto:payload@ietf.org <mailto:payload@ietf.org>>
=A0 =A0 =A0 =A0 =A0 =A0https://www.ietf.org/mailman/____listin= fo/payload
=A0 =A0 =A0 =A0 =A0 =A0<https://www.ietf.org/mailman/__listin= fo/payload>

=A0 =A0 =A0 =A0 =A0 =A0<https://www.ietf.org/mailman/__listin= fo/payload
=A0 =A0 =A0 =A0 =A0 =A0<https://www.ietf.org/mailman/listinfo/p= ayload>>



=A0 =A0 =A0 =A0 =A0 =A0--
=A0 =A0 =A0 =A0 =A0 =A0Kevin P. Fleming
=A0 =A0 =A0 =A0 =A0 =A0Digium, Inc. | Director of Software Technologies =A0 =A0 =A0 =A0 =A0 =A0Jabber: kfleming@digium.com <mailto:kfleming@digium.com>
=A0 =A0 =A0 =A0 =A0 =A0<mailto:kfleming@digium.com <mailto:kfleming@digium.com>> | SIP: =A0 =A0 =A0 =A0 =A0 =A0kpfleming@digium.com <mailto:kpfleming@digium.com>
=A0 =A0 =A0 =A0 =A0 =A0<mailto:kpfleming@digium.com <mailto:kpfleming@digium.com>>

=A0 =A0 =A0 =A0 =A0 =A0| Skype: kpfleming
=A0 =A0 =A0 =A0 =A0 =A0445 Jan Davis Drive NW - Huntsville, AL 35806 - USA=
=A0 =A0 =A0 =A0 =A0 =A0Check us out at www.digium.com <http://www.digium.com>
=A0 =A0 =A0 =A0 =A0 =A0<http://www.digium.com> &
=A0 =A0 =A0 =A0 =A0 =A0www.asterisk.org <http://www.asterisk.org>
=A0 =A0 =A0 =A0 =A0 =A0<http://www.asterisk.org>
=A0 =A0 =A0 =A0 =A0 =A0____________________________________________= _______

=A0 =A0 =A0 =A0 =A0 =A0payload mailing list
=A0 =A0 =A0 =A0 =A0 =A0payload@ietf.org <mailto:payload@ietf.org>
=A0 =A0 =A0 =A0 =A0 =A0<mailto:payload@ietf.org <mailto:payload@ietf.org>>
=A0 =A0 =A0 =A0 =A0 =A0https://www.ietf.org/mailman/____listin= fo/payload
=A0 =A0 =A0 =A0 =A0 =A0<https://www.ietf.org/mailman/__listin= fo/payload>

=A0 =A0 =A0 =A0 =A0 =A0<https://www.ietf.org/mailman/__listin= fo/payload
=A0 =A0 =A0 =A0 =A0 =A0<https://www.ietf.org/mailman/listinfo/p= ayload>>





=A0 =A0--
=A0 =A0Kevin P. Fleming
=A0 =A0Digium, Inc. | Director of Software Technologies
=A0 =A0Jabber: kf= leming@digium.com <mailto:kfleming@digium.com> | SIP:
=A0 =A0kpfleming= @digium.com <mailto:kpfleming@digium.com> | Skype: kpfleming

=A0 =A0445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
=A0 =A0Check us out at www.digium.com <http://www.digium.com> &
=A0 =A0www.asterisk.= org <http://ww= w.asterisk.org>




--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kfleming@d= igium.com | SIP: kpfleming@digium.com | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.dig= ium.com & www= .asterisk.org

--f46d0442816a07ccd904ba1b3ef4-- From pkyzivat@alum.mit.edu Wed Feb 29 07:31:19 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 0835121F866B for ; Wed, 29 Feb 2012 07:31:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 eC-R-BDNu0hu for ; Wed, 29 Feb 2012 07:31:17 -0800 (PST) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by ietfa.amsl.com (Postfix) with ESMTP id C652321F864B for ; Wed, 29 Feb 2012 07:31:16 -0800 (PST) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by QMTA11.westchester.pa.mail.comcast.net with comcast id foKg1i0041c6gX85BrXHJD; Wed, 29 Feb 2012 15:31:17 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta23.westchester.pa.mail.comcast.net with comcast id frXG1i02o07duvL3jrXGjA; Wed, 29 Feb 2012 15:31:17 +0000 Message-ID: <4F4E44C3.4080803@alum.mit.edu> Date: Wed, 29 Feb 2012 10:31:15 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Chhatwal, Harprit S" 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> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit 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: Wed, 29 Feb 2012 15:31:19 -0000 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 > > > > > > >> > > 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 > > > > >__> > 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 > > > > > > > >> > > 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 > > > > > > > >> > > -g729-00.txt > > _____________________________________________________ > > I-D-Announce mailing list > I-D-Announce@ietf.org > > > > >__> > https://www.ietf.org/mailman/______listinfo/i-d-announce > > > > > > >> > Internet-Draft directories: > http://www.ietf.org/shadow.______html > > > > > >> > or ftp://ftp.ietf.org/ietf/______1shadow-sites.txt > > > > > >> > > > _____________________________________________________ > > 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 > > From pravindran@sonusnet.com Wed Feb 29 22:13:19 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 32ECF21F8548 for ; Wed, 29 Feb 2012 22:13:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 O8qgCkp-oCpB for ; Wed, 29 Feb 2012 22:13:17 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 04B5C21F858E for ; Wed, 29 Feb 2012 22:13:16 -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 q216E0bK000968; Thu, 1 Mar 2012 01:14:00 -0500 Received: from USMA-EX-HUB1.sonusnet.com ([66.203.90.16]) by sonusmail04.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Mar 2012 01:13:11 -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, 1 Mar 2012 01:13:12 -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, 1 Mar 2012 11:43:06 +0530 From: "Ravindran, Parthasarathi" To: Paul Kyzivat , "Chhatwal, Harprit S" , "Kevin P. Fleming" Thread-Topic: [payload] FW: I-D Action: draft-muthu-payload-offer-answer-g723-g729-00.txt Thread-Index: AQHM9jmh8tfAyRy4PUGqKK/erdRd25ZSNbwAgAAJKgCAABHCAIAAHhMAgAAA34CAASZBAIAAD9eAgABm5gA= Date: Thu, 1 Mar 2012 06:13:05 +0000 Message-ID: <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> In-Reply-To: <4F4E44C3.4080803@alum.mit.edu> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 01 Mar 2012 06:13:11.0044 (UTC) FILETIME=[60DEAC40:01CCF772] 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 06:13:19 -0000 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.=20 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