Subject: [AVT] FW: RE: Comment on 3984bis: level-asymmetry-required

From: Ye-Kui Wang <[email-masked]>
Date: Tue, 01 Dec 2009 15:08:10 +0200

I got the following strange message. What is "Global Inventures" that
accepts only email addressed listed as members of "imtc_sipparity"? Who is
using this?

BR, YK

-----Original Message-----
From: Global Inventures [mailto:[email-masked]] 
Sent: Tuesday, December 01, 2009 3:01 PM
To: [email-masked]
Subject: Re: RE: [AVT] Comment on 3984bis: level-asymmetry-required

Sorry, but Global Inventures did not find your email address
-> "[email-masked]"

listed as a member of imtc_sipparity.

Only members of imtc_sipparity are allowed to contribute messages.

Because Global Inventures could not confirm that you are a member of
imtc_sipparity,
your message was not accepted.

---

Return-Path: <[email-masked]>
Received: from psmtp.com ([64.18.1.147]) by 192.168.1.85 with SMTP (Global
Inventures WIN32 version 9.3c); Tue, 01 Dec 2009 05:01:10 -0800
Received: from source ([206.16.17.180]) by exprod6mx247.postini.com
([64.18.5.10]) with SMTP;
	Tue, 01 Dec 2009 08:01:09 EST
Received: from huawei.com (usaga04-in [172.18.4.101])
 by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built
Aug
 8 2006)) with ESMTP id <[email-masked]> for
 [email-masked]; Tue, 01 Dec 2009 07:01:07 -0600 (CST)
Received: from W90946 ([10.45.0.3])
 by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built
Aug
 8 2006)) with ESMTPA id <[email-masked]> for
 [email-masked]; Tue, 01 Dec 2009 07:01:06 -0600 (CST)
Date: Tue, 01 Dec 2009 15:00:26 +0200
From: Ye-Kui Wang <[email-masked]>
Subject: RE: [AVT] Comment on 3984bis: level-asymmetry-required
In-reply-to:
 <[email-masked]>
To: "'Mo Zanaty (mzanaty)'" <[email-masked]>,
 'Roni Even' <[email-masked]>,
 "'Stuart Taylor (sttaylor)'" <[email-masked]>, [email-masked]
Cc: "'Cullen Jennings (fluffy)'" <[email-masked]>, [email-masked],
 [email-masked], [email-masked],
 "'Chelliah Sivachelvan (chelliah)'" <[email-masked]>,
 [email-masked]
Message-id: <[email-masked]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
X-Mailer: Microsoft Office Outlook 11
Content-type: multipart/alternative;
 boundary="Boundary_(ID_+5Kb5f8HbFr78tWJQD8DZA)"
Thread-index:
 Acpx+kuRI7/dC30KR/aO+c6uKAPy7gAC/vLgAABO8eAAAHNI4AADL1MgAAOJyGAAGEMOMA==
References: <[email-masked]>
 <[email-masked]>
X-pstn-neptune: 0/0/0.00/0
X-pstn-levels:     (S:91.19397/99.90000 CV:99.9000 FC:95.5390 LC:95.5390
R:95.9108 P:95.9108 M:97.0282 C:98.6951 )

This is a multi-part message in MIME format.

--Boundary_(ID_+5Kb5f8HbFr78tWJQD8DZA)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT

The following text in subsection 8.2.2 clearly tells that level downgrade is
different from level asymmetry, as Randell and Roni explained. If you don't
want level asymmetry, you just don't include the parameter or let the value
be equal to 0, then you can freely choose to do level downgrade or not. In
conclusion, I don't see any problem with the current text. 
 
o          The parameter "level-asymmetry-allowed" indicates whether level
asymmetry is allowed.

If "level-asymmetry-allowed" is equal to 0 (or not present) in either the
offer or the answer, level asymmetry is not allowed.  In this case, the
level to use in the direction from the offerer to the answerer MUST be the
same as the level to use in the opposite direction, and the common level to
use is equal to the lower value of the default level in the offer and the
default level in the answer.

Otherwise ("level-asymmetry-allowed" equals to 1 in both the offer and the
answer), level asymmetry is allowed.  In this case, the level to use in the
offerer-to-answerer direction MUST be equal to the highest level the
answerer supports for receiving, and the level to use in the
answerer-to-offerer direction MUST be equal to the highest level the offerer
supports for receiving.

When level asymmetry is not allowed, level upgrade is not allowed, i.e. the
default level in the answer MUST be equal to or lower than the default level
in the offer.

BR, YK

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mo
Zanaty (mzanaty)
Sent: Tuesday, December 01, 2009 4:10 AM
To: Roni Even; Stuart Taylor (sttaylor); [email-masked]
Cc: Cullen Jennings (fluffy); [email-masked];
[email-masked]; [email-masked]; Chelliah Sivachelvan
(chelliah); [email-masked]
Subject: Re: [AVT] Comment on 3984bis: level-asymmetry-required

I think the confusion might be due to the following text in section 8.1. It
is ambiguous whether "level asymmetry" refers to the actual RTP media level
or the SDP offer/answer level. I assume the RTP media level was intended.
But if some readers interpret this as the SDP offer/answer level, they will
incorrectly conclude that this parameter is required in order to use a
different level in the SDP answer even for level downgrade.

       level-asymmetry-allowed:
          This parameter MAY be used in SDP Offer/Answer to indicate
          whether level asymmetry, i.e., using a different level in the
          offerer-to-answerer direction than the level in the answerer-
          to-offerer direction, is allowed.  The value MAY be equal to
          either 0 or 1.  When the parameter is not present, the value
          MUST be inferred to be equal to 0.  The value 1 in both the
          offer and the answer indicates that level asymmetry is
          allowed.  The value of 0 in either the offer or the answer
          indicates the level asymmetry is not allowed.
 
          If "level-asymmetry-allowed" is equal to 0 (or not present)
          in either the offer or the answer, level asymmetry is not
          allowed.  In this case, the level to use in the direction
          from the offerer to the answerer MUST be the same as the
          level to use in the opposite direction.

Mo Zanaty

  _____  

From: Roni Even [mailto:[email-masked]] 
Sent: Monday, November 30, 2009 6:40 PM
To: Mo Zanaty (mzanaty); Stuart Taylor (sttaylor); [email-masked]
Cc: Cullen Jennings (fluffy); [email-masked];
[email-masked]; [email-masked]; Chelliah Sivachelvan
(chelliah); [email-masked]
Subject: RE: [AVT] Comment on 3984bis: level-asymmetry-required

Hi,

I think that it is clear since it addresses asymmetry and not the downgrade
of the level.

Asymmetry means not the same level in both directions.

Roni

From: Mo Zanaty (mzanaty) [mailto:[email-masked]] 
Sent: Tuesday, December 01, 2009 12:51 AM
To: Stuart Taylor (sttaylor); Roni Even; [email-masked]
Cc: Cullen Jennings (fluffy); [email-masked];
[email-masked]; [email-masked]; Chelliah Sivachelvan
(chelliah); [email-masked]
Subject: RE: [AVT] Comment on 3984bis: level-asymmetry-required

This inconsistency in the original RFC 3984 was pointed out several times
before on this list, and was one of the key things to clarify in 3984 bis. I
think the current draft is clear in this regard, except for the description
of level-asymmetry-allowed, which might be clearer if it explicitly
mentioned that level downgrade is always allowed regardless of this
parameter.

Mo Zanaty

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of Stuart
Taylor (sttaylor)
Sent: Monday, November 30, 2009 4:56 PM
To: Roni Even; [email-masked]
Cc: Cullen Jennings (fluffy); [email-masked];
[email-masked]; [email-masked]; Chelliah Sivachelvan
(chelliah); [email-masked]
Subject: Re: [AVT] Comment on 3984bis: level-asymmetry-required

Current usage is justified by the following paragraph, later in section
8.2.2 of RFC-3984, which admittedly can be interpreted multiple ways:

*         Parameters declaring a configuration point are not downgradable,

      with the exception of the level part of the "profile-level-id"

      parameter.  This expresses values a receiver expects to be used

      and must be used verbatim on the sender side.

Stuart Taylor

From: Roni Even [mailto:[email-masked]] 
Sent: Monday, November 30, 2009 4:50 PM
To: Stuart Taylor (sttaylor); [email-masked]
Cc: Cullen Jennings (fluffy); [email-masked];
[email-masked]; Chelliah Sivachelvan (chelliah);
[email-masked]; [email-masked]
Subject: RE: [AVT] Comment on 3984bis: level-asymmetry-required

Hi,

Just to remind all of you that the current text in RFC3984 mandated level
symmetry - downgrading was not allowed - see section 8.2.2 of RFC3984

" The parameters identifying a media format configuration for H.264

      are "profile-level-id", "packetization-mode", and, if required by

      "packetization-mode", "sprop-deint-buf-req".  These three

      parameters MUST be used symmetrically; i.e., the answerer MUST

      either maintain all configuration parameters or remove the media

      format (payload type) completely, if one or more of the parameter

      values are not supported."

This means that every shipping product that does level downgrade is not
compliant, and therefore cannot claim that the current text break backward
computability.

The 3984bis draft is addressing the issue and the current text and products
should align to it.  If the text is not clear enough than it should be fixed
but the backward computability should address the issue that some
implementations did support the standard and supported only symmetry as
discussed in  RFC3984

Roni Even

From: [email-masked] [mailto:[email-masked]] On Behalf Of Stuart
Taylor (sttaylor)
Sent: Monday, November 30, 2009 10:19 PM
To: [email-masked]
Cc: Cullen Jennings (fluffy); [email-masked];
[email-masked]; Chelliah Sivachelvan (chelliah);
[email-masked]; [email-masked]
Subject: [AVT] Comment on 3984bis: level-asymmetry-required

I am commenting on H.264 level asymmetry in general and the
level-asymmetry-allowed attribute, introduced in draft 8 of RFC-3984bis, in
particular.  The current draft contains  confusing language and is likely to
break compatibility with many existing devices.

The current language implies that level-asymmetry-allowed applies to both
downgrading and upgrading the level in an answer.  In its absence neither is
therefore allowed.  However, it is only in the description of
level-asymmetry-allowed that this is indicated.  The first paragraphs of
Section 8.2.2 explicitly state that level downgrading is allowed, without
mention of the level-asymmetry-allowed attribute until later.  There are
four examples of level asymmetry given:  level-asymmetry-allowed is absent
in the three downgrade cases and present only the one upgrade case.   Thus
it might be reasonable to infer an intent that level-asymmetry-allowed only
applies to upgrades.

More seriously, I am concerned that this attribute changes the SDP semantics
in a way that is not backwards compatible.  There is a statement near the
end of RFC-3984 Section 8.2.2 which is commonly interpreted as meaning the
level can be downgraded:

*         Parameters declaring a configuration point are not downgradable,

      with the exception of the level part of the "profile-level-id"

      parameter.  This expresses values a receiver expects to be used

      and must be used verbatim on the sender side.

All the H.264 SIP devices that I am familiar with allow the level to be
downgraded in an answer, and some depend on it.  As an example, the
Radvision 3545 MCU will answer any H.264 offer with Level 1.2 (or less, when
operating in "standard rate" mode), and then depend on the remote end to
conform.  All current Cisco endpoints (and Cisco Unified Communications
Manager, acting as B2BUA for SCCP and H.323 devices) use this
interpretation.  If the lack of level-asymmetry-allowed means an endpoint
cannot answer with a lower level, the installed base of these devices will
be non-conformant when 3984bis goes into effect.

Not having been privy to the discussions leading up to this, I do not
understand why level-asymmetry-allowed is required.  Downgrading is an
important mechanism for negotiation between different level endpoints.
Upgrading is harmless in any case: an endpoint is always allowed to encode
at a lower level than negotiated.  If an offering endpoint doesn't like the
answer it can always re-INVITE without the offending PT.

>From my perspective, any of the following are acceptable:

1.       Drop the level-asymmetry-allowed parameter entirely and
unconditionally permit level asymmetry in SDP negotiation.

2.       Change the default to "level-asymmetry-allowed=1", meaning that
legacy endpoints get permissive treatment.

3.       Reverse "level-asymmetry-allowed" to "level-asymmetry-required"
(and leave the default as off).

Stuart Taylor

Technical Leader

Cisco Systems, Inc.

[email-masked]

--Boundary_(ID_+5Kb5f8HbFr78tWJQD8DZA)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:v =3D=20
"urn:schemas-microsoft-com:vml" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word" xmlns:x =3D=20
"urn:schemas-microsoft-com:office:excel" xmlns:p =3D=20
"urn:schemas-microsoft-com:office:powerpoint" xmlns:a =3D=20
"urn:schemas-microsoft-com:office:access" xmlns:dt =3D=20
"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s =3D=20
"uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs =3D=20
"urn:schemas-microsoft-com:rowset" xmlns:z =3D "#RowsetSchema" xmlns:b =
=3D=20
"urn:schemas-microsoft-com:office:publisher" xmlns:ss =3D=20
"urn:schemas-microsoft-com:office:spreadsheet" xmlns:c =3D=20
"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc =3D=20
"urn:schemas-microsoft-com:office:odc" xmlns:oa =3D=20
"urn:schemas-microsoft-com:office:activation" xmlns:html =3D=20
"http://www.w3.org/TR/REC-html40" xmlns:q =3D=20
"http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc =3D=20
"http://microsoft.com/officenet/conferencing" XMLNS:D =3D "DAV:" =
XMLNS:Repl =3D=20
"http://schemas.microsoft.com/repl/" xmlns:mt =3D=20
"http://schemas.microsoft.com/sharepoint/soap/meetings/" xmlns:x2 =3D=20
"http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ppda =3D=20
"http://www.passport.com/NameSpace.xsd" xmlns:ois =3D=20
"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir =3D=20
"http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds =3D=20
"http://www.w3.org/2000/09/xmldsig#" xmlns:dsp =3D=20
"http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc =3D=20
"http://schemas.microsoft.com/data/udc" xmlns:xsd =3D=20
"http://www.w3.org/2001/XMLSchema" xmlns:sub =3D=20
"http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec =
=3D=20
"http://www.w3.org/2001/04/xmlenc#" xmlns:sp =3D=20
"http://schemas.microsoft.com/sharepoint/" xmlns:sps =3D=20
"http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi =3D=20
"http://www.w3.org/2001/XMLSchema-instance" xmlns:udcs =3D=20
"http://schemas.microsoft.com/data/udc/soap" xmlns:udcxf =3D=20
"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p =3D=20
"http://schemas.microsoft.com/data/udc/parttopart" xmlns:st =3D "=01" =
xmlns:st1 =3D=20
"urn:schemas-microsoft-com:office:smarttags" xmlns:ns0 =3D=20
"http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:ns1 =3D=20
"http://schemas.microsoft.com/office/2006/digsig-setup" xmlns:ns2 =3D=20
"http://schemas.microsoft.com/office/2006/digsig" xmlns:ns3 =3D=20
"http://schemas.openxmlformats.org/package/2006/digital-signature" =
xmlns:ns4 =3D=20
"http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:ns5 =
=3D=20
"http://schemas.microsoft.com/office/2004/12/omml" xmlns:ns6 =3D=20
"http://schemas.openxmlformats.org/package/2006/relationships" xmlns:ns7 =
=3D=20
"http://microsoft.com/sharepoint/webpartpages" xmlns:ns8 =3D=20
"http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ns9 =
=3D=20
"http://schemas.microsoft.com/exchange/services/2006/messages" =
xmlns:ns10 =3D=20
"http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" xmlns:ns11 =
=3D=20
"http://microsoft.com/webservices/SharePointPortalServer/PublishedLinksSe=
rvice"=20
xmlns:ns12 =3D "urn:schemas-microsoft-com:"><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.5726" name=3DGENERATOR><!--[if !mso]>
<STYLE>v\:* {
	BEHAVIOR: url(#default#VML)
}
o\:* {
	BEHAVIOR: url(#default#VML)
}
w\:* {
	BEHAVIOR: url(#default#VML)
}
.shape {
	BEHAVIOR: url(#default#VML)
}
</STYLE>
<![endif]--><o:SmartTagType name=3D"PersonName"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><!--[if !mso]>
<STYLE>st1\:* {
	BEHAVIOR: url(#default#ieooui)
}
</STYLE>
<![endif]-->
<STYLE>@font-face {
	font-family: Tahoma;
}
@font-face {
	font-family: Calibri;
}
@font-face {
	font-family: Consolas;
}
@page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.0in 1.0in 1.0in; }
A:link {
	mso-style-priority: 99
}
SPAN.MSOHYPERLINK {
	mso-style-priority: 99
}
A:visited {
	mso-style-priority: 99
}
SPAN.MSOHYPERLINKFOLLOWED {
	mso-style-priority: 99
}
PRE {
	mso-style-priority: 99
}
P.MSOLISTPARAGRAPH {
	mso-style-priority: 34
}
LI.MSOLISTPARAGRAPH {
	mso-style-priority: 34
}
DIV.MSOLISTPARAGRAPH {
	mso-style-priority: 34
}
SPAN.HTMLPREFORMATTEDCHAR {
	mso-style-priority: 99
}
SPAN.HTMLPREFORMATTEDCHAR0 {
	mso-style-priority: 99
}
P.MsoNormal {
	FONT-SIZE: 11pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: Calibri
}
LI.MsoNormal {
	FONT-SIZE: 11pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: Calibri
}
DIV.MsoNormal {
	FONT-SIZE: 11pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: Calibri
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline
}
PRE {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Courier New"
}
SPAN.HTMLPreformattedChar {
	FONT-FAMILY: Consolas
}
P.msolistparagraph {
	FONT-SIZE: 11pt; MARGIN: 0in 0in 0pt 0.5in; FONT-FAMILY: Calibri
}
LI.msolistparagraph {
	FONT-SIZE: 11pt; MARGIN: 0in 0in 0pt 0.5in; FONT-FAMILY: Calibri
}
DIV.msolistparagraph {
	FONT-SIZE: 11pt; MARGIN: 0in 0in 0pt 0.5in; FONT-FAMILY: Calibri
}
SPAN.htmlpreformattedchar0 {
	FONT-FAMILY: "Courier New"
}
SPAN.EmailStyle21 {
	COLOR: windowtext; FONT-FAMILY: Calibri; mso-style-type: personal
}
SPAN.EmailStyle22 {
	COLOR: #1f497d; FONT-FAMILY: Calibri; mso-style-type: personal
}
SPAN.EmailStyle23 {
	COLOR: #1f497d; FONT-FAMILY: Calibri; mso-style-type: personal
}
SPAN.EmailStyle24 {
	FONT-WEIGHT: normal; COLOR: windowtext; FONT-STYLE: normal; =
FONT-FAMILY: Arial; TEXT-DECORATION: none; mso-style-type: personal
}
SPAN.EmailStyle25 {
	COLOR: #1f497d; FONT-FAMILY: Calibri; mso-style-type: personal
}
SPAN.EmailStyle26 {
	FONT-WEIGHT: normal; COLOR: windowtext; FONT-STYLE: normal; =
FONT-FAMILY: Arial; TEXT-DECORATION: none; mso-style-type: =
personal-reply
}
DIV.Section1 {
	page: Section1
}
OL {
	MARGIN-BOTTOM: 0in
}
UL {
	MARGIN-BOTTOM: 0in
}
</STYLE>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]--></HEAD>
<BODY lang=3DEN-US vLink=3Dpurple link=3Dblue>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D875175312-01122009><FONT =
face=3D&#23435;&#20307;=20
color=3D#0000ff size=3D2>The following text in subsection 8.2.2 clearly =
tells=20
that&nbsp;level downgrade is different from level asymmetry, as Randell =
and Roni=20
explained. If you don't want level asymmetry, you just don't include the =

parameter or let the value be equal to 0, then you can freely choose to =
do level=20
downgrade or not. In conclusion, I don't see any problem with the =
current text.=20
</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D875175312-01122009><FONT =
face=3D&#23435;&#20307;=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D875175312-01122009>
<P class=3DRFCListBullet style=3D"MARGIN: 0cm 0cm 12pt 43.2pt"><SPAN =
lang=3DEN-US=20
style=3D"mso-fareast-font-family: 'Courier New'"><SPAN=20
style=3D"mso-list: Ignore"><FONT face=3D"Courier New">o</FONT><SPAN=20
style=3D"FONT: 7pt 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></SPAN></SPAN><SPAN lang=3DEN-US><FONT face=3D"Courier New">The =
parameter=20
"level-asymmetry-allowed" indicates whether level asymmetry is=20
allowed.<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 12pt 43.4pt"><SPAN =
lang=3DEN-US><FONT=20
size=3D3><FONT face=3D"Courier New">If "level-asymmetry-allowed" is =
equal to 0 (or=20
not present) in either the offer or the answer, level asymmetry is not=20
allowed.<SPAN style=3D"mso-spacerun: yes">&nbsp; </SPAN>In this case, =
the level to=20
use in the direction from the offerer to the answerer MUST be the same =
as the=20
level to use in the opposite direction, and the common level to use is =
equal to=20
the lower value of the default level in the offer and the default level =
in the=20
answer.<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 12pt 43.4pt"><SPAN =
lang=3DEN-US><FONT=20
size=3D3><FONT face=3D"Courier New">Otherwise ("level-asymmetry-allowed" =
equals to 1=20
in both the offer and the answer), level asymmetry is allowed.<SPAN=20
style=3D"mso-spacerun: yes">&nbsp; </SPAN>In this case, the level to use =
in the=20
offerer-to-answerer direction MUST be equal to the highest level the =
answerer=20
supports for receiving, and the level to use in the answerer-to-offerer=20
direction MUST be equal to the highest level the offerer supports for=20
receiving.<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 12pt 43.4pt"><SPAN =
lang=3DEN-US><FONT=20
size=3D3><FONT face=3D"Courier New">When level asymmetry is not allowed, =
level=20
upgrade is not allowed, i.e. the default level in the answer MUST be =
equal to or=20
lower than the default level in the =
offer.</FONT></FONT></SPAN></SPAN></P></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D875175312-01122009><FONT =
face=3D&#23435;&#20307;=20
color=3D#0000ff size=3D2>BR, YK</FONT></SPAN></DIV><BR>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> [email-masked]=20
  [mailto:[email-masked]] <B>On Behalf Of </B>Mo Zanaty=20
  (mzanaty)<BR><B>Sent:</B> Tuesday, December 01, 2009 4:10 =
AM<BR><B>To:</B>=20
  Roni Even; Stuart Taylor (sttaylor); [email-masked]<BR><B>Cc:</B> Cullen =

  Jennings (fluffy); [email-masked]; =
[email-masked];=20
  [email-masked]; Chelliah Sivachelvan (chelliah);=20
  [email-masked]<BR><B>Subject:</B> Re: [AVT] Comment on =
3984bis:=20
  level-asymmetry-required<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV class=3DSection1>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">I think the confusion =
might be due=20
  to the following text in section 8.1. It is ambiguous whether =
&#8220;level=20
  asymmetry&#8221; refers to the actual RTP media level or the SDP =
offer/answer level.=20
  I assume the RTP media level was intended. But if some readers =
interpret this=20
  as the SDP offer/answer level, they will incorrectly conclude that =
this=20
  parameter is required in order to use a different level in the SDP =
answer even=20
  for level downgrade.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P><PRE =
style=3D"PAGE-BREAK-BEFORE: always"><FONT face=3D"Courier New" =
size=3D2><SPAN lang=3DEN style=3D"FONT-SIZE: =
10pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
level-asymmetry-allowed:<o:p></o:p></SPAN></FONT></PRE><PRE =
style=3D"PAGE-BREAK-BEFORE: always"><FONT face=3D"Courier New" =
size=3D2><SPAN lang=3DEN style=3D"FONT-SIZE: =
10pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This =
parameter MAY be used in SDP Offer/Answer to =
indicate<o:p></o:p></SPAN></FONT></PRE><PRE style=3D"PAGE-BREAK-BEFORE: =
always"><FONT face=3D"Courier New" size=3D2><SPAN lang=3DEN =
style=3D"FONT-SIZE: =
10pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; whether =
level asymmetry, i.e., using a different level in =
the<o:p></o:p></SPAN></FONT></PRE><PRE style=3D"PAGE-BREAK-BEFORE: =
always"><FONT face=3D"Courier New" size=3D2><SPAN lang=3DEN =
style=3D"FONT-SIZE: =
10pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
offerer-to-answerer direction than the level in the =
answerer-<o:p></o:p></SPAN></FONT></PRE><PRE style=3D"PAGE-BREAK-BEFORE: =
always"><FONT face=3D"Courier New" size=3D2><SPAN lang=3DEN =
style=3D"FONT-SIZE: =
10pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to-offerer =
direction, is allowed.&nbsp; The value MAY be equal =
to<o:p></o:p></SPAN></FONT></PRE><PRE style=3D"PAGE-BREAK-BEFORE: =
always"><FONT face=3D"Courier New" size=3D2><SPAN lang=3DEN =
style=3D"FONT-SIZE: =
10pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; either 0 or =
1.&nbsp; When the parameter is not present, the =
value<o:p></o:p></SPAN></FONT></PRE><PRE style=3D"PAGE-BREAK-BEFORE: =
always"><FONT face=3D"Courier New" size=3D2><SPAN lang=3DEN =
style=3D"FONT-SIZE: =
10pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MUST be =
inferred to be equal to 0.&nbsp; The value 1 in both =
the<o:p></o:p></SPAN></FONT></PRE><PRE style=3D"PAGE-BREAK-BEFORE: =
always"><FONT face=3D"Courier New" size=3D2><SPAN lang=3DEN =
style=3D"FONT-SIZE: =
10pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; offer and =
the answer indicates that level asymmetry =
is<o:p></o:p></SPAN></FONT></PRE><PRE style=3D"PAGE-BREAK-BEFORE: =
always"><FONT face=3D"Courier New" size=3D2><SPAN lang=3DEN =
style=3D"FONT-SIZE: =
10pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
allowed.&nbsp; The value of 0 in either the offer or the =
answer<o:p></o:p></SPAN></FONT></PRE><PRE style=3D"PAGE-BREAK-BEFORE: =
always"><FONT face=3D"Courier New" size=3D2><SPAN lang=3DEN =
style=3D"FONT-SIZE: =
10pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; indicates =
the level asymmetry is not allowed.<o:p></o:p></SPAN></FONT></PRE><PRE =
style=3D"PAGE-BREAK-BEFORE: always"><FONT face=3D"Courier New" =
size=3D2><SPAN lang=3DEN style=3D"FONT-SIZE: =
10pt"><o:p>&nbsp;</o:p></SPAN></FONT></PRE><PRE =
style=3D"PAGE-BREAK-BEFORE: always"><FONT face=3D"Courier New" =
size=3D2><SPAN lang=3DEN style=3D"FONT-SIZE: =
10pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; If =
"level-asymmetry-allowed" is equal to 0 (or not =
present)<o:p></o:p></SPAN></FONT></PRE><PRE style=3D"PAGE-BREAK-BEFORE: =
always"><FONT face=3D"Courier New" size=3D2><SPAN lang=3DEN =
style=3D"FONT-SIZE: 10pt">&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;in either the offer or the answer, level =
asymmetry is not<o:p></o:p></SPAN></FONT></PRE><PRE =
style=3D"PAGE-BREAK-BEFORE: always"><FONT face=3D"Courier New" =
size=3D2><SPAN lang=3DEN style=3D"FONT-SIZE: =
10pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
allowed.&nbsp; In this case, the level to use in the =
direction<o:p></o:p></SPAN></FONT></PRE><PRE style=3D"PAGE-BREAK-BEFORE: =
always"><FONT face=3D"Courier New" size=3D2><SPAN lang=3DEN =
style=3D"FONT-SIZE: =
10pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; from the =
offerer to the answerer MUST be the same as =
the<o:p></o:p></SPAN></FONT></PRE><PRE style=3D"PAGE-BREAK-BEFORE: =
always"><FONT face=3D"Courier New" size=3D2><SPAN lang=3DEN =
style=3D"FONT-SIZE: =
10pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; level to =
use in the opposite direction.<o:p></o:p></SPAN></FONT></PRE><PRE =
style=3D"PAGE-BREAK-BEFORE: always"><FONT face=3D"Courier New" =
size=3D2><SPAN lang=3DEN style=3D"FONT-SIZE: =
10pt"><o:p>&nbsp;</o:p></SPAN></FONT></PRE>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN lang=3DEN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Mo=20
  Zanaty<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <DIV>
  <DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" =
align=3Dcenter><FONT=20
  face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'">
  <HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2>
  </SPAN></FONT></DIV>
  <P class=3DMsoNormal><B><FONT face=3DTahoma size=3D2><SPAN=20
  style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">From:</SPAN></FONT></B><FONT=20
  face=3DTahoma size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma"> Roni=20
  Even [mailto:[email-masked]] <BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> Monday, November 30, 2009 =
6:40=20
  PM<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B> Mo Zanaty =
(mzanaty);=20
  Stuart Taylor (sttaylor); [email-masked]<BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">Cc:</SPAN></B> <st1:PersonName =
w:st=3D"on">Cullen=20
  Jennings</st1:PersonName> (fluffy); [email-masked];=20
  [email-masked]; [email-masked]; <st1:PersonName=20
  w:st=3D"on">Chelliah Sivachelvan</st1:PersonName> (chelliah);=20
  [email-masked]<BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B> RE: [AVT] Comment on =
3984bis:=20
  level-asymmetry-required</SPAN></FONT><FONT face=3D"Times New Roman"=20
  size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New =
Roman'"><o:p></o:p></SPAN></FONT></P></DIV>
  <P class=3DMsoNormal><FONT face=3DCalibri size=3D2><SPAN=20
  style=3D"FONT-SIZE: 11pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DCalibri color=3D#1f497d =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 11pt; COLOR: =
#1f497d">Hi,<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DCalibri color=3D#1f497d =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 11pt; COLOR: #1f497d">I think that it is clear =
since it=20
  addresses asymmetry and not the downgrade of the=20
  level.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DCalibri color=3D#1f497d =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 11pt; COLOR: #1f497d">Asymmetry means not the same =
level in=20
  both directions.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DCalibri color=3D#1f497d =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 11pt; COLOR: =
#1f497d">Roni<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DCalibri color=3D#1f497d =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 11pt; COLOR: =
#1f497d"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <DIV=20
  style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: =
medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0in; BORDER-LEFT: blue =
1.5pt solid; PADDING-TOP: 0in; BORDER-BOTTOM: medium none">
  <DIV>
  <DIV=20
  style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: =
#b5c4df 1pt solid; PADDING-LEFT: 0in; PADDING-BOTTOM: 0in; BORDER-LEFT: =
medium none; PADDING-TOP: 3pt; BORDER-BOTTOM: medium none">
  <P class=3DMsoNormal><B><FONT face=3DTahoma size=3D2><SPAN=20
  style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">From:</SPAN></FONT></B><FONT=20
  face=3DTahoma size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma"> Mo=20
  Zanaty (mzanaty) [mailto:[email-masked]] <BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> Tuesday, December 01, =
2009 12:51=20
  AM<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B> Stuart =
Taylor=20
  (sttaylor); Roni Even; [email-masked]<BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">Cc:</SPAN></B> <st1:PersonName =
w:st=3D"on">Cullen=20
  Jennings</st1:PersonName> (fluffy); [email-masked];=20
  [email-masked]; [email-masked]; <st1:PersonName=20
  w:st=3D"on">Chelliah Sivachelvan</st1:PersonName> (chelliah);=20
  [email-masked]<BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B> RE: [AVT] Comment on =
3984bis:=20
  level-asymmetry-required<o:p></o:p></SPAN></FONT></P></DIV></DIV>
  <P class=3DMsoNormal><FONT face=3DCalibri size=3D2><SPAN=20
  style=3D"FONT-SIZE: 11pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">This inconsistency in =
the original=20
  RFC 3984 was pointed out several times before on this list, and was =
one of the=20
  key things to clarify in 3984 bis. I think the current draft is clear =
in this=20
  regard, except for the description of level-asymmetry-allowed, which =
might be=20
  clearer if it explicitly mentioned that level downgrade is always =
allowed=20
  regardless of this parameter.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Mo=20
  Zanaty<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <DIV>
  <DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" =
align=3Dcenter><FONT=20
  face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'">
  <HR align=3Dcenter width=3D"100%" SIZE=3D2>
  </SPAN></FONT></DIV>
  <P class=3DMsoNormal><B><FONT face=3DTahoma size=3D2><SPAN=20
  style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">From:</SPAN></FONT></B><FONT=20
  face=3DTahoma size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">=20
  [email-masked] [mailto:[email-masked]] <B><SPAN=20
  style=3D"FONT-WEIGHT: bold">On Behalf Of </SPAN></B>Stuart Taylor=20
  (sttaylor)<BR><B><SPAN style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> =
Monday,=20
  November 30, 2009 4:56 PM<BR><B><SPAN style=3D"FONT-WEIGHT: =
bold">To:</SPAN></B>=20
  Roni Even; [email-masked]<BR><B><SPAN style=3D"FONT-WEIGHT: =
bold">Cc:</SPAN></B>=20
  <st1:PersonName w:st=3D"on">Cullen Jennings</st1:PersonName> (fluffy); =

  [email-masked]; [email-masked]; =
[email-masked];=20
  <st1:PersonName w:st=3D"on">Chelliah Sivachelvan</st1:PersonName> =
(chelliah);=20
  [email-masked]<BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B> Re: [AVT] Comment on =
3984bis:=20
  level-asymmetry-required</SPAN></FONT><FONT face=3D"Times New Roman"=20
  size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New =
Roman'"><o:p></o:p></SPAN></FONT></P></DIV>
  <P class=3DMsoNormal><FONT face=3DCalibri size=3D2><SPAN=20
  style=3D"FONT-SIZE: 11pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DCalibri color=3D#1f497d =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 11pt; COLOR: #1f497d">Current usage is justified =
by the=20
  following paragraph, later in section 8.2.2 of RFC-3984, which =
admittedly can=20
  be interpreted multiple ways:<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DCalibri color=3D#1f497d =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 11pt; COLOR: =
#1f497d"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3Dmsolistparagraph style=3D"TEXT-INDENT: -0.25in"><FONT =
face=3DSymbol=20
  size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Symbol">&middot;</SPAN></FONT><FONT=20
  face=3D"Times New Roman" size=3D1><SPAN=20
  style=3D"FONT-SIZE: 7pt; FONT-FAMILY: 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN></FONT><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">Parameters =
declaring a=20
  configuration point are not downgradable,<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier =
New'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  with the exception of the level part of the=20
  "profile-level-id"<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier =
New'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  parameter.&nbsp; This expresses values a receiver expects to be=20
  used<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier =
New'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  and must be used verbatim on the sender =
side.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DCalibri color=3D#1f497d =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 11pt; COLOR: =
#1f497d"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DCalibri color=3D#1f497d =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 11pt; COLOR: #1f497d">Stuart=20
  Taylor<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DCalibri color=3D#1f497d =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 11pt; COLOR: =
#1f497d"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DCalibri color=3D#1f497d =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 11pt; COLOR: =
#1f497d"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DCalibri color=3D#1f497d =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 11pt; COLOR: =
#1f497d"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <DIV=20
  style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: =
medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0in; BORDER-LEFT: blue =
1.5pt solid; PADDING-TOP: 0in; BORDER-BOTTOM: medium none">
  <DIV>
  <DIV=20
  style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: =
#b5c4df 1pt solid; PADDING-LEFT: 0in; PADDING-BOTTOM: 0in; BORDER-LEFT: =
medium none; PADDING-TOP: 3pt; BORDER-BOTTOM: medium none">
  <P class=3DMsoNormal><B><FONT face=3DTahoma size=3D2><SPAN=20
  style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">From:</SPAN></FONT></B><FONT=20
  face=3DTahoma size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma"> Roni=20
  Even [mailto:[email-masked]] <BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> Monday, November 30, 2009 =
4:50=20
  PM<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B> Stuart =
Taylor=20
  (sttaylor); [email-masked]<BR><B><SPAN style=3D"FONT-WEIGHT: =
bold">Cc:</SPAN></B>=20
  <st1:PersonName w:st=3D"on">Cullen Jennings</st1:PersonName> (fluffy); =

  [email-masked]; [email-masked]; <st1:PersonName=20
  w:st=3D"on">Chelliah Sivachelvan</st1:PersonName> (chelliah); =
[email-masked];=20
  [email-masked]<BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B> RE: [AVT] Comment on =
3984bis:=20
  level-asymmetry-required<o:p></o:p></SPAN></FONT></P></DIV></DIV>
  <P class=3DMsoNormal><FONT face=3DCalibri size=3D2><SPAN=20
  style=3D"FONT-SIZE: 11pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DCalibri color=3D#1f497d =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 11pt; COLOR: =
#1f497d">Hi,<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DCalibri color=3D#1f497d =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 11pt; COLOR: #1f497d">Just to remind all of you =
that the=20
  current text in RFC3984 mandated level symmetry &#8211; downgrading =
was not allowed=20
  &#8211; see section 8.2.2 of RFC3984<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DCalibri color=3D#1f497d =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 11pt; COLOR: =
#1f497d"><o:p>&nbsp;</o:p></SPAN></FONT></P><PRE =
style=3D"PAGE-BREAK-BEFORE: always"><FONT face=3DCalibri color=3D#1f497d =
size=3D3><SPAN style=3D"FONT-SIZE: 12pt; COLOR: #1f497d; FONT-FAMILY: =
Calibri">"</SPAN></FONT><FONT size=3D2><SPAN style=3D"FONT-SIZE: 10pt"> =
</SPAN></FONT><FONT size=3D2><SPAN lang=3DEN style=3D"FONT-SIZE: =
10pt">The parameters identifying a media format configuration for =
H.264<o:p></o:p></SPAN></FONT></PRE>
  <P class=3DMsoNormal style=3D"PAGE-BREAK-BEFORE: always"><FONT =
face=3D"Courier New"=20
  size=3D2><SPAN lang=3DEN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier =
New'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  are "profile-level-id", "packetization-mode", and, if required=20
  by<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal style=3D"PAGE-BREAK-BEFORE: always"><FONT =
face=3D"Courier New"=20
  size=3D2><SPAN lang=3DEN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier =
New'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  "packetization-mode", "sprop-deint-buf-req".&nbsp; These=20
  three<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal style=3D"PAGE-BREAK-BEFORE: always"><FONT =
face=3D"Courier New"=20
  size=3D2><SPAN lang=3DEN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier =
New'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  parameters MUST be used symmetrically; i.e., the answerer=20
  MUST<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal style=3D"PAGE-BREAK-BEFORE: always"><FONT =
face=3D"Courier New"=20
  size=3D2><SPAN lang=3DEN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier =
New'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  either maintain all configuration parameters or remove the=20
  media<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal style=3D"PAGE-BREAK-BEFORE: always"><FONT =
face=3D"Courier New"=20
  size=3D2><SPAN lang=3DEN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier =
New'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  format (payload type) completely, if one or more of the=20
  parameter<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal style=3D"PAGE-BREAK-BEFORE: always"><FONT =
face=3D"Courier New"=20
  size=3D2><SPAN lang=3DEN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier =
New'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  values are not supported."<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal style=3D"PAGE-BREAK-BEFORE: always"><FONT =
face=3D"Courier New"=20
  size=3D2><SPAN lang=3DEN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier =
New'"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DCalibri color=3D#1f497d =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 11pt; COLOR: #1f497d">This means that every =
shipping product=20
  that does level downgrade is not compliant, and therefore cannot claim =
that=20
  the current text break backward =
computability.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DCalibri color=3D#1f497d =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 11pt; COLOR: =
#1f497d"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DCalibri color=3D#1f497d =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 11pt; COLOR: #1f497d">The 3984bis draft is =
addressing the=20
  issue and the current text and products should align to it. &nbsp;If =
the text=20
  is not clear enough than it should be fixed but the backward =
computability=20
  should address the issue that some implementations did support the =
standard=20
  and supported only symmetry as discussed in=20
  &nbsp;RFC3984<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DCalibri color=3D#1f497d =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 11pt; COLOR: =
#1f497d"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DCalibri color=3D#1f497d =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 11pt; COLOR: #1f497d">Roni =
Even<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DCalibri color=3D#1f497d =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 11pt; COLOR: =
#1f497d"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <DIV=20
  style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: =
medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0in; BORDER-LEFT: blue =
1.5pt solid; PADDING-TOP: 0in; BORDER-BOTTOM: medium none">
  <DIV>
  <DIV=20
  style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: =
#b5c4df 1pt solid; PADDING-LEFT: 0in; PADDING-BOTTOM: 0in; BORDER-LEFT: =
medium none; PADDING-TOP: 3pt; BORDER-BOTTOM: medium none">
  <P class=3DMsoNormal><B><FONT face=3DTahoma size=3D2><SPAN=20
  style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">From:</SPAN></FONT></B><FONT=20
  face=3DTahoma size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">=20
  [email-masked] [mailto:[email-masked]] <B><SPAN=20
  style=3D"FONT-WEIGHT: bold">On Behalf Of </SPAN></B>Stuart Taylor=20
  (sttaylor)<BR><B><SPAN style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> =
Monday,=20
  November 30, 2009 10:19 PM<BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">To:</SPAN></B> [email-masked]<BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">Cc:</SPAN></B> <st1:PersonName =
w:st=3D"on">Cullen=20
  Jennings</st1:PersonName> (fluffy); [email-masked];=20
  [email-masked]; <st1:PersonName w:st=3D"on">Chelliah=20
  Sivachelvan</st1:PersonName> (chelliah); [email-masked];=20
  [email-masked]<BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B> [AVT] Comment on =
3984bis:=20
  level-asymmetry-required<o:p></o:p></SPAN></FONT></P></DIV></DIV>
  <P class=3DMsoNormal><FONT face=3DCalibri size=3D2><SPAN=20
  style=3D"FONT-SIZE: 11pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DCalibri size=3D2><SPAN =
style=3D"FONT-SIZE: 11pt">I=20
  am commenting on H.264 level asymmetry in general and the <I><SPAN=20
  style=3D"FONT-STYLE: italic">level-asymmetry-allowed</SPAN></I> =
attribute,=20
  introduced in draft 8 of RFC-3984bis, in particular.&nbsp; The current =
draft=20
  contains&nbsp; confusing language and is likely to break compatibility =
with=20
  many existing devices.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DCalibri size=3D2><SPAN=20
  style=3D"FONT-SIZE: 11pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DCalibri size=3D2><SPAN =
style=3D"FONT-SIZE: 11pt">The=20
  current language implies that level-asymmetry-allowed applies to both=20
  downgrading and upgrading the level in an answer.&nbsp; In its absence =
neither=20
  is therefore allowed.&nbsp; However, it is only in the description of=20
  level-asymmetry-allowed that this is indicated.&nbsp; The first =
paragraphs of=20
  Section 8.2.2 explicitly state that level downgrading is allowed, =
without=20
  mention of the level-asymmetry-allowed attribute until later.&nbsp; =
There are=20
  four examples of level asymmetry given:&nbsp; level-asymmetry-allowed =
is=20
  absent in the three downgrade cases and present only the one upgrade=20
  case.&nbsp;&nbsp; Thus it might be reasonable to infer an intent that=20
  level-asymmetry-allowed only applies to =
upgrades.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DCalibri size=3D2><SPAN=20
  style=3D"FONT-SIZE: 11pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DCalibri size=3D2><SPAN=20
  style=3D"FONT-SIZE: 11pt">More seriously, I am concerned that this =
attribute=20
  changes the SDP semantics in a way that is not backwards =
compatible.&nbsp;=20
  There is a statement near the end of RFC-3984 Section 8.2.2 which is =
commonly=20
  interpreted as meaning the level can be=20
  downgraded:<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DCalibri size=3D2><SPAN=20
  style=3D"FONT-SIZE: 11pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3Dmsolistparagraph style=3D"TEXT-INDENT: -0.25in"><FONT =
face=3DSymbol=20
  size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Symbol">&middot;</SPAN></FONT><FONT=20
  face=3D"Times New Roman" size=3D1><SPAN=20
  style=3D"FONT-SIZE: 7pt; FONT-FAMILY: 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN></FONT><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">Parameters =
declaring a=20
  configuration point are not downgradable,<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier =
New'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  with the exception of the level part of the=20
  "profile-level-id"<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier =
New'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  parameter.&nbsp; This expresses values a receiver expects to be=20
  used<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier =
New'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  and must be used verbatim on the sender =
side.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DCalibri size=3D2><SPAN=20
  style=3D"FONT-SIZE: 11pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DCalibri size=3D2><SPAN =
style=3D"FONT-SIZE: 11pt">All=20
  the H.264 SIP devices that I am familiar with allow the level to be =
downgraded=20
  in an answer, and some depend on it.&nbsp; As an example, the =
Radvision 3545=20
  MCU will answer any H.264 offer with Level 1.2 (or less, when =
operating in=20
  &#8220;standard rate&#8221; mode), and then depend on the remote end =
to conform.&nbsp; All=20
  current Cisco endpoints (and Cisco Unified Communications Manager, =
acting as=20
  B2BUA for SCCP and H.323 devices) use this interpretation.&nbsp; If =
the lack=20
  of level-asymmetry-allowed means an endpoint cannot answer with a =
lower level,=20
  the installed base of these devices will be non-conformant when =
3984bis goes=20
  into effect.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DCalibri size=3D2><SPAN=20
  style=3D"FONT-SIZE: 11pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DCalibri size=3D2><SPAN =
style=3D"FONT-SIZE: 11pt">Not=20
  having been privy to the discussions leading up to this, I do not =
understand=20
  why level-asymmetry-allowed is required.&nbsp; Downgrading is an =
important=20
  mechanism for negotiation between different level endpoints.&nbsp; =
Upgrading=20
  is harmless in any case: an endpoint is always allowed to encode at a =
lower=20
  level than negotiated.&nbsp; If an offering endpoint doesn&#8217;t =
like the answer=20
  it can always re-INVITE without the offending =
PT.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DCalibri size=3D2><SPAN=20
  style=3D"FONT-SIZE: 11pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DCalibri size=3D2><SPAN=20
  style=3D"FONT-SIZE: 11pt">From my perspective, any of the following =
are=20
  acceptable:<o:p></o:p></SPAN></FONT></P>
  <P class=3Dmsolistparagraph=20
  style=3D"TEXT-INDENT: -0.25in; mso-list: l0 level1 lfo2"><![if =
!supportLists]><FONT=20
  face=3DCalibri size=3D2><SPAN style=3D"FONT-SIZE: 11pt"><SPAN=20
  style=3D"mso-list: Ignore">1.<FONT face=3D"Times New Roman" =
size=3D1><SPAN=20
  style=3D"FONT: 7pt 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN></FONT></SPAN></SPAN></FONT><![endif]>Drop the =
level-asymmetry-allowed=20
  parameter entirely and unconditionally permit level asymmetry in SDP=20
  negotiation.<o:p></o:p></P>
  <P class=3Dmsolistparagraph=20
  style=3D"TEXT-INDENT: -0.25in; mso-list: l0 level1 lfo2"><![if =
!supportLists]><FONT=20
  face=3DCalibri size=3D2><SPAN style=3D"FONT-SIZE: 11pt"><SPAN=20
  style=3D"mso-list: Ignore">2.<FONT face=3D"Times New Roman" =
size=3D1><SPAN=20
  style=3D"FONT: 7pt 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN></FONT></SPAN></SPAN></FONT><![endif]>Change the default to=20
  &#8220;level-asymmetry-allowed=3D1&#8221;, meaning that legacy =
endpoints get permissive=20
  treatment.<o:p></o:p></P>
  <P class=3Dmsolistparagraph=20
  style=3D"TEXT-INDENT: -0.25in; mso-list: l0 level1 lfo2"><![if =
!supportLists]><FONT=20
  face=3DCalibri size=3D2><SPAN style=3D"FONT-SIZE: 11pt"><SPAN=20
  style=3D"mso-list: Ignore">3.<FONT face=3D"Times New Roman" =
size=3D1><SPAN=20
  style=3D"FONT: 7pt 'Times New =
Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN></FONT></SPAN></SPAN></FONT><![endif]>Reverse =
&#8220;level-asymmetry-allowed&#8221;=20
  to &#8220;level-asymmetry-required&#8221; (and leave the default as =
off).<o:p></o:p></P>
  <P class=3DMsoNormal><FONT face=3DCalibri size=3D2><SPAN=20
  style=3D"FONT-SIZE: =
11pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;=20
  <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DCalibri size=3D2><SPAN=20
  style=3D"FONT-SIZE: 11pt">Stuart Taylor<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DCalibri size=3D2><SPAN=20
  style=3D"FONT-SIZE: 11pt">Technical =
Leader<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DCalibri size=3D2><SPAN=20
  style=3D"FONT-SIZE: 11pt">Cisco Systems, =
Inc.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DCalibri size=3D2><SPAN =
style=3D"FONT-SIZE: 11pt"><A=20
  =
href=3D"mailto:[email-masked]">[email-masked]</A><o:p></o:p></SPA=
N></FONT></P>
  <P class=3DMsoNormal><FONT face=3DCalibri size=3D2><SPAN=20
  style=3D"FONT-SIZE: =
11pt"><o:p>&nbsp;</o:p></SPAN></FONT></P></DIV></DIV></DIV></DIV></BLOCKQ=
UOTE></BODY></HTML>

--Boundary_(ID_+5Kb5f8HbFr78tWJQD8DZA)--

---

From: Ye-Kui Wang <[email-masked]>
Date: Tue, 01 Dec 2009 15:35:34 +0200

OK, got it. I did not notice that the message was cross-posted to another
mailing list. Thanks Roni for pointing it out. 

BR, YK 

> Sent: Tuesday, December 01, 2009 3:23 PM
> To: 'Ye-Kui Wang'; [email-masked]
> Subject: RE: [AVT] FW: RE: Comment on 3984bis: 
> level-asymmetry-required
> 
> The message was cc:ed to the imtc-sipparity mailing list, who 
> sends this
> message from global indentures the mail server owner, since 
> you are not a
> member. 
> Roni
> 
> > From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of
> > Ye-Kui Wang
> > Sent: Tuesday, December 01, 2009 3:08 PM
> > To: [email-masked]
> > Subject: [AVT] FW: RE: Comment on 3984bis: level-asymmetry-required
> > 
> > 
> > accepts only email addressed listed as members of 
> "imtc_sipparity"? Who
> > is
> > using this?
> > 
> > BR, YK
> > 
> Acpx+kuRI7/dC30KR/aO+c6uKAPy7gAC/vLgAABO8eAAAHNI4AADL1MgAAOJyG
> AAGEMOMA=
> > =
> > different from level asymmetry, as Randell and Roni 
> explained. If you
> > don't
> > want level asymmetry, you just don't include the parameter 
> or let the
> > value
> > be equal to 0, then you can freely choose to do level 
> downgrade or not.
> > In
> in either
> > the
> > level to use in the direction from the offerer to the 
> answerer MUST be
> > the
> > use is equal to the lower value of the default level in the 
> offer and
> > the
> > Otherwise ("level-asymmetry-allowed" equals to 1 in both 
> the offer and
> > the
> > answer), level asymmetry is allowed.  In this case, the 
> level to use in
> > the
> > When level asymmetry is not allowed, level upgrade is not 
> allowed, i.e.
> > the
> > default level in the answer MUST be equal to or lower than 
> the default
> > level
> > in the offer.
> > 
> > BR, YK
> > 
> > 
> >   _____
> > 
> > From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of
> > Mo
> > Zanaty (mzanaty)
> > is ambiguous whether "level asymmetry" refers to the actual 
> RTP media
> > level
> > But if some readers interpret this as the SDP offer/answer 
> level, they
> > will
> > before on this list, and was one of the key things to 
> clarify in 3984
> > bis. I
> > From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of
> > Stuart
> > Taylor (sttaylor)
> > should align to it.  If the text is not clear enough than 
> it should be
> > fixed
> > From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of
> > Stuart
> > Taylor (sttaylor)
> > level-asymmetry-allowed that this is indicated.  The first 
> paragraphs
> > of
> > it might be reasonable to infer an intent that 
> level-asymmetry-allowed
> > only
> > applies to upgrades.
> > 
> > 
> > 
> > in a way that is not backwards compatible.  There is a 
> statement near
> > the
> > end of RFC-3984 Section 8.2.2 which is commonly interpreted 
> as meaning
> > the
> > level can be downgraded:
> > 
> > 
> > 
> > Radvision 3545 MCU will answer any H.264 offer with Level 
> 1.2 (or less,
> > when
> > operating in "standard rate" mode), and then depend on the 
> remote end
> > to
> > cannot answer with a lower level, the installed base of 
> these devices
> > will
> > at a lower level than negotiated.  If an offering endpoint 
> doesn't like
> > the
> > "urn:schemas-microsoft-com:rowset" xmlns:z =3D 
> "#RowsetSchema" xmlns:b
> > =
> > =3D=20
> "http://schemas.openxmlformats.org/markup-compatibility/2006" 
> xmlns:ns5
> > =
> > =3D=20
> "http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" 
> xmlns:ns11
> > =
> > =3D=20
> > 
> "http://microsoft.com/webservices/SharePointPortalServer/Publi
> shedLinks
> > Se=
> > rvice"=20
> > color=3D#0000ff size=3D2>The following text in subsection 
> 8.2.2 clearly
> > =
> > tells=20
> > that&nbsp;level downgrade is different from level 
> asymmetry, as Randell
> > =
> > and Roni=20
> > parameter or let the value be equal to 0, then you can 
> freely choose to
> > =
> > do level=20
> > </SPAN></SPAN></SPAN><SPAN lang=3DEN-US><FONT 
> face=3D"Courier New">The
> > =
> > parameter=20
> > use in the direction from the offerer to the answerer MUST 
> be the same
> > =
> > as the=20
> > level to use in the opposite direction, and the common 
> level to use is
> > =
> > equal to=20
> > the lower value of the default level in the offer and the 
> default level
> > =
> > in the=20
> > style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: 
> #0000ff 2px
> > =
> > indicate<o:p></o:p></SPAN></FONT></PRE><PRE 
> style=3D"PAGE-BREAK-BEFORE:
> > =
> 10pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
> to-offerer
> > =
> > the level asymmetry is not 
> allowed.<o:p></o:p></SPAN></FONT></PRE><PRE
> > =
> > present)<o:p></o:p></SPAN></FONT></PRE><PRE 
> style=3D"PAGE-BREAK-BEFORE:
> > =
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;in either the offer or the 
> answer, level
> > =
> >   style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B> RE: [AVT] 
> Comment on
> > =
> > 3984bis:=20
> > medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0in; 
> BORDER-LEFT: blue
> > =
> > #b5c4df 1pt solid; PADDING-LEFT: 0in; PADDING-BOTTOM: 0in; 
> BORDER-LEFT:
> > =
> >   style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B> RE: [AVT] 
> Comment on
> > =
> > 3984bis:=20
> >   key things to clarify in 3984 bis. I think the current 
> draft is clear
> > =
> > in this=20
> >   regard, except for the description of 
> level-asymmetry-allowed, which
> > =
> > might be=20
> >   style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B> Re: [AVT] 
> Comment on
> > =
> > 3984bis:=20
> >   style=3D"FONT-SIZE: 11pt; COLOR: #1f497d">Current usage 
> is justified
> > =
> > by the=20
> >   configuration point are not
> > downgradable,<o:p></o:p></SPAN></FONT></P>
> > medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0in; 
> BORDER-LEFT: blue
> > =
> > #b5c4df 1pt solid; PADDING-LEFT: 0in; PADDING-BOTTOM: 0in; 
> BORDER-LEFT:
> > =
> >   style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B> RE: [AVT] 
> Comment on
> > =
> > 3984bis:=20
> > Calibri">"</SPAN></FONT><FONT size=3D2><SPAN 
> style=3D"FONT-SIZE: 10pt">
> > =
> >   issue and the current text and products should align to 
> it. &nbsp;If
> > =
> > the text=20
> > medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0in; 
> BORDER-LEFT: blue
> > =
> > #b5c4df 1pt solid; PADDING-LEFT: 0in; PADDING-BOTTOM: 0in; 
> BORDER-LEFT:
> > =
> >   four examples of level asymmetry given:&nbsp; 
> level-asymmetry-allowed
> > =
> > is=20
> >   There is a statement near the end of RFC-3984 Section 
> 8.2.2 which is
> > =
> > commonly=20
> >   configuration point are not
> > downgradable,<o:p></o:p></SPAN></FONT></P>
> >   &#8220;standard rate&#8221; mode), and then depend on the 
> remote end
> > =
> > to conform.&nbsp; All=20
> >   is harmless in any case: an endpoint is always allowed to 
> encode at a
> > =
> > lower=20
> 11pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n
> bsp;&nbsp
> > ;&=
> > 
> nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
> sp;&nbsp;
> > &n=
> > 
> bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs
> p;&nbsp;&
> > nb=
> > 
> sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
> ;&nbsp;&n
> > bs=
> > 
> p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
> &nbsp;&nb
> > sp=
> > 
> ;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
> nbsp;&nbs
> > p;=
> > 
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n
> bsp;&nbsp
> > ;&=
> > 
> nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
> sp;&nbsp;
> > &n=
> > 
> bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs
> p;&nbsp;&
> > nb=
> > 
> sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
> ;&nbsp;&n
> > bs=
> > 
> p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
> &nbsp;&nb
> > sp=
> > 
> ;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
> nbsp;&nbs
> > p;=
> > 
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n
> bsp;&nbsp
> > ;&=
> > 
> nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
> sp;&nbsp;
> > &n=
> > 
> bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs
> p;&nbsp;&
> > nb=
> > sp;&nbsp;&nbsp;=20
> href=3D"mailto:[email-masked]">[email-masked]</A><o:p>
> </o:p></S
> > PA=
> > N></FONT></P>
> 11pt"><o:p>&nbsp;</o:p></SPAN></FONT></P></DIV></DIV></DIV></D
> IV></BLOC
> > KQ=
> > UOTE></BODY></HTML>
> > 
> > _______________________________________________
> > Audio/Video Transport Working Group
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/avt
> 
>