sg16-avd
Threads by month
- ----- 2025 -----
- April
- March
- February
- January
- ----- 2024 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2023 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2022 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2021 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2020 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2019 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2018 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2017 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2016 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2015 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2014 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2013 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2012 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2011 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2010 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2009 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2008 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2007 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2006 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2005 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2004 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2003 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2002 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2001 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2000 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 1999 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 1998 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 1997 -----
- December
- November
- October
- September
- August
- 5804 discussions
<x-html><!x-stuff-for-pete id="0">
<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { margin-top: 0 ; margin-bottom: 0 }
--></style><title>Quick report of the Portland
meeting</title></head><body>
<div>Dear Q12-14/16 experts,</div>
<div><br></div>
<div>A quick report of the Portland meeting is uploaded at the
following place:</div>
<div><br></div>
<div><font size="+1" color="#000000">
http://standard.pictel.com/ftp/avc-site/Incoming/Portland_quick<span
></span>_report.zip</font></div>
<div><font size="+1" color="#000000"><br></font></div>
<div>It contains TD-34b (general), TD-36a (Q13) and TD-37b (Q14) and
will be integrated into APC-1949 with other materials.</div>
<div><br></div>
<div>Best regards,<br>
<br>
Sakae OKUBO<br>
*****************************************<span
></span>******************<br>
Waseda Research Center<br>
Telecommunications Advancement Organization of Japan (TAO)<br>
5th Floor, Nishi-Waseda Bldg.<br>
1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo<br>
169-0051 Japan<br>
Tel: +81 3 5286 3830 (to be
transferred)<br>
+81 3
3204 8194 (direct)<br>
Fax: +81 3 5287 7287<br>
e-mail: okubo(a)giti.or.jp<br>
*****************************************<span
></span>******************</div>
</body>
</html>
</x-html>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
1
0
As indicated in the quotation below, the latest version of the IPPhone
profile has been sent to the IETF. If you can't wait for it to be posted,
please send an E-mail to Peter Blatherwick asking for a copy.
When it appears, I offer it for WG Last Call, with a view to publishing it
as an Informational RFC.
Tom Taylor
-----Original Message-----
From: Blatherwick, Peter [CAR:AT14:EXCH]
Sent: Friday, August 25, 2000 12:29
To: 'internet-drafts(a)ietf.org'
Cc: 'Bob Bell (Cisco)'; 'Phil Holland (Circa)'
Subject: I-D Submission: Megaco IP Phone MG 03
Greetings:
Please find I-D submission, "draft-ietf-megaco-ipphone-03.txt", for Megaco
WG, attached. This replaces the previous submission of the same name
(draft-ietf-megaco-ipphone-02.txt).
Please copy announcement to Megaco mailing list
(megaco(a)standards.nortelnetworks.com) when posted.
Thanks, and have a great day,
Peter Blatherwick
613-763-7539
blather(a)nortelnetworks.com
<< File: draft-ietf-megaco-ipphone-03.txt >>
1
0
G'Day all,
There has been some confusion at the SG16 on what is supported in
Packages.
The understanding that I had was that: If you support a package you must
support all the signals, properties, events and statistics. However you
do not have to support all the values associated with the properties and
parameters.
Tom mentioned that a thread discussed on the list contravened this.
The reasoning that I have for not having to support all the values is
the following:
o Proliferation of packages. Eg: if a package has a list of tones, and I
must support all the values, if I only want to support a subset of these
values then I need a new package. Therefore you may get the case of a
package "Package Call Progress Tones E.7" where an MG doesn't support
Payphone Recognition Tone because it doesn't have payphones connected to
it. To be compliant with H.248 I can't extend the package because I want
to remove the payphone tone. So a new Package needs to be defined
containing exactly the same information but without the payphone tone.
Now my MG won't support the standard Call Progress Tone package but will
support the XXX_companies_Call_Progress_Tone package. This would lead to
a proliferation of packages.
o Multiple GW support - One MG may not implement all the values of a
property. For something like a list of codecs, a group of resources
associated with the value may be placed in different MG GWs. ie. GSM
codecs in MG1, PCM codecs in MG2. So whilst the MGs support the same
package properties, they can't support a subset of values then you'd
need to define a different package for each MG configuration. Again
leading to a proliferation of packages.
o The MGC knows the PackageID, that all Properties, Signals, Events,
Statistics are supported. In H.248 we have the AuditCapability and
AuditValue commands to find out what actual values of properties are
supported.
So if people agree that not all values in a package need to be supported
I propose to add some text to the implementor's guide:
Section 12.1 after 2nd Paragraph
"A MG SHALL support all Property, Signals & parameters, Events &
parameters and Statistics. A MG MAY support a subset of property and
parameter values defined in the package unless specified in a package."
Cheers, Christian
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
1
0
Hi, Everyone:
Yesterday, we had a brief discussion with the above contribution. Please
note the following:
1. MGA has been proposed as another alternative mechanism to take care-of
the problems of GRQ/GCF/GRJ messages. The Bandwidth problems have been taken
care-of because it can be unicast as well, if needed. If anyone has any more
comments, please let us know.
(GRQ/GCF/GRJ messages have serious limitations in many mobile communications
environments. For example, sending of GRQs to discover GKs while the mobile
is moving from place to place. In addition, we have just discovered how
authentication messages are causing problems when the multicast GRQs are
sent to many GKs, and every GKs start processing these messages while the
mobile has to choose an unique GK that will be its GK in that particular
place given the fact it is changing its network point of attachment. How
does a mobile can decide a unique GK in a dynamic environment when the
multiple GKs respond back? Does the load (bandwidth) not increase lineally
by 2*N [where N = # of users] for all GKs of all zones around the whole
domain?)
2. GK needs to be allowed to communicate with HLF directly while service
provisioning is done to populate the HLF to store the profile of the mobile
users.
3. RRQ messages are NOT sent to the HLF. It is a "new" message that will be
used between the GK and HLF, however, the mobility related information
provided in RRQ will be communicated to the HLF via the "new" message.
In addition, the decision has been made that, like Annex G messages, LRQ
messages should also be augmented to support mobility.
We already know (as explained in Annex H) that there can be many HLFs, VLFs,
etc. in a given domain, and no architectural restriction will be provided
in the protocol whether HLFs are centralized or distributed.
If you have any questions, please let me know.
Best regards,
Radhika R. Roy
AT&T
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
1
0
24 Aug '00
Rich wrote:
"...Note that we allow the E.164 number to be included in both the
sourceAddress field and the Calling Party Number IE. If we're saying
that it "shall" be in the IE, should we at least say that it "should
not" be included in the sourceAddress field?
..."
YES, we should state that the real E.164 number of the calling user shall be
in Calling Party Number IE and should not be in SourceAddress field.
Regards,
Karl
-----------------------------------------------------------
Karl Klaghofer / ICN EN HC SE 81
HiPath VoIP Enterprise Architecture & Standardization
Hofmannstr. 51, 81359 Munich, Germany
Tel.: +49 89 722 31488
Fax.: +49 89 722 37629
E-Mail: karl.klaghofer(a)icn.siemens.de
-----Ursprüngliche Nachricht-----
Von: Rich Bowen [mailto:rkbowen@CISCO.COM]
Gesendet am: Freitag, 21. Juli 2000 02:06
An: ITU-SG16(a)mailbag.cps.intel.com
Betreff: Re: Comments on H.225.0 v4 Whitedraft (sourceAddress)
Karl,
Glad you noticed this. How about the following slight modification of
the wording that you proposed:
"sourceAddress - Contains the alias addresses of the source. The
primary address shall be first. Note that the E.164 Number of the
source, if any, shall be contained within the Calling Party Number
Information Element."
Note that we allow the E.164 number to be included in both the
sourceAddress field and the Calling Party Number IE. If we're saying
that it "shall" be in the IE, should we at least say that it "should
not" be included in the sourceAddress field?
Regards,
Rich
Klaghofer Karl ICN EN HC SE 81 wrote:
>
> One more try, since it seems that my previous mail I sent out yesterday
did
> not arrive.
> Regards,
> Karl Klaghofer
>
> > -----Ursprüngliche Nachricht-----
> > Von: Klaghofer Karl ICN EN HC SE 81
> > Gesendet am: Tuesday, July 18, 2000 12:02
> > An: 'ITU-SG16(a)mailbag.cps.intel.com'
> > Betreff: Comments on H.225.0 v4 Whitedraft (sourceAddress)
> >
> > Rich and others,
> >
> > H.225.0v4 White draft, section 7.3.10 Setup reads:
> > "...
> > sourceAddress - Contains the alias addresses for the source; the dialed
> > digit string of the source is in the Q.931 Calling Party Number IE. The
> > primary address shall be first.
> > ..."
> >
> > PROPOSED TO BE CORRECTED TO:
> > "...
> > sourceAddress - Contains the alias addresses of the source. Note that
the
> > E.164 Number of the source is contained within Calling Party Number
> > Information Element. The primary address shall be first.
> > ..."
> >
> > Background:
> > As part of the global v4 change to replace the term "e164" by the term
> > "dialedDigits" in the whole H.225.0 document, the sentense in current v4
> > Whitedraft does not make sense anymore and should be corrected in v4 in
> > Portland. I think what we wanted to say is that the E.164 number is
> > contained within the Calling Party Number IE and not the dialed digit
> > string ! Dialed digit string (unstructured number which maybe may
include
> > prefixes, etc would be put into sourceAddress.dialedDigits).
> > Note: There might be further sections where the simple replacement of
the
> > term e164 by term dialed digits may have caused vagueness, since term
e164
> > in v2 was actually used for both - real E.164 but also unstructured
digit
> > strings.
> >
> > Regards,
> > Karl Klaghofer
> > -------------------------------------------------------
> > Karl Klaghofer, Siemens AG
> > Dpmt ICN EN HC D81, VoIP Architecture & Standardization
> > Hofmannstr. 51, 81359 Munich, Germany
> > Tel.: +49 89 722 31488; Fax.: +49 89 722 37629
> > Mail: karl.klaghofer(a)icn.siemens.de
> >
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
2
1
24 Aug '00
I just have copied the version of H.450.5 with the correct figures 1-12 to
the pictel server at
ftp://standard.pictel.com/avc-site/Incoming/h4505finalwhite.zip
This is the editors input document to the ITU secretary for translation
dated Dec. 10, 98.
After that only on change has been made in clause 8.3 via H.323 Implementers
Guide approved in Feb. 2000.
Note: H.450.5 itself has been approved in Santiago 5/99 ITU meeting.
Regards,
Karl
-----Ursprüngliche Nachricht-----
Von: Klaghofer Karl ICN EN HC SE 81
Gesendet am: Mittwoch, 23. August 2000 10:22
An: 'ITU-SG16(a)mailbag.cps.intel.com'
Betreff: Correct H.450.5 Call Park/pickup document
In the process of ITU secretary generating COM88 (H.450.5) for the 5/99
Santiago meeting out of the Whitepaper input from the Editor, it happened
that figures 1 to 12 had accidently been replaced by the ITU secretary with
some other figures from the H.450.2 standard.
During WP2/SG16 meeting in 5/99 this was pointed out and the correct
document (i.e. the white input from the editor) was again handed to the ITU
secretary.
However, it seems that the final H.450.5 standard published by ITU
afterwards still has the wrong figures 1-12.
Therefore, I will upload the correct file (i.e. the editors input to the
secretary dated Dec. 10, 98)once again to the standard.pictel.com ftp site
/avc/Incoming directory asap (I currently do not have access due to unknown
reason).
Note that section 8.3 was changed in 2/00 meeting via Implementers Guide.
Officially I guess the best way to handle this is by an Implementers Guide
contribution to either current Portland meeting or to next Geneva meeting.
Regards,
Karl Klaghofer
-----------------------------------------------------------
Karl Klaghofer / ICN EN HC SE 81
HiPath VoIP Enterprise Architecture & Standardization
Hofmannstr. 51, 81359 Munich, Germany
Tel.: +49 89 722 31488
Fax.: +49 89 722 37629
E-Mail: karl.klaghofer(a)icn.siemens.de
-----Ursprüngliche Nachricht-----
Von: Paul E. Jones [mailto:paulej@packetizer.com]
Gesendet am: Mittwoch, 23. August 2000 03:38
An: Klaghofer Karl ICN EN HC SE 81
Betreff: Fw: [Q] About H.450.5 Call Park/pickup
Karl,
This fellow pointed out an error in the published H.450.5. I downloaded the
PDF and, indeed, there is an error. It appears that the ITU has replaced
the diagrams in the white paper with diagrams from H.450.2.
Can you check the rest of the document and bring a contribution for the next
meeting for the Implementers Guide?
Thanks,
Paul
----- Original Message -----
From: "D.K Bay" <pango(a)mmrnd.sec.samsung.co.kr>
To: "Paul E. Jones" <paulej(a)packetizer.com>
Sent: Thursday, August 17, 2000 10:04 PM
Subject: Re: [Q] About H.450.5 Call Park/pickup
> Hello.
> I downloaded the h.450.5 documents from www.itu.ch(pdf format).
> It's date is H.450.5(05/99).
> If you see H.450.5(call park/pickup), all the figures are identical to
H.450.2(call transfer).
> See the page 17~18.
>
> But the text explains about different messages.
>
> > Paul Long forwarded this message to me. What figures numbers in H.450.5
do
> > you believe are incorrect? Is the document a draft copy of the document
or
> > the final published document from the ITU?
> >
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
1
0
In the process of ITU secretary generating COM88 (H.450.5) for the 5/99
Santiago meeting out of the Whitepaper input from the Editor, it happened
that figures 1 to 12 had accidently been replaced by the ITU secretary with
some other figures from the H.450.2 standard.
During WP2/SG16 meeting in 5/99 this was pointed out and the correct
document (i.e. the white input from the editor) was again handed to the ITU
secretary.
However, it seems that the final H.450.5 standard published by ITU
afterwards still has the wrong figures 1-12.
Therefore, I will upload the correct file (i.e. the editors input to the
secretary dated Dec. 10, 98)once again to the standard.pictel.com ftp site
/avc/Incoming directory asap (I currently do not have access due to unknown
reason).
Note that section 8.3 was changed in 2/00 meeting via Implementers Guide.
Officially I guess the best way to handle this is by an Implementers Guide
contribution to either current Portland meeting or to next Geneva meeting.
Regards,
Karl Klaghofer
-----------------------------------------------------------
Karl Klaghofer / ICN EN HC SE 81
HiPath VoIP Enterprise Architecture & Standardization
Hofmannstr. 51, 81359 Munich, Germany
Tel.: +49 89 722 31488
Fax.: +49 89 722 37629
E-Mail: karl.klaghofer(a)icn.siemens.de
-----Ursprüngliche Nachricht-----
Von: Paul E. Jones [mailto:paulej@packetizer.com]
Gesendet am: Mittwoch, 23. August 2000 03:38
An: Klaghofer Karl ICN EN HC SE 81
Betreff: Fw: [Q] About H.450.5 Call Park/pickup
Karl,
This fellow pointed out an error in the published H.450.5. I downloaded the
PDF and, indeed, there is an error. It appears that the ITU has replaced
the diagrams in the white paper with diagrams from H.450.2.
Can you check the rest of the document and bring a contribution for the next
meeting for the Implementers Guide?
Thanks,
Paul
----- Original Message -----
From: "D.K Bay" <pango(a)mmrnd.sec.samsung.co.kr>
To: "Paul E. Jones" <paulej(a)packetizer.com>
Sent: Thursday, August 17, 2000 10:04 PM
Subject: Re: [Q] About H.450.5 Call Park/pickup
> Hello.
> I downloaded the h.450.5 documents from www.itu.ch(pdf format).
> It's date is H.450.5(05/99).
> If you see H.450.5(call park/pickup), all the figures are identical to
H.450.2(call transfer).
> See the page 17~18.
>
> But the text explains about different messages.
>
> > Paul Long forwarded this message to me. What figures numbers in H.450.5
do
> > you believe are incorrect? Is the document a draft copy of the document
or
> > the final published document from the ITU?
> >
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
1
0
Hi Jaakko,
Please review Intel's APC-1902 contribution which is at Pictel site and
provide your comments.
For you information I am enclosed the APC-1902.zip document.
thanks,
Paul
Paul K. Reddy
Roaming Services Capability Manager
Mobile Data Services Area of Opportunity
Applications and Services Lab
Intel's Architecture Labs
Intel Corporation
Office Phone# +1 (503)-264-9896
Mobile Phone# +1 (503)-807-9564
Email: paul.k.reddy(a)intel.com
-----Original Message-----
From: Jaakko Sundquist [mailto:jaakko.sundquist@NOKIA.COM]
Sent: Friday, August 18, 2000 5:53 AM
To: ITU-SG16(a)MAILBAG.INTEL.COM
Subject: [H.323 Mobility:] Comments on APC-1932
Hi Radhika & the rest of you mob people,
Since I'm not coming to Portland, I'll send you my comments on APC-1932
here. You can discuss these issues further with Mr. Rissanen in Portland.
** Comments on chapter 2 of APC-1932 **
The LRQ mechanism will, of course still work, but I think that for a true
global mobile system, the mechanism is VERY inefficient and thus a better
way of locating the called user must be standardized. I.e. generally a GK
has no way of knowing under which GK (or set of GKs) the called user is
located and thus in order for the LRQ mechanism to work, the LRQ must be
sent to all GKs in a domain. The domains may include many GKs, thus the LRQs
would create very much traffic also adding one GK to the domain would
necessitate all the other GKs to be informed in order for the LRQ mechanism
to work. Furthermore the originating GK does not even know whether the user
is located in the same domain, thus the GK would have to wait an arbitrarily
long time for an LCF and if the LCF does not arrive, inter-domain
communications would be needed -> how long should this time be?
I really do not see, how the VLF <-> HLF communications across domain
boundaries BREAKS the H.323 model. The H.225 Annex G states that "all
inter-domain communications are executed via border elements" (not an exact
quotation), but we can either change that statement into "all inter-domain
communications must be executed by using the H.225 Annex G protocol" and use
the protocol between VLFs and HLFs or we can say that the VLF and the HLF
must always be co-located with a BE (to create elements HLF/BE and VLF/BE).
As for the question about the "distributed" vs. "hierarchical" model. Again,
the VLF, HLF and AuF are just FUNCTIONALITIES, i.e. you can co-locate them
with each other or with a GK or a BE. Thus, if you want your GK to be able
to directly communicate with a HLF, you can add the VLF functionality to
that network element thus creating a GK/VLF (or perhaps a GK/VLF/BE), which
can communicate with the HLF. Thus the current H.323 Annex H architectural
model does not stop you from utilizing either the "distributed" or the
"hierarchical" model.
These comments apply on some parts of the chapter 3 also.
** Section 2.1 **
I do not understand this at all. We are producing an enhanchement to the
H.323 protocols and in doing this, we have identified new functional
elements that are not present in the H.323 standards beforehand. So, the
interfaces may not have been a part of the H.323 standards before, but after
Annex H is done they will be.
As for the specific interfaces, I don't think we need to specify the HLF-HLF
interface (in fact, the interface is not even present in the architecture
diagram) and my opinion is that we can leave the AuF-HLF and especially the
AuF-VLF interface unspecified in the first version of the annex (thus
assuming that the AuF is co-located with the HLF). I have proposed to use
the H.225 Annex G protocol in these interfaces, but there can, of course, be
other options as well and I would really love to see contributions utilizing
other mechanisms, such as the IETF's AAA, etc. My opinion is, however, that
we must select and standardize the use of some specific protocol to really
enable interworking between different manufacturer's products.
These comments apply on some parts of the chapter 3 also.
** Section 2.2 **
I think we have a linguistic misunderstanding here. I would like, if some
native English speaker would comment this, but I understand the terms in the
following way:
- Visited Domain, etc. should be read: "the domain currently being visited
by the user". I think that this kind of interpretation is commonly used in
technical language (or am I totally wrong?).
- Visiting Domain would sound to me like: "the domain is visiting
somewhere".
- Serving Domain is OK, and is already used in Annex H.
- Target Domain is OK. In the present draft I have used "new Domain" instead
of "target Domain". Target and source are words that are commonly used for
the new and old domain, etc. (E.g. in GSM handovers, the terms "source BTS"
and "target BTS" are used. If using the words "new" and "old" is confusing
or misleading, I ahve nothing against using target and source.
These comments apply on some parts of the chapter 3 also.
** Chapter 3 **
Most of my comments on this chapter are already captured in the above
comments for chapter 2.
A few short notes on the other issues:
- You're right, the security check for unregistration is definitely needed.
- Also Connection Termination needs to be handled, although I imagine that
there is nothing really special about it compared to the "normal" H.323
system (that is why it isn't included in the present draft), unless
supplementary services (and perhaps some billing issues) are taken into
account.
Those are my comments, I will discuss the issues with Mr. Rissanen so that
you can have a meaningful discussion about them in Portland. Have a nice
meeting everyone!
***
Finally, just to annoy the editor of H.323 Annex K:
Ice-hockey isn't enough for us Finns anymore, now we are beating you in
football (socker) also...
Finland - Norway 3-1!!!!
------------------------------------------------
Jaakko Sundquist *
+358 50 3598281 * Audere est Facere!
jaakko.sundquist(a)nokia.com *
------------------------------------------------
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
begin 600 apc-1902.zip
M4$L#!!0````(``!(a)%2G31+\I.;$````>!0`,````05!#+3$Y,#(N9&]C[%P)
M?%1%FJ_N=)).PAL.0^2F2$`)=-HDW!%'0(a)Z20*!).CHP'G2Z7](/^HC]7B=$
M'0<</&>=\=99&74]%M9CEH&%T14U>/(3#UQ=1A=!\,)!CJS#C"`#F7_5>Z_[
M=:<;(L*@(Q7^J5?UJK[ZZKOJJT[(YK?Z[OBWWP_:2>+*CTD*.=J50=(,?>SY
M9K/6Z$/(O^#9A,>C75U=K&L9VM<!UP,W`#<"-P%=9\IWMNQY=`.Y@F18"+'V
M>SZB613T2.<2\B/2N+!QH3)6&4NZE0Q+#AE?0TA.J8DC-)R0>V$0[KAQA]#'
MS*:KJW>D+]FS7B[EW\L'DDC-D(GGV:A[H;8/5=\9ZVP#A<N&)J\GH[Y;&_\8
MZDL,[WN76X@/[.8.4]NLSD$]6:MG:_UZ_=HXC$&]9YS*UT'45M0?E%KXKK>C
M)G&U`[5]NH6\B]I<IM9;4(]$?56EA1R`Q()5%O(YVE^COS_I7O1]D_$)7J)<
M9B?$FTK(*^.X,J/CM)K1967S!+7=.C"VUO>G%];NTR<J%WU>?,WH?T!4.HHY
M2F?[$%7N>OL#31[Q9?I09G6$.+1Z_D"U]FIU/)_Z?G1ZC(^K>T7YF36=D-7E
MB%1?IY"]>-X]F)`#Z,\!_0'DQ(N^GKZ?--38(J$O+C`]E-5ABK>[#\:KZ^Z;
M:B'[$F_]-)121UE!T93"8L&47NULH$[1)[J#?G\X(+E=BA0,T'K%%?"X0AY)
MUMJB6PF&*!7JE;"GG<X(!<,MM&BBC<X-BS(?433NO*+Q@C#77E1<4#3^O**)
MM,[5TA(,*6(X)--:452D0+.-.M#C`VT;G1,2FX,!&VVH+[71XJ*"X@FT--P<
MEA5:7%A8F)Y>'G2'_6)`*1&<DN(32P2A?DY#75E%27J$^RK[N.)QM#;8*/DD
MI1U,AEHEMRC3L(RU:'6%L_)V67TMTFH'Q;(T(+91<;$B!CRBA[:$@DK0'?3)
M0G5`$7WF]'2A='J]LZZTS%E",YQ>2:;N8$`)28UAOD>,;PG*6$`)4I?'0^/6
MCY"CC2X9Y#'C&_!@%X2,C`Q!Z$4=?!F7C[J]KD"SNIRZ5&D@("ZF5=03E8U7
MI$U!GR_8QK8L>UT^'VT4&7>@C7F3[<7V(KXJ>RJF(a)N`40WXI`.IE7E?(Y5;$
MD`0-NN42ZE+4K8K4(\IN/#*2"A:05<%2%]^H),HVJHAN+[,67[23!IOX:+^Z
M645;QTXK83GB8I>_Q2?:^`C]%=N@D05(.^SS4"G@878HTC:O2Z%*>XM*6^,"
MB\\-UE-1<=NIRT#*%:!RF%N<(`@1$6J:8B+WB[+L@CAA2>7A$-L;+!`+A[B)
MJYS-F(FAHH>+/`2?:`Y(5XJQ/+MD6L5T$>G`[ES=-UW=%#L-MM04#`>X4J`@
M1L*&>8%@R(^W1DZ82;A%3S@D1O4I!5J#BT2/G58%V\16,42E./)>.)L8D#7J
MW?CIOCN5(KUH5J6-5LVJY"92VE!)855<FS#'Z@#VYL%B&.YA&@HTAR79&[MP
M4RCHUP02U%95%XM:I5'XU(5M:7[D86MT%Y/&^NA:9[Z-AEL@$/"-]=U!;+S=
M1B4%IA#`+NHJ9E0S;W56SYE-:ROJZTMG5#`NM*TJ7D2I9B\M==BIT,#HQ$B9
M;=@5QEALV&TP@1BJ=16.6?,84R%1"8<"JD^Q4;5.N^I[,%]TP$YKG6P<XXSM
M.2%O4D!61)>'&3.76%W=7.KVB:Z0KSUB]'+,#IC])Q8/8[^;\IAV-1-@^O6U
M<AD+=<9].W3KDN%?8H#QK0M7QJ(E"!%86B,/C_0C#(C,*1'/H#ION\S=GMM)
MN\"%`!*J1EQ)=0*2H\>"8'Z,6MADS3)XI'5)S(0Y143-%NS:%<!"T?U7E]MH
M=6U%-1W=YI7<7BU@<(MGP=7CP;9D9C8R\Q&/RB2;4H\I<KB1AS6\JB['(#VL
MA<0KV"E&6Q",_*+"Y,"VS_C0*.JAC<D:YM<H^H*!9J8I=0O87%BU+[<HM293
MOPWO?:YV=8/ZKC5E0S(J*2YSK^A>Q,)%B+]K`0=B`'QJ3.ALPXN:F"5HW7S+
MHZ,G#[:<'PE#[.7M<K>I,"=7(X@K-IT+?7')0)2-8KZLVE8HZ/(S:U#%`[5H
MIM6*8R/HAP;YHH$@MUQUF'ILS8P-`EI(X]L,-C+5Z\<-7Y2Y9C`D7<F-EI.,
MZ8'C23Y993L@-JOK)W9=F5N0*N=N87H.$ZQ.641:PF3`8RG,65*@^;9`Q`HT
M((a)EMG%D,MM*&I$E./DJC4*6K6Q'].+%<H7:=,UE1MU==3NEH)].A*GXYJ'&E
MAR`6"51QJI386*,[N"'C`IA&U"W4@,5,6+,8[F3>H%]7G&:_XC'XY]%>-Q6-
M3*LD2^QLB*I?X<<]PH9*B7DV=*!Z5:O+)WEXG$/TP=L0<RBVQ0!G33=ZQ%=&
MAV\\:I+:4-HDA>"O,>%<=V+,#XF)WMCI=-TWF/1L/&""FFZ'HS&SL;W%)6-0
MOBI3QI`>V$H;G%45LYW59;IUS6VHJ'?J"@4M!-H&9KA(G96P+*1'\BRU([W4
MS;EI;-<M(#V=CY\]QVD\AT1/=&;W5_6B%IBD0!,+/I'5N>`:@XJ71F8S:?,5
M2F-.N63+TNBZI=]@S0;=6:,K0,2^=FV9D[2S:/;U35>*[9[.%1PG$5B9$FSF
MQH@;`/<2'H+@@Z-Y&+49#R#65P&W9#%,<_AH6L#XU=S"Z%AL"W&<MX1#ZEW"
MY78CR^*Q3Z6!(XIEQ"Z$9AS*JB4RNIH;L"$LT?5)_%1N8@DDI]@F0?LL9,&]
M7.P<L.O9E<'264H0B=YQ'+'$0-9B*C/]-A>CIGMD-P=@X342#Y@#Z(=-2&QA
M"8T<"<Q1DIHWM;`,$%M4CAV\HX>CC:KG/6-8/T:E2%1G*8P8:(^[KD2V'^$'
M`I?X6D:V;2I1QEVX18U,[(TOJ)N8\20,<`''':.VF(F-$L\`93HZFK]4.[2T
M15=Q)#C;U,#-;C/YW&-E[>2AH[%8`IEH03^?=DL=])1"C9G&;`K9GG9H0I<1
M0<;&3XB'AV:JI9S,'<%A=#07(a)#_,XVZ!.E4,,1G;HM?=R#B>/^D^(_,`:(N8
M8ANN4"P_T"-O1/ZRY&>:2BA-1/^`R.R3'9910;$QQ[2<TRD;_=:!4[5%83,2
M<!HQQ:I9E=$L;/38&3/S$0E$+@B7(4\X5O87%4MRPS'X#+]>G+`PV,5"J-6(
M5B(]9!=K:VQ!AZ#!RJO88KAGR"++OI7X"X;$K^M.;T_O&#_8R\6Q[Q:1%%"G
MR$XE52`LGD6<3)N!H2VBFT=*-EF+>I%CY>1>5&($9SMS;_F>W5MBU/?#NK(H
MH3!.J^/<6O0IJE\EN+!(J@,EN-($]5G&WC/7F#/7F!Y=8X28FTR"B\P_^AYS
M*F\CWZGKB/[);5,XQ)3QO;ROG/3KRIG;RC_O;>54WE-T9_HV]Q1.`UK3-&9(
ME1.LW^AR+XHZ:M)+CB!$'JSJ[4;]%JUB;CQF6L8VX%8$AROLHS/MM$[T>-CM
M@?WD&2]#3&Z,<1NMJ1Q7,&[2)/93\:(B.MM>8:?%$W`DEK:*@3"\MTKR^>3&
M8"AHHW/JZ-UTRJ2BXO'\!^DTRRGZ2NC8(CIZ0N&X?%H\<7S!E,E3)MIHI6MQ
M7/_DH@F85(&XCAEGT:IYCHJZ6=6S^=T`!TE)"_BT+[*'&)O3),:EW0WEF[(3
MO^@OS)86>24?+1=E;PLT+";96W%!,?O%@6^^M]BM39E46#!YPOCC;RW`V;+[
M[1Z=L2C3@G!Y@B((!1"(@R6/])(Q2"3K9E14SJFK+772[.+^M$`08G\:'_D%
M@-J@1_2I::7Z\WGV\WRANXWUH$_+7I/U)CZ?P9B:X\;TS9@Y-GGJ*P@7Z1W,
MV...5<-ZW3_\P]1CD(7/]7#%GN_DFT@HF=QBTX;$P[7M)<PQ>JY/5H[_JSAG
MRIGRCR_L-S\MA/\&:":0!4P"2H!YP'Q@&?`0\`BP#E@//`L\![P"O`KDI!)R
M-C``&`B,`NX"[@;N`WX+O`8<`(a)X#?P.RTPCI#^P$NH!AF80,!V8"7\%A+NY-
MR/5`=0XA/P'F`5Y@(;`("`!!(`0H0!AH!:X%_A-X;!!H#L%ZAPZ0SGV[R6>?
MD&U_?.?-PX<V=?SW.K(:7T^L>&+%`[_!-_($6<$:OXI\H:-_RD(FH3DU9C(7
M:+":_%7$DC71NE3O^M$$ZU)#DU@C3UD3HMWI7BL)5&58TM%75M./9*(^GST.
MP/[5-0IK<HWK6,IJP'>&2GWZ&%.:^L1G3F0S\5:(O&7-%+08?3_625.[20J^
MI6OO,]1U0#MEHCJRK(:R7\C4=)\5I_.'-7W_#EBKZ?TY3==]-3U_:;2C/QD;
M.XR-_^U98^V[IFACI?%-\L9]QL:M21M7D?B23<E9CV23;"!GI$EX98!Y^MDK
M1J4-2EEA&9_F2-^0WC&BHZ.#=)BS"`8ZH@-3B:ECA)G]HF_*2',,B;@WW>90
MPEIGCS29[_81ZY9"]LO!SK2Z<Q@[:285^G.B/LY)M_4R6._4;CV.2,^\H22.
M6^$5*S$_F-HQ8AH,^-OHG_GY(,W'[]'\?+GFY[J/?PB_WF'P<9*.V&`EY!S@
M)N!FX$N@$FSO!?8!^S.BL:#&$`\NZJW&!#?@`10M/MP`W`\\#1P!C@(Y?0@I
M`#R`""P&[@#>!-X"/(a)(.`8/Z$C(8&`(,!3X'=O7#FNQ7PX^P<IA_/_+5X;^0
M/Q/2R?6QFW_?M7,K(5O(.^3-C40?&0-"7EB_+FITF=85Y@P3B[*1YQ3#L]GP
MS/5N-3<2WB2IUL=16<V#B?4QULZT/FJ8\6AD1JKZ;-U@BO:PYQ3S-))B'D32
M884IIM1,<XJ)6-A#Y:G0XS9B*#$^_HZQ\8:Q\:*Q\8RQ81!@'($3:9Q<:K]/
MVH@6""_S'))5^:A9?]I@@J"$5S(M:KC9`%%":KV7/9C:=]F"K[G7/I@ZC>!?
M[V7P-H#]-QOKH-@YN<9XDGZG-S5!3#'6"?NR3Y;??4T,Y6#2QL=)WVQ/^N9]
M8^/=I,/>/H'&O1\8A)-\F+%,-HH]=<L`"R@D@G5+)4FYLVM(UB,YMER2=F-6
M-TH][$OA"^JVL\*<VAAYTOH>-_<?3%)'DK21:OLQA/K%,):S+'.L"S.DK&=[
M:3;#CC23T2))WY,=,YO[(UX8V7]QN4'$,6^2-UY<>0)S"D]@CK&Q(6ECO;&1
MW.63^']61'.]EVTV<^_>;$Z+ZI/_%[K39%4D6]>9%ZA$SCP#J,J)S;DE+>?V
M`7XM[VX!KM!R;Y9WMP&+@7;@2N`JX&K@9\`UP,^!)<!2+3__!;`,N`ZX'K@!
M^%U.-&\?.D3-W<<`8X'S@5I@-B`"2X"7@)>!;<`!-@ZIC@VX$)@/W#54_5]>
M_P%T`#N!CX"/@4^`3X'/@%U`ZS"<?<-AWQ0Y.0NMP#Y@/S`V#W3S6(P[T$VT
M7\8DP?O)[D_(3I0/X\%?O__.&Z_"M)[!F;V2G=/IK%-[3C,\IQJ>+8;G%,,S
M/_LCY[C>&\T;5JIYPY-F=OH/TO,*;945^BHUIT/WAXTB^ZNQ$2/??[9&C*7$
M-$[AHKR8!A%CW$?,26'YAM=$AIP*7SQB7/M$&C'G>LR;/QL;^Y(.^^($&JN-
MN4!/YRQ/-B>FG.:<864D9U@9R1F>5,^=[&&:'NV(;Q<`/P;*@!G`+&`V,`=P
M`'5`/>`$&H"+@9\`\X#YP$^!2X#+@,N!!8`+:`3<0!/0#'B!*X`0(`-K@+5`
MWY&$]`/.!Z8"%P#U@!/X-7`;D#N*D#Q@"E`"G`],!?S`$F`@<M]"H`BH!/X`
MO`Z\`7P$?`P<!`X!?<[%&H`#F`MXSE7_S_.A`X<._"GI%_F(["!;R=M;W]S*
M'[9NVDHV\J^7(WBYFY*.7RQE-7WX=YS(%O9!$[$4UE3C,F^V+DU9N/TL*-IJ
M8F\;K";#ISE58TQ"]#,D]"3^U"KQ)U.D_%2<G<=(N+Y;B5T/&^N-C;4]:W0O
MZ1%O9'E@U#=/;_Z7+-<IR(N-">5`!5"9I\:&VCPU-K"XP&("BP<L%K`XP&+`
MY9KONS6?EX"%P**\'I__/YS,X%2?_ZP8SO^5AO/_5.O:!_B!`!`$6O*BL?]J
M1(a)LQ/0-Q.Q,8#E!#7+\0F`8L`GR&&+\4N!.X"W@,>!SH`#8`[P'O`WN`O4`6
MXGPO8,`YW<^&&4`CX`9^!EP#W`S\$G@(>!A8=YPSI"_.BW[`*.`<8&J",Z4)
M\&IGR['+D8/_OU\M>_;O)_MW\R]RS"]]Q/XHE11S,TDU4R*8S"83$<QYQ/J"
M_H&(a)56]A%,3_TQ/5T;?1S;?.#Y,WDH>6F$8/J<5X4LR;F/3]1!CM/*EODC>(
MJ1F@P`B2FJ?Z_PLF8LI3_W3/D-/E*Z?0!LXTXAHQ3J$6;A6HAQXK;HE:[&HV
MQ*_DA$_+ULZ4$RNZ_K.*26:A*;MP3+JC-[$"PU?]PDY7O5`Z8E7`D@ODW7IS
MZDA@U"I"SEXUR3P`."[U,^5[4]B]LIQXM):N6O7&-3;UH=1W4QY(23C14'H3
M2^=4U*LMF9WL+U^9V&>6F824D:Q.]A>6+*6,WE)37URYGS>Q/S#695+_1E:?
M3HM*8DDQ2>^<#5Y2+&OOW3;Y"_]OGGK[RFWK=I9FK^TB8\Y2.2KG0^\P+1@Q
MN#,7??$C6^R$W'20D*\0(BCN(a)SN0_13^3R^RY)!`.OMAZM'%RY^8EZYL>7GU
M`[5+'/TZIM\QIJ!\.B[8N4?J1EENW[S(VV_^^FF/7/K)9[D5-W>.?Y!>^Y#U
MROR<\@K+;;D;*_K,'4;-N7AS;]?K5^]9_W[MXEUKY6=W?;IIRO-K#N]]\^@U
M:S[<]_J^:XH<%KI:&KC$[-BXY&A_9_8O-SX][KR6M9_?./.V3;GRUFL*V[:^
MMNSNBIS-\T>X:<TFAV7)C4O<II4/3[UN[2/6YM]NO6-K8,>^E1_-O^CB[>T;
M>O][S<8-^25_6Q!Z]86?'_WT5[<<O/"NW)^U7]I__U^/_K&H\WGEF?9M@U8-
M7//DBWV7NX,[LJ\:?LL:07IJ;W6*+^TOZ]Z:NWI;U05[2E]^:_ZO=VQ?-[7W
M?PGM3^U]Z>.]T^YO.K?SDO/_]8$UST[9M&Y7_KK[U]WS\=R<Q2N/W)2V^[VC
MK[U]^=-I_W?A.X[[9N7YS;?\X='/\Z\:O&;/I*=>>NZ&QR]8?E[;KD-=]\UK
MOG#-PE53%\P;=LFM]UQ;MKKDO3%?7'O/IW]G[[O#HDJ:O7LB0\Y1<A(4$1`0
M$)1@1)($14$1)0@"2A04`RR&ES4KB@F5(.:$HJZ"("IF45$1!3/F%0,F4&]U
MGV&8M.SKWN_^\SU[>.K,H:O[U]755=W59TZ?V32Q/%-K\8JY3/,DTRD&_7];
M[Z_Q^TA5F==&Z<VFCP?%L>?$J3_>T*S\[)KTT3M1CQ+NJB^[NR;]SJW!RU<&
MCS-;M/9WMQ!'W8^K9E>O.NB2WS,DV^Z@08/IU-]JWN^,/?ER]L3S]Q>__*:9
M1V_9^FCZPF&YT__(KV/^1\9[=?96<W\S6P^IA0>+AT_9^^FR^L4RD]-E]7,6
MZ`\R<70>E?`A_5C)XX16CGQMWJ"K?_Y9.#S64NZPN<],/\=UGM8'%QA&#CI0
M,=3QTX3*>.4O,^[^?MXGRNAJ\J@[YTHB^]Y>ONI>\-XD];=+/KRD]SQ_NR/_
M]1.G@UF]SR=GGO1Z,FGE*99QEMN?D:-\C"2V;SFQS>G&CL7%?G8[ALF:Y#;.
M<@@[U:_L?O9FESF2<C7S'\QVT#O!&<3J]\#3BCE'OM'=^*R[N874X=:=ATX;
M79>XO]8K<\3!=S%W%A0]43'-F+9QS+/]RUY721Y4>G9!)C-HP8.>UVDG\[ZE
MC^PU:<2BZD;4X)9QX\%,*^6].V_MJSZ^<RXGKK5HX0>3N?UFG;OZ>J!9UAEO
M6S6[^0>6F\\[JR%3O4E?PNRHI&-UT+XG*B9'.8KI+*E'LF;9)SUL;58/MOH\
MF1;`ENY1JUSP?79><N*JWC7Q>V5I_6F/TG*-S[A^=QYZM[0J\DK.5&>MO5/O
MIKXYOM?^]A?%^'V,0<EV#E>?.FN/24^KGBAU.MQT_,J@E'%I=;>3ULM)7=,U
MKSV>$O;GZC]S4YK[C#T1-KHU_,[IGA']PY9/S@RXDI3S^6Q&:K9TS5JO]Y)A
M>4>^[+8(.#XV,[#@@<>%1-=C<F;/W"2OA3MZW#_G<W-6GJ6G6M/*\)G:#D2G
MT0=^2SQW:D&4Z6C[N=6&+3$G6&7O;"U.N^S7[E_]ZJAV<^W8_?(W'AIOJ^H3
M)WMFNUQ]\?NZ!;GIH%*=%[J+2G=.ES=!DWHZ+&,\L(JJZND@\6/IKHEVE=(7
M6Z6#%T=/'-B\X-A.._G>Z^<W5)V8%P\6__#._9[3*QUSRBY;=OR>H=?O<HA#
M\^YJQ98AKZ>MF>0+&@T[57O8Y>;NVNHHZ:6V>KN:=#?&+7U@FZRUV7YI3^?V
M6<9OVS1J[KL[_:0;?9'[^'AE2^+>V/7)V3O.O_&6Z;G!\-Z=P(=JIEFO\C^%
M5G]\4KAMD)',P\WA9IOGT3*K:A+GUY9=?>ZQ;-4AQ80;/11J]KFGGC'J<$IY
M>F3KH+D/;FZ,M9DKI9/1V_:A=^R'\L9*6<=#FE?J[!M&'G>!7G'NX?UF2<WT
MV.)TOU=G+AM/^M)[?+;Z\Y!@W_:*]0%-@\.JI:Y7##EY2L8FRK!IZMD`NS,U
MXZ:]>7CTU.-U(>8+[T]9_G6&5GC:->66/D/*;_T<R@CJ<V>7X\T7]3<OE026
M;?RVZ[+^89V(RAO?4CW?[7KS`(J-E7.9J%UXM-"\)LBK3U/8Y:-_O+ADYQUV
M1CGW_+>OYGMWM7UK'!W6_G+#MF_'3&LW^'<L-S]WH,4^Z//TT(?G[1/S)^O$
MAN\^/3G7>.*:0]7>UY5]+YA9H+DWE:?;F59;;N0,FF0_^,:LNN`QJ9SQ.28J
MV4TJCRL2)[PIM(DR4+5A/&?7E[[=HA"_\*W=Q<Q%-^RFMF7O:$#L5^?O25X=
M'I`Y)O9QW([<BN*5L6-&Z_5Z]E6I(.X&_>=E^S-VY8H_FNRKEL6-OQ?]^%W^
MGB71KSUF3EU\,6!W89O$X3V]=`_?3%RVY$Q\X\\UC2?C>CR:]"K]5$I(\<ZS
M#^UO]K^]O>28:],E\Z:U83>"D^=M6[_IX^*O\];D>]M>C2LJO1QM>TV[>$6+
M1IM]Z8ZRKRO6;[BH,BW!SX2,0VH95QL]I-K*Y'SKS`9LLGEC.//LWFUQQ^<W
M'QKPPFA6?N6ATN>+*P8?>1W?RW#HM*PS1[?>J]U4["R_9N?,S4L>G_%?>_M\
M3<>.@OR>Q?\I..A];'M426Q=OM[\H1OILNGTTQ^<%SV]O45JVL*D]3-&OD\U
M.SVD(^[>;O?`.I5'O?VR3RZXWJ$8^,3.+^_9\_S$UN5)IWN/T7FZ>]>]U,"B
M\MB;UY5/.NU;>^'$X`OO`X\M7#A"<4[H]SA#Q\"@O2_W?+38ZC)4_?5`I]@C
MUWR.%]@W/CUTX4K)D#2;RX=B;*O32FWE/X_/B59O/NUTRX\1DJUU5^KC]B5%
M]M^NOYP2,JKPC;OYA//F,#XT%=5?M*\;,U[V9>S%ZYOCK&,CWTY,GJ6S(;A6
M>5M[OR!;N<_)AV+.T5*>?9CY0R?[Y`O)@RO'5*L5R&Y.=LJL:7JXL?GSWL2,
M<]?NKGSZNY+B-__[_=\^'Q!]3$4Z<N3B6T6']TQ_OK)<M:Y]8N314Y<?VI:^
M7-*+,?!)='B???-9)Q@%3Z;IY_5])<ENH57>9ZJ\>I@I>;7]X*'F#8_W[XZ9
M?]BKKY>59D.C1=65*(;INN\-%T-/#]QFU6:7J.6[J<UB^.TO(<7/JDUCHY;Z
MZ[S]SX?G#G;6;_T'?-`V67\@]F[09-NE"UXVA%]8$?7ID<('TT_]/EC?67S&
M<EO/<MO+^RMW+`CR2JR8-6#0J;+18:Q]&:&<RKJ0GT';YUGO_+C\Q;(W'Q,:
M;I]8.OGC4+O+'0N2O4S&13C5^:_:JAG!ZF,URVQDV25CEVG7O3)TIR9<]RI;
MIK9^K7E(_.CM;SP#LM9LV'#T=.;6(P?M9M:L7^#AW2O-;DEK^&SOU3:.U7T<
M]KS=75'M)/]L9'I4.;-]W,(4[6D#'CA?_F-:0^&78]_MOIPOX.0^;Z\HB).>
M>?YNM5>&2W#?J=E%W]).&KW*7K_?\;G<@.P=S3V>W9Q5'?9@R1:)$]KUV4]C
MR[SBQS!?P20;)S/S0D^W>$<EE=6_5\O;TV=,N146&?+88H#VL,;Y#4TUX&KK
M9M<^/1-^I'+_[0^*Q^<=:4CL./'F0D"<=NF=X3[70QO/5I9JA@^\6>:QO3S>
M_5WYT:C_?&BX-"='IZ+_E5U[ON2[_-X6;WMFIW?0X=EUEENTTG8U_G3UCE>9
ML3_UZ.8WU9IIAGWW7_TP\_A\^<;?.G:YU$:>KL95'MOTI"[[^#J#>^<N/;)I
M4:U@S=T^ML/JI$1TQHK*CJ&NB_1^.^<7LTAJ_`KWK5<SRSGINSM.O3D!%=X_
MFA>U*F7S$,^=EUUB>RCWDI[OON=CI..XL*4C'X8TLX]_L=T].2LC],[B)\.\
M0WS:CM^I_OI^6+\-CLDM@]:M:Q]_8.83BW1E]:I>F6H%8RZ-N>3O7*)1JK%M
M]NQ$`^>LQVWL&P'WH[WKR^DGBHX45:2/]7DTZEB6WDB5/:I+W&(&!Q1+R]Z^
M';,RXOKD@\L?M1W^,B_BQNSW,D,N;MXQ[U/3@2:SVO(M&\IUQY?9O<B-]ZA]
MX_KMDL^-Y!=#QNV8VK&[8,R--]Y:4]\^="O7_;Q_6?*L`0OT#GPXMO?//;%I
M>FL/JSN<';K`\$WJTO+28X=<JO+>C%Y:MB_1Z'B^7MF-HZMTSIRW'^O8./V/
M]Q&-N1LCBS(.1-X\5AC=$3/S_@]/O7$/=,J-YR;L:J4='C`IY+WDAG//7NM7
M3KIKW3@N-'A22EN"?Y^O:W17O*D/NE6GO\[#]T+P>J/SA]S7WXC:,716B<:F
MU?=;%V0N&[5?[^(K[_WT>U6Y"FYY#R;LI,N_//XQ?"=M;J'#\V&I;4V-2H_,
M1MS?6=.VQTGURD,EAT6OVC:U:Y[(+DT9GS31L#F:_>+N(673V*5:T;T>3@K0
MZ+^A1_6H#[/VW\_)?K,-5<87OC.Y?.IJOD1B]HZBL2?7%3!UK*X83Q[1+S##
M]/FL&:9_WO[\<4#KRF:_IF\_K_E\>WO2\.?538&W:H>/RL_9$V&<%G`HSV)9
M@HUD>[O-R(LC=/?\L#+\>6R<R3XUQHB&8=K^^W^7\3]\[8+S^:*3BP.*'R/-
MW[^KS';>&/]C]=NV"Z-VWC.1G_V^X7A5PXGR#O/`SU(F=LW^!LH+S5]9:61[
M&*BVIZ>5VK`'N#FEY;S+]3H3-^W5A7M_].A1T';IM$KDR`^+RURN'^I3L[;L
M\*6/PR57C7.+O"SI[UPT^8JDS0/_Y6O&M-S:Y)U>GY0=?F'-2TV=#R7Z07>=
MOKU?N<91M^;]CK09^T;7IR:;[7JE4?0J)F6\SO$`Q2'%>\?G[-TUJL>JZ!X%
M%>-&?8ZV_./)@<^*JVZK%51HE5Q;DC7T\-D)DDMJDK26J7X(7'PVK/BLP13G
M275AEA)-[[FRG=8?<:=QYM#:3,<INSPE*T_L-IEI/'_$Y<BC(_*?@!3&7JV:
M?8]<VC-@0T>3B]:LPTGKQ^@D]]<LTEC:%,GY5+_X]K!K0\H\E!;7+=)\5C;O
MM]\U%@:B[Z'![9/JM^4TKJFSMG8J7Y0T^$M0\O1[<U^_./FI0F;+K96#_Y.;
M9G/6:!3[&@I;NO5'Y9]QIY2#+F_?['!HRY_7"YP\#0^WO?8Q"?)M*;`-]GV:
M5?C62QY:F)%67+ZSX('+N4C?NO*&$Y_N#1PC[RM3VGN5Q[!EP7ON#YFCJI4Q
M_Z#5Y@LU2;E9D8%R!]L2#N8\"J?994=OU[RT9;35BL8G&8K2RMM-(\Q,_5/S
M=Y<'?/3I%U3K6^1O-=ZQ9=6BWJ53'>\79>8G?0J-O#RZ_*MNX1'/%8<K+^<=
M2XU6UCT<YSFJW/;JT5M&WG=M,H^-OABW;/JF.7=M$_I/V>TTM/:$FV]5'L[;
M%A\^X+O]\TTI/<ZFG\W3M6XT?70A;QRL3&[_4;%C=TA>_&\+SXT^\XR"737H
M\/&3MKJUY;H+]\N^/CNZU=K^QJP4HX:<=SLGJ-Z:[+BO)?#S1//9M:L7S@Z6
MK*RK]`C6D9OL[5#HL/1`QKEIJYN^ZQ9VS"UL;,G0V-46?'2Q9*6+9]'%MF,S
MTP\.7=U2$FJ<GG=QIMJ`P4\'2#>[?-TWN7!C[:VD@*O+%-)6T]<O!!LZELUX
MJB6W)FSZ\HTW>U19'[[<I[T=F\6T-NU/?N5I!>_RAPUP7+AD=H;7Q61=EU/%
M+3[E6?4U_9Q:LNH;-J<<BTQHNO/D[9.3[;MJ7*]NW-YS[,J4DH@7@RN*B^;4
MZ*1ZWU#UC5UZI7C!^J)7U18[9<O:O!W'?'CGW*M(\WKD4(FU0[1#3Y^ID@@>
M^KARY=DALE]4ID[5KK]1<=_O\VRCIKR$A4X?5Z%9Y^.];@5Y75]GVFMCW[G.
M97/[>(8D>20^/[\D0J5_7LP]?[7DGF,O5T08+5LMG[X^\]+(IZIG+FXTN;/1
M7-IA?-1[A?,/!MKDKS)9<;SWL$FZ6@O.EVTZ%*@]L#0F:='0<^:>>5/K1QC6
MUUQ_&1/?YG"[??".4MU`?]_"FT4*LJ..7TO*,KWX>77)XS4S'?:V#O[H\W+C
MPI*,UYL>!DX(23><:=2VX$W!@0#=I#N;+LQH_*PJFU5A&QH_M(KV_<2UHC*]
MQR\?_N?`FYD_XNO'O]*03R^."?&<,"MA\ZZ%P_9(EKII1Z</+56J-?>;<'=]
M>L07L.1EX[1GC"YO+CAP8MC;GU,.=XS?D%OH,*?:S5U=PF"(U*0#6_S<ULI)
MN:NR/!:R,TPUEJ^O7S#<VG[U6;V)$]P6U2L-4#$(<.MO\,=P16G+J.G+L^]T
M>(0V:R[=W&ZTU+*B9NV,^Y\+VEV>-<VXZJB>8-(ZY\K292WQF1X%;C&+R_[,
MN+@C9%GITRQ'\Y%1[G_F:X=:-IQQW-7O^IAE[GYOIUI.3WR?XN84F^CA7]%K
M@U//OFV%*>>OWI[IT_P@YG9&V82>$2&^$U>5YGJ-#(A^:O`I==/:2-M8VJ;A
M*PZW/C^PR]MP;%Z?/<IC\SAOE<[$&WZZ=OO08&:0X5B30OL5)>\''V^(4TZ4
M7S*A+O?#F'$=DLOF^/7-G_#@4>!RJ6='LAH?SRUPWKVV3XO_CO6I/F&,0QG[
M'%3N:0U8NBI2-JG</6WLF7(/64O)$YO+'CLT#]TN.VJJ@_%BY3+Y_DG!R<E%
M4U0CSODL^6*ZZ^A;OP4AD*O'T%VP0%[R+N_E.]G@U%?OI%6?%-WK__;=48DC
MZJ\?;0RZ^]U%RJWI/MMBQJ&[-_L]>YBKN>5CEG/FL.:*IQ.NY0WN'^&V]NDV
MM:=:.G,F]&UU/M.>^&706/<98=?OWS'ZGI?Z<;ENYO!G[>M4+\L[U7[>/5CB
M@$Y]FLKO!]>M6;GND;/7A<+S'U0S#B;XIZ5X3GBA^;[#^?/&D8$E%P_NO5TR
MQ#OX1LXSE^97K=XM_??/6CI[8:KYJX"4"<.O.9<D'0FM'-O0;\JHJ&>>+?T&
M#@KO5Y76NEEG0$O:R[[#LP;;/N#=-?M?''7G7V9\_>.*XN)LM!.-W"&-;Q*J
M<VDZ"D>I*`Y9HJE`22@21<!?!G)%,2@!I<#_F#<934/QD/N!$!*^:1@/"#&0
M*P7R./TBWK_'__I00E.0%**A$"2/R&,!0)X(N;[[2<>?B(U\0-E)I)OB$-7I
MU-/E<HBW%Z$*/UBN@O"&-E\H-`IHZO`GS/CADIQ01'.E`7(HPMN0AD,'AD.'
MXLZ,1OK(&EE`_=;`ZP,RL(QI;&,:^8IR!%VY^`'-U13J4>%6PGN8G=3&0':<
M+#`+.E($<D7X+K0PN@V@#R?G*7#&]YWI2,J41J&[`CH-@<DQ7#&"DUCY^I&R
M_4A9!I2E4V7/(5=3\`)7Q`39J=I%R]J2LK8(_VH$$\HR<%E74X;L60F:%H-6
MRJQ"D)M%$/#]=UT1!#N"@,\C4``@64.:N#S#D1VIA06U,*E:F/RUN$(O_K6<
M]J06>X+`!@06A<#B1QB')`C".,BE*8+0GR#@<S*XJ`7(.AAY07H*Y$@!JXDD
MV!*`S::PV8+8G&ZP'0`OBJ!&05HT#`YX4!#&Y@"V!(4MP8\=C"0)=C#"O_4@
MC.T(J"D$.P72)Q$T861)0.90R!Q^9&?DYOK^YU;D3'(-AMQ1W*$K!3#\X#H)
M*)J<IX-V]-%0\",\A/$?ND@+T6ATA']"@H4"D2_R(&W&W\3@WT0Q1*I($?B&
M`GQLCVRP2+S-#^=1008B>6Q('D7BJUA:9?`O0YJS0![L=WHP`LCG:#$4<UHZ
ML&W/]C1YD6&IR[A214E.,E/V)E,J$KR&&;T_X*H2O+H9O1_BJA*\FAF]+
M^&IPMH"VXC'$`N&OE4:`%B-`W^E<RXL![>*VJD,["MD(F8+F<&Y3A)^YX\]M
M3_)I0+Z%+)Q/[B_RV9%\FI`OCHGU*T5&,$.1?-9$0BTXVZ,?OMC.<`V2(`^_
MG86!92'HB1Z\W5S*Q5M@`)%$6`;IOY"!ZC]M**--P_ED_B(?90LZD`]_+VN*
MS%P+T4,:SB<-/H@EP#;M`Y89#W)$@CWBPQ(9$#Q+N)85P!/T$=P^/3B/1OI8
M!_31I"78DJ>1R3B)^&77?_IP%4%&,TV$=]CB;6X*O&F"[+$%1`DT@-H(#77H
M`:X2/0%*&/#JIG"G\/W7B2N<&DD\*@D"!#P*#D'8%PT0PYA&5<VW6XX)LY,:
M^($IZ,>`COU`B=>.!*[\^LB?^'$D&6,2(,S`8P`'X0=SAPQG(W>D`]+:T-V)
MUD1+!Q(=8(a)]7149X-H,.IT&'_R2;?A"M"C@VT*<TY$ZW(1C\<ZL^KQ^H48*-
MC(EGXA^X^2$?3O>G8X^0@5HZQZHPZ.%(Z*5(4@[[A@GQ=Y5B,_@O%DK1T"1Z
M+.'PE^J2<Q!8C#+DQB5DS]HP*'7):=/ZTP,8"<Q<5@GH[A[GBZ2R=%\93]DH
MN2SA7VJB].H`=671)]'QR"4M5%?7:"J)>F*MX+Z!UE&;X&V)E$FD;1(")8T0
MGG7-<&^R<2$KN@JTC8%M!UF14BOI5J1_</NQ?>-R:<0KY9`YWZB&1TD+*+&"
M7DBW$%/"AFBH%Y0H92KF)/]`4.L/^:WT@W0S,;DIC^L-N6W9.'[`?7.*[B2B
MY4YKQJVPX+4";POWXT8O/J05U^D^B+*GKOE-N&=U(#YB<1$Z-W'S;Q_%O:!$
MVIA%?\]MHR">$9'/$N&P2H7,"5CSB70ZHJQ*,+=(a)K_7%.PM5H"!"I*?!8QD.
MI+_<0+X$8DU4#<K0,]#23E%Q57Y(H,\,&58$D[\DY778<JR[2B,<M^`2-@Q7
MPN,OP2^?,O0?7YVM(*D&C:MA9X)`1Y2_"WI;.(DKJ'&$?\YG0P_C\)"R`AK#
MGV%&=.<&\_AT;H_$\%I,Z0]K7I$QB6%!="F:L[.%=#*W8$T8,&R()N3$Y.9O
M'36GV)!V9#-LB.XH-.%>ZD^->P]H7'U;<,M0UM!5IM/WI:`O.WV$SHQCV
M)/<0E`BV$$[T@J,6K&5'_MA`1EG#M/H4MRTT5$C:PN2S>37P#&H0EN79*4U"
MJXKR&+`@$G%3;9DLU!9Y-$"P1WFCA26W/RU);9-)3^)5B0+T,)4=MPC/KPQD
MS[.Y@T0Z%J\N(U*'BZ"E<K5&:=J09D-*X$7I9+`/*V(_`P5;8V=ZBK(R!_`0
M&GI/?())9MUDHF$=&%_E<WPYBCD'/@O,@R5L7PZL8?"O+/[PA?8P!Z+.>3V*
MS'33R&_HZ2*\`SR7I9B3]DU$E[FLJDX/46*ZDIJIJ!/7;`!6)9]3PE;,"?E*
M175\M7<P2]AD!87;2_6&(=,)4?Z,9UD\!B3#'Y[%W8F-")2O5UJG2J0WIOR3
M:4QJ]^'.@]BR/!"9\I;@*8^R+'<F95DC(4<&FD$\,8+4H0S1<Z<=RIYETW$M
MD(PFD'+^S`FD)]Q@5>$#_8Y'=VNP3TH?9CRII/K3$Z!=]SC*TIZR6?)'%=\J
MFZI5\0[H;_+*$Q6$-\,DX-TU_M3\R/0GUB!L\<(CL`&,D%T:]1/4:#O,DZ>X
M_8EG,]*?+#0*;+/+%H9!^7M@"\:"MM`/YE?>>A;;]U9&(<.2]$8\U!Y))*)B
M,3GP+Q68!XEN+VHC/$(%03RS@HE'*$G@9I"1)(G4FX"F(NPY`WO1W'O!S"Q+
M(CX')!Q!XO%+'=;Z\CD!#(%5_3PXB!7V$!.=.R(\-HU$B(RQUMPQ5C3VC4$X
M8O02B7V)1X.+4B/T=:8SP?,!=!QQ>U/1TS28CO=TX*Y6*3XD&L^I$.M]QWQ$
MK)<.MHJ]5@]0<%L4<Y[\$%N46]8,<H/7$MVQ>5ZKSXT&?!'>I:.8D_^#LN!W
M##K+GEL+ML$>X&WR.0YTP5K8Q+4[:X@`FP7O9&'[48)RV+,S^.)$P8B/BN6U
MP&H8Q@Q<N4@,JT)BK<Z]6_A-/_BM0E&4![/P_*(*5II*(E=]T.$T@HUOF'6.
M+'@5&@>?,XCGJ8$/0%TJ,,+^%_6,H[R=-8[T<QQ/7_@>3AS1B0FT%_!(UTWG
M8-U1FMDBI'\%HAU?3R;@,PE^+VQ#+'=6+R%L&X)-K84"0=\-L&BBVNM/VJLH
M-*<G@_U-(V,@OA=A`:W&[31`05@N,CML8?VW,FVCQ@?6-H1''/X[!/QK$'SO
M8`KWK$]6#`DHA8\S6>CN@N#ZA3\_'B-&\^)$9Y#164A&9<1]@92O)PPN0%A,
ML$.LNR06CG+Y8V_^U1&".6\,8%-OB0`U,&%=TO&CJQH84`ZASCAR"A4YL*80
MNPW@2HGGEAAB0\E$XNG<^SWX"OML,&6WP1**.<-_=`:Z`@T0W^]NK)4B_=Z/
M]#L5:8^%?G>5IN)5:U8A"X]7<@+VIT]L&H\W%MQX@(W&0?4XAJN'N1LB`%8]
MG*7YO-R=W*N)(^,K0EM0"):>W'H<11<8!8&+AIR=A^/1M7^X8Z.C#G7>%;DS
M\'<'#1T1V+[QJX<,\<E.7_0D/72*A>_02@NT19\O_E!#H8@TZ3>Z0#]($RSN
M2\FXO7V=]+8DN0$O>.<*1[?CL7:4BR-`J1'0I]H\+/86EJOT`X5Y:OK:50:4
MI.J(O'(,#R!LZ&@V3V@81WOBNQ-D'%6$603?Q(_GC7[BUMY,LO8>3"1\S\+?
M9$@(>+PUJ2\,9I5%2*37A-I)S<UT]D""V[EJQ^4G@H5QP&RMO@OZFV!Y+RK6
M8GLA'"]T69(;R('U%$[NK^#9>C+)$8ZZ0_-![F">AFP?HG71N0'WWB1*ZV)F
M`96_&IW9U.@\!#`F$\_LBN!U(85X:.<0Z$H3P%7'D8*P@Q)9HZ"O(()C8^-7
M^-MY#$>-$;@F#_P&,N$^T43D_75J:,P%"?"I.H\AIKQZO$!&&-F)AF5$[(-?
M,Y$87P1<!E$!'@7G@$:#M86S'5#G/:LX[MR'OU3J)E:2L41^T#=);$M$>9=H
M>_&,1`<?H>9Y-1JUYY%&6K@6/M;3J/_H',1WK*?Q_X?OC.+8`]MC(!`>M^8!
M;0;:#70:J!%1&]<4H:0ND#V0)]!$H#2@Q4`E0,>P*H&>`'T1D`8?^'>^U9C4
MM6"JJMA4>;&I<F)3I<2F<L2FLL6F,L6F*HA-51&;:B$V54MLJH;85%VQJ=IB
M4PW%IAJ)3>TK-M58;*JYV%0SL:E68E-[,;NND=CC_]+FVCN%X9`+#ME+PB&;
M1RASX+#(F2SN.,1A.<0].)+D+$7.9*,Z1X:<R3MS.7+D3.X[<A3(69&<E<A9
MF9Q5R)G\2CI'C9R[-("EP?[0J16:B'ZZM"B<RNS\AP\/8^$7I.%KC(3S"?HY
MSM%UJ'5#]ER:Q$=X3L(5XS=SX!UWU#<D5!I^6Q]^8QM^:Q=^<P]^>PM^@P/>
MQ8]W\N+=G";<G7H8'^^^P3^3CK^CP.M%'83(_7Q]1$4M6%!C+C9^$Q3>#8[+
MXN"F!\*1,X71%R$RUY+[;08J/_/F88NY`/004>.:<O!J2`6Q6JEON-BMN`ZZ
M#'G3`'>\I`CCT+C7>HC6:D'X$JU8#@939ORF@L?[?X1?B1NU+,OL]96?:*D>
M`>3UFBO2?:=`_B>I"*]2/^.)21[16YWD<>,X9!L2%AH[BCQBM#;(4=N4S$CE
MDJT*J/.@,Y@L-DV"8^!&1]3V):P,;*HX_W#X+)2ATLD0*H65)MV*#70>P1+<
MRD3,$2F2:V+N2):[Q8DF@F<D!D]1"$^/#X\A@*<H@B<G!H\IA"?/AR<H'U,$
M3T4,GI00GB(?GJ!\4B)X"F+P)(7P%/CPF`)XDCP\=QJ%Q^#B=6XS&TSVG<VE
M85UW;C-3(((a)4MIP0-L9SYY./R<53!CPV5[XNR63_4C*.B&2L7Y1,YF\D8XN1
M3()76OHO)9,0D4SB%R63^AO).&(D8_-*2_ZE9&P1R21_43+.WT@F)48R%J^T
MQ%]*QB)(/GR227.1`(a)!)5ZQDUVAX0!.4CRU&/GY4F7^$RA*#&LB'*LM%G0RH
MQF)1K]"P9)W8&F1X5^#3@R`VO__*<['Y_9<AY+\,/@S!\8`A(JLB,%S_H:QT
MH7J$M:O$Q?XU[=+^!E7Y'Z$B,:C\>E45HU>ZD%Z5^#`$QVVZB.5K</'X+5^6
MAZ3&AR0A@"0K@J0E!DF&AZ3!AR0I@"0CTD9M,6V41[E4.A=/E0^/+8`G+X*G
M*P9/#O!T^?!4^/`$=28GTK-Z7+Q?ZUD#OAIH2-1>]/\1JK$85'Z_,>"B_A._
M,>'#%F>+AF+T*KQ=6Y</0U"O"B)XQF+PE(7P#/GPZ`)XRB)M-V'^\S&C-U\]
MG?$=?V^9,O^)=_?B0V6*0>WYCU#[B)&57Z]F8O2J*J37GGP8''+=J5=5$3QS
M,7@J0GBF0C)UX:F(X/42@Z<NA&?.AR<X?JB+C$067#S^D4B:AZ3^ETC2(OW1
MAXOT:_UAQ%>#.$^W_$>];,&'RF^1G:WNRY6U'Z#B&6`>PC-!+DD7U*4^'Y+@
MO*LDTC=68OI&30C/C`^/*8"G)A*YJ7/Q_MO(38</NU.7_'B:OXBG]3=X/7X1
M3_MO\'1^$:_'W^#U_D4\33%XV%>4N.M74ERNRQ8IC(LX*[>7F0SL)8,8-%*^
M"XF&E]!8-`7N$IHD<J(a)EM!4274*[MMG0AC+QFS8HXBVA.91!CP6K'0<4`A0*
M-!YH`E`8T$2@<*!)0).!(H`B@:*`HH%B\?.!0$E`R4"I0`-A/3P(R!7(#<@=
M:!C0<*`10)Y`(X%\@/R`1@$%``4!C08*!AH'%`HT'B@,*!QH,E`$4"10M!YU
M!P<'>]O!EZJA7(a)T9ZI.ZMXYRB"*M?#57JD^+@D!:GO(-UMH8N]4EQ</#L
M`%&8&ZAE$40FUI*='%ENF41IJ@S^I#@RW'JJ):D<U;PRTES9%#E<23B='+SL
M.:I%W65)-T!H!:.3@Q=8&!^GX,]KZIT<O(@[JL@MH\%?1H(K&RFCRE\&+TF/
M<KAEY/G+L+A2DS(R_&7P`AM;%RZ#;P!VE6%PVX-3\&=7&7Q3(Y%!W85,E*'J
MI3@*F*-*O078$UIZ@X>FPN7@4-<2]S"/@T-MFBS%&:7"CX9O[F#'\8%Z1D$/
MQ/`X.*14[$'5<PWJ6<K&'.P9.'C=JD1QPC7Y.3@$WXHHS@%6)P<?>")["/B7
MX#I?@9^#@VTW-L7Y(L7/P0/$.5GJ;NUY^-RMTLG!0Z49A^*8<_@Y>)#:KDMQ
M\&<7!P^'VU6Y'%5^#A[('9@4!W]V<0RY[<'/XEP#N2QY&L4WL0Q@L,&_*(%U
M_HFG-SQ)98%,:7!]`'+H,3JUH\>M9Q.BI,>?5!D<+JY0HWK;'7PPC5=/'VY+
M\>"'=:')*Z//U8X)MSTF/(X!MZ75B-)!-8]CSI4:]P^6NIDGM1E7`LQ)T@=[
MX'&LN!+@]@1#64V>;#C8L0:)E\)U.-CU!!X'AY0K0+9MW'JV\23`@6RGC2;J
M4I\4!X<2[R0H'>"R^)/BX%`2VV@EHG)4\LK@^[+4G6A9\N0IWH5@BQP@<.B'
M;%!_^'-`=FB$/O5>3GQX\ET_1=3+JV,`8!K028C"3P&9,*B>9H,U2@$U`[T&
M.@;"5@#M`2\]#I0$/J8(>(%`04`A0*%`D4"2X#%27-+CDCZ0(9`S4!Q0O$'7
MNZ&Q3!(P!7=/^/D?X?^8B$ZN)7B?^%@$UGH=Z`90`B2E`:T!,@(?M`:R`0H"
M.@5C6"U07V7H::`OT*ZO0*U@:!^`3L&8>EM+L*W_;=N^P@I'`=IE"C3`2+BM
M$A#`4"3!^]020U0KQ;65O_S/GRK$"O"S@*GDF9B1R!)1WZY36^DV0*#AA$)Y
M6^VZ-MF%\DJ%\>4/)4\234(QB'JN>3!Y2BX<K@+(]Z=IY!MO_,1@**1@#OXN
M.)S[?%\824LB9?#S=!AO!`I$080S#.8">[C"WZ1'$`0_[O,[<5R<,*B=_RFX
M,&0%MFP#Y6S@"O^)+S.-/`>50IX'FD;2J%K[P)F_9E$T-\#S@'S6R!&\QQJT
M1SV/^:]._]_HU`K2_]7IOSK]_T6GUER=CH%:?$!#OG`5`/\'HB$@BQ]!347X
M27+J^?-IH+5(\E0>?I(NG/R']S=%(7TQ]8=#GHA_^_1?/_E7I__J5$2G&__5
MZ2_I-/Q?2_T_M-04>N;/GS^W.;TT_2F\3136_;.!=_;Y1DEQO#G`6WEDVU-Q
MO+G`\S-:T"*.-P]X%Y[/?"^.EP4\RR:K.'&\;."-_FAQ11SO-\Q[+>,HCK<(
M>'^R;GF)X_T'>)DN^U^)X[7_Y![RPG\(_>#Q1,O1$+YOQT#B>'3NE3A,!H\G
M6H[9#8_5#0]_[2+)E!;+D^!>B9.%TPU/DL<3Q93JAM?Y<S;B>#(\GFA]LMV4
MD^N&UYDDCM?Y*)DXGF(W/*5N>,K=\%1X/-'VX:_0_\I>U+HII]X-3Z,;GF8W
M/*UN>#VZX6EWP]/A\9#002-?2^>$642(*Z?733E]'D^TG$$W/,-N>$8\'A(Z
M:-RO]\7S3'@\44S3;G@]N^&9\7A(Z*!QOX(57ZY7-^5Z=U/.HAM>GVYXEMWP
MK'@\)'30D'4W/)MN>/VZX4EIXD</))GB>%/B2I#<\$/^XGCOPNN0'WVTI3A>
MLNUO_\/>E4`U>6WK0$((`2($"!&9QS"%0<`(,0PR3X8YS%,89(P,$1DM(D6+
MJ&AQJBAJE5I$2Q5M]594KJ+5EBI:EE6K2"U2M3Z?Y5K'2T2!X-ZMNMYZ;]VU
M7ERNUO7]WSY[.OOL<_X_?V3:FH:_@;"$N9=E/+</5$#8"ETYV;4#LGT05JZ>
M+^O_9.V/$!:4LD86LV%IU544J\T))F(R0Y5*B:WBC6LAS)#V"_$;8]O+<5.A
M4>P8D4TZXZB5!,762#F,=%D[="F$9<M7DD8K.JBG,.TC%%L^9P7)\WB/$H0=
MUME,PFP?<<`Q1^87)$HTKPG"/O,Y2LHKZI>%L"[A&1+F3R>G85)U?-U1")L=
MZ"Z'Z7+<9)6<)H(Q8F[+=80V98$V*#R6PW2YZA!(7M\VLAV*@X;+3V09@@+H
MSW\E/R>WG6"Z0]A]^[GRF`W//&+D,=YM4IL\IJ>B=[L\+6_C/R#LWIRUE(=)
M":9OVB!#X/J>I`S9[=X.\39XWZ#T7J<Z0QA=;YB"Y9F<ZDP%;-Y^:KU)X3[=
M%]!EM#_+(%'S2H1)H`W&"M1>HZ??0AC74YF:M*GG#PB[R-6DZ@:<;8<PE^+%
M5,(]VQ`($]MMH/)"&@60GGIE)ZF8[:<6#:)8"W.[HH.O!P/"2H2=BFV#W7P(
MXU1U*V+Y8A$^C&+9I<I*F.V+[`V5L%RJJ(I1LC(;J8>P5O-!)6R\K-S#RBG\
MQVL@GQE&'E-61'CUA#C:8Q$/7!]<9XAH,(a)C/4K28UA$B`.M+$W4O#8L#4><4
MC7I4*1'"/M;\B8;9=]#W)HUWE+$.PM86^D[S_\WJ`(3)\#*GW7IT_C28+_2Z
M:8.#QC80MB2X>5I[9V<$A.F%5ZHPOJC[#O+USYP:%<R&GQ5VJ1#2A(,@5OBM
M2O,O`U1(YO?R,JJ8S&ZY$`D&UL%"1JLJEF=_9LO1L?HRAS>#_D#,'H1T>6QB
M2=<>;-.'L+XR$=W^9),8DNEE6T_'<JD]>@6=FF(/[E-MM3ZAQQUM\H<P\_P6
M.I9G*=.):OSYG)N0GH9B%36"=G\IA/&#EJCY[V=^!,F4Y[6H<7+W;X.P-6:[
MU4)/ZW9!6#RM1PV+7X;O5;6M:;X;(5WN%O/5F??IH$S]Y'AUS':GN`QU++:\
MLEKU!S[5S1!V@]&LCM4L)=)6]0(6XSF$/2W;K5[0X-8`V1!MKZ*!Z3FS6$_C
M2NYY$L2+4A9H8/G2HOTA*O-G]DX-L0;S$H25+3BJ(6"3/X#&<W9P96`UA&B2
MQ5"22["$>-["`XSF.B:XCB5Q;C&P-2<@_AZC<P4I%Y)9+V>L^?`/PA.(E^?C
MJ8GEDEE1AF;_5_K1D,RKY&Q-<G>]$H0=L5JEV?>9:#\D\P+1AXGY.GM.--/W
MG\[@7.EP:&":"@^!<TPG9S<JLUNKEXG%W3ALA%GSKSN-$-:>ZC8=ZX59G&?3
ML1KRIQ=-"^MM`O2X6IB>%I%KM;BK^RY#V)W<'U!>E8?V#*P_.Z&7/..[#1Y%
M$.8<K:*-]>7"A*7:[)5;`R",'710^\[6<!:$_1;MIH/9'I_FH]/91AN&XO?A
MHAR=TB\[0)FG>4TZF'U/8]?I](P<.0O)-%#?IY-^6&LAQ+L8=50'6\,;A1:Z
M'A\.G(9D.B9%Z&+Y><UJEV[M1TTZ$&]>?*<NMK=84-FMB_52U?.&=#%_MJ9S
M]`*O$L#Y8#LC7`^;T]>GB_6P-7QH5IL>-IZ,V8]Z70%.#A"63?E53TDTU`UA
MJLK6^I@NNR/C]0\9+*^';-!U.:6/K1U;K)ZB,MN4R`8;/^7>A;!\=U4##OLQ
M&(=;1HX&M1M2]D.ZK!,(#+#YIR->C&*T>;4&]4$/P#K_R.2\@:>"TT$(N^EH
M:A@7\'08DMF?'V:(S=LVXXV&F%_662L9U7:$QT`85];*".N7CGCV&?4&>:2#
M.>\[8+2M//0FA#4'NQIC=5<F*\T8B^W"H#7&<@@O7;_+N'&3T`+R64^NM4G/
MC5NI$';8.]:D=U$"'\*V+UQH@NDIJ[02Q<IUFU!,2?>@"18':]7_-L'FBF5R
MHRE6ZPQ2OS7%:O)0/M<,\]D.HP`S[*R$/Z?(#,O=C]D+S;!>XX7PH1D6/X[0
MAX7Y17E^,`OS2_*,4!3;X9K'PNIN8>XBUE:;3O!^U<W87UE8K8OV?(YBK=D*
MYI(a)NEV98FF.UG,;9;([-S<=!O>98W!NGW3+'^HFE!L/F6$VFSW]@CO6*Y[SE
M+##L#V\OB_(@>B<T']QL0RRP^)E9Z5MB<?]%.-MR6">I&I+9G)=LR:I=?`CB
M'20H6&&^5DK*L4K9N7,`PC8F?6Z%Y6Y<8+M5^](Z,"=.B/9:8?9YED=:8SW#
MARD5UNAY.7.9=>;2C5MBIT*C&+?H8VO1KL7@/%H9_ZDU5C\C3>AL+.==/'Y@
MRR.Z;*4]86-^B68R;+#ZLC?1R0:+[7Z#5!M,YAESD<TU/OD`%/?AJL4VF*_/
M^3VSP?H>OP6RMFR"YS$(.^XRU[:GX1JX9[:R+[>EU@A$X#Q*T++3;^]?!^E9
M:.5FA^D9K+S1#CN'EA,,V<4MN78;DCEWFK8]YK.U)HGV6&W](a))-EC^ER(.P3
M^[[&02MHO/+B%GOT3*!L!ZK+X^CSZ'B.J8MF4N]RP7RA"N_-Q-:<#E*80TZ)
MX3)(S_/%9QSJ"=7@GKG13L,1T\4JBN%8;BUZ#/'25$,<L;I;6K3!$3N#-R9K
M.V%^T=`3.:VZFQ<!C;?(MLYI&L);4+;*"5W[R9N<!'0/\&RTPG"3$[8G,<_;
M[(35@D_D.YPPGU64?SH+LV\+X0R*&9J.S&J@>X/GY8/J!`ZV5CTVRY^-R4QP
MWHMB+H(O9_=?\;6$,''Q^=EW$BA@C72(V.'<6<_]`<).%+<Z8WZ9*]_F/!:C
MJ7]&8Z1YS1D]"S+2=<$P5HS8Y=(%3_`>IJQ?BPN6@_&A@RY8W#6S?W/!\GJG
M&HV+]?-VV69<S/9EV6QNT;</8Z#8V@9]RCUR<Q58RT^'1L]ISO1="&'W'5+G
M8./=-EF,8J6Q>^9@_DQV7LG#L`BUU2BFR&GB8>/I:'?RNI=^4P?94"(XRC,!
M<X)`L(P_S0O6N(a);N#7.$CWC8NOF!BY,KMO9?,BUVQ>I$D6"MJ\-J&EA[9@4>
M<&UL,P7/2CH4K[@6/`K<!V'"63==T7LOFK/=,#VO,_S=TONR6)`NWQ.'W3"9
MEXO\W:__0@'/#LNH(>X%\QM*()X2.]I]<43[:@@[RRERQ\ZO6VS[W;&<8.K\
MB6)?VAAX-%R1Z/DF%J5EYX'9I^?AY.&KW-$!82?BVSW$M2PP#HRX@+G8?+](
M'FU!*=O@,YV<+,]`B_,Y$#;;R,+K^,E5NI#,%<Q97BPF+P/"!%Y^7IA].79[
MO$*%))C'O>B%Q6&6S6TOS#X[/LD;&\_$N=X[[B#S(H1]97#+&UMOV[*/^=3?
MU0)Y5VRO^F!QS_=YX=.[1Y`'^5,CR]$7X]G)K?'M$I1\`F%'2II\]YGS=T$R
MKWCN]/V$Y`D_!V&AXH>-Y^WGZI>U<1OX/,K=X"@_K(=NB3KMAZTY#/]?_;'Q
M&I-U`C",ZF,:4*K_2!ZR3S'=,@"+[:5*OP#V!1'XO"DIJPSEA;NN#\!ZC4*'
M`P$-$27@OOA/PPL!F.U$?DP@M@=:5^D0U'3Z4"AD7XA!9!!EB0.8U_5\Q6!L
M']=%B0G&>K>4O/3@(Q>U-2&LR+DW&%M7_A&I-@_#]I&=YJDA_OS1^,"\IY<:
MP3/'&U7WYZ'[CA0"'_/G:7(B?R1WU54(^UV[D$_/6'X,&N^.YTH^^LQ"["H^
MEH-:,9?XV+I9G40)<;#8Z0"-MSY\3@CFZ["%'X5@,E>'4D*9NP8W0EB=CGHH
MIR?)"QI/6]$^%)-YN8H?6O3+^EX(.Y?>&8K9OD[]?BAVEL?(a)&H5A\;.QL`Z[
M991)AK"0O+PP"F,$?-9HH]ST\)(GU0J(a)/\4!X1Z=Z10P?NY-X9CMMM.)$6W7
M[<'["`I^(1&'LNY]#HU')JZ/2`AA"B'>W(JN"/T4PST0]CQD>B3F3T]"<>2=
M;6QPO.',&5&8GGI5<Z,PF;M3+D5UW_8'ZPN%=#T*\XL::R@*BU]5X$@4]NR=
M-B%`\.`H:2^$^;`C!=AXGQ7E"#`;U"BE@NH?=X/G&DKQRP5UY[Q/0+Q]\ML$
M_N?#09_M-=XCP.RKC;(a)D.+*X'IQC']#*HC$]O=Q[HS&9%T,8,9CMROKF,9Q2
M%1%DW[+"L)C2KSM&(&QE254,IDM36$V,Z>\<\!F>IHC&&.RLQ$-N?TR;\#YX
M#VR+%SD6.\.MI\3&UL2L5X6PA.+66'YL\`^03'G!V5C,+Z<7G(W=9]AT$L)B
MZ2-QV+I9S*+%=_+N+8>PZ@KO>&P-'Z9LB,?L*PS=&]_T_,X^R`;OJJ_CL;7C
M2?2I>"PGKN>?BL=L;YIW)AZ+T3F>;`+&NY_DEX"MQ6GDH`1L7V5?%(7*W$P3
M)V`]PSV]SQ-&,G-60W[Q<F$E8OD9KN^0B/70Z1'<1,SVM+B\1*[U(RJ$#26=
M3<36L88%PXF8#0.>-DF8SQR8)4E8_);.KDT:T/JN`[+]HO/Q)$,+YT40K[^\
M+TG_1?,R"#,DSDXN.5$.[N-"+#V3]VW[#NQWL\0[D[&>J$3Q4O*0NV<XQ`LV
M"D[!_'+49VD*EM?.*JM39)<_!>]-N/O=20F\OQ;LP0;3%%.QOB=REF4J=L^T
MB,5.Q>+0&E2=BN69?T%S*I;7'VL>%F+WSLC,8T+TO,?EI#!N<(<:I.<=E0$A
M%H>?<A\(L9HU:ZY2&G8&GQ67E(;I^:#X8AHF\XKLS31A2O@12,\CI%MIGM=J
MZR#>,J%J.C8?5)W9Z9A?.#,BTFDYM^C0>+^+'Z9C\9ON/9*.W5-<5>Z5@<7O
M094H`[L_MK:0D8GI:65JF(G5B=ABNTQ,3]O,/E3F5],TYN],[6N%,/F*&?-Y
MV;P>",O-+YZ/V?>CPIKYF"Z-%LTH;S[M[/S+/)8::$.V>19F@^6L[BQUQCWP
MO+6,D9&MB/"$?'$VIF?7@@^S,3V[K#:@V)=9OV7KAO:80[HL4GZ&\EHR7F0W
M;^E:!?%4*<0<3,\TL4H.EKO<.`;*B\SVR,'VVAJ6:3F8GJ>F[<K!GG$1\7[+
MP>9TNL+]'"Q^V^((N1A&#U;)Q6RHC\&Q?>YQJ,S?O1?F8M\+^9*Q)!<[4RT)
M:<KM,V6#:YPBOR<7Z\_N6);EC5(a)]!L_\&RI*\[&SIPN)F_*Q.O%%[F?Y7;DT
M74AF=-#5?*Q.;%8+$K'K>FH@;%Y8G`CSV0U?D8CYZU`NA#'*BT5HKR%H$ZUG
M]P5!F*K3$1&V3K](ZQ9A.7@[ZF=4SP'#ZZ)^K^I("%ND<$N$QCW:<@$F,RB[
M?0$6A]7<Z@*^;L\2"&NQN550J;?S(809B14*,9]M458IQ-;4?G.W0LQGAPHB
M"[?V<\'OQ]W4$Z+CV6JM*?1H$X#/[[K.UB_">!4S+A3Y>QGN@+#*2L5BS)_.
M@:QBSK8=1I">I[R3B@?2'-(A3+?\\V),EQ)J&SI>#V=_\=?&"6!OX\27$6-Y
M1C%7%X\4E8//XNS7,18O]FJ?!V%Z]M[BR.H<<!WCL?:(L;.G\.![J"YJ?OH+
ML>>>ODC-+L%JST]6#278\]>%*NM*T&=QC'M+L%[J5%SYHNO#76V0[<?C@TL+
M:O>K2]XZ0"20"'($,D&>0'GY_?T,5D$I%J/M:@,H9B+0*L/VTPW6@C+,ONVD
MJC)LCT!/V%+V,.].%&3#/YE?E)V_4<"!>!%S.\LPGQF[G2M#>T53V7+L^V,E
M1%HY=J]GH))6CLGT*+<J#\_U_R_(!LN91>68[3=F$BMH<?[@.R;\$L,K.C<W
M@-_G2L\_4B&[0O0]Q/O&XG8%U@LO*'"HQ'+IL$-:I>3_()EILAF56#^Q/GUA
M)98O+0E#E=B:>M4EKDI;AP;*+%5HJ<)Z19E7_WWCHT)X]9N`ZY]K2'X<DR)/
MEKQO@_TWC*URXXRM<F_%X)#&&1S26S'&?I7V):-7=A)CT@]2CG\4`3OF^8_N
MW4?_YK,(DA^E_&NJM$'O1)6V[)VHTB8"5-P[F3+CU$R9M_*.-`,:S$UZL&Z)
M5,E+L6NZ1_7D/IL4-#>9UV]>F7)EG9SD2M*K*R>N?OW"%>FK`RF2J\GC5\M.
M9KQ^UXH4(X\D85"D&$0IUNM7K4QF]2E+6-0W6"1IYNNWK4QBKE>1,)5`IMP4
M]NN7KDRPX]0D;!K*)D^5,&VJ!'V&1(+*7TJ0?T.*ZA0I@TR)%/K?2J$07K^<
M`O[($"S>/\E:WS.C";+2R3;!8!)5:_AC#":1/"7I"-))-\'J&4TAROA4!Y*/
M()U\$\PNLFI-R;.73!&%C"0A03H))]B'1I-]Z.E+=K\"^2^2D2"=C!,2]E%5
M:P1C$EJ5R'^3E`3II)R0TJJD6M/SY*44%1KY+9*3()V<$Y*VTE1K.&.2KJN0
MWS))"=)).B'M^NA42WK\4MH^-?+;):M$(A'(*")07D>3\*^7'2*PB+S,7,+K
M/'R#HC&>N8=>O,Y<1XJ,$X4P]L/`8S]?+37RV\\=^5&R_-C<Z4?GSH2EML\F
M62JY\.4+L$AO3AZ$(KE.HJ+,*]K4V8/0Y`@3@1JG3ID^"%6>(!WC";KT_"&.
MK[.O\G9TG1VE*Q#>3)%)(J0F$")"$1`AR;+)8B;/(.)XL_`J4T<KR*@8942,
M)%FE1$V:0HBH:7\A2I+WTN(FYM!$\CYZ-"EY5?]&'/O5:\LDP1]/+I6Q%TE)
M_LV:]!.B!H2QET&]^/_/?\3G/Z6`0V6-#%1$1PIAM+!*-09O\"8JZ41!'OM]
M=GGI,OQ_1R:Y29,S)?^D3)@KN=)\;)@I5_:.-W1CI?3URO3^$J$K_Z>UE-HV
MO"&3.DGF6(`EOS0^MA;I_Z^RB._$DBRNR>_!DUR=,LHBO3,K^>44>O>QV&-O
MNWSGL=Z=E?)R<K_/6._.2GE91-Z%-9:'E'<>*?F]6!+]%-YKK'=GO=]8J:,L
MZK_9^Q+X*(KL_^J9R61"`B3<-Y'[C.$&08B&(]SA!(a)%)(.$,)$"X07`)BBXJ
M'HNLU\*NKNBZBHJ*J[\5CP6\_J*K+KO*BC<JNG@RW0W=_ZKNZ9EZ/=V3[IEP
M^KY\FLF;Z??JZ/=>O3JZRC5785Q<,^/B8CE,=<U5&!<7RZ$.R,50U[8QRAW6
M@$;YA#IY$G'RU6W$Z"%:7JV,BE*]E<RK983J#%8=`YM^C$`ZA]BB4XG=F?;9
MY@MRA`K3/CXF_513.Z:HF)?=Z-%9;#HK42Q&9\4;8K/NK$2Q\9T58K!:=E:B
M6"T[*Q:=?1MVV\Z*16_?1D3,SHI%=S_>SHI%N)A(9\4B7K01YZ2S$I_:N^-@
M<&F-C-$<,CU$R;J:PWF()C(I['#8P("'N@P/"2ER>Y*I,=BG&65G0FB+69<L
M5BWF'F)D<P_)J!BA&N,7S+-Y:3:]$<^6<"D9:P(CU!Y3VHT9J:7=F+)^'@I*
MJR27[C3&39*L7@,TR4!4DB8!UL$Y@\NGGD"M)UR7L9N"QE[ZV/01S<9>9TU!
M%(O1%"2'V*R;@B@VOBE(,E@MFX(H5G-38&38NBF(8H_=%,!Q7\?C5EU)Y4U!
ME)@+ORF(4ZV)#6LE\99+%JW78*'[^N#&R?IAEI/UV:AQ:4*QH/.:2*$UD6*,
M*_\:[)/3/2?L9\0^NY%?I7VZ#]7BLNC.E5BT;;/H+*)@<"D<VSVTJ_.OW3L7
MK)79IF6+%INEJJ/<L^]W[/TBG"45C#L#SN[7G4)7@\=F"014NZ@97`N/H/,5
M4)/>H9MT@=?OM)G5>4]0WG2=]X37[V8X1.??0(UX@V[$&WQ^MV,ANHQT6NX3
M>KG3D_SQ>`&K^HO7!>BRLOT9%8=$35:VW^_4_IVU6W9Z7=-".7.'I1,0&RX^
M_^U6:RISH+:Q7G,#,,S+AC/Z=]!&>KFQVFJD%]&[33U"GX1DGA,GDC!K8LK@
MM)XM/%9$$<"ZCD@PYSQG]F/,EN(3*DZ"K/:^>[<07I"V6XCX;HN83K\_AQ9M
MGUZT',-WAQ?KVOAN6!WHNR\LW\UP`<0U;OV*U=!E*N>$H^;(JF2,-O%!7K?9
M9G#9(EZ,'<%H#]!=RW1XJ9@3$3V)WNRR9I@UP=TX8\/.H)O.H#,[97#I>LX.
MB]\]2Z(a)BHWDL6.*=!43#=6BXW=%PXS#<\V$J5C`)L%\.&&<4$=N&)E'=>DC7
MK4D.;2B*Q;"A4$HV-A3%QMM09!C3$:LY=`Z$V1-;M6X1/3NVGPM[(4C<J];C
MF"9+>);^C'0<K=H?AC/>+#*<W?Z(5?ZL5GOW[T!"'L%8X^6<J[*>M#^L(Y&>
MM,[II#]MS^VT5VTOP8UW\%MX!UV*6P=A+RD>'^&W\!&ZM'C=A+U$Q_.0)K.O
M?#DX3HSC!-X9"OT8XN@C7>S:B-/)OX)E5'&PA/0BBL7Z'3%GRZC.LY%6=T';
M64_,GL/M;#744*^FFETC6FW)@S,>%_*,1S5='HE";(USN.F#LSDSW/+AXMKR
MX3QQ?F?`-Y^=V3I7)6*(8Z#%679TV&7'9CX]@//IV+I4R5K(A$?0G1O=N<SE
MV79(<2^+C#.C"<ZEG+W75<,]9&=LO#<B!JMEYSJ*U=U03Q0[OJY:A>]`Y$`7
MWCALOKJ/L#3?M/#RQ"Y$'Y9@GX0:-(-+TPJ-Z43S6!0,!#XV[2RA%C57T#AZ
M^^+<>,UY2\O%X(%DERTMC,#=M[1<_)V3&F=+>T:B[Y4UJS+ZSJOE,/IF<!D,
MODM_-O9)-<#V_^9I=FXX3YOO9WOD\[2BZMM2Y=2NXV.%9/N^\K^SLVAX.KG_
MSMH\?8.J(a)B4/AKQ[0O(,.FBBQ]>!].X0S?:2YN6Q\R2MY!_>_YF7W<_VW>9_
MWY+4"M2J<7_W`_K][(QPJ]^WAGXWZ.,AFNV/;W5_WD']=W96'?_[?_,^:<G3
M[+Q=GF9[@?,T.Q.:IP_4VLPKJW86%T\;Z=\?2I_M)VSU.WE5_[W?P.K5^-_7
MK;\JC:?9N90\O7'4?2!]=K8H3[-]\7EZ"YE6@Z?9N6(\;>1G6B@_9M?I(1`^
M$QTUX6BB#?E[7X7/S_>:3IO]KD$7A'XW^\F`B3:Y0@(JDP)Z.D)`Y5+TR]L/
M1+(SMGB:G6/"TT;^]X3RQ\ZFYW]??,TKS7AZ;-IJ4$1V9@-/L[-Z>/I(]Q&@
M"MD>T#S-SB*UHM-?U_/#SHSE?P_3;^B_L_/D^=^_799?QXHN"-W/SB#B?V=G
M:O#TR)FW`Q59VVQ;:YYF9UWS]$NMMP*58>>Q\W36R&>:\#0[6X^GV?DI/,W.
M*>%I=G853[/]]'F:G;7!TU,:U+N4I]E>UCQ]=>Y_@$ET++RM#4\G970#*OAJ
M_VU->9J=(\;3[.P-GGXK6>!:*_T<19YF9_KP-#O/A:=/=,T%)L+.(.%I=EXZ
M3T^J/KDN3[/S?7AZ_95-&O,T._.8I]EYHCS-S@'GZ>M7E8#R+^V^$=0?.QN`
MI]F94SS-SG/AZ>S&XYOS-#OOFJ?9.<\\S<ZGYFEA?G$K<'_^<B"?G4O&T^P<
M*)Z^MO=\H)_LS!R>]J3=`O2=G6/*T\WZ'LCDZ<=F]`3ZQO:BYVEVGAM/]RX:
MTHZGV7[_/,W.8^/IC^O=!^R9G2_&TU^OWP#2?Z71H08\O6!U=>`BVW;*!/'*
M>_WJ`Q?+SG+B:;7HI[8\S<X^XVEVEBM/LW.;>'I`XS+07K$S2WB:G?7.TVS/
M>I[>-;LWT)>#"SN#Y\/.`./IMN5S0#S"SL3E:79&)T^S<U5YFIUIR]/L_#&>
M7MHIIPM/L_,A>+ISQH\@?PL"7X+\2R,/M2<<V-F15G3%&[!]W==7I]DYC?S]
MQN]-^NF_LW/@^=_-[;';]KZR]MI(?V4_F-]W373VY9#>$J)!IX,"*`MW_['0
M_2!8(EI_```X7XI:)AH$TQ3`N"B`,Z6H9Z+-70A@;!0-370C$PV<,05H'"F`
MLZ4`P0?1M[?ED6FB+S'1+4PT")8I(a)#.E`,I+`1I'"N`,*(`S(\:H>P2J#4;0
M_DDFC=[8,ZV?`WF:",;++$V$C(K/%#!F=O2$E;A=5%P!F6<IKG%8G#YJ`<1]
MK(GST=Y0YBU%[G.CLQ?48:D75\+>-)I]AL9>0?M6F818LK,1TYH:^\/:B&GN
ML%H$B+@>U,=G,43%S,DS0$S.`2=B+.HC(N8>*J*`E-H6*I4;!K80$8R1@Y@/
M-)*#\0>=%$*LK"ZLL%L3;:V]T84+#XVQ005#1-JK<19P1J6Y8YBKB>_F7A&N
MMQ7_"A6Y0[IA@-]"I'G]O5'2=-JM.DH_K;(1_<Z:Y3,HH2(*%"^QVT'6"Q9#
M"NP&NQ*8L8^*WM%SDV4E17*GCPVYU!"&)J_KC]ACD_.8+^P90M+>J`(A#/E]
M(PKG;,.VZ!(ASA36]HT\9F<OMS"N-_K:.Y%H!0;;9QD)M^O'_+3/&]L/K?#$
M<+1VJ.CGQ/CU4X(a)L7-Q11^P6OJ.#QM[O<GOV)AZ#O<)+/>!IB]2W4_:"B<F6
M59L93GTSK9>CL?SS3RP7Q"=X+,1$[XK>^2S;W),$<7:@#ZJE4$5@4VLI`?:I
MYG@W".39GD2[[O^\MC8B_VQH?,?X9-_M\;PD"+M);BLR:/\&*_%G$S-?:TO@
M)(0=/(^$_OB&=K..T^L_M/OP`;UNHV6[/53NO]&K5Q]">M.K#[VVT.LF>MU,
MKWQF'SFT42,M-C,Y^>1P%YW>,XE]YI.G0Y_D1OWWIT>SMBV?>$)TJV7Z[Z^M
MUC\S0Y\M0I\'5_._LZ&0(?ZMM,H]'K\WR9?D\;*P`W2B#=\\GG8W%M*@?RG)
M)*/HYPKZ.98&O`M)(5E$?^]!Y;!7]/@>MJFWNH']-XZLHCPS*2<;Z.NFIY[J
M]WD8;%._@BRAZ1?R/'Q*E>28D"D]MPH;4F@Z)-F3%/#X]'N2`Y$<ZAK;6>VF
M9I)L=4_V,]DO9S^677FYAZ33W,!A>\O<-,HLH=<2RET[<P9IF/D0@3D<K96J
MX:FDH?7WY>4$8CR'8K*`E-,<+**R\FF-+-/R-I9^/X?^74+SQ::`>O6@)68U
MF^*DQ)'R]G58NWDTO1*RG/Y?3DLQBZ:J\U).C^`1`KY`LC9X8J4#DRC'(IK;
MHM`G*W\+&O%V"6QIH+<36@Q`REOT&/Q&QQZS=]#/F21(OQE,969=RL9-V$B$
MCWC3V?#RDO:$]#_.OF6#BR=#6;PD>E(<X1@/^/<E[R%[Z`-KELW&F1H25M-L
MO.<$]52[ZQIZ4!E>I=R/DB=,WS+=6RZHJC%>E4%]'%LYT8MTI?]G4B]13'6*
M:9:NY[WH59?D:AZ@A/[=AEY7TGN8KA<39E6YVIWE]&_F6=I3RRBDFJ7K5Z>0
MS2[3)!K?#-)L;PFEBNEWLZA?ZJ3)T=/H%+*I$BV5I81-,S2B^9JKI5E();%[
MYVI>H"B4AW942BF-:HHUS68VNH3F),/$-8YD1?$B$`@$`H%`(!`(!`*!0"`0
M"`0"@4`@$`@$`H%`(!`(!`*!0"`0"`0"@4`@$`@$`H%`(!`(!`*!0"`0"`0"
M@4`@$`@$`H%`(!`(!`*!0"`0"`0"@4`@$`@$`H%`(!`(!`*!0"`0"`0"@4`@
M$`@$`H%`(!`(!`*!0"`0"`0"@4`@$`@$`H%`(!`(!`*!0"`0"`0"@4`@$`@$
M`H%`(!`(!`*!0"`0"`0"@4`@$`@$`H%`(!`(!`*!0"`0"`0"@4`@$`@$`H%`
M(!`(!`*!0"`0"`0"@4`@$`@$`H%`(!`(!`*!0"`0"`0"@4`@$`@$`H%`(!`(
M!`*!0"`0"`0"@4`@$`@$`H%`(!`(!`*!0"`0"`0"@4`@$`@$`H%`(!`(!`*!
M0"`0"`0"@4`@$`@$`H%`(!`(!`*!0"`0"`0"@4`@$`@$`H%`(!`(!`*!0"`0
M"`0"@4`@$`@$`H%`(!`(!`*!0"`0"$0$U;3_A:COO>F$U*P()&=4;%?J[D\B
M0B#97]I.NU&[V1/-4E=CV>S)J#BJLVSV^'L$A)X!DCNL'AD]S$/&T*NJA'CH
MS5DD16.RR_XA*B;[M";FD`=DGPA>:Y:<U#!+3BIC8?=E42:#+<F2;7?M,-ON
MVHPM*<2613,:9DVV8LUL$F;-;,)8DSG6+)I^A#W%@CW8.J/BH*RQ!ULS]A03
M>Q;Q\2)2HT7,S0J+F)O%1*1:B,BB1>+%5(\2D],[HZ)`TJNN-Q-3W49,%O%#
M437-HG;GA$7MSF&B:L80E45K#(K+,(G;/"RC(AC4U6D8$Y=1B;@L$B")H$I,
MY%S!SJ:(_FB$C(I\/?.[!7\L@](+FT,+NR]D4#:%K<S$B(4Q.[$OG:_`FU&Q
MXY3&5^#U.S4NG?<$Y4W7>4]X_6XL2^??X,NHV*!;U@:?WZU9Z3+2DS(J3NBV
MD)[DC\>F=#D[DL(VM2/)'Z]!Z;*R_1D5AT1-5K;?[\2:F+SZ)!JIN@<2PNW,
M7,$_>IA`54/0[6#7B=CZ"%GU5B%D?C8:V<`;UN`&7FN-]!&C1#KL=/(@?;X!
MQ:A3/^'K(<QIJ97[:`VNU+6Y+.`/$',-1KBM]')O(*/BF*Z7AU/\U:*X?5""
MA6;NKI91,5F7L"O-GV8I(<DD)5HW=Z6%6X[T&OX:ME+\9DG1VEDCHZ*W+NEH
MNC\]IJ3D*&EF_3R:'M;UO%K^6I5*"Q#[4`+5#-7L8E,S:U&<FAWTQ6ZJ#4&H
M=1>&UMEU\^I::%V,[A83H'JBI+A1Q2XDFPKJ$F+TV8ARH(J&*%3&7YTRAGL=
M'CO]<:&*>C[4*$$N5-&`X/.;^XT6*JAW([)1"5$)40E1">V5$`ZUQ%9"VZ`.
MQU]P_(7JFN82<J"F-:9DW0"3UYAJVN=*CP#1E*,!50Y"E8-$E",S-"":H*IJ
MH:-M5R8G,BY:F:KZ-3;WJDH,OCA4-<(;GZIR_'&K*B\C$54%<A)452@K<575
M:M=V\)RUS'O5F"US[*DA;."Q@;?1/2CM3([VH!*B$MJH#92&2GB>*R$QH:Y9
M"7=7<SJ4>K'K82+`[CI!'<9AHS.AAZ&N9O2POED/]_G][('SNF=FJ6O6O;T!
M9YIC+0A5T$(%]9@'53#$8RZ#8Q5DC#Y4POB44&NSXNBD)]$J2XITTB_>9AUU
M^8+195U_$M;EB]`OZT!=QN"`$^)0";N@$OY:E3!-ETC,./M*V!65\->JA%4X
MZAE5[<Z5T$OZH`K^6E60E=57%6_*)20DLG33N1A2-6)BYL;*.+T6QNF0J<(;
M9JKP0B:?+5/4&X(Z4R)@23E_TR69UDNR_J@?/!$1`!'):XC5>5[MZHQ8Y(:7
M5^69B+-*[/+OMWCF5-_"&=+<E,_N+<_COO!C/^Z+>LN3LEF_Y1G%%K4*BK%:
MON4YWA]V:^/]MF]Y^J)'\VW8;=="Z2(LWO)\/CGLP)Y/KO0M3U^T?[814^F*
M*%^T@]9%M4H)OY;9*L7Q6YZ^:`]M(\[I>VF.[(-J._!"T3&!.238D>2/O'EA
M<%7Z@D]9P/2"3YBSLM7M.:D6J]LCW)5,$M'&UGJ2B),0>[:=-K+VL^V\E)B-
M_N[:E33Z0%*L1G]#/0>-/I06H]'?V\A%HQ_7FX[/G$B0U9V?/WL<T1&K33/O
M)2S.;1^ZZ2PU6G9M"V320Z)XZR$V8N_!$#-$B:O$"!T)F!NQ8=5K?U-21L4`
M_9%M2M+WG:B=:7&W"7$)=*D!L<O,O&?!]WKK5<-<9M;BQ8ZDH])K3RJ'?:G+
M`F&1M%4,E3K!AV8/NT&KFA:"]3Y->(TT8]*=G%W`&67$1L!IL%D'G%%LSK<5
MB6)UMZU(%+N;Q?>ZB-Z^<*/>VQ?_MB)18N+?5@2N:W8:<%I$!S;BG"[$CZLO
MM*@2IQ/5F@JDL\7-SL$*;V_O-GWTY#"K%9/EACQQ6HXWQ':^64Z4OIXSRXG2
MSPO;<A+P_`FP)L5D[>0+LW;R^4&3T)GX8[*>\W#>":HTOK3+8DR'8GYT<T/\
M<3QUR-H[\NAZLT<7H*P!G;6TDE3AMF@6(U;VK(=3PJR'4]QEF'620ZR[TMQE
M>&7-,.O*FNXRG%<KS)I7RUV&&]0-LS:HZR[#Q^J'68_5KRS#!BIM0(a)^?L.!R
M!5<A>N=$7%8"<4)<=N:)R12C-V%^JU![D-I;A5NUE&)W5Q-S3W:P>UE1+\QD
M6IA=^J.:['!;P"B6*HC?PZP8A9!S$H4P-QX:,-9WMZS2`6/0,MM;<C'EN-MI
M&&`XR=B)^6PY8)OG(<;(M,=CQ\'J:(1JU)&'<"/2-ARPA?.$1Z'M<P4;-D]X
MU-D^5ZP]"^6*MF<>?H39A@,V8Y[P2+)]KF#KY0F/%MOGBC5:H5S11LOCX)T7
M]\K$\_&H-"QS.<QR]OIQH3K`$9!?RPB(G6K5TD3>0:N]1*_V.[1A=Q=C;<XD
M5-9TU[)X_-%2>#T,#T68]-"9)*=J6<M"&:*EN=%29Q+=*FTM"]6(EAJ/#CN3
M'*]*.Y/N1,,97`[4"38L"<]%5$2:A`I/?*DET/F*ZM+8MRF64;EA60Y9JJ!-
ML;-EC,HOQ*C\UQ.NH&J=-QV^V(BMJC%6,;K+1)(-1PR+,"K/(0M:Q*_4(F*#
M)7A&(AG+?FJ"TZGV8%;D>MUPE1L=>]PA%OUQ.S,Z5E4A-KVJG!M=U`$H[HPN
MO4:8/;U&?$;'AFI"1I=7*WZC8^,W(3$-ZB9F=/D-PT:7WS!QHV,GOH3$Z2>^
MG.'93[MW`O7<W$]9I^FL]PN&5L:.NZ-8L"G`IL`"">@L8ZWBQ2=P7,B1^XUB
M,12]>8@-%?W"4_2X%Y_8SW3.Y68Z0XG#NQ(a)L-!?G;!CL.,[5G(TY5P9T]3E-
M+=2K6^AI4^(a)7YSHAN_2B-.80OH."[Z!4[JO.U*PC0H?[^HMMKYF4(X\8'CX.
M>XTZ%,JQO=+V(0%[M=U8T+&]4G]1!?9:Z8OBCNV5MDQ5:*_N=B"RT*C(FTC\
M!*+`Q:Y5O""VA@7KE1V(B3N.Q0%V%F##@HN\?\5Q=@*CA[$1QYQL'&\ONBM"
MU`8`9V_B.+YV[(P\'2;8OKMO.2EB_YIH9>]OUK#ABZAMR"YUM74:`KE\<"'7
M9L-BXQ&SPS9GS8;CQ7$[THMLO#@1V#F&&-:8I>LS[KC!B<`=-^P5TTVKXY[#
M?<L66WMCSWW;:F_E\:FM]CJ+3VVUU_GB55OM=1>?VFJO^\6KMMH;7WQJJ[U5
M&I\ZZSC9Z65-"\=J6G>(3A:=K+MMC<Z7;A3"+>PB+]BE*>6[)G%U;6.E8[&Z
M)3;<M[G:O3F08S<C?82P&0S!D&?K\-ZF4B_5I;X=O1#!UN%MB#B\#2X='CO.
M+L2:'8?#.YH<9C^:')_#"U8+^\Q@M?@='C=\NBLM,8>WKV;8=^ZKF;C#*\L(
MBRO+<!=5VL&];O)\/&(:HJ[0<,#(/$ELC!*YW/2)W1A[40ZNSZS,%B[`,=2X
M5RQ7\;S`F7F[(_82_#/Q=D?XG2]4:'+A*+3+^28<*K53+QPJM5*OA->01VMF
MO%M(>BV2A.&%!5/L*,;EJX%VE9&LL>RD_FFUSK+3YV='A6MLE>UNF$"S8L'%
MP9U(a),-=V0;17208KME?DPFFO$#QB&UH3JL.?Z3K<Q*&A1;$8AA::V,6>#O9T
M$FQ78B.^ACA>Q+5<(8&&,79L8C,VF,"32&#E=")P_Q#C#MKBGS`B-MP)A*:1
MQV@SE.R:*;Z:3,ANHQ.K+.*.C03,A=BPVFA%Y:/O-B\8Q,44N^VMRI6:X9$5
M9VS8]F+;BW",L^*1K3CT39&BSEFR7)QP!F*`2IQH%;<A5;F@*';V8N[ZJ-\8
M5\MM![O<.(]"['&.'$$"R?K#`B!LM8V$!V(<LISQN;>H-NFLMXI1;=`Y;Q6C
MFK$+_(5XL'.UG0>*/,\0J_X\G3H%^T7WEB+;&W&>#1/.Q3BV'YR+B<]^7.X*
M<=%H;-2"'7<:R[V6>#0]/HW=73LL8G?M^#66O7(?\JO'ZB>FL7L;A47M;92X
MQIYHEE&Q]:0F[D0SIQKKSJ>?G9$O_;AGQRK/;HQS<='YVNV/8C]GW7[W"^#/
M5K<__HU0+%3K'+PT&!OND@5#>JEA`1!Q'!UO/GC=Q='Q/M*%-D-9H7S@X?%`
MD-G6W.\)`"1QIA:U)\`Y.CR>E=CJH=OL"4"KS$NZD9F:5(;H;2-2S.H;YNS?
M@28_2"M&)(:)<LSVGCG"&G'L48XYFMWH>D+VB'./<LSVGCE:!([KGI/5H_9M
M0R_ZX%_5'WPOCS_L(BV\@G[_..HB_ZI[A7%>?V7Q=10/?:1.H@W6Y]#NIY;E
M-,3@>=S$%3R?6UWC>>-1,)X_7JWB923RJJ>3N3K[T6#+PW`3T-H+XK`HG\&*
M<V3DPO*E]@ZQZB8:W'$0UQQVUG6.IP_.F-'CH)!CP\=!H<2#J*HZ8"4!5@LN
MQ[!;,FYC2V=HUR*O!6MI%4Q-G]%*=1GEZ#=4A:^/]P6%>)<X:I)RH#SK_7.U
M2,?VC=]N-,[X67=XW5QL<3`UPC;5Y1N_&R.L&^UG6FW?^#T<"8P.QXZM;-_X
M)9$EGJ3RF5;;-WZW^L.>>JO?D8NU?>-W;T347K]C%VO[QF]>(.RQ\P*)QE:V
M7H>$<V'-$GL2_SS<Y,5YV'ZF-WEQ'[:?K4U>X@K;0XL]B!F5J99M8&@[?6*P
MX?2)G6I=A-,G9S\0N>!8+;@X7!"O[AD3JCAB<R&-V"!XQ%XHB:,DCHT-1TGB
M-;98RA?INI;&O_(]]CRKU60_FV<MU`K&(a)/.LV-+$T](DL.M$PAM6Q$85F9SU
MII9UR.AA231'2<8ZF=B1&?:<XK:7BZSG%!MF)<13MW2."^?4K=@PY]F`KE`=
M(DZF`[<E>6PP8>=;SS8!P37#`B`B)F>S38"[<(FXYO#:<.@9:TP?W>?ZBIW&
M7N>=B&^2PFS?N.A$/!<(LSWGLA/QV]0PZV_C>&.$&6+H`:RL&5^[4$5OC&RH
M%_:^&^HEUBY4\1LCFYN&XZC-39VV"_K#LE.OJAP,2F#Y#@X&7;B#06Y\76S_
M'?.MWS/6ICA!U96QTHS:3WGOB_0O]H&5`N[S9^\0;$XO2:!0.%N$?9[S<[;(
M7BMMWA=.LV$Z^R^^="&&(>.++T"06>\OOA=?[#37\2$I"5J-RQ>,W:8'WNHG
M-JQZ>E6]TCT!UCBF7(V8UR%+%31RX0`=HVQR3AJYL_W"4>B!1['&;.3.F@&Y
MV%71)BIEB&N)*,()8C\3-JC8OZH&%:OB38E$H`=FT44E%JXQGFD=BV98V[?4
M=K4E\SQK3W&>Q_#_WA";M?^/8G.^VC**U=UJRRHXJRQ*1'RK+:OPK+(H48FM
MMCP79Y55T1)ZFQB!W1C[J)[KA/"6^-=Q0:&AQM9,>%+?^:#]Y_-QJ!%]#&F_
M><J]JL<%&D2S7DWI`DJ'TXT]UGZ4,F?JS$?#&^>%TK.Q@RB6*AAK-U+$7L"%
M-]9NAX2TEK'%U:FW2M':Q%P=TQI[?/<\?-'$^?CNF7[1Q/WX[MEZT>0,K6DY
M^Y-)+@\FK)+I$^>L49N@Q9FJRY7-[$9<J&86@9,V;B*Z>%^=C3W(91,A(JH*
M";@VNQA"UX3=0G@F;+?@8#^D'/JD]^D&F^-QN!\2-'(GOD7G*_!F5.S0QTH*
MO,[W1=)X3U#>=)WWA-?=_D@:/SN=>8/N#C;XW.^3I,E(IX9[0C?<]*3X]DNR
M<`#Q.A-=%CLZ^I"HR<KV.]H_*2[+3T!?[29YXEUK427S918#I&YR&'NM/+0/
MTUKYV.9;Q4MC+HAW&G$7J@NU:^UJE-0^LHY4,YA8JY+S..QP1@6[=EYX=D05
MV&F459QS.ST?SHZ(K8\VL]EQ]DK/U_%5[)6>?TL)+;A^Q7!7D6`-R$7R.CV>
MG7)^GIT2N_V(=:QD#F2*;,S&VC%C8[;0>CYBABX^ZCTN=F/LQLGFU:_*-#>*
MS;GF1K%B#^6\60)HKUHVD;B=/L8[SAH;";C]N.S2Y1$NV%9@6T%<G[,52[U<
M3RK8J7E5#9=%G;J<&*J\[/$O^TP-RX#0,X0+S`BP=%Q(a)%A9WCMXA.R,6[;XY
MCYU87.LCSO4R[5\;8H=&<6_K8272\;IUA!DNEUCK[CU6^QJUMB9D_+BV)BP"
M1S'=-&9N_+;+P(_=;K]Z-,9Z.*L7E^MK3$':CD_55P($4T*O_?;2=@<</2Q`
M,QQ@&?:14:24E)-B"S&(^'`>QT)5M7PS=HMJ\YXA]B7,(K`O83=J$-?[5G:(
MO?@WY@G("=B(!1<O0/O?SH+NIX*GZ8+O#\_PQPY?HEC.]_`%Q[G/R4LNL9&`
MOC-]<W^4;*%6%`;<XAC5_<RHNWUC8K&2*I[-P(AKCC,6ML4<D++@XI!@GNR[
M+Z<B\>"I<#S8OI+T$BA((HA=$IM)P@1KSDIU&MAZS;X!(7=8*^L-B:S"@P9A
MWQ'Q8H8DDCLLDY=46<R@RUKI#V\HM=+/RVK"RW(22.CRMB>'WP/8GJS+$S1Y
M#7AY3J.+9II,;C;Q<(I^Z!R321L.VF,W2783>.C2V4Y8(;^W*RUTI)TA73!)
M=^ND]138G&0HA?0:IOR;4XC'?S<(IQ)J45;6C*1BDA^O4]?3R*X9?E/C:'JD
MKDRCHE4_R1"U!=:9@9T!V\0>.(5N%]W@%+J=SKL++>Q>K76UO:*FEYXH[72^
MO:*7]"%&FX2;*P)!9KV]^#97C`WL*&)'\>([=<V^DUD1F?*I\!B=S-AP%^E4
MY:C^1<3*_&#!][K.U:C*KG`5;HJ1R,I]=J/QKJ1#%IS2=NK[?M4OYEATG=Q$
MH`@>"?B2B`"(B+'8+"6(TY^>L2/?$A8<1QW8,YVA4;P<F%[D_1:=U4DB,9NL
M!/*GWWBV;#B!C"8P5:O#I:*X?`$B<B,VN1$1V.2Z[V[$]E`Q%GR=D=4("0A.
M#@N`B&%!>C<>WR:/B$`+2FCL\Y!I._'H<4N-@QNVI)GP$2,'=JY9Y^+&*,L"
M?C_A\VVG5U%#DSFI_@`QE]A.K71N;I`RO8:_6A2W#TJ`PTF:!&YL\FBZ/\U2
M0I))2LR!R=VU*QF8M-.IJ(')#?4<#$S:J534P.3>1E4R,)F`%ZS<G5=EE'IV
M_*V=6:"_17^+_A;];272C%.VXAP,C7N'8$<:[+"?FT#^]4Q$3UK:.'<O85.=
M[<](">RK$5?JAY67$X$K]1TV&/J#ME/6Z*UG[0(1_7[<>M9)Y*'+N#BVGG7G
M7L_.RTLQP^ZXW+E5-IV]2FCWCFLS"]T/+PXUECBZ6"*JR[-9(FK(<[505)=H
MLU#4D.AZN:@NM5T@;'_M`M%2$U@T>C@EW%`<3HDL1*VB1:-Y*6&;S4LQ+1HU
M2X]OT2A;%A'*?UF@DD6O\?B,9F&?$4HED!Q=_W6J8NFHGA+K"H0"6.J=HIX'
M2"EQ?U/IM'Y5QF5.X":U,^`/]?58,$2DSP"C1(P2P^+.UNOT"">([:3P*(B+
M,1[G5M)&1Z<Q5B5&A:R5KTI$.$>"[7&<:[7T5>O1#J#20;,XT_LKE7"@YH,E
M/%L_3Z>6//WHE)MJ\71N\B.7\70W`F'.O=G1^$VTV9^8K:":B:YCHNN:Z(<G
M3L_D:455-1NK*-HO"!Q]-$2_WV;9`/[^W<E_G,S3[U\S=#A/FZNZ@8EN:*(;
MF>C&)KJ)B6YJHIN9Z.8F.M-$7V*B6YOHR"L9.CJ8Z$XFVNQ5S)&Q^14-DXLG
MT&,3DF:B>1_*4,]$MS#1;4QT6Q/=WD1W--'9)KJ+B>YJH@U]Z5<,]>>>$+WG
MDEF7\O?OJ"&#*O(,W=F7IT]?>150^?S+RT$1OIKT41E/[YSTZE">/EFH`!,Z
ML.HS8"*9A=.!B:R;NC6?IXN*?PL>V?;9*Z[AZ:8E#P.5SK@L:S9/[[YBVD*>
M;N5OTI.G_T!>Z\73<]HM6<W339=O`"KZ3^\0D-[\Y7\NY.F.91MJ\/3JJ7^]
MG*>'-^\'3$QJ6]J'IV]9N?XJGDZ;?B.P[WK#OAS&T[-33@!_*+;X)[!_?X,7
MBWCZ>/HG@+YC:;VY//U1RV;@^3\UDX#G4:OYUV"QT>KRW_?@Z9>G/WJE%7W*
MI(\C9NNTX2^V4SJ%HS\+T;<5-@7E,7[/G@/O7QNB#?D'YT#YK>;"^\M,]/,F
M.C!/IV]8D-6/<##DCY^GR_^DQ5&@_RV7IRSE:8-_=^C^R[H/`"[CCJ5YP*7\
M?O#'H'X-_N=#_.*")-"^]9PV!]C/F$6+QO&T.=J60_DW<&F'SN#^EM7'`7O;
MT[35<IX>/OT[D/\#@PN6\?2?:G\"[&=!\C5`7ND5&<">WEU3!LK3N?Y_07M]
M;8TU4WCZSLF3`?^;LY\>R],[FUP/FMCVI3N!_#X=TH%_:KYF/_!'=Q7\!30I
MN36;`!<[9\W]@,Z>^RZPG]FESZ_CZ=^L&SR=IV^K^05P^=F-[@'Y&S]@.]#W
MQV<M6,G3[7J?!DUV:OY!X-\&]6TW@Z<?G94#[N_1X''P/#[H=#.0?W/GR6MX
M^KGNQ<#?/K[PH5*>_KRH#VBR.O9Z93Y/A^TQI+]#9XP'];.L70U0/\G]=];F
MZ1M,^FK(:S4?^I,-)OI#$]U[@4ZO:_S/<E[>DY=>`OR5<?_VT/VW]OO-$O[W
M+4FM0$AEW/]3Z/Y;IC\`0A#C]_P2_?>)"ZX$_MKX_9'0[UOR4T?QO_\W[Q,0
MWRY?]@YH+W9>^@7(7X]9JT"(>Z#69N!?<M?MF\#31OJ!A7KZ#=MXUEK]7A3Z
MO=_`ZL!>UJV_"H1()5W^.HBG-XZZ#Z2_IMJ8*WCZR7H;@?YN(=-`^^GW;K?,
M[[Z%\/DV603IN2':\'^OA&CS2ME^>?O!5X.N.`3\S?.^+XIYVI#?H%27U_?*
MMT'\M/B:5T`(/#9M-7#!=3L6@^=_>.V[!3Q]I/L($"]]W,T+[&5RO_=`_1IT
M>2@_;_0N!_5KT.^&?G^I;RX(*;]=E@_:#X/N7J;?OZG/=07\[_LZ_7X!3X^<
M>3OH`JUMM@V$\'TG/PGT]:766T$72YKR#O"G62.?`5V,=5=L&\_34Y=U`?[V
MM@[WS>/I-_M[KN;I3YL7@?:XW[1ZH/ZG-*@'XN%BSQS(a)[Z[._8_`TQT+;P,A
M?5)&-]"%>+7_-M`EFEKKEVD\7=;_&Y#^6\D"-[-)]3BU*VC//ECX`XC7%I8N
M`^4]T347Q.<9`2^0?T_R$R#>G51],F@??UCV'M#O]5<V`5V^M[Q?Y_"T-_^J
M$3S=[JKE(%Z\?E4)*/_2[AM!_35;^Q<0+XSI.+"0I_<MOA[H5W;C\:`+F=I[
M6W^>+NKU*>@/EQ0%P>_"_.)6X/[\Y4!^U_))0%_*VV7-XNEK>\\'^OFOE-M!
M_7O2;@'Z7G[9(>"_F_4]D,G3C\WH"?2M5<Z;H+V5IQP`[6'OHB&@"SRWU2'0
M7I\H&`KR_W&]^X`]=V^PLH"GOUZ_`:3_2J-#H#^S8'5UX,_;=LH$[?M[_>H#
M_W]#40;H;ZE%/X'^X2<#+RW@Z?^;6'LT3_]O^4^`?T#C,N#_ZZU=!N+K+@O:
M@GA\\9+NP%YWS>X-].7@PL[@^4SLU1$\W[;E<T![?N<UW4?R=,K0,:#]V3[^
M\C$\/7/1;/"\/RM.!?*7=LH!7?;:0S-7\'3GC!]!_A8$O@3YET8>`O'B=1/>
M!_U!@ZXH@^W?NR%ZV[@*T)\T?L]>K/^^<O(+P%Z,W[<LAO*.F>B!2R"](T2#
MP6H*\#"Y^T^%[D\W_0Z<(04(CBE`<$@!@B,*8.P4_QN\`L07*XN>!D,\SW?:
M"IY_K:O_`.RQ^94]07RXV]\3Z._#,]^?Q-/;EP\'[=4ELUX'[471U9M`^W:X
M?0YHGZXK&07BA>R&7J!_'>OWR>'IU,&/`O]_;=^>P!]>-B4=I+<JY0M@3X=+
MQX$AJ_:+[@7MQ;TUE@/_<O/BKT'_HD?!!!#O++A\"O`G';N5@WAR8NM:(%[Z
MDV\]J&^C_Y"W5.]_WUM[),AOC=[W`GNX?\`BX!\_G?HEH+^>VQ@\GW[EOP/Q
M^1\ZG<KDZ0[COP;ZT2-%`O%*AXEW@/&;9_(^!2I^WZ)"X"^'+;D/^(-B_TA0
MGSU[?(a)WZ8\498\!XRKZBU\#O+PS9-).GIPQ40'GK+_@&M,=+Z^T")C4^LSMX
M?D<;+@?^YE7_###>D]'S>5#_@]?_#;1/7_D>`?JWMDXIB`=7=6T!VI,I7=-!
M_'%\X"T@O579FX'^/7O)%X-Y>M?(WX#Z'-5R%*B/SOZ[`?\C:?Y+K.@[ENK^
MY\;+;P+UFS]R(W`Q?5IV`/'V/V?<#?J_/ZPOF\/3T\=^!NI_Y()'%_/TP+43
M@?Y=4F<WB)?>F_0"H.M-&Y[+TRN]-8`]K6L!R]OKTJ]`?H7^<T'_Z\[.:<!E
M_KEV#=">/C3D!5`?ZT?\`NSGC],(\*?;JCT&]']G]F'0__@P^\@0GBZ\[!;0
MWNP+7`7:SVDC'@7C+Y_5(;UY^G=9*T!\88P_[0CYBYT-_@3L=TV].2#>*^C]
M!1B_^D/U=.!_[V@]`\1[O7+30'R\<XX*Y%4K^@[TMX^5]@/Y:]YU,!@_6YVR
M<SU/KUO[`!A_/K[P;>!?&C0507UF+V@/QE>>G-(1Z-<UUZ2"^'KTN&G`?J^^
M[#'0'WNHO`3$$\J8AA-Y>D+M6\'SJCN_1QY/KZSV"$BO^?I<H"]/^,9UY^GG
M5VX#_._YR4">OGK9KJD\_=WE=X#^>5JS9T"\=+04QLN7I=\*_,&1OM-`?7]?
M>(@G29IO!XB7^R[;`.+;C[+^#/S5K6,#H'\VK\8;H#\P>.@`,+[8?<+]8#SS
MV9IUP?TO-R\$_:TC_@4@'NDSX@K0_JRJ?AKHW_A1WP']6KML)]#?I6,?`_7S
MY/QO`/_>)1.!_@_*W@)"KMN*.H#V_;Y1`T"(=:+[+#"_D98U!>AKZ1`5V/^5
M27M`/*H6OP+TL^/T5X&^'>^X9A%/O]:^#/1?JF>V!_*>'_@N\&\MVOP"["O8
M^AW0'OP\>!"84FSA[0/ZHVD%)<`?_:O54R#^^W#@GX$^7]Z_,:B_WQ0$0'_A
M:+UA.3Q]V8AVP'[FECS`D[3__!08#WYDP8N@/F]8.@Z4_[^='@3/Z_:V#X/V
M;&9#+Z";-GD:U/=[E[U4P-/_:[(4M,_?-?\+B%^>&G</T+=7QTX!^G"P]Q[8
MW[]D(NA?G9IZ)VCO#DQ;NXJGFX^_!G01:HR^#CR_NLW+0/LW.W,?T,]J0]J`
M^GN@\]U@O*;7B*=`O/QQ7AG0Q_YKK@/^H4O2[>!Y?]&R!\C/<X.G`O]4.[`:
M^%?O'!_P+Y_V:`/B[R=2/P3Y:4*&0_ZF!T![NVGR(R"_2Q>N`O'@B]XLT)Y?
MN;83B!\F]-T/QI<>:747R,_OZG\`TNN9+P!_4ZTA[)$%?$>!_T^>_`;PY^^-
MJ0?TM;#Q6)#?7>T_`_'BYJ9U@+]=F?H^L,\//9^"]KG;LN;`7QO^ZSB-#UC'
M2FK=$=AG=LE\T/XL[_)[\'S6+'X!R'NB^\V@?Y,T^1CHWV<WNAWXTU-K'@;Z
M,[UX"-#W35<W`OPMEJ>#"LT>^0"(SWSSUP!]KMWN&*CO.7E'`'^7?!^(GS]>
M?P+XK\=:_17HUVU=ZH+^QZ1&74#_=TC61'#_1[TK@'U.R'T:].<"[>L`?1':
M_@OT-^Y*:@CZRU<,/0[:[_M;#@?Q5/]V?P7RZEWU%6@?[ZQS`NC+'P;Y@?Y]
M'?@]:`]KS?L!]"<'%ST%XL,W!R>!]N&EZ:/`_&;RNL:P/5^V"[3WK2_;`NK_
M'PT>!_5S4X->(%Y?.68;B*\_2GD0U._<!C>`_L/\:05`_Z>,/`+Z)YTFU0//
M<_3TIT'[\'[CCJ#\=?M^`.8??E?_.>`?7DD:`_J3G=JT`./Q_UF?#^K_6,$;
MH+\YO<9!H)\?+7T=E.\_Y<-`_/"G%2N`/ZTU*AW43[U^+<'\=>KLCL`^7BY[
M#+3?.=ECP//TMIX/GO?\A<^!(:S>ZU\!_8F!9!F(CPTZ4*[W/PQZ?(B>/&@H
M>+X#^F2"^<<M5\'R?'(-[-^UGMP(Z,OB-5M!>[=U[2#0__RE^[W`WR]-OQ.,
M%S]#4D!][%J0`I[_]3/7`?W*J-XYDZ>-\NTPE?>XB>Z]3*>_'34)Q,.MQOT"
M_&>+B2^"^GYSZ&D0W]V\;C70YYU7'P/CO3<U2P+C#2UJ?`[&S_[>X2LP?[;I
MDJ]!>8_U>@3XH^]:I0#_WW#P+V!\VBA?1:A\*T;>#N(-<5`-T'\S[C^T#-9/
MD^4ZW:GK6C`?]YO1QX!];C3-?__&1%]KHC>8Z,TF>KV)OL9$KS/1:TWT-U-R
M0/LU>T(_8-_;1K\&_.NF]4?`\]DVX3;0_B\:,A#T=PS_.C=4/Z.JWP7:QZ&+
M/:"^M(a)2F`O_^ZF(8;SS7%-I#]7FC0+Q1/OD.$&\UNNI]$.^.6_%;$+]_U7H#
MB&^+IRT"Y>_=>`+0E^+EZ6`^[IUEKX'^L)H`MA;M%S)):/5O#@%H3+],U?:#
M^\:;4?&Y8EKUR]B/QV"?&V;OK>V"9L%^OB"O.'8Q:FK%8)O5;U=RAZ7!-SXZ
M:T79%4-$D["(5E3$9W8BSF<$9NO%TPPQ!TS'VNP;R+@FA[@8S)72R6=PG?!G
M5+PKL]7\C,>8T6%26)C`:"/<-II](QPVPFJC^37<`&L>M%P3*(N%)?'*8F#>
MA,EC>4I4'FLBJDK6NW.<6'%CP<:*S5E)I,KM9+'/1&6QQYBH+-:R\]4=CRR&
M@GG[A0)R6R6>3W<9,6R=92>=$VO`Z)"8OS_?\>X\IHEIMFY0KY8F`G.#H%J.
M6KK`[/FLEN>Y5^R/-7%;*'OF+47N<Z.S']-2+ZZ$O6DT^PR-?>`">ZM\*-PD
M/$S9)]$FH19L$JX']7%_#%$Q<P+;65+B1(Q%?43$3"MA=5)J6RA=Q$-:H6Q$
M['64"[&RPEBASD)[]8O.'7>`2.>PI94MC-.7SG#4B+^AB>_F_DGJ"M%NT7YA
MAW3#`+\%N[D=-DI53GF.JGK+:N^J=!Z+^CY$V0L4K_[:2XX0Q>[EV'L$M!E1
MJX*W*J4Y[[FI$H>I;SP71ZBXH31V@`(+:=IFPA!RM"J$,.24193(>;B$.#O8
M6A9YS(+CIW.TS-XQ1"LP>.O02+C?8N8\?=[8OF6%QR9.8]B^V(DQ6_2X=/?T
MDR-V"U_006//7V+/WL1CL+,=&#X[;9'Z(Y2]8&*R915FAE/?3,M_-)9O#2RE
MN2`^[8`ELYA#[,OPD\@^S;OV<PUS]X%]\C$H^ZP3^JP;^JP7^JP?^N1CT/,-
M1"N?<$[RQ^HF7;AXZQ9Q=N$C<.C`&]*GRCE_G1!"]954!?;G(>?63QIEJ8KT
MC0Y^5<@R=/)<U4O2&4C?7X4RC>&^<U4_9J2>\_R4@XD3!`*!N#BAYN3E9XXH
M7%J\9%AQ>6;WD9GY)<N6SAA8N&+1L-*YBY:6+B+3IHU;439K6MGR\LY%\]EW
M/4A>?G[NB!XCQQ$+7JOO@#S:!?7=07*(=P7Q&_N,,:^=(DSV,'IRU&F^[L&V
M/>.=N$#3&SENPL"`URK'/#X+9:B?]NDC1=I&-!=CF<@&(Y^T?+OF>B+YCL!C
M+!&:UY*0'6R(($??N6=(O:TL.QZ_-\F7Y/'ZS+M=&*+&DWED(2DF2TDF&44_
M5]#/L:24?E=(V/+B'E2.AR0E"1XAV>\);QK'KTS:P/X;1U91GIF4DTWJ=VNC
MI9[J]WD8;%._@BRAZ1=J/'UJ;07EL^/))4-H'B/YIFDS3FYM5N5EK;S<0UI0
MF=QZ%SN9>92WA"RG_Y=3B;,H-RS5+)8W;IVHTU)EDG9D$NFB[8)465[[^K5G
M9)(<_8PF43F+R!RJ7OHGJX<!/;0GE>Q-\7B2/#[;)Y5+TUNFE:N8_F_D@Y`6
M`C4<7Z#!Q#0V1*4-,Q+YX;PV[,JJR+U.-X@M]*9O&S)I;$F3CVPD_-)S7;&-
ME"[Q3DPC%001%Q[P[TO>0_;0!UXKFZE`0\(6*;*-3MX'J[GB@_XT5=681N].
M]3^+="-=Z95)1E(=F4DUI(1>Y=0?9)(RJBNE].]2:AG,,QC?E-%KJ68AF92C
MD/Y=3/.92;]=!.044VHHR0_O_=6,_EU(]9#Q#:<IC]7XBFA:G32=G$<6D+D:
M9R89J%G,7)H6LY(B2E4W<6=R_!<T%)4:5;7H3A$SJ:.;_O"#.'IN^E]N#9".
M;9_\-ULCECTLTE/;0?3'NHOHSND8T;>"^XGHHQYL]H[YUG:"OL5?=T'?*B1/
MT!N:`D'O_94(^A9_FP5]J[@[!'V+N!V"_NKS(X+^RO->^LG>N]LGZ![JH*#G
MY9"@]R8/"WI^/O/I6T[U8&EE=>O:+7-DZ<QY)?/*5V66+2DM+YU56L+^*"M=
M6EB2.9.VKD69I8OT>XHSA^93C<DO;!8J(Z'\[&]F`?F%RTHRAV>-+2XJ6M4I
M<]2\!7/GE60.+%XZMZQP41'UY6$>>I_Y;U:N4:5+%A:69!654@UGW]6(R,S4
MA))1\]CWK`Q=B<['RC=RWJPEI4M+9Y=G3BI=4I39.RN;E.20"+2_2UH=W'G+
M"X+V]Y)U1W:F[@-_>T/Y89_,I;)/YE8-I\W>?\G/BXS0!$BUL:>7WC=)8$_*
M6[\5RXFVX:S6/V_CKTEKF-WKTVB6KQJF?#(-2-44B_V5YIG=N+`V*XULH6RY
MI<N6S"M>DCFJF#4,3(<Z"_JG1Q"TD0#9LR:T9/)YC=^70]+'SUM8O)3Q9(XM
M75BX*,PI:"FFA-.NXUGBR:G)?LNBO[%QA*[5V#>!T,:%A;5G-[XB/[=SES[9
M70O(&%)`74)NZ)_.9<B91]+]>F[N">5FJS:]&RLWGG`Y6+TVTRRAGH_5!@G=
MTU;01[(B98U()Y5(]UI*9=;!GE$][1G1W-.Z:$UO;$F9QB>1$`]?MFKAVHK4
MF^!AS$SR*8^@9RB4JD^S7\FC!P[LKA:A7Y*T3Z\0T/AJT1QU]A36;N+1M6%T
ML/[/NC9\Y;W3:_ZK_JD[O8S;3^M!3U67;:3JMTTUF1A\>CJ;D^O_S*RK%95\
M0_"HD'F*72=/WQ!DUU%!ET/",.0$PBD9Z>O0OTV)2FV4ED9KLEO<IK#K;?%Z
MY7MQE5);6J1TDXJ5<=)T9;$T6=DJC5<>E<8JK]/K&/W;(T]6&LM7*]WD8F6H
M7*I<+:]1RN3-RGQYJS)9WJ@,DE<IE]+O&\IS%2+/5+Z0KJ:\TZB,:536U<I2
M::8R7IJC])!*E;K22N5G<:/RGGBKLD?<H5TL+^82V95AF%:&EF1[4%:W!S]7
M[PJ^J>X(/JT^&+Q7?2*X27TA6*+^O^`$]:/@Y>H/P39J0*RA9HI!I8_XJ3)>
M_'_*8O$YY19QEY8F2_MWXFYEA?BR<I7XOC)`_$9I(Q(U7:RG2L%.ZI?!7/7]
MX%3U0'")^GSP!O7QX$[UX>!>]?[@6^H?:=I_U/(@JT[SGJ7EO2Z1Y9DJNT[+
M<U157J`*I\I4[ZER->G4*M5_:IT:.+5133FUF?YVHZK(F]13\K7T_G6J**]4
M3\KEZL]RJ?HCY?M>GJU=3);3/!@ZX)7ZJNSJ*+57QTH-U=52=76GY%4/2K+R
MG712J27_K/20?U$FR9*R7!;4.^1JZJ-R/76_W%K]0.ZI?BL/U])EZ7\NCU'_
M*?=7]\F=U8?E9NI6N8Y:+J>J$V2?VD,F:BU9I3(%]34I2?T336>M5%^=(+54
M+Y6ZJ<G2(.UB>7%;AI^"Q[3KZ^!;Y//(a)4^33X._)%\%UY'BPD/P2S"5>L2VI
M*U8C[<1OU0'BV^H4\2EUA7B7NDW<H.X5YZH?BF.T=%GZGXA3U+^+9>H]XF9U
MG?A'M5#\/W6(^"\U6_Q1;2JFD^HB;6C%(53N+'(BN)Y\2]/Z7_!)FOZ;1`E^
MIETL+T[+T$$K0VU24ZPAI(G5A(#H%WRB(`CB*7(Z>))(P1_(R>"WFDPF6PU^
M23SB<9(D?D]2Q%](FBB3=)$(=42?4%\,"$R.6SW\5M:O'^3FY&>Y(PG*O8@D
M#Z37&'I=3>D2^OTJ\HV\@GPGSR<GZ'<GZ&\GZ#W?R7WH]YW),;DE^51NJ%U,
MEMMG6"`%57:ME[Y2[Y..J'^7_JD>D5Y7)>D?:D/Y1:H_^]1\>BV07U8WR@?5
MN^6WU,?D?ZLORY^K[\H_J!_3!IJER]+_MQP(a);\B2^G_RM^I?Y(_5.^E]U\KO
MJ//D-ZF,UZBLUZC,U]53TEOJ1])[ZCZ:WA^E+]6-TH]J$76P[&)Y<5N&WXI#
M!'9M%+L)Z\7FPC5BBK!!_)%L$H^0F\1_D.WB8^0!<3MY2KR6'!`7D`_$">1'
M\0J2*G4F;:3&Y$HI14N7I9\G99!.4@N2(?4@HCB4?"I.)V^)B\G_B=>3OXKW
MD1WBD^1.\55RB_@1N5'\F6RF:=T@-A5N$KL(OQ-SM8OEQ:T>_EN\47A3W"2\
M*%XC/"6N$/XBE@H[Q=G"[\5IPFWB.$TFDWV7.))^/U%X2"P0'A?G",_1^_XA
M+A?>%M<(1\0-`I/C5@_GR/NUJT3^%UD@?TUFRZ?)5#E=&"FW$/K*/80V\B"A
MNCQ>2)&'"9GRY4(/N;,P2&XBC).K"=-DD13*Q\A,^=]DNOR:=C%9;O/PDO2L
M=GT@/4I^EOY,JLM_)*WHU4=^@(R0'R'3Y&<TN4S^>/D%DB<_37K)C]%['J'W
M/D).2KO)1])>LE]Z6;N8++=YF"\-$MA5+'6GUR7T[QK",DDFOY&^(K^3_D4>
MD@YJ<IG\QZ1#Y&Z)ZH#T/[).$H1RJ990*K6D5U?Z]Q7:Q62YS0.K9W;]),T0
M_B/-%EZ4Y@E_H=<V^G>%=#65.UZ3R^2OE48(FZ6)PG9I&KUG!KUWAG"8_GU"
MFJ`]*W8Q66[S<%)J)+`K66XJU)<SA794#RZ36PG#Y#;"5?2:1Z_EE%XI9]&_
ML^EWV?2W;*$WI=O(G82Z<@<A26XK_"RUTBXFRVD>#)MN+YY4V-5.;*MV$B>H
M/<2-ZI7B8^HX\0-UKN@COZ'MP0YQ#'E1+">?B=M(FK2']*3/I%#ZDMPJG2(O
M2]6U=%GZ+TKUA9LDOS!=^IYD2X>)7WJ>_)?:\K/B6NH;)I'58A=20-NIH>)'
M:F_Q2;6CN$EM(4Y2F]&TF],\-`_EQ6D9#)N^7+Q=Z2WN5+J+?U6ZB']3LL0#
M2B?Q7:6C^)'2@<8Z[4.R,^G?E]#O6HCO**W$?RAMQ;WT][_0^^]5NHFW*$R.
MVV<H2RT$=OTL90O?20.$SZ51PH=4?_XI+11>DU8+^Z3KA&>D6X7'I!N$O=(&
MX26I7'A=FB.\*TT6CDC#A,^DOL(W4B?A>ZF9=C%93O-PLY:'062"-%5AUSQI
MKK)66J'<+%VG[)"V*8]+NY1]TM^4MZ0WE`^ECY2OI!^5GZ445:"Q2ZK<3:TM
M#U4;RP5J"QIOM9=O4;/D!]6N\@NT_?BWVHNV.;WE:M3V6Y*><C_279Y`NLAE
MI)-\`VDK_XEDRL^3AM2/I<LGB%].T?+-\G]*2A+\\G%24_XGJ2?_C325=Y(6
M\O649Q'I0&5THK(Z4YE95'9GFD9'FE8[VOZUDA]2F\NWJ@WDU6J&7*2FR"-I
M/GNI)Z46ZK<TEOI8$I5WI<^5`]([REYIG_*0]*BR7;I/V2S=K"R7UBNSI#(E
M7YJE7:PNW.K0#V)G19"Z*#6EGDH3J9_27KJ2QO%Y2HXT6ADN3=!D,ME#:-^A
MGS1)Z4+[#*VE$4H#:;"2*N4HI\6^R@FQE\+DN+7!GZ2F`KOJR&E"-SE(\N5/
M:1OQ)JF@OO<>^3[RN+R)O"(O(._)^>03&KM\)S<F)VD\H,A?JIY3;]"8^@D:
M6V]74T]M4ZO3O]/H=X%37]'O?#2V:4Z.RWW)$7DBC1D6DV?EWY+[Y?O)%OGO
M9(G\'IDH?T-]/Q$:R76$H-16NUA>G);!Z*?4HW%=>[&!D".V$R:)/83%XA7"
M%G&8\+`X1C@H3A*^%*<(`>DJH3W5^V'4MRZ@=G(S]:^/29<)[TB=M319VN]+
MO80GI8'"5FFTL)#>.X+:4GMI)N4MHC)F"?O%0F&7.%6X41PO+!2'"^/$`<)E
M8K;04LP4:M#8D.7#;?T?"OY)NSX/ODKCSV])$[$ZE=E!F"8.I''.5<(#8@F-
M&=8(/XG7"\VDFX4ATFW"8FK3=TM;A'](&ZG=+Z/^>Y;06%XH_""M%PY(-PGW
M2MOH/7?3>^\1FDC;A1_$6X57:=RQD\80:\29PD1QA-!=[$KCVKK"R>"/Y`B-
M[?<'']0NEA>W9;A5O$IAUP*Q5!DBWD!]VY^5:N(KRO^"7RC_#J;0OMVEZM[@
M)/61X'KU@>!#ZL[@.[1?=YKV)]N0W<%\\O?@:BU=EOZ>X#7DS\&QY-Y@.]K_
M/*W>2>^]._@@O7^=^FAPG/I_P8[JV\$DVF\\JGC$OU/?>I]RA7BM4BS.46X2
M\[6+Y<5M&0[+C55VO4S[9`_);RM;Y,>51?(=R@C:[VXOSU*\\ACJQZY4]E`;
MO5&Z5"F4.BJ]I$Y*#6JWGXJ7*7\3\[1T6?I/B_V5C\5L)4UJ2^]I0>^]1-DB
MM5:>IO<?E7HKR?(0I;,\51DK+U;*Y2W*'?)#RN/RZ\KK\O^43^3Z*KM87MR6
M@>D!NRZ71PF%<G?A6KF^\`<:NSU+?>5;\A[RL7PS[5?,)J?D_L1[JAY)/G6<
M]H5?TNPW*"]4OY8':NFR]'^2<ZA]+]#L.IW>DT'OK7ZJ`?&?RJ']EOFT7W(;
M^9>\E[PH'R$/RBJY06XNS)'[";GR1$T7V<7R8BZ#,8JR?CW;+TK_MEI4B=BX
M8BOOM627N(7<)_Z6W$&O&^EU+;U6TFL1O8KH;U>)-Y%Y8BEMW<?1'D(O>F\3
M\@2-'/:+WZ@?B.^HWXO/T9[G_2JU'+6[M$H=+A73GM`8=8747[U)ZD1[)HW4
M;5)M]3HI35TJ^>AOIY51M&=^N?2#<JGTG=)&.JY<*;VO7"V]I*RA7O_WTCWT
M*?Z6M(a)9KE1^DA4J&/$.Y5!ZKC)0'*25R'^5&.8MJ3TOE@-Q`^5RNKGA/>943
M<IIR1*ZGO"8W5YZ6VRM_DKLKM\C]E37R4&6N/%X93V5<*2^@<E8H3>6-2II\
MBR+3=([3%O2(])3R/^E9A<A_5]+E5Y1,^35ZW]O*`/G?RFCY$V6&?%P9*(M*
M.SF@5J=/[0>IG?HOJ8_ZO#1"W2G-4*^7EJ@+I>O5\=+=:E]IM]I2VJ^F2A^H
M/XG?J_\5D\E!L3&-DIJ0[\6FQ",U([6D3'()[1EUE5J3P5)[,E7*HCVG`:2]
M-(;VEHII;VDU^42\E;PN/D1[6B^1/X@?TN=RDI2+M849M'<T5!Q-/<LBH9EX
M"^UM[Q:^#[XC_!(\*)P*/D][WH_07OA=U$M>)UPBE@F=J5>^C'KJ(6)[8;R8
M+LRD<LIHCVN]>)#VZ)X@=]'HC3U_*RLX$=89?Y3N--"LH1I9)N:H<\11],I5
M-VK7*'69.$W[W$@_EVE7CHV51<MMILFM3L:(4U1V31"'JS.HW/E4QC+MFJ8N
MHM<"<;JZ4)Q*KRG:Q>YUFD8M+8UDFL;PT#4E)&<X61CZSJFL5IJL=&H?$\D*
ML8CR%Y%"<2:9*$[1Y#!Y);3WNT#,(Z7T6D&O3=J][%/_F_$Z3<^H]Q6TYSU/
MG*7Q;M*N6?2[Q=KG)OJY0KLFN):;1/E/!B=HO$S&R>!B\E5P5NA3_YO=XU;N
MR6`1Y9NH\3(97P4GTN_RM,^OZ.=)[2IR+-?0DZ:T?MG5@-9W=5KO`JU_)H?)
M4^GEI77LH?4OT'N$T+UN]:0IU0W]&AZ2,T450M^YU9-D:A=BD-H#U>6:5*\;
M4OUN&I(G4'WV4KTF5+_%X#3UF^"HT*?^-^-U6^]B<`SER]5XF8QO@KE49@_M
M\QOZ*6K7&-=RF;TO$\=HO$S&,K&'9O_ZI_XWN\=:;G3KVE.3VY#Z$R9CE%I"
MKV(Q7RT4QU'[GT*OX=2NQI#95"\7:?;#+J:7[)I("*4#]+?J])Z:]-Z:E*<Z
MY4VA,CQ:G;/K_[-W+O!15/<>_^^2%WE`0"")&W"C8$0V(=DD$)(BA`1((A)"
M$@($`GDL(1(2V&QXB`J^%5$K*FJ+M47[D%9LJT6K^"JHU8I6BK2VUOJXVENQ
MEFNOU9W13G__<\[L;!*6[.+M_7SN_63R^6;._N><_YPY<\[_/&;F'-8=*DZA
MKW6Y5F)4:U6@S.@05!DKM.5BWZ$M$V[V$ZY>,^\6:0T&,UU;8,S6RHTJK53H
M87V+4*_4:"M1IS0:Z)D(V&^D<2_72G&>`G$NJ:<`LDPEE\?8':Y>LTRL01BF
M7)`)MTGXNO*%KE3:KCGH+BV)[M32:!?JQ5LU%^W0\NE:K8@NTV:23YNESI=)
MZ[1S:3WP:>-I`_QN1GUZ"<)OT4;3I="Q73,,WE^*_7:!(^SXF&EV/<+O0KCM
M`(a)-M%\.X7\AX+]WL)U*]N[0ZA&L18>\7M$"V7NSOQWZ7('*;_1C*P5[D?0[+
M.O;";N\6,MY+]V.G8;/WHMWRF#])A-TM2(+,,'B_&_N]@LC3]P<(OQ_A]@H,
M8S\X)&2\EV[V$ZY><Z3FF+]4<-@_BP[Z9](3_B*TG_+I(;\+YSF;'O"G";VL
M_SG_:+1?'?2"?QR]B&.'_>/I5?^Y]!HXYL]4A)^7S6N+%:/=I2HNF7!GTG%_
M@9#'(@_S,7:'J]<L;[$HNY("H>\XZ@HF-@*;,)YD'73"7V6\YR\Q/H$M_,)?
M;D3!_K`>UO>1O]'XV+_2^-"_PG@'==%1^)7[9<+-82--DW?]"Q&N3(0]*B@S
MWO5/$?NCV+\K6!BQ7K;'C=I"$99U-&I3A'V6>^EF/R?7&[J'URAT5,'^5AOS
MM%JC0JLWRI$^Y4C[-<`+V[11RX-MFDQ7:)/H&K3CKX<=ND%+@;U@.\%P^6,X
M7R?1H_X4E*-QR),3Z&G_).3!R<AW><AS^<@GG&>8!N-S?[WQJ;\6]Z`:UU0%
M."ZAKB%T69BAYQE,C9YOK-8+C2WZ#.,6O<+XMEYO[-/;C$?U+<83^D[C7G"/
M?I6Q2]]H[-#7&%OU)F.]OL18J=<:5?H"Z*A2Y$4<AV>TG09S2-MB'-96&6]J
MBXR/M0K#CKB,09PF(6XRGE7&9)QK',Z9B'-_H37!W\7&^]H&XRWM*H3;*6!=
MX<;!+#?/:)6*G4I/);VI9.'J&D^RW.S3%M,!$;9"(?6POM_AV*^U)GH>_;<#
MVBIZ";_W"2I%&'9'FK\/P);O0S[BL"\)6B"K4W)YC-V1ZIVJM]!$?;T(R_HF
MZG7D@&RJ8+TXQNY(]4[4*Q%NL0CK$"R&;)62RV/L#E>OV4Z:@#`FX\6^0NAA
MW6?I'AJEKZ0$?1$-A6RH\A=I/IF@WVU(*I6>NXVA2A:N+C/?S].W&LQL?9MQ
M(a)7Z%,46_VLC1KT-^O]$X3[\%.F\7>EE_@K[#2(:?%)2_L_4NPZ5?#/]M1HG>
M"ATMBJT1Q\$+W9+;C2Z<LT/?;K0A#LV(RU*<KP9QD_%L,>IQKF:<LP/GWH@X
M;-,W&=?!SP[$[6;HN%GIBC1-O4A'R=U*3R7=K&3AZAI/LNPU(.^T(]RZ@$X)
MZ]N.8]OT9O(A/[2#C?C=(*@48=@=[OG,O-R.,M"`/,QA-PK0UT8YD7)YC-V1
MZCV"<(<0KEU0!W<=[8?LB&"].';D-,K>(5SG$<23P^X7+(9LE9++8X=.H^P]
M@3`FCZ/</058#^M^#&5OG]Y$]T'WO9#=J_Q%FD^X'I)4*CVR7F+9R77UK[LO
M$;J*Z4&$V8M\O0?Y>!?JLNOT.F.#/L]HU><8U?HLU#4E1A;V9^)W+.2?:G6H
M9U8:;VB=QFO:5N,5U!&OP%Z_K%73+V$;#VKUL)%L]]EF,HOI;+V>TG'?4O4%
ME(+XIB!OI^I?-]+UZXT,E)N)J%MS49Z+=)]1JGM1QM8;==@WXG<;Y%TXO@'^
MML#_5H3;AO#;H.=RO9HVPXYY15YG.*\PBY%&]?0(SOD0_#P(OP^&2)L3*DWX
M=ZBW[:0/?ON1WPKF]Q5CQ/N*MH"<]Y&].7ECV&].QJMW.@N&/!#%$GXWE&=1
M=\>SQ"5\R7=#*VKKG+6>#D]+U]JU/9WM+4V^]JY.9XVOJ;.UR=O:WJU^>UI\
M7=Y,FDNU-!;_\RD#Y%,Q->"O&'_R=P;^^-=8*A$2=N=3ICB>W>>X]%^,HS*&
MYGNHYO7S^Y]2,G/(QB3I.MKV[)Y(TDWJL2L]SP>E1J%(#9:,"TJ-&E]/ZV;G
M7&]7SSIG[A27L[K'TRT2(#=O<FZ^F]+)C3\7I5$YXNT6?VGJ/\OX6"9\I0<=
MD>[>UWAZUR%G93J]MVT'?K,X0<7M6)252I4BE5AR?E`J56?GNK-R\R?G3G$N
M;%JWKLOK\_1XNYT7>3R^]LXVEW,!)!W(0"[G?)4&&4$I(=.I$'^<6AF@4*1:
M&C5BSY)T<8Q3=+KRDZY"L*Q_2IKQCDGL?7=9$GQWJ[R>MJY.E[.NIL3E=.=F
MN0N<)3UM/=T^ISLG)V>^.+M;G$G>S4*0UNL*I)1]9$*2IG)`J+L;R1UC>\NV
M9&Q,!IV`K8"UL!]3SYPLBQR9CWOLAOW-`75LCCJ5CZHDP[[UE#Y8QRLCOHJ/
M^?88BAYRJFN1/DX54^FC]UGZ6\X#]H'>:$]4]_#6Z#R[F9OX,R%W/$NX3CQF
MJXG>'#4LIJRKI6>MI]-7!)O(5JX$EC!?V+V^%BU4:1\6LSFJ)EI>=W#)E:'F
MQ%0.,6,P2L2`)3$B!G$(>3"FMMW7X2F:*ZQJAK"SX9WW($+'Q?0_[\G\;HK=
M'/5D"+]6:MT9VQ!(+1E7ELBX>J%A5%Q-5=W"TMDE2*M:FB_^^L>UK\4:Z%XE
MJ;![8K,#%BM)G)TEMJ"S%R%]PDN;47&;H[RQH:[7O#=W1%LV4GYSP9*X(%L3
MWC<7EJ6([$L*&<:LY9?&6+&Y6,2&)3."8M/G2Z$:CW=#>PO2M*<;!MM9,;MV
MSLYNZR,A)VRWLQ/)[=GD\W2V>EI%K5^L:N[5JKZ7?V9=GAEH`V0+O]EDUO3<
M:I@+/YGBB!4Z7QPKP?]\Y9-+4:WZ;;4>BL.\<Z'22H;Z("B-9'EFR="@-#(_
MG^H6;9)B$?]\U7(YO1CPERJZ_<F^K39GB;>]J8/,7#PL<.=[W]4K8ZT8GR%B
MS)+HH!A7S*^=/0]QK14I/#=DWAIVTEA*7]?&^J/-LPP59V$)1S67)O316*SN
MA55G)82=:_O7":;E"UUK#.3C'GM-]$#U&]OJ4_FH2JJ)'JA^JXD>J'X;R,=]
M]E%Q`UTM6YY3QW147.^8GJQE:.[E'8L?^H;-O+N\RH`[GB7Q07FH9%9-[<*2
MTMHB9SFL4R%:7*7$KNEH<_5M:UV6HU]HZNT*Y,U+E-ZNJ,H@O;6KV[N=+5V=
M/F][<X]H0LNO$F%T?%W.IM969XBO%[NMKQ:E79HN6H[</G2I5F2&:DD&M[,S
M5$LL4[4ETX7<%6BUF6VU-%H2")NN?,G0['8%SB5;\BZRVO<92)/I2*'^]7MZ
MQ^E8I"N#[DVI2$.63`A*P]`&V4JM[*#K<8E8%@9=-U]%N?J=KJ3F-?6_YJ]V
M5?]NO[U3[[G15NI-%*G'DE%!J;?B))O97A_H[_120K9?^MG[D.V7X7U*\?!3
MV.F.,=;U2CO-$FFGS^X37[>ZEY;M-7O276/T@!;9;F%)<+O%68HRV]3B2T.>
M=*M<X\+_KYXWK%BDI5C7,DS$@B7VH%CD9KM/FA]EC=KO"](^-6JR"G%&ROA`
MJU2V"UEB"[Y:<H:XLN#8E@6T-*K8EMFG!FGI]9VSRUG1Z?-T(!V]Z!F+X1.7
MLW).7E;>U*G<Z\S-=<[/GIWM=!>(?J];V%G9SRQ5)53V?3-4ZJ>3O!?2PF4(
M27K`5Z;HCYK6S^RM2C=KG1Z0];].F5^?#SN_CE!A$U+R$WK?/Y8$WS_?ZF2T
MXP9.V::`GIDJ99L2S@F^/R4;/)T]'I>SO+VCH[NYR]OE<E8M=.YR3IN:Z\X7
M/7DRQUVD;9,]=VG;,U6*F:,SI2(EK!0RY=S/_Y_,W[>F=/7),2P)SC&UGHXB
MYZ1<YWD%.7D3G>XI^5G3"J=-<3GG-&WJ(R_,+<!USE[;U(X0N)OR[J>I$1+S
MOEMC$:9$7IN5P\+S/YWFJS/TK_VM'!-4_FRGSC$C^Z5,<^".NU3*-">,"4J9
M=2A+V6NRO5R49K9S2<INZ5KK#ER'O`JSG"P3)<$L)2SMVZ^T<MU(,0^#/",/
MACF=/QJ2%HC?Z=_MXM2^UHPEP:7!'<*:23VFM2I([6NM6!*IM2I.M:S5&!6;
M,GMLD!8UMX,H)6YRA[S7IK[E@5&(Q4K?\B%Y0?H"DT2$L'SN+#</I?:R?.6B
M=25+K%5N__T63Z:5:<>R4I_J8\=8$KD=*TX]'M!3I-+H>,)9X=LQ^FHV[.3Q
MBZPU^G"J9;-N%M?`DOJ@:X"M=?:V6].FYF05%N0/;+<Z19;+7IO=:N85JV@'
MQEG_=VV;.1HM?\EQZKYY,GSK$EX/V`S%1]AUAGV5PW(UG2%=G-JFRPS!AE;*
M/`[+M5+YLY'E,N^GG>S*7ZO#<JU0_NQDN<RG(SS;AI2U."Q7H_(WA"R7F>^C
M<'U2UNRP7,N5ORBR7%$J1#1%*W]-#LNU3/F+)LL5K4)PSUC*5CHL5X/R%T.6
M*T:%B,4]D+(5#LNU5/F+)<L5JT+$49SRU^BP7$N4OSBR7'$J!/?,I6RYPW(M
M5OZ&DN4:JD+$4[SRM\QAN>J5OWBR7.;X3P(E*'\-#LNU2/E+(,ME/KE)I$3E
M;ZG#<M4I?XEDN<QQVR1*4OZ6."Q7K?*71);+'&L=!DLI98L=EJM&^1M&EFN8
M"C&<ABM_]0[+M5#Y&TZ6:[@*D4S)RM\BA^6J5OZ2R7*9=><(&J'\U3DLUP+E
M;P19+M/VCZ21RE^MPW)5*7\CR7*-#,PC-+C]W]I"S?_%$OOKAU_?G>U(ONW.
M.)KD\N\K(a)RRZCXPGFN2Y)[DUQIVC=23GZ-I$TK+?3M(^[P8\%]C]).?J^A')
M&9T?(3DWU@&2LQ8=`EPMO$QRYN>C)'6_27).L+$VZC7'%[^[T:])1=DR/^Z6
M,QWQA(%#E![>\W1VO,\='4?F.K2A]N.2Y76=]EQBB<DRPAQ93@#Q0$J<7O0E
M<VRDV@]$YRGA0I)!>$U/]OA3]9OA]OF*!15E*^;6592)HXFFI'Q>Q?P+:P*I
M4X(]OTFZA>:@5IZ*5E$>34,[8!9E"3<_A\NB7/R5X5<6CI31%$BS*`=_A:`4
MH6;#_S1HF`+DFJ^LUZ<NAL]?31V!TA^\Y[O.LZ;QA?-TDSRU'D_G5R2FU>.I
M]+)I#?`&)M*;*2:7](EI,;/%M']KE0X;#6Z#V^`VN`UN@]O@-K@-;H/;X#:X
M#6Y?;>.>%?<8N<?&_5#NM7'/CL=H^:U\?H[.?4[N#W-/D_O0_!R`^_C<7^>^
M//?!N<_.;S7RTR_NMW/?GK\)X??(^*T:!T@'8TGV"+E7YP09Q-\#$)T#QH,)
MQ&,2AI%)LC_,[RWPS%D\C3L_#<L"_&W19)"C_+JQSR,2WW%S/YV_X><^/[_A
M/`WP\X9B\#4P'5P`9I"<-YM[L[.(Q-LE/+XQ&\PA.1]V.:@`_(;WA6`>X"\$
MN%==!180]WYE?[V&>+$%HCJPB'C!!!+/@I:0[,<W@&5@.>#GG2O`2M`$FD$+
M:`4>L`JT@=6@'?#[BFL`/[WG'C$_.^PB.=:R'GA!-\E>>0_8`'@>;1Z#X>GI
M^>VC+>!2P'WXRP'/Q[,-7`&N!%>!J\$UX%IP';@>W`"V@QO!#G`3X&<?MX"O
M@UO!3G`;R;&>.\`N<">X"]P-O@&^27(,Z![P+7`O^#;X#M@#[B,Y-O1=\#WP
M?9+SRC\`]H(?DAPS>A#L`P^!'X.?D!P?>9CD6-+/P'[P*'@,_!P\#IX@.<;T
M)'@*/`V>`<^"7X"#),>>G@//@Q?`+\&+X"7P*Y)C4H?!*^!5\&OP&C@"?D-R
MK.IU<`S\%OP.O`%^#_Y`<@SKC^`M\"?P-G@'O`O>`_\!W@<?@#^3G$__+^!#
M<!Q\!/X*/@9_`R?`?X%/P-])SKO_*?@'^`Q\#OQ``SKX`GP)_@G$XVD4?AN/
MI]EXQFZ4?W[Z8N/OF%#^01P8"N)!`DCD<3XP#`RWR=5%1X"1X`PP"HP&8T`*
M2`5IX$R;7,R7UP/@\;MQX"S@!!DV7@@$Y1^,!Q/`N39^(B37#9@(S@>3@,LF
MGQ#QLZ7)-CEVE@O<(,\FUQ<H`%/`5%`(IH$B4&R3XY33P05@ADTN0UT"9H%2
M4`9F@SE@KDVN4U`!*L&%8!ZX",P'56`!J`8+00VH!75@$:@'B\$2L!0T@&5@
M.6@$*P"O?]`$FD$+:`4>L`JTV>22*.W@8K#&)M=)6`LZ01=8!]8#+^@&/M`#
M-H"-8!/8#"X!6\"EX#)P.=@*>.SV"G`EN`I<#:X!UX+K;'(]AAO`=G`CV`%N
M`C>#6VSR;9A;P4YPFTVNVW`'V`7N!'>!N\$WP#?!;G`/^!:X%_#Z#M\!>\!]
MX'[P7?`]\'WP`YM<HWXO^*%-K@/Q(-@''@(_!C\!/P4/@T?`S\!^\*A-KA?Q
M<_`X>`(<`$^"I\#3@->1>!;\`AP$A\!SX'GP@DVN+_$B>`G\"KP,#H-7P*LV
MN>[$:^`(^`TX"EX'Q\!O;7(]BC?`[\$?P)O@C^`M\"?P-G@'O`O>L\FUG-X'
M'X`_@_\$?P$?@N/@(_!7\#'XFXV_L4/Y!Y^`OX/_!I^"?X#/P.?`#S2@@R_`
ME^"?0"SI:><Y_K$#0T`4X)4"8D`LB+/+U0#X\0"_#I((DL`P,!PD@Q%@I)V?
M`LFGMJ/!&)`"4D$:.!,X['(][+%@'#(a)+.$$&.!N<`\:#">!<D`G.`Q/!^6`2
M<($LD`TF@QR0"]P@#^2#`C`%3`6%8!HH`L7@:V`ZN`#,`#-!"9@%2D$9F`WF
M@+F@'%2`2G`AF`<N`O-!%5@`JL%"4`-J09U=MDGJL5\,EH"EH`$L`\M!(U@!
M5H(FT`Q:0"OP@%6@#:P&[>!BL`9T@+6@$W2!=6`]\()NP&M;]H`-8"/8!#:#
M2\`6NXS79=A?#K:";>`*<"6X2AW_,@0WJN,F@]O_CXT7`^-EEIQH^?*S%Z]<
MT"B>6^0))[C%OXVX9<_V0JPF>X)[">>R'QH!]QBT&$Q=W(>(D<N'B+85R:8T
M,N!GM"?A&=O;'[;;>'^376IE?65H`?M$*UCJDST.V)D3\JE8"GH:42=FP;4G
M,?X$AW#Q@7CN<22<B('#'C@_;RDA-24(3=QVY]@_A<Y*5A2_&5R+LS>+!:-D
M#XAK1INH'Y)AW=E,&K;D?PW<UX'X71G)!M":*"9P'PIF/[!T`DHX<(%Z!-P?
M0#T=%T9T4PV!_'!/%@:0J>'`T"\"MOQ=P!==E8(O:\L#M^0A;H7Y6A_J:V.@
MJ:#^5@,#J-_5!>Q;,3&"^FNL4#=`>E4P]T'FXV`A(`0.`0\PVP34J6$P8&$%
MNA-D*VB&#A3WGD#;T\!NR@7'3";X8BV8>2PHYHD!S=-`"W^(*YV!K@3U_C#]
M#@K+,&#\)X#MEP6Z&]WGQ+D'9IX%T'X6!N3P1\0-`]R_3HR04)0&AV(-*(F"
MK[AS860$7T^7"^Q+^0-30198`A'7,@SXS9-E$0+:#S*.G0%Q(S6Z?[&!+##)
M#[4U%1@")<#^9#[T$D3\X8=PGR0P#AA1;D/&9A<LW\%H4%N&`9JC0<S1\GSD
M`D9@[#-S0=(N>MD-2H%H=X_!-O2"QX1\@T%B0"%PB@2Q]6#R>A8,7RPW%6)+
MC:-@,`$`4$L!`A0`%`````@``&`5*=-$ORDYL0```!X%``P````````````@
I`+:!`````$%00RTQ.3`R+F1O8U!+!08``````0`!`#H```!CL0`````=
`
end
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
2
1
Hi, Jaakko and all:
Let me explain some fundamental aspects of H.323 protocol.
The way the H.323 protocol works is as follows:
1. Communications among the GKs (or BEs) for resolving addresses
If a terminal wants to place a call and it does not know the address of the
called party, it simply sends the query to the GK. If the said GK does not
have the answer, it simply contacts the other GK to resolve the address.
When a GK knows the answer, it sends the answer back to the originating GK,
and then the originating GK sends the reply back to the terminal.
Please note that H.323 does NOT answer the question how a GK will contact
another GK for resolving the address of the called party. There is no
standard mechanism how the GK-to-GK communications are made for resolving
the problem.
The same is also true for the BE-to-BE communication for the inter-domain
communications.
In the same token, we also defining the same process in mobile environment.
2. Efficiency of the LRQ messages
We know that LRQ messages are not very efficient. That is why we created
H.225.0 Annex G (inter-domain) message sets that are more efficient than the
LRQ.
One of the proposal has been to use those H.225.0 Annex G message sets for
the intra-domain communications instead of LRQs. However, this proposal is
yet to be accepted.
So, we can discuss what are the probable solutions can be: 1. Augment LRQs
for intra-domain 2. Augment Annex G for inter domain (if needed this can
also be used for intra-domain), and/or 3. Create new messages for
intra/inter-domain.
3. VLF and HLF communications across the domain (i.e., inter-domain)
Yes, this violates the fundamental protocol architecture of H.225.0 Annex G.
Please note that Annex G message sets basically provide the address
resolution across the administrative domains if the address of the called
party is not known in any given domain. The way this works as follows: If a
terminal dos not know an address of the called party, it contacts its GK.
The GK then contacts the BE (or another GK) if it thinks that answer is not
known in this domain. The BE then contacts the another BE of another domain
for resolving the address, and then the reply comes back following the
reverse path.
Again, the H.323 standard does NOT specify how a GK or BE knows which GK or
BE needs to be contacted for resolving the information. It simply defines
the protocol, nothing else.
If the VLFs and HLFs are allowed to by-pass the BEs, then we do NOT need the
H.225.0 Annex G BE-to-BE communications protocol at all. This VLF <-> HLF
communication becomes another parallel protocol set that can do the same job
what Annex G protocol is doing.
(By the way, an interesting thing is that if there are many VLFs and HLFs,
we may have same problems: How does a VLF knows which HLF needs to contact
unless one "hard-wired" in the protocol that there is only "one" HLF, or the
address of the HLF is "priori" known?)
We have proposals how we can address the mobility problem using the H.225.0
Annex G protocol that uses only the BEs for the inter-domain communications.
3. New terminologies
We can talk about this. We may strike the balance in the context of the IP
world. For example, 3GPP is using the mobile IP. In this context, home and
foreign (visiting [serving]/visited) are used. "Visited" can be currently
visited, previous visited, etc. (The terms like "old" and "new" in the
classical world of cellular mobility and we may avoid this.)
In addition to the above, please also see my reply embedded below [RRR].
I appreciate your response. We will also talk more in the Portland
conference. We will miss you.
Best regards,
Radhika R. Roy
AT&T
-----Original Message-----
From: Jaakko Sundquist [mailto:jaakko.sundquist@nokia.com]
Sent: Friday, August 18, 2000 8:53 AM
To: ITU-SG16(a)MAILBAG.INTEL.COM
Subject: [H.323 Mobility:] Comments on APC-1932
Hi Radhika & the rest of you mob people,
Since I'm not coming to Portland, I'll send you my comments on APC-1932
here. You can discuss these issues further with Mr. Rissanen in Portland.
** Comments on chapter 2 of APC-1932 **
The LRQ mechanism will, of course still work, but I think that for a true
global mobile system, the mechanism is VERY inefficient and thus a better
way of locating the called user must be standardized. I.e. generally a GK
has no way of knowing under which GK (or set of GKs) the called user is
located and thus in order for the LRQ mechanism to work, the LRQ must be
sent to all GKs in a domain. The domains may include many GKs, thus the LRQs
would create very much traffic also adding one GK to the domain would
necessitate all the other GKs to be informed in order for the LRQ mechanism
to work. Furthermore the originating GK does not even know whether the user
is located in the same domain, thus the GK would have to wait an arbitrarily
long time for an LCF and if the LCF does not arrive, inter-domain
communications would be needed -> how long should this time be?
[RRR] Please see my reply provided above in items 1 and 2. We will only
define the protocol, and will NOT address the implementation issues.
I really do not see, how the VLF <-> HLF communications across domain
boundaries BREAKS the H.323 model. The H.225 Annex G states that "all
inter-domain communications are executed via border elements" (not an exact
quotation), but we can either change that statement into "all inter-domain
communications must be executed by using the H.225 Annex G protocol" and use
the protocol between VLFs and HLFs or we can say that the VLF and the HLF
must always be co-located with a BE (to create elements HLF/BE and VLF/BE).
[RRR] Please see my reply provided above items 1 and 2. No, we do not need
to perform inter-domain VLF and HLF communications. Proposals are there how
we can use only the BEs for the inter-domain communications for solving the
mobility problems as specified in H.225.0 Annex G. (By the way, those who
know why Annex G has been developed using the BEs as the ONLY legitimate
entities for the inter-domain communications, they will not raise this issue
at all.)
As for the question about the "distributed" vs. "hierarchical" model. Again,
the VLF, HLF and AuF are just FUNCTIONALITIES, i.e. you can co-locate them
with each other or with a GK or a BE. Thus, if you want your GK to be able
to directly communicate with a HLF, you can add the VLF functionality to
that network element thus creating a GK/VLF (or perhaps a GK/VLF/BE), which
can communicate with the HLF. Thus the current H.323 Annex H architectural
model does not stop you from utilizing either the "distributed" or the
"hierarchical" model.
[RRR] No, picture clearly shows that VLF and HLF and other communications
scenarios. As I told before, we are NOT considering the VLF and HLF
communications per se because there are NOT considered as a part of H.323
protocol. This is called the backend server to the backend server protocol.
We will only concentrate for the GK/BE <-> VLF, GK/BE <-> HLF, and GK/BE <->
AuF protocol from the H.323 point of view. (By the way, there are many
candidate protocols for the VLF <-> HLF and HLF <-> HLF protocol, and other
questions and SGs may also be involved for this.)
These comments apply on some parts of the chapter 3 also.
** Section 2.1 **
I do not understand this at all. We are producing an enhanchement to the
H.323 protocols and in doing this, we have identified new functional
elements that are not present in the H.323 standards beforehand. So, the
interfaces may not have been a part of the H.323 standards before, but after
Annex H is done they will be.
As for the specific interfaces, I don't think we need to specify the HLF-HLF
interface (in fact, the interface is not even present in the architecture
diagram) and my opinion is that we can leave the AuF-HLF and especially the
AuF-VLF interface unspecified in the first version of the annex (thus
assuming that the AuF is co-located with the HLF).
[RRR] Please see my answers for Section 2 as stated above. If there are more
than one HLFs, as agreed, then HLF <-> HLF also needs to be defined because
we NOT considering that our protocol only the centralized architecture. So,
We will only concentrate for the GK/BE <-> VLF, GK/BE <-> HLF, and GK/BE <->
AuF protocol from the H.323 point of view.
I have proposed to use
the H.225 Annex G protocol in these interfaces, but there can, of course, be
other options as well and I would really love to see contributions utilizing
other mechanisms, such as the IETF's AAA, etc. My opinion is, however, that
we must select and standardize the use of some specific protocol to really
enable interworking between different manufacturer's products.
[RRR] No, we do not need to do so. Please see my replies above.
These comments apply on some parts of the chapter 3 also.
** Section 2.2 **
I think we have a linguistic misunderstanding here. I would like, if some
native English speaker would comment this, but I understand the terms in the
following way:
- Visited Domain, etc. should be read: "the domain currently being visited
by the user". I think that this kind of interpretation is commonly used in
technical language (or am I totally wrong?).
- Visiting Domain would sound to me like: "the domain is visiting
somewhere".
- Serving Domain is OK, and is already used in Annex H.
- Target Domain is OK. In the present draft I have used "new Domain" instead
of "target Domain". Target and source are words that are commonly used for
the new and old domain, etc. (E.g. in GSM handovers, the terms "source BTS"
and "target BTS" are used. If using the words "new" and "old" is confusing
or misleading, I ahve nothing against using target and source.
[RRR] We may need to work together. Please see my suggestions provided in
item 3.
These comments apply on some parts of the chapter 3 also.
** Chapter 3 **
Most of my comments on this chapter are already captured in the above
comments for chapter 2.
A few short notes on the other issues:
- You're right, the security check for unregistration is definitely needed.
- Also Connection Termination needs to be handled, although I imagine that
there is nothing really special about it compared to the "normal" H.323
system (that is why it isn't included in the present draft), unless
supplementary services (and perhaps some billing issues) are taken into
account.
Those are my comments, I will discuss the issues with Mr. Rissanen so that
you can have a meaningful discussion about them in Portland. Have a nice
meeting everyone!
***
Finally, just to annoy the editor of H.323 Annex K:
Ice-hockey isn't enough for us Finns anymore, now we are beating you in
football (socker) also...
Finland - Norway 3-1!!!!
------------------------------------------------
Jaakko Sundquist *
+358 50 3598281 * Audere est Facere!
jaakko.sundquist(a)nokia.com *
------------------------------------------------
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
1
0
Hi Radhika & the rest of you mob people,
Since I'm not coming to Portland, I'll send you my comments on APC-1932
here. You can discuss these issues further with Mr. Rissanen in Portland.
** Comments on chapter 2 of APC-1932 **
The LRQ mechanism will, of course still work, but I think that for a true
global mobile system, the mechanism is VERY inefficient and thus a better
way of locating the called user must be standardized. I.e. generally a GK
has no way of knowing under which GK (or set of GKs) the called user is
located and thus in order for the LRQ mechanism to work, the LRQ must be
sent to all GKs in a domain. The domains may include many GKs, thus the LRQs
would create very much traffic also adding one GK to the domain would
necessitate all the other GKs to be informed in order for the LRQ mechanism
to work. Furthermore the originating GK does not even know whether the user
is located in the same domain, thus the GK would have to wait an arbitrarily
long time for an LCF and if the LCF does not arrive, inter-domain
communications would be needed -> how long should this time be?
I really do not see, how the VLF <-> HLF communications across domain
boundaries BREAKS the H.323 model. The H.225 Annex G states that "all
inter-domain communications are executed via border elements" (not an exact
quotation), but we can either change that statement into "all inter-domain
communications must be executed by using the H.225 Annex G protocol" and use
the protocol between VLFs and HLFs or we can say that the VLF and the HLF
must always be co-located with a BE (to create elements HLF/BE and VLF/BE).
As for the question about the "distributed" vs. "hierarchical" model. Again,
the VLF, HLF and AuF are just FUNCTIONALITIES, i.e. you can co-locate them
with each other or with a GK or a BE. Thus, if you want your GK to be able
to directly communicate with a HLF, you can add the VLF functionality to
that network element thus creating a GK/VLF (or perhaps a GK/VLF/BE), which
can communicate with the HLF. Thus the current H.323 Annex H architectural
model does not stop you from utilizing either the "distributed" or the
"hierarchical" model.
These comments apply on some parts of the chapter 3 also.
** Section 2.1 **
I do not understand this at all. We are producing an enhanchement to the
H.323 protocols and in doing this, we have identified new functional
elements that are not present in the H.323 standards beforehand. So, the
interfaces may not have been a part of the H.323 standards before, but after
Annex H is done they will be.
As for the specific interfaces, I don't think we need to specify the HLF-HLF
interface (in fact, the interface is not even present in the architecture
diagram) and my opinion is that we can leave the AuF-HLF and especially the
AuF-VLF interface unspecified in the first version of the annex (thus
assuming that the AuF is co-located with the HLF). I have proposed to use
the H.225 Annex G protocol in these interfaces, but there can, of course, be
other options as well and I would really love to see contributions utilizing
other mechanisms, such as the IETF's AAA, etc. My opinion is, however, that
we must select and standardize the use of some specific protocol to really
enable interworking between different manufacturer's products.
These comments apply on some parts of the chapter 3 also.
** Section 2.2 **
I think we have a linguistic misunderstanding here. I would like, if some
native English speaker would comment this, but I understand the terms in the
following way:
- Visited Domain, etc. should be read: "the domain currently being visited
by the user". I think that this kind of interpretation is commonly used in
technical language (or am I totally wrong?).
- Visiting Domain would sound to me like: "the domain is visiting
somewhere".
- Serving Domain is OK, and is already used in Annex H.
- Target Domain is OK. In the present draft I have used "new Domain" instead
of "target Domain". Target and source are words that are commonly used for
the new and old domain, etc. (E.g. in GSM handovers, the terms "source BTS"
and "target BTS" are used. If using the words "new" and "old" is confusing
or misleading, I ahve nothing against using target and source.
These comments apply on some parts of the chapter 3 also.
** Chapter 3 **
Most of my comments on this chapter are already captured in the above
comments for chapter 2.
A few short notes on the other issues:
- You're right, the security check for unregistration is definitely needed.
- Also Connection Termination needs to be handled, although I imagine that
there is nothing really special about it compared to the "normal" H.323
system (that is why it isn't included in the present draft), unless
supplementary services (and perhaps some billing issues) are taken into
account.
Those are my comments, I will discuss the issues with Mr. Rissanen so that
you can have a meaningful discussion about them in Portland. Have a nice
meeting everyone!
***
Finally, just to annoy the editor of H.323 Annex K:
Ice-hockey isn't enough for us Finns anymore, now we are beating you in
football (socker) also...
Finland - Norway 3-1!!!!
------------------------------------------------
Jaakko Sundquist *
+358 50 3598281 * Audere est Facere!
jaakko.sundquist(a)nokia.com *
------------------------------------------------
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
1
0
Dear Mr. Skjaeran,
At 19:45 +0200 00/08/17, Espen Skj $B%; (Bran (ETO) wrote:
>Dear Mr Okubo and Mr. Skran,
>
>Unfortunately I can not attend to the upcoming meeting in Portland.
>I am sorry fopr this confict, as the editor of H.323 Annex K I really
>should have attended, especially as there now is an contribution with some
>rightful comments to it.
>
>I have made an updated version of H.323 Annex K with the obvious errors
>that APC-1934 points out corrected. Can you provide me a TD number for
>this?
TD-13 has been allocated to your document and it is now available at
/0008_Por directory of the ftp site.
>Mr. Christian Groves will present this (and comment further the APC-1934)
>for me at the meeting.
>As he is mostly covering the H.248 work, we would be glad if this could be
>discussed in the joint session.
Best regards,
Sakae OKUBO
***********************************************************
Waseda Research Center
Telecommunications Advancement Organization of Japan (TAO)
5th Floor, Nishi-Waseda Bldg.
1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo
169-0051 Japan
Tel: +81 3 5286 3830 (to be transferred)
+81 3 3204 8194 (direct)
Fax: +81 3 5287 7287
e-mail: okubo(a)giti.or.jp
***********************************************************
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
1
0
Could I ask a big favor? Please don't copy all the emails on this thread
in your responses. Please snip off most of the thread before sending.
The copied material is exceeding new content by an order of magnitude. The
last email on the thread was 39,000 bytes.
With a best case packet size of 1500 bytes, that is 26 packets injected
into the network (67 packets with a packet size of 576 - Windows default).
With 419 people subscribed to the list, that is about 10,000 packets
injected into the Internet for each of these emails sent.
Thanks, :-)
Chip
-------------------------------------------------------------------
Chip Sharp Consulting Engineering
Cisco Systems
Reality - Love it or Change it.
http://www.netaid.org
-------------------------------------------------------------------
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
2
1
I have uploaded the document TD-12.zip (Liaison statement to IETF AVT Group
for Unequal Error Protection) to the Incoming directory of the AVC-site.
Juergen Pandel
----------------------------------------------------------------------------
--
Dr.-Ing. Juergen Pandel
Siemens-AG Corporate Technologies
ZT IK 2
D-81730 Munich
Phone: ++49 89 636 42071
Fax: ++49 89 636 52393
e-mail: juergen.pandel(a)mchp.siemens.de
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
1
0
Hi, James:
It is good that you are interested about QOS.
Now there are couple of things: Application vs. Network. People know about
the monolithic network layer QOS like RSVP, DiffServ, MPLS, ATM QOS, etc.
However, with the advent of the network independent multimedia (audio,
video, data) application like H.323 where the requirements of the QOS need
to be satisfied at the application layer for its audio codecs, video codecs,
and data (T.120) from end-to-end basis no matter whether there is a single
network, multiple networks, or a single network that implements different
network layer QOS schemes in different domains, the situation is a little
bit different. H.323 QOS Annex N has been opened to deal with this.
The issues like echo and others are also the function of some performance
parameters and when the needs of those performance parameters are satisfied,
the echo and other criteria are also satisfied. That is, the application
level performance parameters are the bottom line, and these parameters are
sent end-to-end basis. The end-to-end performance parameters remain the
same. In turn, these parameters may also be translated to the lower network
layer QOS parameters to have them deal with those in the network layer as
appropriate.
In H.323, there are H.225.0 (RAS, Q.931) and H.245 where QOS signaling
messages are needed to deal with on end-to-end basis.
Similar is the case with SIP, although SIP much thinner compared to that of
H.323. However, SIP also uses SDP. With some indirect hooks in SIP along
with extension of SDP to support QOS, many of those QOS issues can be
addressed.
However, in Q.13 of SG16 where H.323 is addressed, the interworking issues
between the PSTN and packet-switching networks (e.g., IP, ATM) is not
addressed.
Any contributions will be welcome. In the meantime, please look into
Appendix of H.323 QOS Annex N where end-to-end H.323 QOS has been addressed.
If there are any questions, please let us know, and we would be glad to
answer your questions.
Best regards,
Radhika R. Roy
AT&T
-----Original Message-----
From: James Dam [mailto:James.Dam@CWO.COM.AU]
Sent: Wednesday, August 16, 2000 10:05 PM
To: ITU-SG16(a)MAILBAG.INTEL.COM
Subject: Re: H.323 QOS
Hi Mike,
I am new to this forum, i may be wrong, the following is my offering:
>From a carrier/operator point of view , we need standard body addressing the
end-to-end QoS problems, Echo issues....
We need specs/standards to discuss with other carrier/operator....right now.
So much debate between SIP and H.323 but no real progress on this subject
end-to-end QoS.
As far as i know to date , H.323 is probably in front in many aspects. Why
not going beyond the call.
Best Regards
James Dam
+61 29342 8195
James.Dam(a)cwo.com.au
----------
From: Mike Buckley
Reply To: Mailing list for parties associated with ITU-T Study Group
16
Sent: Wednesday, 16 August 2000 11:55 PM
To: ITU-SG16(a)MAILBAG.INTEL.COM
Subject: Re: H.323 QOS
Hi Radhika,
The problem is I don't see a framework in SG16 for how H.323 will be
used in
the real world to solve the general end to end QoS problem.
It's no good putting fields in protocols without some idea of how
they are
going to be used in practice. This doesn't mean you want to tie down the
implementer to go down one particular route but you have to have an
architecture in mind when you develop a protocol. The IETFs architecture is
clear - it is the Internet. I would submit that this is not necessarily
what we are doing in SG16.
Let's define the framework of the problem we are going to solve.
Much of it
has been covered in this recent thread. But it needs documenting and
general agreement.
TIPHON is developing a framework for VoIP. SG16 is developing a
suite of
protocols for VoIP. Both need an agreed architecture. The early
discussions on architecture in TIPHON lead to gateway decomposition and the
birth of H.248. The logical conclusion of this work has lead to the present
TIPHON architecture. Just as the gateway decomposition exercise lead to a
set of requirements and architecture for H.248, the latest TIPHON
architecture leads to a set of requirements for QoS control and a QoS
architecture. See DTS 5003. I want to get general agreement on the problem
we are solving and the roadmap of how we are going to get there. Then we
can start on the ASN.1.
We should not be considering SIP/SDP in SG16 - neither of these
protocols
are needed if we do our job right with H.323. Policy in the IETF is
exclusively transport domain policy. Again it has nothing to do with the
policies we may adopt on application level QoS. As far as I understand the
MCI work this is all about the Internet and makes no recognition of H.323 or
other applications. So lets not get lead astray by orthogonal activities to
those we are engaged on. Our job is application level QoS and defining the
services we need from the transport domain to deliver it. We are not
solving problems in the transport domain. But we can draw up a set of
requirements for an interface and feed this to the IETF.
Let's get our problem statement clear and our TORs and architecture
documented and agreed.
Mike
Mike Buckley
+44-1457-877718 (T)
+44-1457-877721 (F)
mikebuckley(a)44comms.com
----- Original Message -----
From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM>
To: <ITU-SG16(a)MAILBAG.INTEL.COM>
Sent: Wednesday, August 16, 2000 2:08 PM
Subject: Re: H.323 QOS
Hi, Mike:
Our aim is to extend H.323 for supporting QOS. The framework is
already
there.
Please see H.323 and H.225.0 Annex G specs how the general framework
is done
in the context of H.323.
Again, we are dealing with Q.13/16 and TIPHON exceeds the charter of
Q.13/16. It goes beyond H.323 and involves almost all SGs of ITU-T and IETF
that are dealing with QOS.
I understand what TIPHON is trying to do and TIPHON is just NOT
limited to
Q.13/16. The same problem has been in the IETF when TIPHON presented its QOS
model for extending SIP. It appears that it exceeds the charter of SIP.
Please note that people are NOT saying that TIPHON's work is NOT
needed. All
they are saying: Let us divide the work in different items and each item
will have its place in the corresponding WGs. For example, policy will be
addressed in the Policy WG, if any particular messages in SIP needs to be
extended to support QOS following the SIP charter that work may be addressed
in the SIP WG, if any particular item needs to extend in SDP to support QOS
that work needs to be done in the MMUSIC.
From end-to-end call point of view, people will need SIP, SDP,
Policy,
Security, Billing, firewalls, NATs, and others. when the standards in all
areas are done, people just use them. This is the second step. I have also
been working with Joon Maeng of VTEL in this area because Joon submitted a
contribution in Q.13/16 last Feb'99 meeting. We are waiting to complete the
H.323 QOS work first.
You can also see an IETF contribution from MCI WorldCom how the
interdomain
QOS can be used by SIP using Policy, Security, etc. This work is dependent
on the standard work of Policy WG, and others. Again, this contribution for
supporting interdomain QOS by SIP using Policy, etc. does NOT need any
additional standard work is SIP, it is, rather, an implementation that shows
how an end-to-end call can use all those standards including QOS that have
been developed in different WGs.
Appendix of H.323 QOS Annex N has the general framework. Now you can
go
through those items and please let us know where you like to see changes and
why.
Best regards,
Radhika R. Roy
AT&T
-----Original Message-----
From: Mike Buckley [ mailto:mikebuckley@44COMMS.COM
<mailto:mikebuckley@44COMMS.COM> ]
Sent: Tuesday, August 15, 2000 7:51 PM
To: ITU-SG16(a)MAILBAG.INTEL.COM
Subject: Re: H.323 QOS
Radhika,
My aim here is to come up with a general QoS framework in H.323 that
will
handle all these situatioins not just special cases. I think we agree on
this.
I would be reluctant to solve a special case without an idea of how
we are
going to solve the general case. This can only lead to backward
compatibility issues.
I believe the TIPHON approach is totally general. However I agree
it need
some new interfaces defining.
Mike
Mike Buckley
+44-1457-877718 (T)
+44-1457-877721 (F)
mikebuckley(a)44comms.com
----- Original Message -----
From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM>
To: <ITU-SG16(a)MAILBAG.INTEL.COM>
Sent: Tuesday, August 15, 2000 8:21 PM
Subject: Re: H.323 QOS
Hi, Mike:
Yes, you are right that NATs and firewalls problems are yet to be
solved
with complete satisfaction from address translation point of view. This may
be a separate work item all by itself.
I do not think that we will bring H.245 to address those problems.
In fact,
I have not seen any proposal in that direction.
We have to separate our works step by step.
I would not like to include those general problems as a part of
H.323 OQS
for now. Let a separate group or annexes deal with those special problems so
that we can use those solutions for QOS as well, if needed.
Best regards,
Radhika R. Roy
AT&T
-----Original Message-----
From: Mike Buckley [ mailto:mikebuckley@44COMMS.COM
<mailto:mikebuckley@44COMMS.COM> ]
Sent: Tuesday, August 15, 2000 1:13 PM
To: ITU-SG16(a)MAILBAG.INTEL.COM
Subject: Re: H.323 QOS
Hi Radhika,
This model is only valid I think when you have end to end address
transparency as in the Internet. When different transport network domains
are present this doesn't necessarily work. NATs and firewalls will mean
that IP addresses and port numbers in different domains will be different
for the same media stream. Terminating IP and port numbers may well be
different at each end of the call. This is one reason why H.323 will not
work through firewalls. To fix this gatekeepers will have to perform a
mediating function with the H.323 domain and the transport domains. This
mediation will not be via H.245.
SIP has the same problems by the way.
Mike
Mike Buckley
+44-1457-877718 (T)
+44-1457-877721 (F)
mikebuckley(a)44comms.com
----- Original Message -----
From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM>
To: <ITU-SG16(a)MAILBAG.INTEL.COM>
Sent: Tuesday, August 15, 2000 2:15 PM
Subject: Re: H.323 QOS
Hi, Mike:
Just for information, H.245 does many things. As I indicated
earlier, one of
the most important things of H.245 is the opening and closing of the logical
channels that binds the application layer's logical connection abstractions
to all transport network connections (e.g., ATM, etc).
So, this is the fundamental mission of H.245 to provide the
continuity
between the application layer and the lower layer in a transport independent
way using the universal abstractions. These abstractions can be for anything
that we can think of.
Hope this helps.
Best regards,
Radhika R. Roy
AT&T
-----Original Message-----
From: Mike Buckley [ mailto:mikebuckley@44COMMS.COM
<mailto:mikebuckley@44COMMS.COM> ]
Sent: Tuesday, August 15, 2000 8:22 AM
To: ITU-SG16(a)MAILBAG.INTEL.COM
Subject: Re: H.323 QOS
Hi Radhika,
This use of H.245 as a bridging mechanism is where I have
difficulties. The
original intenmt behind H.245 was media control and negociation. Transport
mechanisms should not be signalled in H.245 or elsewhere in the application.
This is entirely the business of the transport network provider.
Unfortunately I will not be present in Portland, however, I am happy
to
continue this productive dialogue on the list with a view to providing a new
draft in the next few weeks.
Regards,
Mike
Mike Buckley
+44-1457-877718 (T)
+44-1457-877721 (F)
mikebuckley(a)44comms.com
----- Original Message -----
From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM>
To: <ITU-SG16(a)MAILBAG.INTEL.COM>
Sent: Monday, August 14, 2000 7:29 PM
Subject: Re: H.323 QOS
Hi, Mike:
I guess that we have agreement on the fundamental basis. However, I
have
problems when you translate this in signaling terms. As I have explained
earlier that we are following the exiting framework of H.323 which is the
application layer, and H.323 is transported over one or different transport
networks. H.323 uses H.245 as a common mechanism that helps to transports
the abstraction of H.323 application signaling messages over any networks
(e.g., IP, ATM, etc).
You may look to the H.245 spec very carefully instead of making any
generalized statement.
H.245 provides the bridging between the application layer and
transport
layer mechanism. For example, H.245's OLC abstraction is the link for ATM
network layer logical connection as well as for other transport networks.
In the same token, H.323 QOS abstraction may also provide link to
the lower
transport layer QOS signaling mechanisms (e.g., RSVP, DiffServ, MPLS, ATM
QOS, etc), if needed. H.323 DOES support RSVP and ATM QOS now.
Please also see my reply embedded in you email [RRR].
Again, I would suggest to bring contributions explaining the
solution and we
will go from there. In absence of your contributions, I would suggest to
provide comments on Appendix of H.323 QOS Annex N. We can then answer your
questions step by step.
Best regards,
Radhika R. Roy
AT&T
-----Original Message-----
From: Mike Buckley [ mailto:mikebuckley@44COMMS.COM
<mailto:mikebuckley@44COMMS.COM> ]
Sent: Monday, August 14, 2000 12:56 PM
To: ITU-SG16(a)MAILBAG.INTEL.COM
Subject: Re: H.323 QOS
Radhika,
>However, this is only good for the single network. For example,
>end-to-end RSVP or end-to-end ATM QOS.
>If there are multiple networks or if a single IP network implements
RSVP in
>one domain, DiffServ in another domain, and MPLS in another domain, there
is
>no transparent H.323 QOS signaling mechanism that is universal on
end-to-end
>basis so that it can be mapped over the RSVP, DiffServ, MPLS, ATM QOS, etc
>transparently
This is the nub of the problem and I am afraid why this approach is
flawed.
[RRR] I am NOT afraid of anything. Rather we are solving all problems
including the above as well. No one should be afraid of anything. The only
thing that I can suggest is to bring contributions. We will go from there.
Please remember that H.323 QOS supports RSVP and ATM QOS and we MUST provide
backward compatibility. We will be waiting to see contributions from you to
prove your points whether things are flawed or not. Please read Appnedix of
H.323 QOS Annex N very carefully along with exiting H.323 and H.245
standard how they support H.323 QOS for RSVP and ATM QOS.
>We have shown how the H.323 QOS can
>be mapped over the RSVP, DiffServ, ATM QOS, etc. if needed.
This mapping must be done within the transport plane not by the
application.
All the application needs to specify are the entries in your Table 1. i.e
delay, jitter. packet loss and peak bit rate (the latter parameter for
policy enforcement and resource reservation).
[RRR] Please see my generalized clarification how H.245 provides translation
between H.323 signaling schemes over the lower layer transport networks
(e.g., IP, ATM, etc). The mechanism already exists in H.323 and this is the
beauty of the transport independent H.323 application. Now there are two
separate things: one is what the calling side of the application demands and
what the called side of the application agrees on. This is called
negotiation capability (e.g., choosing a particular type codec that has a
certain bandwidth, jitter, and other requirements). How the choosing
criteria is determined, the H.323 application is NOT aware of those things.
It may depend on many criteria (e.g., policy, bandwidth, type of network
[e.g., IP, ATM], pricing, security, personal preferences, etc.), but H.323
is not involved. These are separate issues and we are NOT addressing at the
H.323 layer.
I am still not clkear how you propose to signal these parameters to
the
transport plane.
[RRR] It is NOT new in H.323, and this mechanism already exits. Please see
the support of RSVP and ATM QOS in H.323/H.245 spec. We are not inventing
anything NEW here. Then, if you read Appendix of H.323 QOS Annex N very
carefully, you will find how it happening (whether you call it as transport
plane or something else, it does not matter).
I think we are getting loser to a common understanding.
Mike
Mike Buckley
+44-1457-877718 (T)
+44-1457-877721 (F)
mikebuckley(a)44comms.com
----- Original Message -----
From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM>
To: <ITU-SG16(a)MAILBAG.INTEL.COM>
Sent: Monday, August 14, 2000 2:37 PM
Subject: Re: H.323 QOS
Hi, Bob:
I agree completely agree with you.
In fact, we are all trying to achieve the same goal. For example,
H.323 does
supports QOS today via H.245. You can easily see that RSVP and ATM QOS are
supported using H.245. The beauty of this approach is that H.245 is still
transport independent. All we have done here is: the abstraction of H.245
has been used to support the RSVP and ATM QOS to implement the network layer
QOS. However, this is only good for the single network. For example,
end-to-end RSVP or end-to-end ATM QOS.
If there are multiple networks or if a single IP network implements
RSVP in
one domain, DiffServ in another domain, and MPLS in another domain, there is
no transparent H.323 QOS signaling mechanism that is universal on end-to-end
basis so that it can be mapped over the RSVP, DiffServ, MPLS, ATM QOS, etc
transparently.
In Appendix of H.323 Annex N, we have done the same. We have the
abstraction
of H.323 QOS in the application layer. We have shown how the H.323 QOS can
be mapped over the RSVP, DiffServ, ATM QOS, etc. if needed. It also provides
the backward compatibility with the existing H.323 standard. However, we
have done only for the pre-call setup signaling part. We have not done the
call setup part yet. In the call setup part, we will include H.245 in a
similar way what H.323 is supporting RSVP and ATM QOS today in a monolithic
network.
I appreciate your email.
Best regards,
Radhika R. Roy
AT&T
> -----Original Message-----
> From: Callaghan, Robert [SMTP:Robert.Callaghan@icn.siemens.com]
> Sent: Monday, August 14, 2000 9:08 AM
> To: Roy, Radhika R, ALCOO
> Cc: 'Mailing list for parties associated with ITU-T Study Group 16'
> Subject: RE: H.323 QOS
>
> Roy,
>
> In my view, the network, as a minimum, needs only provide transport.
> H.323
> is an application using this transport and is not different from any other
> application being transported. Any application may request a desired
> quality of service that the network may grant based on policies, service
> level agreements, and availability. Each data connection used by an
> application may request a different QOS. Most likely H.323 is such an
> application as needing an enhanced QOS. This simple case should work.
> This
> is all that is required.
>
> In addition to transport, the network may optionally provide other
> additional services. These services may include application layer
> routing.
> These optional services should be configured and indicated independently
> from the basic transport QOS.
>
> It is correct that H.323, as an application, is (mostly) transport
> independent. However, the interface between the application and the
> transport layer is not transport independent. The interface specification
> used to request a given QOS is totally dependant on the standards body
> that
> specified the transport layer; and for this there has been little or no
> coordination.
>
> Because transport QOS over IP is based on IETF specifications, it is
> necessary that the interface used to request a given QOS conform to the
> appropriate IETF specification. If such an interface specification is not
> available, that input might be provided to the appropriate IETF body as to
> the requirements.
>
> I can see the endpoints negotiating the desired QOS base on need, price,
> and
> other considerations. For me, this is the limit to the application layer
> involvement in QOS negotiation. At this point, the application
> negotiations
> with the transport provider as to the desired and available QOS. It is up
> to the transport provider to arrange for the end-to-end QOS. (Again, it
> is
> not necessary for the transport network to know that H.323 is involved in
> the transported data. In fact it may be encrypted in order to mask the
> presence of voice transport.)
>
> For me, this is simple.
>
> Bob
>
> ------------------------------------------------------------------
> Robert Callaghan
> Siemens Enterprise Networks
> Tel: +1.561.923.1756 Fax: +1.561.923.1403
> Email: Robert.Callaghan(a)ICN.Siemens.com
> ------------------------------------------------------------------
>
> -----Original Message-----
> From: Roy, Radhika R, ALCOO [ mailto:rrroy@ATT.COM
<mailto:rrroy@ATT.COM> ]
> Sent: Friday, August 11, 2000 7:59 AM
> To: ITU-SG16(a)mailbag.cps.intel.com
> Subject: Re: H.323 QOS
>
> Hi, Mike:
>
> Let me try again.
>
> What is the reference point of H.323 QOS? Is it not H.323? If it is so,
> what
> do we mean by H.323?
>
> The answer is: Audio (different codecs), Video (different codecs), and
> Data
> (T.120 applications) that are used by H.323.
>
> What are the QOS/performance characteristics of audio, video, and data
> from
> the application point of view that is generated by audio codecs, video
> codecs, and data (T.120) applications?
>
> These QOS/performance characteristics come from the SOURCE codecs and data
> applications. Per transport independent H.323 specifications, an enduser
> express their QOS/performance requirements on end-to-end basis purely from
> application point of view irrespective of the transport network (e.g., IP,
> ATM, etc.).
>
> Moreover, H.323 is meant for the packet network, not for any
> circuit-switched network like PSTN or ISDN.
>
> Let us NOT go beyond this before we start debating transport layer QOS or
> service provider requirements. These are NOT the concern of H.323. H.323
> is
> the transport independent application.
>
> H.323v2/v3/v4 has also provided mechanisms how RSVP and ATM QOS can be
> used
> for H.323 audio, video, and data. So, H.323 QOS that will be defined in
> H.323 Annex N MUST provide mapping for the backward compatibility. It is a
> requirement that MUST be met per the norm of ITU-T.
>
> So, what is left for mapping? Mapping is simply a by-product of the above
> requirement. Mapping is simply a table, nothing else.
>
> Did I miss anything?
>
> Best regards,
> Radhika R. Roy
> AT&T
>
> -----Original Message-----
> From: Mike Buckley [ mailto:mikebuckley@44COMMS.COM
<mailto:mikebuckley@44COMMS.COM> ]
> Sent: Thursday, August 10, 2000 10:19 PM
> To: ITU-SG16(a)MAILBAG.INTEL.COM
> Subject: Re: H.323 QOS
>
>
> Radhika,
>
> Thanks for the input which I welcome as I will unfortunately not be
> present
> at Portland.
>
> Let me ask a few questions and make a few comments hopefully with the
> intent
> of opening up the debate.
>
> 1. I am not sure I understand your concept of a mapping table between the
> H.323 QOS and the transport layer QoS. My understanding is that QoS is on
> three levels:
>
> a) that specified from a service point of view between the user and
> service
> provider (e.g PSTN quality, conference quality etc) This is the domain of
> the speech experts and can be characterised by Listener Speech Quaklity
> (MOS), end to end delay, and absolute category rating, R.
>
> b) application specific parameters, (e.g. equipment delays, codec choice
> and performance, codec frame size, packetisation arrangements, jitter
> buffer
> design, overall packet loss etc.) Optimisation of all these will
> determine
> what can be delivered in a).
>
> c) transport parameters for a given choice of application parameters.
> This
> boils down only to three parameters as far as I cna see: tranport network
> delay, packet delay variation in the transport network and packet loss in
> the transport network. Again these parameters will determine the results
> in
> a) for a given choice of the parameters in b). These parameters are
> generic
> from the perspective of the transport network. i.e the transport network
> does not need to know the details of the application.
>
> So the sequence of cause and effect and control is:
>
> a) User requests QoS class from service provider,
> b) Service provider determines application specific parameters in
> conjunction with users equipment and other service providers,
> c) Service provider requests required delay, delay variation and packet
> loss from network provider.
>
> I see no need for mapping here. The only QoS info flows within the
> application are specific to the application and those between the
> application (service provider) and the transport network are generic. i.e.
> delay, jitter and packet loss. Have I missed something?
>
> 2. The issue of bit rate and media stream statistics I think need to be
> decoupled from QoS. These are specified to enable optimisation of
> resources
> within the transport network. They have no QoS significance from an
> application point of view. i.e the apllication does not care about the
> media stream bit rate and statistics but the transport network provider
> does
> as it eats up his resource. They may be used for policy enforcement
> however
> in the transport network so they do need to be agreed between service
> provider and network operator. i.e the network operator agrees to provide
> a
> given QoS level (delay, jitter, packet loss) provided the media properties
> are within an agreed profile (bit rate, flow statistics).
>
> 3. The next point is how can the service provider know the statistics of
> a
> particular VBR stream? These can only be specified over a large number of
> similar calls and will depend, for instance, on who is speaking, the
> nature
> of the speech interaction etc etc. They can only be measured not
> calculated. The service provider is in no better position to measure
> these
> than the transport network operator and, in fact, where no gateways are
> involved, may not be able to. On the other hand the class of signal would
> have to be signalled to the network operator for him to be able to
> distinguish which class a particular measurement belonged to. e.g
> voice/speech/data, codec type, conference, multicast etc. So I see no
> purpose in trying to exchange statistics between the service provider
> (application) and transport operator. I think peak bit rate is all that
> can
> be meaningfully excanged. The specification of media class is however
> perhaps worth exploring.
>
> 4. The controlled category has always puzzled me. I only see two
> possibilities. Either the requested QoS level is guaranteed (on a
> statistical basis e.g 95% of all connections over a specified period) or
> not
> guaranteed. Is your controlled category a way of saying guaranteed, not
> to
> 95% but to some lower figure? If you can't put a percentage on it then it
> seems it is plain and simple not guaranteed. Anything that is not
> guaranteed to some specified statistical level is best effort and you
> can't
> say anything more about it. So I only see two categories here.
>
> In summary, I think we need to do three things in Annex N.
>
> a) Figure out the QoS information to be exchanged within the Application
> between service providers and end users. This will go in H.225.0 and
> H.245.
>
> b) Figure out how we are going to signal QoS and media information between
> the application (service providers) and transport domains (IP or ATM
> networks etc). The info is basically delay, jitter, packet loss
> requirements and peak bit rate. We need a protocol for this.
>
> c) we need to work out the interactions between the application QoS
> signal
> flows and the application/transport signal flows. I don't think we need
> worry about how the transport network mechanisms assure the requested QoS
> paramerters. RSVP/Intserv, Diffserv, MPLS, ATM, over provisioning are all
> possibilities.
>
> Would welcome comments and views on the above.
>
> Mike
>
>
> Mike Buckley
> +44-1457-877718 (T)
> +44-1457-877721 (F)
> mikebuckley(a)44comms.com
>
>
> ----- Original Message -----
> From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM>
> To: <ITU-SG16(a)MAILBAG.INTEL.COM>
> Sent: Thursday, August 10, 2000 10:15 PM
> Subject: H.323 QOS
>
>
> Hi, Mike and All:
>
> It is time to discuss about H.323 QOS.
>
> I believe that we have an agreement as follows:
>
> · H.323 QOS MUST be backward compatible to support RSVP and ATM QOS as it
> exists for H.323v2/v3/v4
> · Like H.323 spec, the application level H.323 QOS MUST be independent of
> the transport layer QOS and should support all transport networks (e.g.,
> IP,
> ATM)
> · A mapping table between the H.323 QOS and the transport layer QOS (e.g.,
> IP QOS [DiffServ, RSVP, etc.], ATM QOS [CBR, rt-VBR, nrt-VBR, ABR, etc.])
> should be provided.
>
> From the H.323 multimedia application point of view, there are following
> performance parameters can be used to characterize the traffic
> characteristics:
>
> · Bitrate characteristics: Peak bit rate (PBR) or peak rate (PR),
> Sustained
> bit rate (SBR) or average rate (AR), minimum bit rate (MBR) or minimum
> rate
> (MR), and mean bust size (MBS)
> · Delay and loss characteristics: end-to-end delay (EED) or delay,
> end-to-end delay variation (EEDV) or delay variation (DV), and
> bit-error-rate (BER) or (packet) loss rate (LR)
>
> We can now form a table with all parameters as follows:
>
> Table 1: H.323 Multimedia Application Performance Matrix
> Audio (codecs)--- Video (codecs)--- Data
> (T.120)
> PBR/PR Yes/No/Value Yes/No/Value Yes/No/value
> SBR/AR Yes/No/Value Yes/No/Value Yes/No/value
> MBR/MR Yes/No/Value Yes/No/Value Yes/No/value
> MBS Yes/No/Value Yes/No/Value Yes/No/value
> EED/Delay Yes/No/Value Yes/No/Value Yes/No/value
> EEDV/DV Yes/No/Value Yes/No/Value Yes/No/value
> BER/LR Yes/No/Value Yes/No/Value Yes/No/value
>
> From the above table we will have the opportunity to choose each parameter
> for each medium (audio, video, data) that makes sense from the
> application's
> and enduser's point of view. Again, these parameters can be specified as
> follows:
>
> · Guaranteed: The value specified for each parameter MUST be guaranteed.
> · Controlled: The value specified for each parameter MAY be satisfied as
> far
> as practicable (possibly with certain range), but definitely NOT
> guaranteed.
> · Best effort: No commitment will be made.
>
> Now each medium (e.g., audio, video, or data) will have different
> categories
> of performance matrix depending on its selection criteria and this can
> also
> be mapped to RSVP, ATM QOS, and others, if needed.
>
> Once we agree on this format, the next step is to create H.323 QOS
> signaling
> messages.
>
> This is my input for discussion in the upcoming Portland Q.13 meeting for
> H.323 QOS.
>
> I like to see the comments from other members as well.
>
> Best regards,
> Radhika R. Roy
> AT&T
> +1 732 420 1580
> rrroy(a)att.com
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv(a)mailbag.intel.com
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv(a)mailbag.intel.com
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
1
0
Dear Q12-14/16 experts,
The web page document referred to in APC-1947 "IP Telephony and CSTA" is
now available as APC-1947-att at the /0008_Por directory. You can browse it
locally by opening APC-1947-att.html.
Best regards,
Sakae OKUBO
***********************************************************
Waseda Research Center
Telecommunications Advancement Organization of Japan (TAO)
5th Floor, Nishi-Waseda Bldg.
1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo
169-0051 Japan
Tel: +81 3 5286 3830 (to be transferred)
+81 3 3204 8194 (direct)
Fax: +81 3 5287 7287
e-mail: okubo(a)giti.or.jp
***********************************************************
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
1
0
Hi Mike,
I am new to this forum, i may be wrong, the following is my offering:
>From a carrier/operator point of view , we need standard body addressing the
end-to-end QoS problems, Echo issues....
We need specs/standards to discuss with other carrier/operator....right now.
So much debate between SIP and H.323 but no real progress on this subject
end-to-end QoS.
As far as i know to date , H.323 is probably in front in many aspects. Why
not going beyond the call.
Best Regards
James Dam
+61 29342 8195
James.Dam(a)cwo.com.au
> ----------
> From: Mike Buckley
> Reply To: Mailing list for parties associated with ITU-T Study Group
> 16
> Sent: Wednesday, 16 August 2000 11:55 PM
> To: ITU-SG16(a)MAILBAG.INTEL.COM
> Subject: Re: H.323 QOS
>
> Hi Radhika,
>
> The problem is I don't see a framework in SG16 for how H.323 will be used
> in
> the real world to solve the general end to end QoS problem.
>
> It's no good putting fields in protocols without some idea of how they are
> going to be used in practice. This doesn't mean you want to tie down the
> implementer to go down one particular route but you have to have an
> architecture in mind when you develop a protocol. The IETFs architecture
> is
> clear - it is the Internet. I would submit that this is not necessarily
> what we are doing in SG16.
>
> Let's define the framework of the problem we are going to solve. Much of
> it
> has been covered in this recent thread. But it needs documenting and
> general agreement.
>
> TIPHON is developing a framework for VoIP. SG16 is developing a suite of
> protocols for VoIP. Both need an agreed architecture. The early
> discussions on architecture in TIPHON lead to gateway decomposition and
> the
> birth of H.248. The logical conclusion of this work has lead to the
> present
> TIPHON architecture. Just as the gateway decomposition exercise lead to a
> set of requirements and architecture for H.248, the latest TIPHON
> architecture leads to a set of requirements for QoS control and a QoS
> architecture. See DTS 5003. I want to get general agreement on the
> problem
> we are solving and the roadmap of how we are going to get there. Then we
> can start on the ASN.1.
>
> We should not be considering SIP/SDP in SG16 - neither of these protocols
> are needed if we do our job right with H.323. Policy in the IETF is
> exclusively transport domain policy. Again it has nothing to do with the
> policies we may adopt on application level QoS. As far as I understand
> the
> MCI work this is all about the Internet and makes no recognition of H.323
> or
> other applications. So lets not get lead astray by orthogonal activities
> to
> those we are engaged on. Our job is application level QoS and defining
> the
> services we need from the transport domain to deliver it. We are not
> solving problems in the transport domain. But we can draw up a set of
> requirements for an interface and feed this to the IETF.
>
> Let's get our problem statement clear and our TORs and architecture
> documented and agreed.
>
> Mike
>
>
>
>
>
> Mike Buckley
> +44-1457-877718 (T)
> +44-1457-877721 (F)
> mikebuckley(a)44comms.com
>
>
> ----- Original Message -----
> From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM>
> To: <ITU-SG16(a)MAILBAG.INTEL.COM>
> Sent: Wednesday, August 16, 2000 2:08 PM
> Subject: Re: H.323 QOS
>
>
> Hi, Mike:
>
> Our aim is to extend H.323 for supporting QOS. The framework is already
> there.
>
> Please see H.323 and H.225.0 Annex G specs how the general framework is
> done
> in the context of H.323.
>
> Again, we are dealing with Q.13/16 and TIPHON exceeds the charter of
> Q.13/16. It goes beyond H.323 and involves almost all SGs of ITU-T and
> IETF
> that are dealing with QOS.
>
> I understand what TIPHON is trying to do and TIPHON is just NOT limited to
> Q.13/16. The same problem has been in the IETF when TIPHON presented its
> QOS
> model for extending SIP. It appears that it exceeds the charter of SIP.
>
> Please note that people are NOT saying that TIPHON's work is NOT needed.
> All
> they are saying: Let us divide the work in different items and each item
> will have its place in the corresponding WGs. For example, policy will be
> addressed in the Policy WG, if any particular messages in SIP needs to be
> extended to support QOS following the SIP charter that work may be
> addressed
> in the SIP WG, if any particular item needs to extend in SDP to support
> QOS
> that work needs to be done in the MMUSIC.
>
> From end-to-end call point of view, people will need SIP, SDP, Policy,
> Security, Billing, firewalls, NATs, and others. when the standards in all
> areas are done, people just use them. This is the second step. I have also
> been working with Joon Maeng of VTEL in this area because Joon submitted a
> contribution in Q.13/16 last Feb'99 meeting. We are waiting to complete
> the
> H.323 QOS work first.
>
> You can also see an IETF contribution from MCI WorldCom how the
> interdomain
> QOS can be used by SIP using Policy, Security, etc. This work is dependent
> on the standard work of Policy WG, and others. Again, this contribution
> for
> supporting interdomain QOS by SIP using Policy, etc. does NOT need any
> additional standard work is SIP, it is, rather, an implementation that
> shows
> how an end-to-end call can use all those standards including QOS that have
> been developed in different WGs.
>
> Appendix of H.323 QOS Annex N has the general framework. Now you can go
> through those items and please let us know where you like to see changes
> and
> why.
>
> Best regards,
> Radhika R. Roy
> AT&T
>
> -----Original Message-----
> From: Mike Buckley [mailto:mikebuckley@44COMMS.COM]
> Sent: Tuesday, August 15, 2000 7:51 PM
> To: ITU-SG16(a)MAILBAG.INTEL.COM
> Subject: Re: H.323 QOS
>
>
> Radhika,
>
> My aim here is to come up with a general QoS framework in H.323 that will
> handle all these situatioins not just special cases. I think we agree on
> this.
>
> I would be reluctant to solve a special case without an idea of how we are
> going to solve the general case. This can only lead to backward
> compatibility issues.
>
> I believe the TIPHON approach is totally general. However I agree it need
> some new interfaces defining.
>
> Mike
>
>
> Mike Buckley
> +44-1457-877718 (T)
> +44-1457-877721 (F)
> mikebuckley(a)44comms.com
>
>
> ----- Original Message -----
> From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM>
> To: <ITU-SG16(a)MAILBAG.INTEL.COM>
> Sent: Tuesday, August 15, 2000 8:21 PM
> Subject: Re: H.323 QOS
>
>
> Hi, Mike:
>
> Yes, you are right that NATs and firewalls problems are yet to be solved
> with complete satisfaction from address translation point of view. This
> may
> be a separate work item all by itself.
>
> I do not think that we will bring H.245 to address those problems. In
> fact,
> I have not seen any proposal in that direction.
>
> We have to separate our works step by step.
>
> I would not like to include those general problems as a part of H.323 OQS
> for now. Let a separate group or annexes deal with those special problems
> so
> that we can use those solutions for QOS as well, if needed.
>
> Best regards,
> Radhika R. Roy
> AT&T
>
> -----Original Message-----
> From: Mike Buckley [mailto:mikebuckley@44COMMS.COM]
> Sent: Tuesday, August 15, 2000 1:13 PM
> To: ITU-SG16(a)MAILBAG.INTEL.COM
> Subject: Re: H.323 QOS
>
>
> Hi Radhika,
>
> This model is only valid I think when you have end to end address
> transparency as in the Internet. When different transport network domains
> are present this doesn't necessarily work. NATs and firewalls will mean
> that IP addresses and port numbers in different domains will be different
> for the same media stream. Terminating IP and port numbers may well be
> different at each end of the call. This is one reason why H.323 will not
> work through firewalls. To fix this gatekeepers will have to perform a
> mediating function with the H.323 domain and the transport domains. This
> mediation will not be via H.245.
>
> SIP has the same problems by the way.
>
> Mike
>
>
> Mike Buckley
> +44-1457-877718 (T)
> +44-1457-877721 (F)
> mikebuckley(a)44comms.com
>
>
> ----- Original Message -----
> From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM>
> To: <ITU-SG16(a)MAILBAG.INTEL.COM>
> Sent: Tuesday, August 15, 2000 2:15 PM
> Subject: Re: H.323 QOS
>
>
> Hi, Mike:
>
> Just for information, H.245 does many things. As I indicated earlier, one
> of
> the most important things of H.245 is the opening and closing of the
> logical
> channels that binds the application layer's logical connection
> abstractions
> to all transport network connections (e.g., ATM, etc).
>
> So, this is the fundamental mission of H.245 to provide the continuity
> between the application layer and the lower layer in a transport
> independent
> way using the universal abstractions. These abstractions can be for
> anything
> that we can think of.
>
> Hope this helps.
>
> Best regards,
> Radhika R. Roy
> AT&T
>
> -----Original Message-----
> From: Mike Buckley [mailto:mikebuckley@44COMMS.COM]
> Sent: Tuesday, August 15, 2000 8:22 AM
> To: ITU-SG16(a)MAILBAG.INTEL.COM
> Subject: Re: H.323 QOS
>
>
> Hi Radhika,
>
> This use of H.245 as a bridging mechanism is where I have difficulties.
> The
> original intenmt behind H.245 was media control and negociation.
> Transport
> mechanisms should not be signalled in H.245 or elsewhere in the
> application.
> This is entirely the business of the transport network provider.
>
> Unfortunately I will not be present in Portland, however, I am happy to
> continue this productive dialogue on the list with a view to providing a
> new
> draft in the next few weeks.
>
> Regards,
>
> Mike
>
> Mike Buckley
> +44-1457-877718 (T)
> +44-1457-877721 (F)
> mikebuckley(a)44comms.com
>
>
> ----- Original Message -----
> From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM>
> To: <ITU-SG16(a)MAILBAG.INTEL.COM>
> Sent: Monday, August 14, 2000 7:29 PM
> Subject: Re: H.323 QOS
>
>
> Hi, Mike:
>
> I guess that we have agreement on the fundamental basis. However, I have
> problems when you translate this in signaling terms. As I have explained
> earlier that we are following the exiting framework of H.323 which is the
> application layer, and H.323 is transported over one or different
> transport
> networks. H.323 uses H.245 as a common mechanism that helps to transports
> the abstraction of H.323 application signaling messages over any networks
> (e.g., IP, ATM, etc).
>
> You may look to the H.245 spec very carefully instead of making any
> generalized statement.
>
> H.245 provides the bridging between the application layer and transport
> layer mechanism. For example, H.245's OLC abstraction is the link for ATM
> network layer logical connection as well as for other transport networks.
>
> In the same token, H.323 QOS abstraction may also provide link to the
> lower
> transport layer QOS signaling mechanisms (e.g., RSVP, DiffServ, MPLS, ATM
> QOS, etc), if needed. H.323 DOES support RSVP and ATM QOS now.
>
> Please also see my reply embedded in you email [RRR].
>
> Again, I would suggest to bring contributions explaining the solution and
> we
> will go from there. In absence of your contributions, I would suggest to
> provide comments on Appendix of H.323 QOS Annex N. We can then answer your
> questions step by step.
>
> Best regards,
> Radhika R. Roy
> AT&T
>
> -----Original Message-----
> From: Mike Buckley [mailto:mikebuckley@44COMMS.COM]
> Sent: Monday, August 14, 2000 12:56 PM
> To: ITU-SG16(a)MAILBAG.INTEL.COM
> Subject: Re: H.323 QOS
>
>
> Radhika,
>
> >However, this is only good for the single network. For example,
> >end-to-end RSVP or end-to-end ATM QOS.
>
> >If there are multiple networks or if a single IP network implements RSVP
> in
> >one domain, DiffServ in another domain, and MPLS in another domain, there
> is
> >no transparent H.323 QOS signaling mechanism that is universal on
> end-to-end
> >basis so that it can be mapped over the RSVP, DiffServ, MPLS, ATM QOS,
> etc
> >transparently
>
> This is the nub of the problem and I am afraid why this approach is
> flawed.
> [RRR] I am NOT afraid of anything. Rather we are solving all problems
> including the above as well. No one should be afraid of anything. The only
> thing that I can suggest is to bring contributions. We will go from there.
> Please remember that H.323 QOS supports RSVP and ATM QOS and we MUST
> provide
> backward compatibility. We will be waiting to see contributions from you
> to
> prove your points whether things are flawed or not. Please read Appnedix
> of
> H.323 QOS Annex N very carefully along with exiting H.323 and H.245
> standard how they support H.323 QOS for RSVP and ATM QOS.
>
> >We have shown how the H.323 QOS can
> >be mapped over the RSVP, DiffServ, ATM QOS, etc. if needed.
>
> This mapping must be done within the transport plane not by the
> application.
> All the application needs to specify are the entries in your Table 1. i.e
> delay, jitter. packet loss and peak bit rate (the latter parameter for
> policy enforcement and resource reservation).
> [RRR] Please see my generalized clarification how H.245 provides
> translation
> between H.323 signaling schemes over the lower layer transport networks
> (e.g., IP, ATM, etc). The mechanism already exists in H.323 and this is
> the
> beauty of the transport independent H.323 application. Now there are two
> separate things: one is what the calling side of the application demands
> and
> what the called side of the application agrees on. This is called
> negotiation capability (e.g., choosing a particular type codec that has a
> certain bandwidth, jitter, and other requirements). How the choosing
> criteria is determined, the H.323 application is NOT aware of those
> things.
> It may depend on many criteria (e.g., policy, bandwidth, type of network
> [e.g., IP, ATM], pricing, security, personal preferences, etc.), but H.323
> is not involved. These are separate issues and we are NOT addressing at
> the
> H.323 layer.
>
> I am still not clkear how you propose to signal these parameters to the
> transport plane.
> [RRR] It is NOT new in H.323, and this mechanism already exits. Please see
> the support of RSVP and ATM QOS in H.323/H.245 spec. We are not inventing
> anything NEW here. Then, if you read Appendix of H.323 QOS Annex N very
> carefully, you will find how it happening (whether you call it as
> transport
> plane or something else, it does not matter).
>
> I think we are getting loser to a common understanding.
>
> Mike
>
> Mike Buckley
> +44-1457-877718 (T)
> +44-1457-877721 (F)
> mikebuckley(a)44comms.com
>
>
> ----- Original Message -----
> From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM>
> To: <ITU-SG16(a)MAILBAG.INTEL.COM>
> Sent: Monday, August 14, 2000 2:37 PM
> Subject: Re: H.323 QOS
>
>
> Hi, Bob:
>
> I agree completely agree with you.
>
> In fact, we are all trying to achieve the same goal. For example, H.323
> does
> supports QOS today via H.245. You can easily see that RSVP and ATM QOS are
> supported using H.245. The beauty of this approach is that H.245 is still
> transport independent. All we have done here is: the abstraction of H.245
> has been used to support the RSVP and ATM QOS to implement the network
> layer
> QOS. However, this is only good for the single network. For example,
> end-to-end RSVP or end-to-end ATM QOS.
>
> If there are multiple networks or if a single IP network implements RSVP
> in
> one domain, DiffServ in another domain, and MPLS in another domain, there
> is
> no transparent H.323 QOS signaling mechanism that is universal on
> end-to-end
> basis so that it can be mapped over the RSVP, DiffServ, MPLS, ATM QOS, etc
> transparently.
>
> In Appendix of H.323 Annex N, we have done the same. We have the
> abstraction
> of H.323 QOS in the application layer. We have shown how the H.323 QOS can
> be mapped over the RSVP, DiffServ, ATM QOS, etc. if needed. It also
> provides
> the backward compatibility with the existing H.323 standard. However, we
> have done only for the pre-call setup signaling part. We have not done the
> call setup part yet. In the call setup part, we will include H.245 in a
> similar way what H.323 is supporting RSVP and ATM QOS today in a
> monolithic
> network.
>
> I appreciate your email.
>
> Best regards,
> Radhika R. Roy
> AT&T
>
> > -----Original Message-----
> > From: Callaghan, Robert [SMTP:Robert.Callaghan@icn.siemens.com]
> > Sent: Monday, August 14, 2000 9:08 AM
> > To: Roy, Radhika R, ALCOO
> > Cc: 'Mailing list for parties associated with ITU-T Study Group 16'
> > Subject: RE: H.323 QOS
> >
> > Roy,
> >
> > In my view, the network, as a minimum, needs only provide transport.
> > H.323
> > is an application using this transport and is not different from any
> other
> > application being transported. Any application may request a desired
> > quality of service that the network may grant based on policies, service
> > level agreements, and availability. Each data connection used by an
> > application may request a different QOS. Most likely H.323 is such an
> > application as needing an enhanced QOS. This simple case should work.
> > This
> > is all that is required.
> >
> > In addition to transport, the network may optionally provide other
> > additional services. These services may include application layer
> > routing.
> > These optional services should be configured and indicated independently
> > from the basic transport QOS.
> >
> > It is correct that H.323, as an application, is (mostly) transport
> > independent. However, the interface between the application and the
> > transport layer is not transport independent. The interface
> specification
> > used to request a given QOS is totally dependant on the standards body
> > that
> > specified the transport layer; and for this there has been little or no
> > coordination.
> >
> > Because transport QOS over IP is based on IETF specifications, it is
> > necessary that the interface used to request a given QOS conform to the
> > appropriate IETF specification. If such an interface specification is
> not
> > available, that input might be provided to the appropriate IETF body as
> to
> > the requirements.
> >
> > I can see the endpoints negotiating the desired QOS base on need, price,
> > and
> > other considerations. For me, this is the limit to the application
> layer
> > involvement in QOS negotiation. At this point, the application
> > negotiations
> > with the transport provider as to the desired and available QOS. It is
> up
> > to the transport provider to arrange for the end-to-end QOS. (Again, it
> > is
> > not necessary for the transport network to know that H.323 is involved
> in
> > the transported data. In fact it may be encrypted in order to mask the
> > presence of voice transport.)
> >
> > For me, this is simple.
> >
> > Bob
> >
> > ------------------------------------------------------------------
> > Robert Callaghan
> > Siemens Enterprise Networks
> > Tel: +1.561.923.1756 Fax: +1.561.923.1403
> > Email: Robert.Callaghan(a)ICN.Siemens.com
> > ------------------------------------------------------------------
> >
> > -----Original Message-----
> > From: Roy, Radhika R, ALCOO [mailto:rrroy@ATT.COM]
> > Sent: Friday, August 11, 2000 7:59 AM
> > To: ITU-SG16(a)mailbag.cps.intel.com
> > Subject: Re: H.323 QOS
> >
> > Hi, Mike:
> >
> > Let me try again.
> >
> > What is the reference point of H.323 QOS? Is it not H.323? If it is so,
> > what
> > do we mean by H.323?
> >
> > The answer is: Audio (different codecs), Video (different codecs), and
> > Data
> > (T.120 applications) that are used by H.323.
> >
> > What are the QOS/performance characteristics of audio, video, and data
> > from
> > the application point of view that is generated by audio codecs, video
> > codecs, and data (T.120) applications?
> >
> > These QOS/performance characteristics come from the SOURCE codecs and
> data
> > applications. Per transport independent H.323 specifications, an enduser
> > express their QOS/performance requirements on end-to-end basis purely
> from
> > application point of view irrespective of the transport network (e.g.,
> IP,
> > ATM, etc.).
> >
> > Moreover, H.323 is meant for the packet network, not for any
> > circuit-switched network like PSTN or ISDN.
> >
> > Let us NOT go beyond this before we start debating transport layer QOS
> or
> > service provider requirements. These are NOT the concern of H.323. H.323
> > is
> > the transport independent application.
> >
> > H.323v2/v3/v4 has also provided mechanisms how RSVP and ATM QOS can be
> > used
> > for H.323 audio, video, and data. So, H.323 QOS that will be defined in
> > H.323 Annex N MUST provide mapping for the backward compatibility. It is
> a
> > requirement that MUST be met per the norm of ITU-T.
> >
> > So, what is left for mapping? Mapping is simply a by-product of the
> above
> > requirement. Mapping is simply a table, nothing else.
> >
> > Did I miss anything?
> >
> > Best regards,
> > Radhika R. Roy
> > AT&T
> >
> > -----Original Message-----
> > From: Mike Buckley [mailto:mikebuckley@44COMMS.COM]
> > Sent: Thursday, August 10, 2000 10:19 PM
> > To: ITU-SG16(a)MAILBAG.INTEL.COM
> > Subject: Re: H.323 QOS
> >
> >
> > Radhika,
> >
> > Thanks for the input which I welcome as I will unfortunately not be
> > present
> > at Portland.
> >
> > Let me ask a few questions and make a few comments hopefully with the
> > intent
> > of opening up the debate.
> >
> > 1. I am not sure I understand your concept of a mapping table between
> the
> > H.323 QOS and the transport layer QoS. My understanding is that QoS is
> on
> > three levels:
> >
> > a) that specified from a service point of view between the user and
> > service
> > provider (e.g PSTN quality, conference quality etc) This is the domain
> of
> > the speech experts and can be characterised by Listener Speech Quaklity
> > (MOS), end to end delay, and absolute category rating, R.
> >
> > b) application specific parameters, (e.g. equipment delays, codec
> choice
> > and performance, codec frame size, packetisation arrangements, jitter
> > buffer
> > design, overall packet loss etc.) Optimisation of all these will
> > determine
> > what can be delivered in a).
> >
> > c) transport parameters for a given choice of application parameters.
> > This
> > boils down only to three parameters as far as I cna see: tranport
> network
> > delay, packet delay variation in the transport network and packet loss
> in
> > the transport network. Again these parameters will determine the
> results
> > in
> > a) for a given choice of the parameters in b). These parameters are
> > generic
> > from the perspective of the transport network. i.e the transport
> network
> > does not need to know the details of the application.
> >
> > So the sequence of cause and effect and control is:
> >
> > a) User requests QoS class from service provider,
> > b) Service provider determines application specific parameters in
> > conjunction with users equipment and other service providers,
> > c) Service provider requests required delay, delay variation and packet
> > loss from network provider.
> >
> > I see no need for mapping here. The only QoS info flows within the
> > application are specific to the application and those between the
> > application (service provider) and the transport network are generic.
> i.e.
> > delay, jitter and packet loss. Have I missed something?
> >
> > 2. The issue of bit rate and media stream statistics I think need to be
> > decoupled from QoS. These are specified to enable optimisation of
> > resources
> > within the transport network. They have no QoS significance from an
> > application point of view. i.e the apllication does not care about the
> > media stream bit rate and statistics but the transport network provider
> > does
> > as it eats up his resource. They may be used for policy enforcement
> > however
> > in the transport network so they do need to be agreed between service
> > provider and network operator. i.e the network operator agrees to
> provide
> > a
> > given QoS level (delay, jitter, packet loss) provided the media
> properties
> > are within an agreed profile (bit rate, flow statistics).
> >
> > 3. The next point is how can the service provider know the statistics
> of
> > a
> > particular VBR stream? These can only be specified over a large number
> of
> > similar calls and will depend, for instance, on who is speaking, the
> > nature
> > of the speech interaction etc etc. They can only be measured not
> > calculated. The service provider is in no better position to measure
> > these
> > than the transport network operator and, in fact, where no gateways are
> > involved, may not be able to. On the other hand the class of signal
> would
> > have to be signalled to the network operator for him to be able to
> > distinguish which class a particular measurement belonged to. e.g
> > voice/speech/data, codec type, conference, multicast etc. So I see no
> > purpose in trying to exchange statistics between the service provider
> > (application) and transport operator. I think peak bit rate is all that
> > can
> > be meaningfully excanged. The specification of media class is however
> > perhaps worth exploring.
> >
> > 4. The controlled category has always puzzled me. I only see two
> > possibilities. Either the requested QoS level is guaranteed (on a
> > statistical basis e.g 95% of all connections over a specified period) or
> > not
> > guaranteed. Is your controlled category a way of saying guaranteed,
> not
> > to
> > 95% but to some lower figure? If you can't put a percentage on it then
> it
> > seems it is plain and simple not guaranteed. Anything that is not
> > guaranteed to some specified statistical level is best effort and you
> > can't
> > say anything more about it. So I only see two categories here.
> >
> > In summary, I think we need to do three things in Annex N.
> >
> > a) Figure out the QoS information to be exchanged within the
> Application
> > between service providers and end users. This will go in H.225.0 and
> > H.245.
> >
> > b) Figure out how we are going to signal QoS and media information
> between
> > the application (service providers) and transport domains (IP or ATM
> > networks etc). The info is basically delay, jitter, packet loss
> > requirements and peak bit rate. We need a protocol for this.
> >
> > c) we need to work out the interactions between the application QoS
> > signal
> > flows and the application/transport signal flows. I don't think we
> need
> > worry about how the transport network mechanisms assure the requested
> QoS
> > paramerters. RSVP/Intserv, Diffserv, MPLS, ATM, over provisioning are
> all
> > possibilities.
> >
> > Would welcome comments and views on the above.
> >
> > Mike
> >
> >
> > Mike Buckley
> > +44-1457-877718 (T)
> > +44-1457-877721 (F)
> > mikebuckley(a)44comms.com
> >
> >
> > ----- Original Message -----
> > From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM>
> > To: <ITU-SG16(a)MAILBAG.INTEL.COM>
> > Sent: Thursday, August 10, 2000 10:15 PM
> > Subject: H.323 QOS
> >
> >
> > Hi, Mike and All:
> >
> > It is time to discuss about H.323 QOS.
> >
> > I believe that we have an agreement as follows:
> >
> > · H.323 QOS MUST be backward compatible to support RSVP and ATM QOS as
> it
> > exists for H.323v2/v3/v4
> > · Like H.323 spec, the application level H.323 QOS MUST be independent
> of
> > the transport layer QOS and should support all transport networks (e.g.,
> > IP,
> > ATM)
> > · A mapping table between the H.323 QOS and the transport layer QOS
> (e.g.,
> > IP QOS [DiffServ, RSVP, etc.], ATM QOS [CBR, rt-VBR, nrt-VBR, ABR,
> etc.])
> > should be provided.
> >
> > From the H.323 multimedia application point of view, there are following
> > performance parameters can be used to characterize the traffic
> > characteristics:
> >
> > · Bitrate characteristics: Peak bit rate (PBR) or peak rate (PR),
> > Sustained
> > bit rate (SBR) or average rate (AR), minimum bit rate (MBR) or minimum
> > rate
> > (MR), and mean bust size (MBS)
> > · Delay and loss characteristics: end-to-end delay (EED) or delay,
> > end-to-end delay variation (EEDV) or delay variation (DV), and
> > bit-error-rate (BER) or (packet) loss rate (LR)
> >
> > We can now form a table with all parameters as follows:
> >
> > Table 1: H.323 Multimedia Application Performance Matrix
> > Audio (codecs)--- Video (codecs)--- Data
> > (T.120)
> > PBR/PR Yes/No/Value Yes/No/Value Yes/No/value
> > SBR/AR Yes/No/Value Yes/No/Value Yes/No/value
> > MBR/MR Yes/No/Value Yes/No/Value Yes/No/value
> > MBS Yes/No/Value Yes/No/Value Yes/No/value
> > EED/Delay Yes/No/Value Yes/No/Value Yes/No/value
> > EEDV/DV Yes/No/Value Yes/No/Value Yes/No/value
> > BER/LR Yes/No/Value Yes/No/Value Yes/No/value
> >
> > From the above table we will have the opportunity to choose each
> parameter
> > for each medium (audio, video, data) that makes sense from the
> > application's
> > and enduser's point of view. Again, these parameters can be specified as
> > follows:
> >
> > · Guaranteed: The value specified for each parameter MUST be guaranteed.
> > · Controlled: The value specified for each parameter MAY be satisfied as
> > far
> > as practicable (possibly with certain range), but definitely NOT
> > guaranteed.
> > · Best effort: No commitment will be made.
> >
> > Now each medium (e.g., audio, video, or data) will have different
> > categories
> > of performance matrix depending on its selection criteria and this can
> > also
> > be mapped to RSVP, ATM QOS, and others, if needed.
> >
> > Once we agree on this format, the next step is to create H.323 QOS
> > signaling
> > messages.
> >
> > This is my input for discussion in the upcoming Portland Q.13 meeting
> for
> > H.323 QOS.
> >
> > I like to see the comments from other members as well.
> >
> > Best regards,
> > Radhika R. Roy
> > AT&T
> > +1 732 420 1580
> > rrroy(a)att.com
> >
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > For help on this mail list, send "HELP ITU-SG16" in a message to
> > listserv(a)mailbag.intel.com
> >
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > For help on this mail list, send "HELP ITU-SG16" in a message to
> > listserv(a)mailbag.intel.com
> >
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > For help on this mail list, send "HELP ITU-SG16" in a message to
> > listserv(a)mailbag.intel.com
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv(a)mailbag.intel.com
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv(a)mailbag.intel.com
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv(a)mailbag.intel.com
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv(a)mailbag.intel.com
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv(a)mailbag.intel.com
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv(a)mailbag.intel.com
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv(a)mailbag.intel.com
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv(a)mailbag.intel.com
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv(a)mailbag.intel.com
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv(a)mailbag.intel.com
>
>
1
0
Re: [IPTEL] URL to support Number Portability [was: draft-yu-tel- url-00.txt]
by James Yu 16 Aug '00
by James Yu 16 Aug '00
16 Aug '00
Would appreciate if people on the iptel and SIP discussion lists can voice
their opinions (agree or disagree) on draft-yu-tel-url-00.txt (see
attachment). This enhancement to the tel URL is intended to allow SIP to
carry number portability related information in the Request-URI field. The
information (e.g., routing number and POTS number) in the tel URL may be
used by the LSs for call routing. Thanks.
James
> -----Original Message-----
> From: Orit Levin [mailto:orit@radvision.com]
> Sent: Tuesday, August 15, 2000 1:06 PM
> To: James Yu; IPTEL WG; sip-h323(a)egroups.com
> Cc: h323implementors(a)imtc.org; ITU-SG16(a)MAILBAG.INTEL.COM;
> SIP reflector
> Subject: [IPTEL] URL to support Number Portability [was:
> draft-yu-tel-url-00.txt]
>
>
> James!
> After reviewing your draft, below are my comments.
> As in regards to H.323, H.323 doesn't currently have an
> explicit notion of
> two different fields carrying the exact meaning of "current
> destination" and
> "the final recipient", using SIP language.
> On the other hand, the definition of H.323 URL potentially allows for
> cascading of URLs
> of different kinds. This concept appear in the last draft of
> "Annex O" to be
> discussed next week. Therefore, tel url can be placed in the
> "user" part of
> H.323 URL.
> Since, in your proposal, the original "final recipient"
> information (i.e.
> the phone number itself) is preserved in the tel url after
> the NPDB deep is
> performed, I don't see a technical problem for using the
> proposed algorithm
> within H.323.
>
> I will bring your work to the attention of H.323 community next week,
> including the H.323 mobility WG. My question (and that of the H.323
> community) would be: what level of consensus does the
> approach, presented in
> your draft, currently have within SIP and IPTEL working groups?
>
>
> Orit Levin
> RADVision Inc.
> 575 Corporate Drive Suite 420
> Mahwah, NJ 07430
> Tel: 1 201 529 4300 (230)
> Fax: 1 201 529 3516
> www.radvision.com
> orit(a)radvision.com
> -----Original Message-----
> From: James Yu <james.yu(a)neustar.com>
> To: 'Orit Levin' <orit(a)radvision.com>; IPTEL WG
> <iptel(a)lists.bell-labs.com>
> Date: Monday, August 14, 2000 1:24 PM
> Subject: RE: [IPTEL] A draft of H323-URL to be presented
> during the IPTEL
> session
>
>
> >Orit,
> >
> >Please review the attached draft-yu-tel-url-00.txt, titled
> "Extensions to
> >the tel and fax URL to support Number Portability." It is
> intended for the
> >SIP to carry number portability (NP) information in the
> Request URI field.
> >It may be carried by H.225.0 directly or may be mapped to
> the proposed
> H.323
> >URL to support NP in H.323.
> >
> >There has not been lots of discussion on this I-D. Comments
> from you and
> >others are welcome.
> >
> >James
> >
> >
> >
> >-----Original Message-----
> >From: Orit Levin [mailto:orit@radvision.com]
> >Sent: Monday, July 31, 2000 9:05 PM
> >To: IPTEL WG
> >Subject: [IPTEL] A draft of H323-URL to be presented during the IPTEL
> >session
> >
> >
> >Hello!
> >I have submitted the attached draft 3 weeks ago.
> >Unfortunately, the document doesn't appear on the IETF Drafts site.
> >Since this topic is going to be presented during the IPTEL session on
> >Thursday morning, I am attaching the draft for you review.
> >Best Regards,
> >Orit Levin
> >RADVision Inc.
> >575 Corporate Drive Suite 420
> >Mahwah, NJ 07430
> >Tel: 1 201 529 4300 (230)
> >Fax: 1 201 529 3516
> >www.radvision.com <http://www.radvision.com>
> >orit(a)radvision.com <mailto:orit@radvision.com>
> >-----Original Message-----
> >From: Orit Levin < orit(a)radvision.com <mailto:orit@radvision.com> >
> >To: internet-drafts(a)ietf.org <mailto:internet-drafts@ietf.org> <
> >internet-drafts(a)ietf.org <mailto:internet-drafts@ietf.org> >
> >Date: Tuesday, July 11, 2000 1:59 AM
> >Subject: Request for Draft Submission
> >
> >
> >Hello!
> >I would like to submit the attached paper as the first
> drafts to become an
> >Informational RFC.
> >Thank you,
> >Orit Levin
> >RADVision Inc.
> >575 Corporate Drive Suite 420
> >Mahwah, NJ 07430
> >Tel: 1 201 529 4300 (230)
> >Fax: 1 201 529 3516
> >www.radvision.com <http://www.radvision.com>
> >orit(a)radvision.com <mailto:orit@radvision.com>
> >
> >
>
>
>
> _______________________________________________
> IPTEL mailing list
> IPTEL(a)lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/iptel
>
1
0
Dear Q12-14/16 experts,
This is a follow-up report to my yesterday's message:
>Somehow I cannot find those with * (1884, 1900, 1901, 1902, 1905, 1906,
>1924, 1925, 1931, 1940, 1941, 1942) at the ftp site. Please upload them as
>soon as possible for the member's review, or advise me if my understanding
>is incorrect. Otherwise they will be dealt with as late arrival
>contributions whose consideration is subject to the agreement of the
>meeting.
After 24 hours tolerance, let me mark APC-1884, 1900, 1901, 1902, 1906,
1924, 1925, 1931, 1940 with late arrival. Please make them available at the
earliest occasion for the pre-review of experts to have an efficient
meeting.
Please note that TD-06, TD-07, which were registered as TD due to late
registration, are already available at /0008_Por directory.
Best regards,
Sakae OKUBO
***********************************************************
Waseda Research Center
Telecommunications Advancement Organization of Japan (TAO)
5th Floor, Nishi-Waseda Bldg.
1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo
169-0051 Japan
Tel: +81 3 5286 3830 (to be transferred)
+81 3 3204 8194 (direct)
Fax: +81 3 5287 7287
e-mail: okubo(a)giti.or.jp
***********************************************************
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
2
1
Agreed!
Bob
------------------------------------------------------------------
Robert Callaghan
Siemens Enterprise Networks
Tel: +1.561.923.1756 Fax: +1.561.923.1403
Email: Robert.Callaghan(a)ICN.Siemens.com
------------------------------------------------------------------
-----Original Message-----
From: Mike Buckley [mailto:mikebuckley@44COMMS.COM]
Sent: Wednesday, August 16, 2000 2:40 PM
To: ITU-SG16(a)mailbag.cps.intel.com
Subject: Re: H.323 QOS
>We will go step-by-step.
I am happy to agree to this once we know where we are trying to get to. We
also need to scope out the problem space before we start taking steps.
Mike
Mike Buckley
+44-1457-877718 (T)
+44-1457-877721 (F)
mikebuckley(a)44comms.com
----- Original Message -----
From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM>
To: <ITU-SG16(a)MAILBAG.INTEL.COM>
Sent: Wednesday, August 16, 2000 5:49 PM
Subject: Re: H.323 QOS
Hi, Mike:
As I said, we will only work in the framework of H.323 (i.e., Q.13/16).
I understand other questions like Q.14 as well and I am a part of it.
We will go step-by-step. We worked for H.323 in Q.13/16 before we developing
Q.14/16 where the interworking issues like H.248 GWs have been addressed. In
the same token, we are also addressing the H.323 mobility. First, we are
developing the H.323 mobility model in Q.13/16. Then we will address the
interoperability between the PSTN and packet switching network mobility
where H.248 will be one of the items, and these items may fall into other
questions including Q.14/16.
As I told, I have objections when TIPHON model does NOT say which items they
need to address in which questions or which study groups. The confusion
comes when they "dump" everything in one question.
As I told before, no one is saying against TIPHON because we all know this:
There are items that are also being addressed by us in the ITU-T in general.
Hope this will clarify.
Let us NOT create confusions mixing things. Let us focus on our work while
inputs from all ITU-T SGs, TIPHON, IETF, IMTC, and other forums are also
welcome.
Best regards,
Radhika R. Roy
AT&T
-----Original Message-----
From: Mike Buckley [mailto:mikebuckley@44COMMS.COM]
Sent: Wednesday, August 16, 2000 11:56 AM
To: ITU-SG16(a)MAILBAG.INTEL.COM
Subject: Re: H.323 QOS
Hi Radhika,
>We MUST not speak about TIPHON models. It confuses people because it
exceeds
>the charter of Q.13/16. we do not like to address issues related to H.248
>now (it is a part of Q.14/16). We will go step-by-step.
I am only referring to the TIPHON model because you did!
Having said that there is nothing confusing in the TIPHON model for the
participants in Q13 - my experience is they are pretty smart people. I
think if we can pick up useful ideas from the work of other groups we should
be open to that.
>Let us wear the "HAT" of H.323 in Q.13/16, not beyond that.
The work of Q.13 and 14 seems pretty seamless to me. That's why the two
questions are often run as one. We should not be too blinkered in our
approach or we will definitely end up with something that is unuseable.
Mike
Mike Buckley
+44-1457-877718 (T)
+44-1457-877721 (F)
mikebuckley(a)44comms.com
----- Original Message -----
From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM>
To: <ITU-SG16(a)MAILBAG.INTEL.COM>
Sent: Wednesday, August 16, 2000 3:44 PM
Subject: Re: H.323 QOS
Hi, Mike:
I understand what you are saying. I took IETF model as example how works can
be divided when TIPHON model is considered in the context of SIP.
In SG16 of Q.13, the charter is clear: It is H.323 that can be used over any
"packet" networks (i.e., transport independent).
In this context, please H.323 specs: H.323, H.225.0, H.225.0 Annex G, and
H.245.
So, our reference is: To extend H.323 to "express" QOS (application layer)
considering audio codecs, video codecs, data (T.120).
Please see Appendix of H.323 Annex N. We will go from there (you can see the
frame work of H.225.0 Annex G - how simple it is - we will follow the
similar model).
This is as simple as stated above.
We MUST not speak about TIPHON models. It confuses people because it exceeds
the charter of Q.13/16. we do not like to address issues related to H.248
now (it is a part of Q.14/16). We will go step-by-step.
Let us wear the "HAT" of H.323 in Q.13/16, not beyond that.
By the way, we are also doing the same thing in H.323 mobility: To extend
H.323 to support mobility in the application layer.
Hope this helps.
Best regards,
Radhika R. Roy
AT&T
-----Original Message-----
From: Mike Buckley [mailto:mikebuckley@44COMMS.COM]
Sent: Wednesday, August 16, 2000 9:56 AM
To: ITU-SG16(a)MAILBAG.INTEL.COM
Subject: Re: H.323 QOS
Hi Radhika,
The problem is I don't see a framework in SG16 for how H.323 will be used in
the real world to solve the general end to end QoS problem.
It's no good putting fields in protocols without some idea of how they are
going to be used in practice. This doesn't mean you want to tie down the
implementer to go down one particular route but you have to have an
architecture in mind when you develop a protocol. The IETFs architecture is
clear - it is the Internet. I would submit that this is not necessarily
what we are doing in SG16.
Let's define the framework of the problem we are going to solve. Much of it
has been covered in this recent thread. But it needs documenting and
general agreement.
TIPHON is developing a framework for VoIP. SG16 is developing a suite of
protocols for VoIP. Both need an agreed architecture. The early
discussions on architecture in TIPHON lead to gateway decomposition and the
birth of H.248. The logical conclusion of this work has lead to the present
TIPHON architecture. Just as the gateway decomposition exercise lead to a
set of requirements and architecture for H.248, the latest TIPHON
architecture leads to a set of requirements for QoS control and a QoS
architecture. See DTS 5003. I want to get general agreement on the problem
we are solving and the roadmap of how we are going to get there. Then we
can start on the ASN.1.
We should not be considering SIP/SDP in SG16 - neither of these protocols
are needed if we do our job right with H.323. Policy in the IETF is
exclusively transport domain policy. Again it has nothing to do with the
policies we may adopt on application level QoS. As far as I understand the
MCI work this is all about the Internet and makes no recognition of H.323 or
other applications. So lets not get lead astray by orthogonal activities to
those we are engaged on. Our job is application level QoS and defining the
services we need from the transport domain to deliver it. We are not
solving problems in the transport domain. But we can draw up a set of
requirements for an interface and feed this to the IETF.
Let's get our problem statement clear and our TORs and architecture
documented and agreed.
Mike
Mike Buckley
+44-1457-877718 (T)
+44-1457-877721 (F)
mikebuckley(a)44comms.com
----- Original Message -----
From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM>
To: <ITU-SG16(a)MAILBAG.INTEL.COM>
Sent: Wednesday, August 16, 2000 2:08 PM
Subject: Re: H.323 QOS
Hi, Mike:
Our aim is to extend H.323 for supporting QOS. The framework is already
there.
Please see H.323 and H.225.0 Annex G specs how the general framework is done
in the context of H.323.
Again, we are dealing with Q.13/16 and TIPHON exceeds the charter of
Q.13/16. It goes beyond H.323 and involves almost all SGs of ITU-T and IETF
that are dealing with QOS.
I understand what TIPHON is trying to do and TIPHON is just NOT limited to
Q.13/16. The same problem has been in the IETF when TIPHON presented its QOS
model for extending SIP. It appears that it exceeds the charter of SIP.
Please note that people are NOT saying that TIPHON's work is NOT needed. All
they are saying: Let us divide the work in different items and each item
will have its place in the corresponding WGs. For example, policy will be
addressed in the Policy WG, if any particular messages in SIP needs to be
extended to support QOS following the SIP charter that work may be addressed
in the SIP WG, if any particular item needs to extend in SDP to support QOS
that work needs to be done in the MMUSIC.
>From end-to-end call point of view, people will need SIP, SDP, Policy,
Security, Billing, firewalls, NATs, and others. when the standards in all
areas are done, people just use them. This is the second step. I have also
been working with Joon Maeng of VTEL in this area because Joon submitted a
contribution in Q.13/16 last Feb'99 meeting. We are waiting to complete the
H.323 QOS work first.
You can also see an IETF contribution from MCI WorldCom how the interdomain
QOS can be used by SIP using Policy, Security, etc. This work is dependent
on the standard work of Policy WG, and others. Again, this contribution for
supporting interdomain QOS by SIP using Policy, etc. does NOT need any
additional standard work is SIP, it is, rather, an implementation that shows
how an end-to-end call can use all those standards including QOS that have
been developed in different WGs.
Appendix of H.323 QOS Annex N has the general framework. Now you can go
through those items and please let us know where you like to see changes and
why.
Best regards,
Radhika R. Roy
AT&T
-----Original Message-----
From: Mike Buckley [mailto:mikebuckley@44COMMS.COM]
Sent: Tuesday, August 15, 2000 7:51 PM
To: ITU-SG16(a)MAILBAG.INTEL.COM
Subject: Re: H.323 QOS
Radhika,
My aim here is to come up with a general QoS framework in H.323 that will
handle all these situatioins not just special cases. I think we agree on
this.
I would be reluctant to solve a special case without an idea of how we are
going to solve the general case. This can only lead to backward
compatibility issues.
I believe the TIPHON approach is totally general. However I agree it need
some new interfaces defining.
Mike
Mike Buckley
+44-1457-877718 (T)
+44-1457-877721 (F)
mikebuckley(a)44comms.com
----- Original Message -----
From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM>
To: <ITU-SG16(a)MAILBAG.INTEL.COM>
Sent: Tuesday, August 15, 2000 8:21 PM
Subject: Re: H.323 QOS
Hi, Mike:
Yes, you are right that NATs and firewalls problems are yet to be solved
with complete satisfaction from address translation point of view. This may
be a separate work item all by itself.
I do not think that we will bring H.245 to address those problems. In fact,
I have not seen any proposal in that direction.
We have to separate our works step by step.
I would not like to include those general problems as a part of H.323 OQS
for now. Let a separate group or annexes deal with those special problems so
that we can use those solutions for QOS as well, if needed.
Best regards,
Radhika R. Roy
AT&T
-----Original Message-----
From: Mike Buckley [mailto:mikebuckley@44COMMS.COM]
Sent: Tuesday, August 15, 2000 1:13 PM
To: ITU-SG16(a)MAILBAG.INTEL.COM
Subject: Re: H.323 QOS
Hi Radhika,
This model is only valid I think when you have end to end address
transparency as in the Internet. When different transport network domains
are present this doesn't necessarily work. NATs and firewalls will mean
that IP addresses and port numbers in different domains will be different
for the same media stream. Terminating IP and port numbers may well be
different at each end of the call. This is one reason why H.323 will not
work through firewalls. To fix this gatekeepers will have to perform a
mediating function with the H.323 domain and the transport domains. This
mediation will not be via H.245.
SIP has the same problems by the way.
Mike
Mike Buckley
+44-1457-877718 (T)
+44-1457-877721 (F)
mikebuckley(a)44comms.com
----- Original Message -----
From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM>
To: <ITU-SG16(a)MAILBAG.INTEL.COM>
Sent: Tuesday, August 15, 2000 2:15 PM
Subject: Re: H.323 QOS
Hi, Mike:
Just for information, H.245 does many things. As I indicated earlier, one of
the most important things of H.245 is the opening and closing of the logical
channels that binds the application layer's logical connection abstractions
to all transport network connections (e.g., ATM, etc).
So, this is the fundamental mission of H.245 to provide the continuity
between the application layer and the lower layer in a transport independent
way using the universal abstractions. These abstractions can be for anything
that we can think of.
Hope this helps.
Best regards,
Radhika R. Roy
AT&T
-----Original Message-----
From: Mike Buckley [mailto:mikebuckley@44COMMS.COM]
Sent: Tuesday, August 15, 2000 8:22 AM
To: ITU-SG16(a)MAILBAG.INTEL.COM
Subject: Re: H.323 QOS
Hi Radhika,
This use of H.245 as a bridging mechanism is where I have difficulties. The
original intenmt behind H.245 was media control and negociation. Transport
mechanisms should not be signalled in H.245 or elsewhere in the application.
This is entirely the business of the transport network provider.
Unfortunately I will not be present in Portland, however, I am happy to
continue this productive dialogue on the list with a view to providing a new
draft in the next few weeks.
Regards,
Mike
Mike Buckley
+44-1457-877718 (T)
+44-1457-877721 (F)
mikebuckley(a)44comms.com
----- Original Message -----
From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM>
To: <ITU-SG16(a)MAILBAG.INTEL.COM>
Sent: Monday, August 14, 2000 7:29 PM
Subject: Re: H.323 QOS
Hi, Mike:
I guess that we have agreement on the fundamental basis. However, I have
problems when you translate this in signaling terms. As I have explained
earlier that we are following the exiting framework of H.323 which is the
application layer, and H.323 is transported over one or different transport
networks. H.323 uses H.245 as a common mechanism that helps to transports
the abstraction of H.323 application signaling messages over any networks
(e.g., IP, ATM, etc).
You may look to the H.245 spec very carefully instead of making any
generalized statement.
H.245 provides the bridging between the application layer and transport
layer mechanism. For example, H.245's OLC abstraction is the link for ATM
network layer logical connection as well as for other transport networks.
In the same token, H.323 QOS abstraction may also provide link to the lower
transport layer QOS signaling mechanisms (e.g., RSVP, DiffServ, MPLS, ATM
QOS, etc), if needed. H.323 DOES support RSVP and ATM QOS now.
Please also see my reply embedded in you email [RRR].
Again, I would suggest to bring contributions explaining the solution and we
will go from there. In absence of your contributions, I would suggest to
provide comments on Appendix of H.323 QOS Annex N. We can then answer your
questions step by step.
Best regards,
Radhika R. Roy
AT&T
-----Original Message-----
From: Mike Buckley [mailto:mikebuckley@44COMMS.COM]
Sent: Monday, August 14, 2000 12:56 PM
To: ITU-SG16(a)MAILBAG.INTEL.COM
Subject: Re: H.323 QOS
Radhika,
>However, this is only good for the single network. For example,
>end-to-end RSVP or end-to-end ATM QOS.
>If there are multiple networks or if a single IP network implements RSVP in
>one domain, DiffServ in another domain, and MPLS in another domain, there
is
>no transparent H.323 QOS signaling mechanism that is universal on
end-to-end
>basis so that it can be mapped over the RSVP, DiffServ, MPLS, ATM QOS, etc
>transparently
This is the nub of the problem and I am afraid why this approach is flawed.
[RRR] I am NOT afraid of anything. Rather we are solving all problems
including the above as well. No one should be afraid of anything. The only
thing that I can suggest is to bring contributions. We will go from there.
Please remember that H.323 QOS supports RSVP and ATM QOS and we MUST provide
backward compatibility. We will be waiting to see contributions from you to
prove your points whether things are flawed or not. Please read Appnedix of
H.323 QOS Annex N very carefully along with exiting H.323 and H.245
standard how they support H.323 QOS for RSVP and ATM QOS.
>We have shown how the H.323 QOS can
>be mapped over the RSVP, DiffServ, ATM QOS, etc. if needed.
This mapping must be done within the transport plane not by the application.
All the application needs to specify are the entries in your Table 1. i.e
delay, jitter. packet loss and peak bit rate (the latter parameter for
policy enforcement and resource reservation).
[RRR] Please see my generalized clarification how H.245 provides translation
between H.323 signaling schemes over the lower layer transport networks
(e.g., IP, ATM, etc). The mechanism already exists in H.323 and this is the
beauty of the transport independent H.323 application. Now there are two
separate things: one is what the calling side of the application demands and
what the called side of the application agrees on. This is called
negotiation capability (e.g., choosing a particular type codec that has a
certain bandwidth, jitter, and other requirements). How the choosing
criteria is determined, the H.323 application is NOT aware of those things.
It may depend on many criteria (e.g., policy, bandwidth, type of network
[e.g., IP, ATM], pricing, security, personal preferences, etc.), but H.323
is not involved. These are separate issues and we are NOT addressing at the
H.323 layer.
I am still not clkear how you propose to signal these parameters to the
transport plane.
[RRR] It is NOT new in H.323, and this mechanism already exits. Please see
the support of RSVP and ATM QOS in H.323/H.245 spec. We are not inventing
anything NEW here. Then, if you read Appendix of H.323 QOS Annex N very
carefully, you will find how it happening (whether you call it as transport
plane or something else, it does not matter).
I think we are getting loser to a common understanding.
Mike
Mike Buckley
+44-1457-877718 (T)
+44-1457-877721 (F)
mikebuckley(a)44comms.com
----- Original Message -----
From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM>
To: <ITU-SG16(a)MAILBAG.INTEL.COM>
Sent: Monday, August 14, 2000 2:37 PM
Subject: Re: H.323 QOS
Hi, Bob:
I agree completely agree with you.
In fact, we are all trying to achieve the same goal. For example, H.323 does
supports QOS today via H.245. You can easily see that RSVP and ATM QOS are
supported using H.245. The beauty of this approach is that H.245 is still
transport independent. All we have done here is: the abstraction of H.245
has been used to support the RSVP and ATM QOS to implement the network layer
QOS. However, this is only good for the single network. For example,
end-to-end RSVP or end-to-end ATM QOS.
If there are multiple networks or if a single IP network implements RSVP in
one domain, DiffServ in another domain, and MPLS in another domain, there is
no transparent H.323 QOS signaling mechanism that is universal on end-to-end
basis so that it can be mapped over the RSVP, DiffServ, MPLS, ATM QOS, etc
transparently.
In Appendix of H.323 Annex N, we have done the same. We have the abstraction
of H.323 QOS in the application layer. We have shown how the H.323 QOS can
be mapped over the RSVP, DiffServ, ATM QOS, etc. if needed. It also provides
the backward compatibility with the existing H.323 standard. However, we
have done only for the pre-call setup signaling part. We have not done the
call setup part yet. In the call setup part, we will include H.245 in a
similar way what H.323 is supporting RSVP and ATM QOS today in a monolithic
network.
I appreciate your email.
Best regards,
Radhika R. Roy
AT&T
> -----Original Message-----
> From: Callaghan, Robert [SMTP:Robert.Callaghan@icn.siemens.com]
> Sent: Monday, August 14, 2000 9:08 AM
> To: Roy, Radhika R, ALCOO
> Cc: 'Mailing list for parties associated with ITU-T Study Group 16'
> Subject: RE: H.323 QOS
>
> Roy,
>
> In my view, the network, as a minimum, needs only provide transport.
> H.323
> is an application using this transport and is not different from any other
> application being transported. Any application may request a desired
> quality of service that the network may grant based on policies, service
> level agreements, and availability. Each data connection used by an
> application may request a different QOS. Most likely H.323 is such an
> application as needing an enhanced QOS. This simple case should work.
> This
> is all that is required.
>
> In addition to transport, the network may optionally provide other
> additional services. These services may include application layer
> routing.
> These optional services should be configured and indicated independently
> from the basic transport QOS.
>
> It is correct that H.323, as an application, is (mostly) transport
> independent. However, the interface between the application and the
> transport layer is not transport independent. The interface specification
> used to request a given QOS is totally dependant on the standards body
> that
> specified the transport layer; and for this there has been little or no
> coordination.
>
> Because transport QOS over IP is based on IETF specifications, it is
> necessary that the interface used to request a given QOS conform to the
> appropriate IETF specification. If such an interface specification is not
> available, that input might be provided to the appropriate IETF body as to
> the requirements.
>
> I can see the endpoints negotiating the desired QOS base on need, price,
> and
> other considerations. For me, this is the limit to the application layer
> involvement in QOS negotiation. At this point, the application
> negotiations
> with the transport provider as to the desired and available QOS. It is up
> to the transport provider to arrange for the end-to-end QOS. (Again, it
> is
> not necessary for the transport network to know that H.323 is involved in
> the transported data. In fact it may be encrypted in order to mask the
> presence of voice transport.)
>
> For me, this is simple.
>
> Bob
>
> ------------------------------------------------------------------
> Robert Callaghan
> Siemens Enterprise Networks
> Tel: +1.561.923.1756 Fax: +1.561.923.1403
> Email: Robert.Callaghan(a)ICN.Siemens.com
> ------------------------------------------------------------------
>
> -----Original Message-----
> From: Roy, Radhika R, ALCOO [mailto:rrroy@ATT.COM]
> Sent: Friday, August 11, 2000 7:59 AM
> To: ITU-SG16(a)mailbag.cps.intel.com
> Subject: Re: H.323 QOS
>
> Hi, Mike:
>
> Let me try again.
>
> What is the reference point of H.323 QOS? Is it not H.323? If it is so,
> what
> do we mean by H.323?
>
> The answer is: Audio (different codecs), Video (different codecs), and
> Data
> (T.120 applications) that are used by H.323.
>
> What are the QOS/performance characteristics of audio, video, and data
> from
> the application point of view that is generated by audio codecs, video
> codecs, and data (T.120) applications?
>
> These QOS/performance characteristics come from the SOURCE codecs and data
> applications. Per transport independent H.323 specifications, an enduser
> express their QOS/performance requirements on end-to-end basis purely from
> application point of view irrespective of the transport network (e.g., IP,
> ATM, etc.).
>
> Moreover, H.323 is meant for the packet network, not for any
> circuit-switched network like PSTN or ISDN.
>
> Let us NOT go beyond this before we start debating transport layer QOS or
> service provider requirements. These are NOT the concern of H.323. H.323
> is
> the transport independent application.
>
> H.323v2/v3/v4 has also provided mechanisms how RSVP and ATM QOS can be
> used
> for H.323 audio, video, and data. So, H.323 QOS that will be defined in
> H.323 Annex N MUST provide mapping for the backward compatibility. It is a
> requirement that MUST be met per the norm of ITU-T.
>
> So, what is left for mapping? Mapping is simply a by-product of the above
> requirement. Mapping is simply a table, nothing else.
>
> Did I miss anything?
>
> Best regards,
> Radhika R. Roy
> AT&T
>
> -----Original Message-----
> From: Mike Buckley [mailto:mikebuckley@44COMMS.COM]
> Sent: Thursday, August 10, 2000 10:19 PM
> To: ITU-SG16(a)MAILBAG.INTEL.COM
> Subject: Re: H.323 QOS
>
>
> Radhika,
>
> Thanks for the input which I welcome as I will unfortunately not be
> present
> at Portland.
>
> Let me ask a few questions and make a few comments hopefully with the
> intent
> of opening up the debate.
>
> 1. I am not sure I understand your concept of a mapping table between the
> H.323 QOS and the transport layer QoS. My understanding is that QoS is on
> three levels:
>
> a) that specified from a service point of view between the user and
> service
> provider (e.g PSTN quality, conference quality etc) This is the domain of
> the speech experts and can be characterised by Listener Speech Quaklity
> (MOS), end to end delay, and absolute category rating, R.
>
> b) application specific parameters, (e.g. equipment delays, codec choice
> and performance, codec frame size, packetisation arrangements, jitter
> buffer
> design, overall packet loss etc.) Optimisation of all these will
> determine
> what can be delivered in a).
>
> c) transport parameters for a given choice of application parameters.
> This
> boils down only to three parameters as far as I cna see: tranport network
> delay, packet delay variation in the transport network and packet loss in
> the transport network. Again these parameters will determine the results
> in
> a) for a given choice of the parameters in b). These parameters are
> generic
> from the perspective of the transport network. i.e the transport network
> does not need to know the details of the application.
>
> So the sequence of cause and effect and control is:
>
> a) User requests QoS class from service provider,
> b) Service provider determines application specific parameters in
> conjunction with users equipment and other service providers,
> c) Service provider requests required delay, delay variation and packet
> loss from network provider.
>
> I see no need for mapping here. The only QoS info flows within the
> application are specific to the application and those between the
> application (service provider) and the transport network are generic. i.e.
> delay, jitter and packet loss. Have I missed something?
>
> 2. The issue of bit rate and media stream statistics I think need to be
> decoupled from QoS. These are specified to enable optimisation of
> resources
> within the transport network. They have no QoS significance from an
> application point of view. i.e the apllication does not care about the
> media stream bit rate and statistics but the transport network provider
> does
> as it eats up his resource. They may be used for policy enforcement
> however
> in the transport network so they do need to be agreed between service
> provider and network operator. i.e the network operator agrees to provide
> a
> given QoS level (delay, jitter, packet loss) provided the media properties
> are within an agreed profile (bit rate, flow statistics).
>
> 3. The next point is how can the service provider know the statistics of
> a
> particular VBR stream? These can only be specified over a large number of
> similar calls and will depend, for instance, on who is speaking, the
> nature
> of the speech interaction etc etc. They can only be measured not
> calculated. The service provider is in no better position to measure
> these
> than the transport network operator and, in fact, where no gateways are
> involved, may not be able to. On the other hand the class of signal would
> have to be signalled to the network operator for him to be able to
> distinguish which class a particular measurement belonged to. e.g
> voice/speech/data, codec type, conference, multicast etc. So I see no
> purpose in trying to exchange statistics between the service provider
> (application) and transport operator. I think peak bit rate is all that
> can
> be meaningfully excanged. The specification of media class is however
> perhaps worth exploring.
>
> 4. The controlled category has always puzzled me. I only see two
> possibilities. Either the requested QoS level is guaranteed (on a
> statistical basis e.g 95% of all connections over a specified period) or
> not
> guaranteed. Is your controlled category a way of saying guaranteed, not
> to
> 95% but to some lower figure? If you can't put a percentage on it then it
> seems it is plain and simple not guaranteed. Anything that is not
> guaranteed to some specified statistical level is best effort and you
> can't
> say anything more about it. So I only see two categories here.
>
> In summary, I think we need to do three things in Annex N.
>
> a) Figure out the QoS information to be exchanged within the Application
> between service providers and end users. This will go in H.225.0 and
> H.245.
>
> b) Figure out how we are going to signal QoS and media information between
> the application (service providers) and transport domains (IP or ATM
> networks etc). The info is basically delay, jitter, packet loss
> requirements and peak bit rate. We need a protocol for this.
>
> c) we need to work out the interactions between the application QoS
> signal
> flows and the application/transport signal flows. I don't think we need
> worry about how the transport network mechanisms assure the requested QoS
> paramerters. RSVP/Intserv, Diffserv, MPLS, ATM, over provisioning are all
> possibilities.
>
> Would welcome comments and views on the above.
>
> Mike
>
>
> Mike Buckley
> +44-1457-877718 (T)
> +44-1457-877721 (F)
> mikebuckley(a)44comms.com
>
>
> ----- Original Message -----
> From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM>
> To: <ITU-SG16(a)MAILBAG.INTEL.COM>
> Sent: Thursday, August 10, 2000 10:15 PM
> Subject: H.323 QOS
>
>
> Hi, Mike and All:
>
> It is time to discuss about H.323 QOS.
>
> I believe that we have an agreement as follows:
>
> · H.323 QOS MUST be backward compatible to support RSVP and ATM QOS as it
> exists for H.323v2/v3/v4
> · Like H.323 spec, the application level H.323 QOS MUST be independent of
> the transport layer QOS and should support all transport networks (e.g.,
> IP,
> ATM)
> · A mapping table between the H.323 QOS and the transport layer QOS (e.g.,
> IP QOS [DiffServ, RSVP, etc.], ATM QOS [CBR, rt-VBR, nrt-VBR, ABR, etc.])
> should be provided.
>
> From the H.323 multimedia application point of view, there are following
> performance parameters can be used to characterize the traffic
> characteristics:
>
> · Bitrate characteristics: Peak bit rate (PBR) or peak rate (PR),
> Sustained
> bit rate (SBR) or average rate (AR), minimum bit rate (MBR) or minimum
> rate
> (MR), and mean bust size (MBS)
> · Delay and loss characteristics: end-to-end delay (EED) or delay,
> end-to-end delay variation (EEDV) or delay variation (DV), and
> bit-error-rate (BER) or (packet) loss rate (LR)
>
> We can now form a table with all parameters as follows:
>
> Table 1: H.323 Multimedia Application Performance Matrix
> Audio (codecs)--- Video (codecs)--- Data
> (T.120)
> PBR/PR Yes/No/Value Yes/No/Value Yes/No/value
> SBR/AR Yes/No/Value Yes/No/Value Yes/No/value
> MBR/MR Yes/No/Value Yes/No/Value Yes/No/value
> MBS Yes/No/Value Yes/No/Value Yes/No/value
> EED/Delay Yes/No/Value Yes/No/Value Yes/No/value
> EEDV/DV Yes/No/Value Yes/No/Value Yes/No/value
> BER/LR Yes/No/Value Yes/No/Value Yes/No/value
>
> From the above table we will have the opportunity to choose each parameter
> for each medium (audio, video, data) that makes sense from the
> application's
> and enduser's point of view. Again, these parameters can be specified as
> follows:
>
> · Guaranteed: The value specified for each parameter MUST be guaranteed.
> · Controlled: The value specified for each parameter MAY be satisfied as
> far
> as practicable (possibly with certain range), but definitely NOT
> guaranteed.
> · Best effort: No commitment will be made.
>
> Now each medium (e.g., audio, video, or data) will have different
> categories
> of performance matrix depending on its selection criteria and this can
> also
> be mapped to RSVP, ATM QOS, and others, if needed.
>
> Once we agree on this format, the next step is to create H.323 QOS
> signaling
> messages.
>
> This is my input for discussion in the upcoming Portland Q.13 meeting for
> H.323 QOS.
>
> I like to see the comments from other members as well.
>
> Best regards,
> Radhika R. Roy
> AT&T
> +1 732 420 1580
> rrroy(a)att.com
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv(a)mailbag.intel.com
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv(a)mailbag.intel.com
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
1
0
Mi, Mike:
Please see my response below [RRR].
Best regards,
Radhika R. Roy
AT&T
-----Original Message-----
From: Mike Buckley [mailto:mikebuckley@44COMMS.COM]
Sent: Wednesday, August 16, 2000 2:37 PM
To: ITU-SG16(a)MAILBAG.INTEL.COM
Subject: Re: H.323 QOS
>As I told, I have objections when TIPHON model does NOT say which items
they
>need to address in which questions or which study groups. The confusion
>comes when they "dump" everything in one question.
You have totally lost me here.
[RRR] For example, bringing interworking between PSTN and Packet Switching
networks as a part of Q.13/16, and similarly many other items that are
supposed to be a part of other questions of SG16 or other SGs.
Mike
Mike Buckley
+44-1457-877718 (T)
+44-1457-877721 (F)
mikebuckley(a)44comms.com
----- Original Message -----
From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM>
To: <ITU-SG16(a)MAILBAG.INTEL.COM>
Sent: Wednesday, August 16, 2000 5:49 PM
Subject: Re: H.323 QOS
Hi, Mike:
As I said, we will only work in the framework of H.323 (i.e., Q.13/16).
I understand other questions like Q.14 as well and I am a part of it.
We will go step-by-step. We worked for H.323 in Q.13/16 before we developing
Q.14/16 where the interworking issues like H.248 GWs have been addressed. In
the same token, we are also addressing the H.323 mobility. First, we are
developing the H.323 mobility model in Q.13/16. Then we will address the
interoperability between the PSTN and packet switching network mobility
where H.248 will be one of the items, and these items may fall into other
questions including Q.14/16.
As I told, I have objections when TIPHON model does NOT say which items they
need to address in which questions or which study groups. The confusion
comes when they "dump" everything in one question.
As I told before, no one is saying against TIPHON because we all know this:
There are items that are also being addressed by us in the ITU-T in general.
Hope this will clarify.
Let us NOT create confusions mixing things. Let us focus on our work while
inputs from all ITU-T SGs, TIPHON, IETF, IMTC, and other forums are also
welcome.
Best regards,
Radhika R. Roy
AT&T
-----Original Message-----
From: Mike Buckley [mailto:mikebuckley@44COMMS.COM]
Sent: Wednesday, August 16, 2000 11:56 AM
To: ITU-SG16(a)MAILBAG.INTEL.COM
Subject: Re: H.323 QOS
Hi Radhika,
>We MUST not speak about TIPHON models. It confuses people because it
exceeds
>the charter of Q.13/16. we do not like to address issues related to H.248
>now (it is a part of Q.14/16). We will go step-by-step.
I am only referring to the TIPHON model because you did!
Having said that there is nothing confusing in the TIPHON model for the
participants in Q13 - my experience is they are pretty smart people. I
think if we can pick up useful ideas from the work of other groups we should
be open to that.
>Let us wear the "HAT" of H.323 in Q.13/16, not beyond that.
The work of Q.13 and 14 seems pretty seamless to me. That's why the two
questions are often run as one. We should not be too blinkered in our
approach or we will definitely end up with something that is unuseable.
Mike
Mike Buckley
+44-1457-877718 (T)
+44-1457-877721 (F)
mikebuckley(a)44comms.com
----- Original Message -----
From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM>
To: <ITU-SG16(a)MAILBAG.INTEL.COM>
Sent: Wednesday, August 16, 2000 3:44 PM
Subject: Re: H.323 QOS
Hi, Mike:
I understand what you are saying. I took IETF model as example how works can
be divided when TIPHON model is considered in the context of SIP.
In SG16 of Q.13, the charter is clear: It is H.323 that can be used over any
"packet" networks (i.e., transport independent).
In this context, please H.323 specs: H.323, H.225.0, H.225.0 Annex G, and
H.245.
So, our reference is: To extend H.323 to "express" QOS (application layer)
considering audio codecs, video codecs, data (T.120).
Please see Appendix of H.323 Annex N. We will go from there (you can see the
frame work of H.225.0 Annex G - how simple it is - we will follow the
similar model).
This is as simple as stated above.
We MUST not speak about TIPHON models. It confuses people because it exceeds
the charter of Q.13/16. we do not like to address issues related to H.248
now (it is a part of Q.14/16). We will go step-by-step.
Let us wear the "HAT" of H.323 in Q.13/16, not beyond that.
By the way, we are also doing the same thing in H.323 mobility: To extend
H.323 to support mobility in the application layer.
Hope this helps.
Best regards,
Radhika R. Roy
AT&T
-----Original Message-----
From: Mike Buckley [mailto:mikebuckley@44COMMS.COM]
Sent: Wednesday, August 16, 2000 9:56 AM
To: ITU-SG16(a)MAILBAG.INTEL.COM
Subject: Re: H.323 QOS
Hi Radhika,
The problem is I don't see a framework in SG16 for how H.323 will be used in
the real world to solve the general end to end QoS problem.
It's no good putting fields in protocols without some idea of how they are
going to be used in practice. This doesn't mean you want to tie down the
implementer to go down one particular route but you have to have an
architecture in mind when you develop a protocol. The IETFs architecture is
clear - it is the Internet. I would submit that this is not necessarily
what we are doing in SG16.
Let's define the framework of the problem we are going to solve. Much of it
has been covered in this recent thread. But it needs documenting and
general agreement.
TIPHON is developing a framework for VoIP. SG16 is developing a suite of
protocols for VoIP. Both need an agreed architecture. The early
discussions on architecture in TIPHON lead to gateway decomposition and the
birth of H.248. The logical conclusion of this work has lead to the present
TIPHON architecture. Just as the gateway decomposition exercise lead to a
set of requirements and architecture for H.248, the latest TIPHON
architecture leads to a set of requirements for QoS control and a QoS
architecture. See DTS 5003. I want to get general agreement on the problem
we are solving and the roadmap of how we are going to get there. Then we
can start on the ASN.1.
We should not be considering SIP/SDP in SG16 - neither of these protocols
are needed if we do our job right with H.323. Policy in the IETF is
exclusively transport domain policy. Again it has nothing to do with the
policies we may adopt on application level QoS. As far as I understand the
MCI work this is all about the Internet and makes no recognition of H.323 or
other applications. So lets not get lead astray by orthogonal activities to
those we are engaged on. Our job is application level QoS and defining the
services we need from the transport domain to deliver it. We are not
solving problems in the transport domain. But we can draw up a set of
requirements for an interface and feed this to the IETF.
Let's get our problem statement clear and our TORs and architecture
documented and agreed.
Mike
Mike Buckley
+44-1457-877718 (T)
+44-1457-877721 (F)
mikebuckley(a)44comms.com
----- Original Message -----
From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM>
To: <ITU-SG16(a)MAILBAG.INTEL.COM>
Sent: Wednesday, August 16, 2000 2:08 PM
Subject: Re: H.323 QOS
Hi, Mike:
Our aim is to extend H.323 for supporting QOS. The framework is already
there.
Please see H.323 and H.225.0 Annex G specs how the general framework is done
in the context of H.323.
Again, we are dealing with Q.13/16 and TIPHON exceeds the charter of
Q.13/16. It goes beyond H.323 and involves almost all SGs of ITU-T and IETF
that are dealing with QOS.
I understand what TIPHON is trying to do and TIPHON is just NOT limited to
Q.13/16. The same problem has been in the IETF when TIPHON presented its QOS
model for extending SIP. It appears that it exceeds the charter of SIP.
Please note that people are NOT saying that TIPHON's work is NOT needed. All
they are saying: Let us divide the work in different items and each item
will have its place in the corresponding WGs. For example, policy will be
addressed in the Policy WG, if any particular messages in SIP needs to be
extended to support QOS following the SIP charter that work may be addressed
in the SIP WG, if any particular item needs to extend in SDP to support QOS
that work needs to be done in the MMUSIC.
>From end-to-end call point of view, people will need SIP, SDP, Policy,
Security, Billing, firewalls, NATs, and others. when the standards in all
areas are done, people just use them. This is the second step. I have also
been working with Joon Maeng of VTEL in this area because Joon submitted a
contribution in Q.13/16 last Feb'99 meeting. We are waiting to complete the
H.323 QOS work first.
You can also see an IETF contribution from MCI WorldCom how the interdomain
QOS can be used by SIP using Policy, Security, etc. This work is dependent
on the standard work of Policy WG, and others. Again, this contribution for
supporting interdomain QOS by SIP using Policy, etc. does NOT need any
additional standard work is SIP, it is, rather, an implementation that shows
how an end-to-end call can use all those standards including QOS that have
been developed in different WGs.
Appendix of H.323 QOS Annex N has the general framework. Now you can go
through those items and please let us know where you like to see changes and
why.
Best regards,
Radhika R. Roy
AT&T
-----Original Message-----
From: Mike Buckley [mailto:mikebuckley@44COMMS.COM]
Sent: Tuesday, August 15, 2000 7:51 PM
To: ITU-SG16(a)MAILBAG.INTEL.COM
Subject: Re: H.323 QOS
Radhika,
My aim here is to come up with a general QoS framework in H.323 that will
handle all these situatioins not just special cases. I think we agree on
this.
I would be reluctant to solve a special case without an idea of how we are
going to solve the general case. This can only lead to backward
compatibility issues.
I believe the TIPHON approach is totally general. However I agree it need
some new interfaces defining.
Mike
Mike Buckley
+44-1457-877718 (T)
+44-1457-877721 (F)
mikebuckley(a)44comms.com
----- Original Message -----
From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM>
To: <ITU-SG16(a)MAILBAG.INTEL.COM>
Sent: Tuesday, August 15, 2000 8:21 PM
Subject: Re: H.323 QOS
Hi, Mike:
Yes, you are right that NATs and firewalls problems are yet to be solved
with complete satisfaction from address translation point of view. This may
be a separate work item all by itself.
I do not think that we will bring H.245 to address those problems. In fact,
I have not seen any proposal in that direction.
We have to separate our works step by step.
I would not like to include those general problems as a part of H.323 OQS
for now. Let a separate group or annexes deal with those special problems so
that we can use those solutions for QOS as well, if needed.
Best regards,
Radhika R. Roy
AT&T
-----Original Message-----
From: Mike Buckley [mailto:mikebuckley@44COMMS.COM]
Sent: Tuesday, August 15, 2000 1:13 PM
To: ITU-SG16(a)MAILBAG.INTEL.COM
Subject: Re: H.323 QOS
Hi Radhika,
This model is only valid I think when you have end to end address
transparency as in the Internet. When different transport network domains
are present this doesn't necessarily work. NATs and firewalls will mean
that IP addresses and port numbers in different domains will be different
for the same media stream. Terminating IP and port numbers may well be
different at each end of the call. This is one reason why H.323 will not
work through firewalls. To fix this gatekeepers will have to perform a
mediating function with the H.323 domain and the transport domains. This
mediation will not be via H.245.
SIP has the same problems by the way.
Mike
Mike Buckley
+44-1457-877718 (T)
+44-1457-877721 (F)
mikebuckley(a)44comms.com
----- Original Message -----
From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM>
To: <ITU-SG16(a)MAILBAG.INTEL.COM>
Sent: Tuesday, August 15, 2000 2:15 PM
Subject: Re: H.323 QOS
Hi, Mike:
Just for information, H.245 does many things. As I indicated earlier, one of
the most important things of H.245 is the opening and closing of the logical
channels that binds the application layer's logical connection abstractions
to all transport network connections (e.g., ATM, etc).
So, this is the fundamental mission of H.245 to provide the continuity
between the application layer and the lower layer in a transport independent
way using the universal abstractions. These abstractions can be for anything
that we can think of.
Hope this helps.
Best regards,
Radhika R. Roy
AT&T
-----Original Message-----
From: Mike Buckley [mailto:mikebuckley@44COMMS.COM]
Sent: Tuesday, August 15, 2000 8:22 AM
To: ITU-SG16(a)MAILBAG.INTEL.COM
Subject: Re: H.323 QOS
Hi Radhika,
This use of H.245 as a bridging mechanism is where I have difficulties. The
original intenmt behind H.245 was media control and negociation. Transport
mechanisms should not be signalled in H.245 or elsewhere in the application.
This is entirely the business of the transport network provider.
Unfortunately I will not be present in Portland, however, I am happy to
continue this productive dialogue on the list with a view to providing a new
draft in the next few weeks.
Regards,
Mike
Mike Buckley
+44-1457-877718 (T)
+44-1457-877721 (F)
mikebuckley(a)44comms.com
----- Original Message -----
From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM>
To: <ITU-SG16(a)MAILBAG.INTEL.COM>
Sent: Monday, August 14, 2000 7:29 PM
Subject: Re: H.323 QOS
Hi, Mike:
I guess that we have agreement on the fundamental basis. However, I have
problems when you translate this in signaling terms. As I have explained
earlier that we are following the exiting framework of H.323 which is the
application layer, and H.323 is transported over one or different transport
networks. H.323 uses H.245 as a common mechanism that helps to transports
the abstraction of H.323 application signaling messages over any networks
(e.g., IP, ATM, etc).
You may look to the H.245 spec very carefully instead of making any
generalized statement.
H.245 provides the bridging between the application layer and transport
layer mechanism. For example, H.245's OLC abstraction is the link for ATM
network layer logical connection as well as for other transport networks.
In the same token, H.323 QOS abstraction may also provide link to the lower
transport layer QOS signaling mechanisms (e.g., RSVP, DiffServ, MPLS, ATM
QOS, etc), if needed. H.323 DOES support RSVP and ATM QOS now.
Please also see my reply embedded in you email [RRR].
Again, I would suggest to bring contributions explaining the solution and we
will go from there. In absence of your contributions, I would suggest to
provide comments on Appendix of H.323 QOS Annex N. We can then answer your
questions step by step.
Best regards,
Radhika R. Roy
AT&T
-----Original Message-----
From: Mike Buckley [mailto:mikebuckley@44COMMS.COM]
Sent: Monday, August 14, 2000 12:56 PM
To: ITU-SG16(a)MAILBAG.INTEL.COM
Subject: Re: H.323 QOS
Radhika,
>However, this is only good for the single network. For example,
>end-to-end RSVP or end-to-end ATM QOS.
>If there are multiple networks or if a single IP network implements RSVP in
>one domain, DiffServ in another domain, and MPLS in another domain, there
is
>no transparent H.323 QOS signaling mechanism that is universal on
end-to-end
>basis so that it can be mapped over the RSVP, DiffServ, MPLS, ATM QOS, etc
>transparently
This is the nub of the problem and I am afraid why this approach is flawed.
[RRR] I am NOT afraid of anything. Rather we are solving all problems
including the above as well. No one should be afraid of anything. The only
thing that I can suggest is to bring contributions. We will go from there.
Please remember that H.323 QOS supports RSVP and ATM QOS and we MUST provide
backward compatibility. We will be waiting to see contributions from you to
prove your points whether things are flawed or not. Please read Appnedix of
H.323 QOS Annex N very carefully along with exiting H.323 and H.245
standard how they support H.323 QOS for RSVP and ATM QOS.
>We have shown how the H.323 QOS can
>be mapped over the RSVP, DiffServ, ATM QOS, etc. if needed.
This mapping must be done within the transport plane not by the application.
All the application needs to specify are the entries in your Table 1. i.e
delay, jitter. packet loss and peak bit rate (the latter parameter for
policy enforcement and resource reservation).
[RRR] Please see my generalized clarification how H.245 provides translation
between H.323 signaling schemes over the lower layer transport networks
(e.g., IP, ATM, etc). The mechanism already exists in H.323 and this is the
beauty of the transport independent H.323 application. Now there are two
separate things: one is what the calling side of the application demands and
what the called side of the application agrees on. This is called
negotiation capability (e.g., choosing a particular type codec that has a
certain bandwidth, jitter, and other requirements). How the choosing
criteria is determined, the H.323 application is NOT aware of those things.
It may depend on many criteria (e.g., policy, bandwidth, type of network
[e.g., IP, ATM], pricing, security, personal preferences, etc.), but H.323
is not involved. These are separate issues and we are NOT addressing at the
H.323 layer.
I am still not clkear how you propose to signal these parameters to the
transport plane.
[RRR] It is NOT new in H.323, and this mechanism already exits. Please see
the support of RSVP and ATM QOS in H.323/H.245 spec. We are not inventing
anything NEW here. Then, if you read Appendix of H.323 QOS Annex N very
carefully, you will find how it happening (whether you call it as transport
plane or something else, it does not matter).
I think we are getting loser to a common understanding.
Mike
Mike Buckley
+44-1457-877718 (T)
+44-1457-877721 (F)
mikebuckley(a)44comms.com
----- Original Message -----
From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM>
To: <ITU-SG16(a)MAILBAG.INTEL.COM>
Sent: Monday, August 14, 2000 2:37 PM
Subject: Re: H.323 QOS
Hi, Bob:
I agree completely agree with you.
In fact, we are all trying to achieve the same goal. For example, H.323 does
supports QOS today via H.245. You can easily see that RSVP and ATM QOS are
supported using H.245. The beauty of this approach is that H.245 is still
transport independent. All we have done here is: the abstraction of H.245
has been used to support the RSVP and ATM QOS to implement the network layer
QOS. However, this is only good for the single network. For example,
end-to-end RSVP or end-to-end ATM QOS.
If there are multiple networks or if a single IP network implements RSVP in
one domain, DiffServ in another domain, and MPLS in another domain, there is
no transparent H.323 QOS signaling mechanism that is universal on end-to-end
basis so that it can be mapped over the RSVP, DiffServ, MPLS, ATM QOS, etc
transparently.
In Appendix of H.323 Annex N, we have done the same. We have the abstraction
of H.323 QOS in the application layer. We have shown how the H.323 QOS can
be mapped over the RSVP, DiffServ, ATM QOS, etc. if needed. It also provides
the backward compatibility with the existing H.323 standard. However, we
have done only for the pre-call setup signaling part. We have not done the
call setup part yet. In the call setup part, we will include H.245 in a
similar way what H.323 is supporting RSVP and ATM QOS today in a monolithic
network.
I appreciate your email.
Best regards,
Radhika R. Roy
AT&T
> -----Original Message-----
> From: Callaghan, Robert [SMTP:Robert.Callaghan@icn.siemens.com]
> Sent: Monday, August 14, 2000 9:08 AM
> To: Roy, Radhika R, ALCOO
> Cc: 'Mailing list for parties associated with ITU-T Study Group 16'
> Subject: RE: H.323 QOS
>
> Roy,
>
> In my view, the network, as a minimum, needs only provide transport.
> H.323
> is an application using this transport and is not different from any other
> application being transported. Any application may request a desired
> quality of service that the network may grant based on policies, service
> level agreements, and availability. Each data connection used by an
> application may request a different QOS. Most likely H.323 is such an
> application as needing an enhanced QOS. This simple case should work.
> This
> is all that is required.
>
> In addition to transport, the network may optionally provide other
> additional services. These services may include application layer
> routing.
> These optional services should be configured and indicated independently
> from the basic transport QOS.
>
> It is correct that H.323, as an application, is (mostly) transport
> independent. However, the interface between the application and the
> transport layer is not transport independent. The interface specification
> used to request a given QOS is totally dependant on the standards body
> that
> specified the transport layer; and for this there has been little or no
> coordination.
>
> Because transport QOS over IP is based on IETF specifications, it is
> necessary that the interface used to request a given QOS conform to the
> appropriate IETF specification. If such an interface specification is not
> available, that input might be provided to the appropriate IETF body as to
> the requirements.
>
> I can see the endpoints negotiating the desired QOS base on need, price,
> and
> other considerations. For me, this is the limit to the application layer
> involvement in QOS negotiation. At this point, the application
> negotiations
> with the transport provider as to the desired and available QOS. It is up
> to the transport provider to arrange for the end-to-end QOS. (Again, it
> is
> not necessary for the transport network to know that H.323 is involved in
> the transported data. In fact it may be encrypted in order to mask the
> presence of voice transport.)
>
> For me, this is simple.
>
> Bob
>
> ------------------------------------------------------------------
> Robert Callaghan
> Siemens Enterprise Networks
> Tel: +1.561.923.1756 Fax: +1.561.923.1403
> Email: Robert.Callaghan(a)ICN.Siemens.com
> ------------------------------------------------------------------
>
> -----Original Message-----
> From: Roy, Radhika R, ALCOO [mailto:rrroy@ATT.COM]
> Sent: Friday, August 11, 2000 7:59 AM
> To: ITU-SG16(a)mailbag.cps.intel.com
> Subject: Re: H.323 QOS
>
> Hi, Mike:
>
> Let me try again.
>
> What is the reference point of H.323 QOS? Is it not H.323? If it is so,
> what
> do we mean by H.323?
>
> The answer is: Audio (different codecs), Video (different codecs), and
> Data
> (T.120 applications) that are used by H.323.
>
> What are the QOS/performance characteristics of audio, video, and data
> from
> the application point of view that is generated by audio codecs, video
> codecs, and data (T.120) applications?
>
> These QOS/performance characteristics come from the SOURCE codecs and data
> applications. Per transport independent H.323 specifications, an enduser
> express their QOS/performance requirements on end-to-end basis purely from
> application point of view irrespective of the transport network (e.g., IP,
> ATM, etc.).
>
> Moreover, H.323 is meant for the packet network, not for any
> circuit-switched network like PSTN or ISDN.
>
> Let us NOT go beyond this before we start debating transport layer QOS or
> service provider requirements. These are NOT the concern of H.323. H.323
> is
> the transport independent application.
>
> H.323v2/v3/v4 has also provided mechanisms how RSVP and ATM QOS can be
> used
> for H.323 audio, video, and data. So, H.323 QOS that will be defined in
> H.323 Annex N MUST provide mapping for the backward compatibility. It is a
> requirement that MUST be met per the norm of ITU-T.
>
> So, what is left for mapping? Mapping is simply a by-product of the above
> requirement. Mapping is simply a table, nothing else.
>
> Did I miss anything?
>
> Best regards,
> Radhika R. Roy
> AT&T
>
> -----Original Message-----
> From: Mike Buckley [mailto:mikebuckley@44COMMS.COM]
> Sent: Thursday, August 10, 2000 10:19 PM
> To: ITU-SG16(a)MAILBAG.INTEL.COM
> Subject: Re: H.323 QOS
>
>
> Radhika,
>
> Thanks for the input which I welcome as I will unfortunately not be
> present
> at Portland.
>
> Let me ask a few questions and make a few comments hopefully with the
> intent
> of opening up the debate.
>
> 1. I am not sure I understand your concept of a mapping table between the
> H.323 QOS and the transport layer QoS. My understanding is that QoS is on
> three levels:
>
> a) that specified from a service point of view between the user and
> service
> provider (e.g PSTN quality, conference quality etc) This is the domain of
> the speech experts and can be characterised by Listener Speech Quaklity
> (MOS), end to end delay, and absolute category rating, R.
>
> b) application specific parameters, (e.g. equipment delays, codec choice
> and performance, codec frame size, packetisation arrangements, jitter
> buffer
> design, overall packet loss etc.) Optimisation of all these will
> determine
> what can be delivered in a).
>
> c) transport parameters for a given choice of application parameters.
> This
> boils down only to three parameters as far as I cna see: tranport network
> delay, packet delay variation in the transport network and packet loss in
> the transport network. Again these parameters will determine the results
> in
> a) for a given choice of the parameters in b). These parameters are
> generic
> from the perspective of the transport network. i.e the transport network
> does not need to know the details of the application.
>
> So the sequence of cause and effect and control is:
>
> a) User requests QoS class from service provider,
> b) Service provider determines application specific parameters in
> conjunction with users equipment and other service providers,
> c) Service provider requests required delay, delay variation and packet
> loss from network provider.
>
> I see no need for mapping here. The only QoS info flows within the
> application are specific to the application and those between the
> application (service provider) and the transport network are generic. i.e.
> delay, jitter and packet loss. Have I missed something?
>
> 2. The issue of bit rate and media stream statistics I think need to be
> decoupled from QoS. These are specified to enable optimisation of
> resources
> within the transport network. They have no QoS significance from an
> application point of view. i.e the apllication does not care about the
> media stream bit rate and statistics but the transport network provider
> does
> as it eats up his resource. They may be used for policy enforcement
> however
> in the transport network so they do need to be agreed between service
> provider and network operator. i.e the network operator agrees to provide
> a
> given QoS level (delay, jitter, packet loss) provided the media properties
> are within an agreed profile (bit rate, flow statistics).
>
> 3. The next point is how can the service provider know the statistics of
> a
> particular VBR stream? These can only be specified over a large number of
> similar calls and will depend, for instance, on who is speaking, the
> nature
> of the speech interaction etc etc. They can only be measured not
> calculated. The service provider is in no better position to measure
> these
> than the transport network operator and, in fact, where no gateways are
> involved, may not be able to. On the other hand the class of signal would
> have to be signalled to the network operator for him to be able to
> distinguish which class a particular measurement belonged to. e.g
> voice/speech/data, codec type, conference, multicast etc. So I see no
> purpose in trying to exchange statistics between the service provider
> (application) and transport operator. I think peak bit rate is all that
> can
> be meaningfully excanged. The specification of media class is however
> perhaps worth exploring.
>
> 4. The controlled category has always puzzled me. I only see two
> possibilities. Either the requested QoS level is guaranteed (on a
> statistical basis e.g 95% of all connections over a specified period) or
> not
> guaranteed. Is your controlled category a way of saying guaranteed, not
> to
> 95% but to some lower figure? If you can't put a percentage on it then it
> seems it is plain and simple not guaranteed. Anything that is not
> guaranteed to some specified statistical level is best effort and you
> can't
> say anything more about it. So I only see two categories here.
>
> In summary, I think we need to do three things in Annex N.
>
> a) Figure out the QoS information to be exchanged within the Application
> between service providers and end users. This will go in H.225.0 and
> H.245.
>
> b) Figure out how we are going to signal QoS and media information between
> the application (service providers) and transport domains (IP or ATM
> networks etc). The info is basically delay, jitter, packet loss
> requirements and peak bit rate. We need a protocol for this.
>
> c) we need to work out the interactions between the application QoS
> signal
> flows and the application/transport signal flows. I don't think we need
> worry about how the transport network mechanisms assure the requested QoS
> paramerters. RSVP/Intserv, Diffserv, MPLS, ATM, over provisioning are all
> possibilities.
>
> Would welcome comments and views on the above.
>
> Mike
>
>
> Mike Buckley
> +44-1457-877718 (T)
> +44-1457-877721 (F)
> mikebuckley(a)44comms.com
>
>
> ----- Original Message -----
> From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM>
> To: <ITU-SG16(a)MAILBAG.INTEL.COM>
> Sent: Thursday, August 10, 2000 10:15 PM
> Subject: H.323 QOS
>
>
> Hi, Mike and All:
>
> It is time to discuss about H.323 QOS.
>
> I believe that we have an agreement as follows:
>
> · H.323 QOS MUST be backward compatible to support RSVP and ATM QOS as it
> exists for H.323v2/v3/v4
> · Like H.323 spec, the application level H.323 QOS MUST be independent of
> the transport layer QOS and should support all transport networks (e.g.,
> IP,
> ATM)
> · A mapping table between the H.323 QOS and the transport layer QOS (e.g.,
> IP QOS [DiffServ, RSVP, etc.], ATM QOS [CBR, rt-VBR, nrt-VBR, ABR, etc.])
> should be provided.
>
> From the H.323 multimedia application point of view, there are following
> performance parameters can be used to characterize the traffic
> characteristics:
>
> · Bitrate characteristics: Peak bit rate (PBR) or peak rate (PR),
> Sustained
> bit rate (SBR) or average rate (AR), minimum bit rate (MBR) or minimum
> rate
> (MR), and mean bust size (MBS)
> · Delay and loss characteristics: end-to-end delay (EED) or delay,
> end-to-end delay variation (EEDV) or delay variation (DV), and
> bit-error-rate (BER) or (packet) loss rate (LR)
>
> We can now form a table with all parameters as follows:
>
> Table 1: H.323 Multimedia Application Performance Matrix
> Audio (codecs)--- Video (codecs)--- Data
> (T.120)
> PBR/PR Yes/No/Value Yes/No/Value Yes/No/value
> SBR/AR Yes/No/Value Yes/No/Value Yes/No/value
> MBR/MR Yes/No/Value Yes/No/Value Yes/No/value
> MBS Yes/No/Value Yes/No/Value Yes/No/value
> EED/Delay Yes/No/Value Yes/No/Value Yes/No/value
> EEDV/DV Yes/No/Value Yes/No/Value Yes/No/value
> BER/LR Yes/No/Value Yes/No/Value Yes/No/value
>
> From the above table we will have the opportunity to choose each parameter
> for each medium (audio, video, data) that makes sense from the
> application's
> and enduser's point of view. Again, these parameters can be specified as
> follows:
>
> · Guaranteed: The value specified for each parameter MUST be guaranteed.
> · Controlled: The value specified for each parameter MAY be satisfied as
> far
> as practicable (possibly with certain range), but definitely NOT
> guaranteed.
> · Best effort: No commitment will be made.
>
> Now each medium (e.g., audio, video, or data) will have different
> categories
> of performance matrix depending on its selection criteria and this can
> also
> be mapped to RSVP, ATM QOS, and others, if needed.
>
> Once we agree on this format, the next step is to create H.323 QOS
> signaling
> messages.
>
> This is my input for discussion in the upcoming Portland Q.13 meeting for
> H.323 QOS.
>
> I like to see the comments from other members as well.
>
> Best regards,
> Radhika R. Roy
> AT&T
> +1 732 420 1580
> rrroy(a)att.com
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv(a)mailbag.intel.com
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv(a)mailbag.intel.com
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
1
0
Hi, Mike:
As I said, we will only work in the framework of H.323 (i.e., Q.13/16).
I understand other questions like Q.14 as well and I am a part of it.
We will go step-by-step. We worked for H.323 in Q.13/16 before we developing
Q.14/16 where the interworking issues like H.248 GWs have been addressed. In
the same token, we are also addressing the H.323 mobility. First, we are
developing the H.323 mobility model in Q.13/16. Then we will address the
interoperability between the PSTN and packet switching network mobility
where H.248 will be one of the items, and these items may fall into other
questions including Q.14/16.
As I told, I have objections when TIPHON model does NOT say which items they
need to address in which questions or which study groups. The confusion
comes when they "dump" everything in one question.
As I told before, no one is saying against TIPHON because we all know this:
There are items that are also being addressed by us in the ITU-T in general.
Hope this will clarify.
Let us NOT create confusions mixing things. Let us focus on our work while
inputs from all ITU-T SGs, TIPHON, IETF, IMTC, and other forums are also
welcome.
Best regards,
Radhika R. Roy
AT&T
-----Original Message-----
From: Mike Buckley [mailto:mikebuckley@44COMMS.COM]
Sent: Wednesday, August 16, 2000 11:56 AM
To: ITU-SG16(a)MAILBAG.INTEL.COM
Subject: Re: H.323 QOS
Hi Radhika,
>We MUST not speak about TIPHON models. It confuses people because it
exceeds
>the charter of Q.13/16. we do not like to address issues related to H.248
>now (it is a part of Q.14/16). We will go step-by-step.
I am only referring to the TIPHON model because you did!
Having said that there is nothing confusing in the TIPHON model for the
participants in Q13 - my experience is they are pretty smart people. I
think if we can pick up useful ideas from the work of other groups we should
be open to that.
>Let us wear the "HAT" of H.323 in Q.13/16, not beyond that.
The work of Q.13 and 14 seems pretty seamless to me. That's why the two
questions are often run as one. We should not be too blinkered in our
approach or we will definitely end up with something that is unuseable.
Mike
Mike Buckley
+44-1457-877718 (T)
+44-1457-877721 (F)
mikebuckley(a)44comms.com
----- Original Message -----
From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM>
To: <ITU-SG16(a)MAILBAG.INTEL.COM>
Sent: Wednesday, August 16, 2000 3:44 PM
Subject: Re: H.323 QOS
Hi, Mike:
I understand what you are saying. I took IETF model as example how works can
be divided when TIPHON model is considered in the context of SIP.
In SG16 of Q.13, the charter is clear: It is H.323 that can be used over any
"packet" networks (i.e., transport independent).
In this context, please H.323 specs: H.323, H.225.0, H.225.0 Annex G, and
H.245.
So, our reference is: To extend H.323 to "express" QOS (application layer)
considering audio codecs, video codecs, data (T.120).
Please see Appendix of H.323 Annex N. We will go from there (you can see the
frame work of H.225.0 Annex G - how simple it is - we will follow the
similar model).
This is as simple as stated above.
We MUST not speak about TIPHON models. It confuses people because it exceeds
the charter of Q.13/16. we do not like to address issues related to H.248
now (it is a part of Q.14/16). We will go step-by-step.
Let us wear the "HAT" of H.323 in Q.13/16, not beyond that.
By the way, we are also doing the same thing in H.323 mobility: To extend
H.323 to support mobility in the application layer.
Hope this helps.
Best regards,
Radhika R. Roy
AT&T
-----Original Message-----
From: Mike Buckley [mailto:mikebuckley@44COMMS.COM]
Sent: Wednesday, August 16, 2000 9:56 AM
To: ITU-SG16(a)MAILBAG.INTEL.COM
Subject: Re: H.323 QOS
Hi Radhika,
The problem is I don't see a framework in SG16 for how H.323 will be used in
the real world to solve the general end to end QoS problem.
It's no good putting fields in protocols without some idea of how they are
going to be used in practice. This doesn't mean you want to tie down the
implementer to go down one particular route but you have to have an
architecture in mind when you develop a protocol. The IETFs architecture is
clear - it is the Internet. I would submit that this is not necessarily
what we are doing in SG16.
Let's define the framework of the problem we are going to solve. Much of it
has been covered in this recent thread. But it needs documenting and
general agreement.
TIPHON is developing a framework for VoIP. SG16 is developing a suite of
protocols for VoIP. Both need an agreed architecture. The early
discussions on architecture in TIPHON lead to gateway decomposition and the
birth of H.248. The logical conclusion of this work has lead to the present
TIPHON architecture. Just as the gateway decomposition exercise lead to a
set of requirements and architecture for H.248, the latest TIPHON
architecture leads to a set of requirements for QoS control and a QoS
architecture. See DTS 5003. I want to get general agreement on the problem
we are solving and the roadmap of how we are going to get there. Then we
can start on the ASN.1.
We should not be considering SIP/SDP in SG16 - neither of these protocols
are needed if we do our job right with H.323. Policy in the IETF is
exclusively transport domain policy. Again it has nothing to do with the
policies we may adopt on application level QoS. As far as I understand the
MCI work this is all about the Internet and makes no recognition of H.323 or
other applications. So lets not get lead astray by orthogonal activities to
those we are engaged on. Our job is application level QoS and defining the
services we need from the transport domain to deliver it. We are not
solving problems in the transport domain. But we can draw up a set of
requirements for an interface and feed this to the IETF.
Let's get our problem statement clear and our TORs and architecture
documented and agreed.
Mike
Mike Buckley
+44-1457-877718 (T)
+44-1457-877721 (F)
mikebuckley(a)44comms.com
----- Original Message -----
From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM>
To: <ITU-SG16(a)MAILBAG.INTEL.COM>
Sent: Wednesday, August 16, 2000 2:08 PM
Subject: Re: H.323 QOS
Hi, Mike:
Our aim is to extend H.323 for supporting QOS. The framework is already
there.
Please see H.323 and H.225.0 Annex G specs how the general framework is done
in the context of H.323.
Again, we are dealing with Q.13/16 and TIPHON exceeds the charter of
Q.13/16. It goes beyond H.323 and involves almost all SGs of ITU-T and IETF
that are dealing with QOS.
I understand what TIPHON is trying to do and TIPHON is just NOT limited to
Q.13/16. The same problem has been in the IETF when TIPHON presented its QOS
model for extending SIP. It appears that it exceeds the charter of SIP.
Please note that people are NOT saying that TIPHON's work is NOT needed. All
they are saying: Let us divide the work in different items and each item
will have its place in the corresponding WGs. For example, policy will be
addressed in the Policy WG, if any particular messages in SIP needs to be
extended to support QOS following the SIP charter that work may be addressed
in the SIP WG, if any particular item needs to extend in SDP to support QOS
that work needs to be done in the MMUSIC.
>From end-to-end call point of view, people will need SIP, SDP, Policy,
Security, Billing, firewalls, NATs, and others. when the standards in all
areas are done, people just use them. This is the second step. I have also
been working with Joon Maeng of VTEL in this area because Joon submitted a
contribution in Q.13/16 last Feb'99 meeting. We are waiting to complete the
H.323 QOS work first.
You can also see an IETF contribution from MCI WorldCom how the interdomain
QOS can be used by SIP using Policy, Security, etc. This work is dependent
on the standard work of Policy WG, and others. Again, this contribution for
supporting interdomain QOS by SIP using Policy, etc. does NOT need any
additional standard work is SIP, it is, rather, an implementation that shows
how an end-to-end call can use all those standards including QOS that have
been developed in different WGs.
Appendix of H.323 QOS Annex N has the general framework. Now you can go
through those items and please let us know where you like to see changes and
why.
Best regards,
Radhika R. Roy
AT&T
-----Original Message-----
From: Mike Buckley [mailto:mikebuckley@44COMMS.COM]
Sent: Tuesday, August 15, 2000 7:51 PM
To: ITU-SG16(a)MAILBAG.INTEL.COM
Subject: Re: H.323 QOS
Radhika,
My aim here is to come up with a general QoS framework in H.323 that will
handle all these situatioins not just special cases. I think we agree on
this.
I would be reluctant to solve a special case without an idea of how we are
going to solve the general case. This can only lead to backward
compatibility issues.
I believe the TIPHON approach is totally general. However I agree it need
some new interfaces defining.
Mike
Mike Buckley
+44-1457-877718 (T)
+44-1457-877721 (F)
mikebuckley(a)44comms.com
----- Original Message -----
From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM>
To: <ITU-SG16(a)MAILBAG.INTEL.COM>
Sent: Tuesday, August 15, 2000 8:21 PM
Subject: Re: H.323 QOS
Hi, Mike:
Yes, you are right that NATs and firewalls problems are yet to be solved
with complete satisfaction from address translation point of view. This may
be a separate work item all by itself.
I do not think that we will bring H.245 to address those problems. In fact,
I have not seen any proposal in that direction.
We have to separate our works step by step.
I would not like to include those general problems as a part of H.323 OQS
for now. Let a separate group or annexes deal with those special problems so
that we can use those solutions for QOS as well, if needed.
Best regards,
Radhika R. Roy
AT&T
-----Original Message-----
From: Mike Buckley [mailto:mikebuckley@44COMMS.COM]
Sent: Tuesday, August 15, 2000 1:13 PM
To: ITU-SG16(a)MAILBAG.INTEL.COM
Subject: Re: H.323 QOS
Hi Radhika,
This model is only valid I think when you have end to end address
transparency as in the Internet. When different transport network domains
are present this doesn't necessarily work. NATs and firewalls will mean
that IP addresses and port numbers in different domains will be different
for the same media stream. Terminating IP and port numbers may well be
different at each end of the call. This is one reason why H.323 will not
work through firewalls. To fix this gatekeepers will have to perform a
mediating function with the H.323 domain and the transport domains. This
mediation will not be via H.245.
SIP has the same problems by the way.
Mike
Mike Buckley
+44-1457-877718 (T)
+44-1457-877721 (F)
mikebuckley(a)44comms.com
----- Original Message -----
From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM>
To: <ITU-SG16(a)MAILBAG.INTEL.COM>
Sent: Tuesday, August 15, 2000 2:15 PM
Subject: Re: H.323 QOS
Hi, Mike:
Just for information, H.245 does many things. As I indicated earlier, one of
the most important things of H.245 is the opening and closing of the logical
channels that binds the application layer's logical connection abstractions
to all transport network connections (e.g., ATM, etc).
So, this is the fundamental mission of H.245 to provide the continuity
between the application layer and the lower layer in a transport independent
way using the universal abstractions. These abstractions can be for anything
that we can think of.
Hope this helps.
Best regards,
Radhika R. Roy
AT&T
-----Original Message-----
From: Mike Buckley [mailto:mikebuckley@44COMMS.COM]
Sent: Tuesday, August 15, 2000 8:22 AM
To: ITU-SG16(a)MAILBAG.INTEL.COM
Subject: Re: H.323 QOS
Hi Radhika,
This use of H.245 as a bridging mechanism is where I have difficulties. The
original intenmt behind H.245 was media control and negociation. Transport
mechanisms should not be signalled in H.245 or elsewhere in the application.
This is entirely the business of the transport network provider.
Unfortunately I will not be present in Portland, however, I am happy to
continue this productive dialogue on the list with a view to providing a new
draft in the next few weeks.
Regards,
Mike
Mike Buckley
+44-1457-877718 (T)
+44-1457-877721 (F)
mikebuckley(a)44comms.com
----- Original Message -----
From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM>
To: <ITU-SG16(a)MAILBAG.INTEL.COM>
Sent: Monday, August 14, 2000 7:29 PM
Subject: Re: H.323 QOS
Hi, Mike:
I guess that we have agreement on the fundamental basis. However, I have
problems when you translate this in signaling terms. As I have explained
earlier that we are following the exiting framework of H.323 which is the
application layer, and H.323 is transported over one or different transport
networks. H.323 uses H.245 as a common mechanism that helps to transports
the abstraction of H.323 application signaling messages over any networks
(e.g., IP, ATM, etc).
You may look to the H.245 spec very carefully instead of making any
generalized statement.
H.245 provides the bridging between the application layer and transport
layer mechanism. For example, H.245's OLC abstraction is the link for ATM
network layer logical connection as well as for other transport networks.
In the same token, H.323 QOS abstraction may also provide link to the lower
transport layer QOS signaling mechanisms (e.g., RSVP, DiffServ, MPLS, ATM
QOS, etc), if needed. H.323 DOES support RSVP and ATM QOS now.
Please also see my reply embedded in you email [RRR].
Again, I would suggest to bring contributions explaining the solution and we
will go from there. In absence of your contributions, I would suggest to
provide comments on Appendix of H.323 QOS Annex N. We can then answer your
questions step by step.
Best regards,
Radhika R. Roy
AT&T
-----Original Message-----
From: Mike Buckley [mailto:mikebuckley@44COMMS.COM]
Sent: Monday, August 14, 2000 12:56 PM
To: ITU-SG16(a)MAILBAG.INTEL.COM
Subject: Re: H.323 QOS
Radhika,
>However, this is only good for the single network. For example,
>end-to-end RSVP or end-to-end ATM QOS.
>If there are multiple networks or if a single IP network implements RSVP in
>one domain, DiffServ in another domain, and MPLS in another domain, there
is
>no transparent H.323 QOS signaling mechanism that is universal on
end-to-end
>basis so that it can be mapped over the RSVP, DiffServ, MPLS, ATM QOS, etc
>transparently
This is the nub of the problem and I am afraid why this approach is flawed.
[RRR] I am NOT afraid of anything. Rather we are solving all problems
including the above as well. No one should be afraid of anything. The only
thing that I can suggest is to bring contributions. We will go from there.
Please remember that H.323 QOS supports RSVP and ATM QOS and we MUST provide
backward compatibility. We will be waiting to see contributions from you to
prove your points whether things are flawed or not. Please read Appnedix of
H.323 QOS Annex N very carefully along with exiting H.323 and H.245
standard how they support H.323 QOS for RSVP and ATM QOS.
>We have shown how the H.323 QOS can
>be mapped over the RSVP, DiffServ, ATM QOS, etc. if needed.
This mapping must be done within the transport plane not by the application.
All the application needs to specify are the entries in your Table 1. i.e
delay, jitter. packet loss and peak bit rate (the latter parameter for
policy enforcement and resource reservation).
[RRR] Please see my generalized clarification how H.245 provides translation
between H.323 signaling schemes over the lower layer transport networks
(e.g., IP, ATM, etc). The mechanism already exists in H.323 and this is the
beauty of the transport independent H.323 application. Now there are two
separate things: one is what the calling side of the application demands and
what the called side of the application agrees on. This is called
negotiation capability (e.g., choosing a particular type codec that has a
certain bandwidth, jitter, and other requirements). How the choosing
criteria is determined, the H.323 application is NOT aware of those things.
It may depend on many criteria (e.g., policy, bandwidth, type of network
[e.g., IP, ATM], pricing, security, personal preferences, etc.), but H.323
is not involved. These are separate issues and we are NOT addressing at the
H.323 layer.
I am still not clkear how you propose to signal these parameters to the
transport plane.
[RRR] It is NOT new in H.323, and this mechanism already exits. Please see
the support of RSVP and ATM QOS in H.323/H.245 spec. We are not inventing
anything NEW here. Then, if you read Appendix of H.323 QOS Annex N very
carefully, you will find how it happening (whether you call it as transport
plane or something else, it does not matter).
I think we are getting loser to a common understanding.
Mike
Mike Buckley
+44-1457-877718 (T)
+44-1457-877721 (F)
mikebuckley(a)44comms.com
----- Original Message -----
From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM>
To: <ITU-SG16(a)MAILBAG.INTEL.COM>
Sent: Monday, August 14, 2000 2:37 PM
Subject: Re: H.323 QOS
Hi, Bob:
I agree completely agree with you.
In fact, we are all trying to achieve the same goal. For example, H.323 does
supports QOS today via H.245. You can easily see that RSVP and ATM QOS are
supported using H.245. The beauty of this approach is that H.245 is still
transport independent. All we have done here is: the abstraction of H.245
has been used to support the RSVP and ATM QOS to implement the network layer
QOS. However, this is only good for the single network. For example,
end-to-end RSVP or end-to-end ATM QOS.
If there are multiple networks or if a single IP network implements RSVP in
one domain, DiffServ in another domain, and MPLS in another domain, there is
no transparent H.323 QOS signaling mechanism that is universal on end-to-end
basis so that it can be mapped over the RSVP, DiffServ, MPLS, ATM QOS, etc
transparently.
In Appendix of H.323 Annex N, we have done the same. We have the abstraction
of H.323 QOS in the application layer. We have shown how the H.323 QOS can
be mapped over the RSVP, DiffServ, ATM QOS, etc. if needed. It also provides
the backward compatibility with the existing H.323 standard. However, we
have done only for the pre-call setup signaling part. We have not done the
call setup part yet. In the call setup part, we will include H.245 in a
similar way what H.323 is supporting RSVP and ATM QOS today in a monolithic
network.
I appreciate your email.
Best regards,
Radhika R. Roy
AT&T
> -----Original Message-----
> From: Callaghan, Robert [SMTP:Robert.Callaghan@icn.siemens.com]
> Sent: Monday, August 14, 2000 9:08 AM
> To: Roy, Radhika R, ALCOO
> Cc: 'Mailing list for parties associated with ITU-T Study Group 16'
> Subject: RE: H.323 QOS
>
> Roy,
>
> In my view, the network, as a minimum, needs only provide transport.
> H.323
> is an application using this transport and is not different from any other
> application being transported. Any application may request a desired
> quality of service that the network may grant based on policies, service
> level agreements, and availability. Each data connection used by an
> application may request a different QOS. Most likely H.323 is such an
> application as needing an enhanced QOS. This simple case should work.
> This
> is all that is required.
>
> In addition to transport, the network may optionally provide other
> additional services. These services may include application layer
> routing.
> These optional services should be configured and indicated independently
> from the basic transport QOS.
>
> It is correct that H.323, as an application, is (mostly) transport
> independent. However, the interface between the application and the
> transport layer is not transport independent. The interface specification
> used to request a given QOS is totally dependant on the standards body
> that
> specified the transport layer; and for this there has been little or no
> coordination.
>
> Because transport QOS over IP is based on IETF specifications, it is
> necessary that the interface used to request a given QOS conform to the
> appropriate IETF specification. If such an interface specification is not
> available, that input might be provided to the appropriate IETF body as to
> the requirements.
>
> I can see the endpoints negotiating the desired QOS base on need, price,
> and
> other considerations. For me, this is the limit to the application layer
> involvement in QOS negotiation. At this point, the application
> negotiations
> with the transport provider as to the desired and available QOS. It is up
> to the transport provider to arrange for the end-to-end QOS. (Again, it
> is
> not necessary for the transport network to know that H.323 is involved in
> the transported data. In fact it may be encrypted in order to mask the
> presence of voice transport.)
>
> For me, this is simple.
>
> Bob
>
> ------------------------------------------------------------------
> Robert Callaghan
> Siemens Enterprise Networks
> Tel: +1.561.923.1756 Fax: +1.561.923.1403
> Email: Robert.Callaghan(a)ICN.Siemens.com
> ------------------------------------------------------------------
>
> -----Original Message-----
> From: Roy, Radhika R, ALCOO [mailto:rrroy@ATT.COM]
> Sent: Friday, August 11, 2000 7:59 AM
> To: ITU-SG16(a)mailbag.cps.intel.com
> Subject: Re: H.323 QOS
>
> Hi, Mike:
>
> Let me try again.
>
> What is the reference point of H.323 QOS? Is it not H.323? If it is so,
> what
> do we mean by H.323?
>
> The answer is: Audio (different codecs), Video (different codecs), and
> Data
> (T.120 applications) that are used by H.323.
>
> What are the QOS/performance characteristics of audio, video, and data
> from
> the application point of view that is generated by audio codecs, video
> codecs, and data (T.120) applications?
>
> These QOS/performance characteristics come from the SOURCE codecs and data
> applications. Per transport independent H.323 specifications, an enduser
> express their QOS/performance requirements on end-to-end basis purely from
> application point of view irrespective of the transport network (e.g., IP,
> ATM, etc.).
>
> Moreover, H.323 is meant for the packet network, not for any
> circuit-switched network like PSTN or ISDN.
>
> Let us NOT go beyond this before we start debating transport layer QOS or
> service provider requirements. These are NOT the concern of H.323. H.323
> is
> the transport independent application.
>
> H.323v2/v3/v4 has also provided mechanisms how RSVP and ATM QOS can be
> used
> for H.323 audio, video, and data. So, H.323 QOS that will be defined in
> H.323 Annex N MUST provide mapping for the backward compatibility. It is a
> requirement that MUST be met per the norm of ITU-T.
>
> So, what is left for mapping? Mapping is simply a by-product of the above
> requirement. Mapping is simply a table, nothing else.
>
> Did I miss anything?
>
> Best regards,
> Radhika R. Roy
> AT&T
>
> -----Original Message-----
> From: Mike Buckley [mailto:mikebuckley@44COMMS.COM]
> Sent: Thursday, August 10, 2000 10:19 PM
> To: ITU-SG16(a)MAILBAG.INTEL.COM
> Subject: Re: H.323 QOS
>
>
> Radhika,
>
> Thanks for the input which I welcome as I will unfortunately not be
> present
> at Portland.
>
> Let me ask a few questions and make a few comments hopefully with the
> intent
> of opening up the debate.
>
> 1. I am not sure I understand your concept of a mapping table between the
> H.323 QOS and the transport layer QoS. My understanding is that QoS is on
> three levels:
>
> a) that specified from a service point of view between the user and
> service
> provider (e.g PSTN quality, conference quality etc) This is the domain of
> the speech experts and can be characterised by Listener Speech Quaklity
> (MOS), end to end delay, and absolute category rating, R.
>
> b) application specific parameters, (e.g. equipment delays, codec choice
> and performance, codec frame size, packetisation arrangements, jitter
> buffer
> design, overall packet loss etc.) Optimisation of all these will
> determine
> what can be delivered in a).
>
> c) transport parameters for a given choice of application parameters.
> This
> boils down only to three parameters as far as I cna see: tranport network
> delay, packet delay variation in the transport network and packet loss in
> the transport network. Again these parameters will determine the results
> in
> a) for a given choice of the parameters in b). These parameters are
> generic
> from the perspective of the transport network. i.e the transport network
> does not need to know the details of the application.
>
> So the sequence of cause and effect and control is:
>
> a) User requests QoS class from service provider,
> b) Service provider determines application specific parameters in
> conjunction with users equipment and other service providers,
> c) Service provider requests required delay, delay variation and packet
> loss from network provider.
>
> I see no need for mapping here. The only QoS info flows within the
> application are specific to the application and those between the
> application (service provider) and the transport network are generic. i.e.
> delay, jitter and packet loss. Have I missed something?
>
> 2. The issue of bit rate and media stream statistics I think need to be
> decoupled from QoS. These are specified to enable optimisation of
> resources
> within the transport network. They have no QoS significance from an
> application point of view. i.e the apllication does not care about the
> media stream bit rate and statistics but the transport network provider
> does
> as it eats up his resource. They may be used for policy enforcement
> however
> in the transport network so they do need to be agreed between service
> provider and network operator. i.e the network operator agrees to provide
> a
> given QoS level (delay, jitter, packet loss) provided the media properties
> are within an agreed profile (bit rate, flow statistics).
>
> 3. The next point is how can the service provider know the statistics of
> a
> particular VBR stream? These can only be specified over a large number of
> similar calls and will depend, for instance, on who is speaking, the
> nature
> of the speech interaction etc etc. They can only be measured not
> calculated. The service provider is in no better position to measure
> these
> than the transport network operator and, in fact, where no gateways are
> involved, may not be able to. On the other hand the class of signal would
> have to be signalled to the network operator for him to be able to
> distinguish which class a particular measurement belonged to. e.g
> voice/speech/data, codec type, conference, multicast etc. So I see no
> purpose in trying to exchange statistics between the service provider
> (application) and transport operator. I think peak bit rate is all that
> can
> be meaningfully excanged. The specification of media class is however
> perhaps worth exploring.
>
> 4. The controlled category has always puzzled me. I only see two
> possibilities. Either the requested QoS level is guaranteed (on a
> statistical basis e.g 95% of all connections over a specified period) or
> not
> guaranteed. Is your controlled category a way of saying guaranteed, not
> to
> 95% but to some lower figure? If you can't put a percentage on it then it
> seems it is plain and simple not guaranteed. Anything that is not
> guaranteed to some specified statistical level is best effort and you
> can't
> say anything more about it. So I only see two categories here.
>
> In summary, I think we need to do three things in Annex N.
>
> a) Figure out the QoS information to be exchanged within the Application
> between service providers and end users. This will go in H.225.0 and
> H.245.
>
> b) Figure out how we are going to signal QoS and media information between
> the application (service providers) and transport domains (IP or ATM
> networks etc). The info is basically delay, jitter, packet loss
> requirements and peak bit rate. We need a protocol for this.
>
> c) we need to work out the interactions between the application QoS
> signal
> flows and the application/transport signal flows. I don't think we need
> worry about how the transport network mechanisms assure the requested QoS
> paramerters. RSVP/Intserv, Diffserv, MPLS, ATM, over provisioning are all
> possibilities.
>
> Would welcome comments and views on the above.
>
> Mike
>
>
> Mike Buckley
> +44-1457-877718 (T)
> +44-1457-877721 (F)
> mikebuckley(a)44comms.com
>
>
> ----- Original Message -----
> From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM>
> To: <ITU-SG16(a)MAILBAG.INTEL.COM>
> Sent: Thursday, August 10, 2000 10:15 PM
> Subject: H.323 QOS
>
>
> Hi, Mike and All:
>
> It is time to discuss about H.323 QOS.
>
> I believe that we have an agreement as follows:
>
> · H.323 QOS MUST be backward compatible to support RSVP and ATM QOS as it
> exists for H.323v2/v3/v4
> · Like H.323 spec, the application level H.323 QOS MUST be independent of
> the transport layer QOS and should support all transport networks (e.g.,
> IP,
> ATM)
> · A mapping table between the H.323 QOS and the transport layer QOS (e.g.,
> IP QOS [DiffServ, RSVP, etc.], ATM QOS [CBR, rt-VBR, nrt-VBR, ABR, etc.])
> should be provided.
>
> From the H.323 multimedia application point of view, there are following
> performance parameters can be used to characterize the traffic
> characteristics:
>
> · Bitrate characteristics: Peak bit rate (PBR) or peak rate (PR),
> Sustained
> bit rate (SBR) or average rate (AR), minimum bit rate (MBR) or minimum
> rate
> (MR), and mean bust size (MBS)
> · Delay and loss characteristics: end-to-end delay (EED) or delay,
> end-to-end delay variation (EEDV) or delay variation (DV), and
> bit-error-rate (BER) or (packet) loss rate (LR)
>
> We can now form a table with all parameters as follows:
>
> Table 1: H.323 Multimedia Application Performance Matrix
> Audio (codecs)--- Video (codecs)--- Data
> (T.120)
> PBR/PR Yes/No/Value Yes/No/Value Yes/No/value
> SBR/AR Yes/No/Value Yes/No/Value Yes/No/value
> MBR/MR Yes/No/Value Yes/No/Value Yes/No/value
> MBS Yes/No/Value Yes/No/Value Yes/No/value
> EED/Delay Yes/No/Value Yes/No/Value Yes/No/value
> EEDV/DV Yes/No/Value Yes/No/Value Yes/No/value
> BER/LR Yes/No/Value Yes/No/Value Yes/No/value
>
> From the above table we will have the opportunity to choose each parameter
> for each medium (audio, video, data) that makes sense from the
> application's
> and enduser's point of view. Again, these parameters can be specified as
> follows:
>
> · Guaranteed: The value specified for each parameter MUST be guaranteed.
> · Controlled: The value specified for each parameter MAY be satisfied as
> far
> as practicable (possibly with certain range), but definitely NOT
> guaranteed.
> · Best effort: No commitment will be made.
>
> Now each medium (e.g., audio, video, or data) will have different
> categories
> of performance matrix depending on its selection criteria and this can
> also
> be mapped to RSVP, ATM QOS, and others, if needed.
>
> Once we agree on this format, the next step is to create H.323 QOS
> signaling
> messages.
>
> This is my input for discussion in the upcoming Portland Q.13 meeting for
> H.323 QOS.
>
> I like to see the comments from other members as well.
>
> Best regards,
> Radhika R. Roy
> AT&T
> +1 732 420 1580
> rrroy(a)att.com
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv(a)mailbag.intel.com
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv(a)mailbag.intel.com
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
2
2
Hi, Mike:
I understand what you are saying. I took IETF model as example how works can
be divided when TIPHON model is considered in the context of SIP.
In SG16 of Q.13, the charter is clear: It is H.323 that can be used over any
"packet" networks (i.e., transport independent).
In this context, please H.323 specs: H.323, H.225.0, H.225.0 Annex G, and
H.245.
So, our reference is: To extend H.323 to "express" QOS (application layer)
considering audio codecs, video codecs, data (T.120).
Please see Appendix of H.323 Annex N. We will go from there (you can see the
frame work of H.225.0 Annex G - how simple it is - we will follow the
similar model).
This is as simple as stated above.
We MUST not speak about TIPHON models. It confuses people because it exceeds
the charter of Q.13/16. we do not like to address issues related to H.248
now (it is a part of Q.14/16). We will go step-by-step.
Let us wear the "HAT" of H.323 in Q.13/16, not beyond that.
By the way, we are also doing the same thing in H.323 mobility: To extend
H.323 to support mobility in the application layer.
Hope this helps.
Best regards,
Radhika R. Roy
AT&T
-----Original Message-----
From: Mike Buckley [mailto:mikebuckley@44COMMS.COM]
Sent: Wednesday, August 16, 2000 9:56 AM
To: ITU-SG16(a)MAILBAG.INTEL.COM
Subject: Re: H.323 QOS
Hi Radhika,
The problem is I don't see a framework in SG16 for how H.323 will be used in
the real world to solve the general end to end QoS problem.
It's no good putting fields in protocols without some idea of how they are
going to be used in practice. This doesn't mean you want to tie down the
implementer to go down one particular route but you have to have an
architecture in mind when you develop a protocol. The IETFs architecture is
clear - it is the Internet. I would submit that this is not necessarily
what we are doing in SG16.
Let's define the framework of the problem we are going to solve. Much of it
has been covered in this recent thread. But it needs documenting and
general agreement.
TIPHON is developing a framework for VoIP. SG16 is developing a suite of
protocols for VoIP. Both need an agreed architecture. The early
discussions on architecture in TIPHON lead to gateway decomposition and the
birth of H.248. The logical conclusion of this work has lead to the present
TIPHON architecture. Just as the gateway decomposition exercise lead to a
set of requirements and architecture for H.248, the latest TIPHON
architecture leads to a set of requirements for QoS control and a QoS
architecture. See DTS 5003. I want to get general agreement on the problem
we are solving and the roadmap of how we are going to get there. Then we
can start on the ASN.1.
We should not be considering SIP/SDP in SG16 - neither of these protocols
are needed if we do our job right with H.323. Policy in the IETF is
exclusively transport domain policy. Again it has nothing to do with the
policies we may adopt on application level QoS. As far as I understand the
MCI work this is all about the Internet and makes no recognition of H.323 or
other applications. So lets not get lead astray by orthogonal activities to
those we are engaged on. Our job is application level QoS and defining the
services we need from the transport domain to deliver it. We are not
solving problems in the transport domain. But we can draw up a set of
requirements for an interface and feed this to the IETF.
Let's get our problem statement clear and our TORs and architecture
documented and agreed.
Mike
Mike Buckley
+44-1457-877718 (T)
+44-1457-877721 (F)
mikebuckley(a)44comms.com
----- Original Message -----
From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM>
To: <ITU-SG16(a)MAILBAG.INTEL.COM>
Sent: Wednesday, August 16, 2000 2:08 PM
Subject: Re: H.323 QOS
Hi, Mike:
Our aim is to extend H.323 for supporting QOS. The framework is already
there.
Please see H.323 and H.225.0 Annex G specs how the general framework is done
in the context of H.323.
Again, we are dealing with Q.13/16 and TIPHON exceeds the charter of
Q.13/16. It goes beyond H.323 and involves almost all SGs of ITU-T and IETF
that are dealing with QOS.
I understand what TIPHON is trying to do and TIPHON is just NOT limited to
Q.13/16. The same problem has been in the IETF when TIPHON presented its QOS
model for extending SIP. It appears that it exceeds the charter of SIP.
Please note that people are NOT saying that TIPHON's work is NOT needed. All
they are saying: Let us divide the work in different items and each item
will have its place in the corresponding WGs. For example, policy will be
addressed in the Policy WG, if any particular messages in SIP needs to be
extended to support QOS following the SIP charter that work may be addressed
in the SIP WG, if any particular item needs to extend in SDP to support QOS
that work needs to be done in the MMUSIC.
>From end-to-end call point of view, people will need SIP, SDP, Policy,
Security, Billing, firewalls, NATs, and others. when the standards in all
areas are done, people just use them. This is the second step. I have also
been working with Joon Maeng of VTEL in this area because Joon submitted a
contribution in Q.13/16 last Feb'99 meeting. We are waiting to complete the
H.323 QOS work first.
You can also see an IETF contribution from MCI WorldCom how the interdomain
QOS can be used by SIP using Policy, Security, etc. This work is dependent
on the standard work of Policy WG, and others. Again, this contribution for
supporting interdomain QOS by SIP using Policy, etc. does NOT need any
additional standard work is SIP, it is, rather, an implementation that shows
how an end-to-end call can use all those standards including QOS that have
been developed in different WGs.
Appendix of H.323 QOS Annex N has the general framework. Now you can go
through those items and please let us know where you like to see changes and
why.
Best regards,
Radhika R. Roy
AT&T
-----Original Message-----
From: Mike Buckley [mailto:mikebuckley@44COMMS.COM]
Sent: Tuesday, August 15, 2000 7:51 PM
To: ITU-SG16(a)MAILBAG.INTEL.COM
Subject: Re: H.323 QOS
Radhika,
My aim here is to come up with a general QoS framework in H.323 that will
handle all these situatioins not just special cases. I think we agree on
this.
I would be reluctant to solve a special case without an idea of how we are
going to solve the general case. This can only lead to backward
compatibility issues.
I believe the TIPHON approach is totally general. However I agree it need
some new interfaces defining.
Mike
Mike Buckley
+44-1457-877718 (T)
+44-1457-877721 (F)
mikebuckley(a)44comms.com
----- Original Message -----
From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM>
To: <ITU-SG16(a)MAILBAG.INTEL.COM>
Sent: Tuesday, August 15, 2000 8:21 PM
Subject: Re: H.323 QOS
Hi, Mike:
Yes, you are right that NATs and firewalls problems are yet to be solved
with complete satisfaction from address translation point of view. This may
be a separate work item all by itself.
I do not think that we will bring H.245 to address those problems. In fact,
I have not seen any proposal in that direction.
We have to separate our works step by step.
I would not like to include those general problems as a part of H.323 OQS
for now. Let a separate group or annexes deal with those special problems so
that we can use those solutions for QOS as well, if needed.
Best regards,
Radhika R. Roy
AT&T
-----Original Message-----
From: Mike Buckley [mailto:mikebuckley@44COMMS.COM]
Sent: Tuesday, August 15, 2000 1:13 PM
To: ITU-SG16(a)MAILBAG.INTEL.COM
Subject: Re: H.323 QOS
Hi Radhika,
This model is only valid I think when you have end to end address
transparency as in the Internet. When different transport network domains
are present this doesn't necessarily work. NATs and firewalls will mean
that IP addresses and port numbers in different domains will be different
for the same media stream. Terminating IP and port numbers may well be
different at each end of the call. This is one reason why H.323 will not
work through firewalls. To fix this gatekeepers will have to perform a
mediating function with the H.323 domain and the transport domains. This
mediation will not be via H.245.
SIP has the same problems by the way.
Mike
Mike Buckley
+44-1457-877718 (T)
+44-1457-877721 (F)
mikebuckley(a)44comms.com
----- Original Message -----
From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM>
To: <ITU-SG16(a)MAILBAG.INTEL.COM>
Sent: Tuesday, August 15, 2000 2:15 PM
Subject: Re: H.323 QOS
Hi, Mike:
Just for information, H.245 does many things. As I indicated earlier, one of
the most important things of H.245 is the opening and closing of the logical
channels that binds the application layer's logical connection abstractions
to all transport network connections (e.g., ATM, etc).
So, this is the fundamental mission of H.245 to provide the continuity
between the application layer and the lower layer in a transport independent
way using the universal abstractions. These abstractions can be for anything
that we can think of.
Hope this helps.
Best regards,
Radhika R. Roy
AT&T
-----Original Message-----
From: Mike Buckley [mailto:mikebuckley@44COMMS.COM]
Sent: Tuesday, August 15, 2000 8:22 AM
To: ITU-SG16(a)MAILBAG.INTEL.COM
Subject: Re: H.323 QOS
Hi Radhika,
This use of H.245 as a bridging mechanism is where I have difficulties. The
original intenmt behind H.245 was media control and negociation. Transport
mechanisms should not be signalled in H.245 or elsewhere in the application.
This is entirely the business of the transport network provider.
Unfortunately I will not be present in Portland, however, I am happy to
continue this productive dialogue on the list with a view to providing a new
draft in the next few weeks.
Regards,
Mike
Mike Buckley
+44-1457-877718 (T)
+44-1457-877721 (F)
mikebuckley(a)44comms.com
----- Original Message -----
From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM>
To: <ITU-SG16(a)MAILBAG.INTEL.COM>
Sent: Monday, August 14, 2000 7:29 PM
Subject: Re: H.323 QOS
Hi, Mike:
I guess that we have agreement on the fundamental basis. However, I have
problems when you translate this in signaling terms. As I have explained
earlier that we are following the exiting framework of H.323 which is the
application layer, and H.323 is transported over one or different transport
networks. H.323 uses H.245 as a common mechanism that helps to transports
the abstraction of H.323 application signaling messages over any networks
(e.g., IP, ATM, etc).
You may look to the H.245 spec very carefully instead of making any
generalized statement.
H.245 provides the bridging between the application layer and transport
layer mechanism. For example, H.245's OLC abstraction is the link for ATM
network layer logical connection as well as for other transport networks.
In the same token, H.323 QOS abstraction may also provide link to the lower
transport layer QOS signaling mechanisms (e.g., RSVP, DiffServ, MPLS, ATM
QOS, etc), if needed. H.323 DOES support RSVP and ATM QOS now.
Please also see my reply embedded in you email [RRR].
Again, I would suggest to bring contributions explaining the solution and we
will go from there. In absence of your contributions, I would suggest to
provide comments on Appendix of H.323 QOS Annex N. We can then answer your
questions step by step.
Best regards,
Radhika R. Roy
AT&T
-----Original Message-----
From: Mike Buckley [mailto:mikebuckley@44COMMS.COM]
Sent: Monday, August 14, 2000 12:56 PM
To: ITU-SG16(a)MAILBAG.INTEL.COM
Subject: Re: H.323 QOS
Radhika,
>However, this is only good for the single network. For example,
>end-to-end RSVP or end-to-end ATM QOS.
>If there are multiple networks or if a single IP network implements RSVP in
>one domain, DiffServ in another domain, and MPLS in another domain, there
is
>no transparent H.323 QOS signaling mechanism that is universal on
end-to-end
>basis so that it can be mapped over the RSVP, DiffServ, MPLS, ATM QOS, etc
>transparently
This is the nub of the problem and I am afraid why this approach is flawed.
[RRR] I am NOT afraid of anything. Rather we are solving all problems
including the above as well. No one should be afraid of anything. The only
thing that I can suggest is to bring contributions. We will go from there.
Please remember that H.323 QOS supports RSVP and ATM QOS and we MUST provide
backward compatibility. We will be waiting to see contributions from you to
prove your points whether things are flawed or not. Please read Appnedix of
H.323 QOS Annex N very carefully along with exiting H.323 and H.245
standard how they support H.323 QOS for RSVP and ATM QOS.
>We have shown how the H.323 QOS can
>be mapped over the RSVP, DiffServ, ATM QOS, etc. if needed.
This mapping must be done within the transport plane not by the application.
All the application needs to specify are the entries in your Table 1. i.e
delay, jitter. packet loss and peak bit rate (the latter parameter for
policy enforcement and resource reservation).
[RRR] Please see my generalized clarification how H.245 provides translation
between H.323 signaling schemes over the lower layer transport networks
(e.g., IP, ATM, etc). The mechanism already exists in H.323 and this is the
beauty of the transport independent H.323 application. Now there are two
separate things: one is what the calling side of the application demands and
what the called side of the application agrees on. This is called
negotiation capability (e.g., choosing a particular type codec that has a
certain bandwidth, jitter, and other requirements). How the choosing
criteria is determined, the H.323 application is NOT aware of those things.
It may depend on many criteria (e.g., policy, bandwidth, type of network
[e.g., IP, ATM], pricing, security, personal preferences, etc.), but H.323
is not involved. These are separate issues and we are NOT addressing at the
H.323 layer.
I am still not clkear how you propose to signal these parameters to the
transport plane.
[RRR] It is NOT new in H.323, and this mechanism already exits. Please see
the support of RSVP and ATM QOS in H.323/H.245 spec. We are not inventing
anything NEW here. Then, if you read Appendix of H.323 QOS Annex N very
carefully, you will find how it happening (whether you call it as transport
plane or something else, it does not matter).
I think we are getting loser to a common understanding.
Mike
Mike Buckley
+44-1457-877718 (T)
+44-1457-877721 (F)
mikebuckley(a)44comms.com
----- Original Message -----
From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM>
To: <ITU-SG16(a)MAILBAG.INTEL.COM>
Sent: Monday, August 14, 2000 2:37 PM
Subject: Re: H.323 QOS
Hi, Bob:
I agree completely agree with you.
In fact, we are all trying to achieve the same goal. For example, H.323 does
supports QOS today via H.245. You can easily see that RSVP and ATM QOS are
supported using H.245. The beauty of this approach is that H.245 is still
transport independent. All we have done here is: the abstraction of H.245
has been used to support the RSVP and ATM QOS to implement the network layer
QOS. However, this is only good for the single network. For example,
end-to-end RSVP or end-to-end ATM QOS.
If there are multiple networks or if a single IP network implements RSVP in
one domain, DiffServ in another domain, and MPLS in another domain, there is
no transparent H.323 QOS signaling mechanism that is universal on end-to-end
basis so that it can be mapped over the RSVP, DiffServ, MPLS, ATM QOS, etc
transparently.
In Appendix of H.323 Annex N, we have done the same. We have the abstraction
of H.323 QOS in the application layer. We have shown how the H.323 QOS can
be mapped over the RSVP, DiffServ, ATM QOS, etc. if needed. It also provides
the backward compatibility with the existing H.323 standard. However, we
have done only for the pre-call setup signaling part. We have not done the
call setup part yet. In the call setup part, we will include H.245 in a
similar way what H.323 is supporting RSVP and ATM QOS today in a monolithic
network.
I appreciate your email.
Best regards,
Radhika R. Roy
AT&T
> -----Original Message-----
> From: Callaghan, Robert [SMTP:Robert.Callaghan@icn.siemens.com]
> Sent: Monday, August 14, 2000 9:08 AM
> To: Roy, Radhika R, ALCOO
> Cc: 'Mailing list for parties associated with ITU-T Study Group 16'
> Subject: RE: H.323 QOS
>
> Roy,
>
> In my view, the network, as a minimum, needs only provide transport.
> H.323
> is an application using this transport and is not different from any other
> application being transported. Any application may request a desired
> quality of service that the network may grant based on policies, service
> level agreements, and availability. Each data connection used by an
> application may request a different QOS. Most likely H.323 is such an
> application as needing an enhanced QOS. This simple case should work.
> This
> is all that is required.
>
> In addition to transport, the network may optionally provide other
> additional services. These services may include application layer
> routing.
> These optional services should be configured and indicated independently
> from the basic transport QOS.
>
> It is correct that H.323, as an application, is (mostly) transport
> independent. However, the interface between the application and the
> transport layer is not transport independent. The interface specification
> used to request a given QOS is totally dependant on the standards body
> that
> specified the transport layer; and for this there has been little or no
> coordination.
>
> Because transport QOS over IP is based on IETF specifications, it is
> necessary that the interface used to request a given QOS conform to the
> appropriate IETF specification. If such an interface specification is not
> available, that input might be provided to the appropriate IETF body as to
> the requirements.
>
> I can see the endpoints negotiating the desired QOS base on need, price,
> and
> other considerations. For me, this is the limit to the application layer
> involvement in QOS negotiation. At this point, the application
> negotiations
> with the transport provider as to the desired and available QOS. It is up
> to the transport provider to arrange for the end-to-end QOS. (Again, it
> is
> not necessary for the transport network to know that H.323 is involved in
> the transported data. In fact it may be encrypted in order to mask the
> presence of voice transport.)
>
> For me, this is simple.
>
> Bob
>
> ------------------------------------------------------------------
> Robert Callaghan
> Siemens Enterprise Networks
> Tel: +1.561.923.1756 Fax: +1.561.923.1403
> Email: Robert.Callaghan(a)ICN.Siemens.com
> ------------------------------------------------------------------
>
> -----Original Message-----
> From: Roy, Radhika R, ALCOO [mailto:rrroy@ATT.COM]
> Sent: Friday, August 11, 2000 7:59 AM
> To: ITU-SG16(a)mailbag.cps.intel.com
> Subject: Re: H.323 QOS
>
> Hi, Mike:
>
> Let me try again.
>
> What is the reference point of H.323 QOS? Is it not H.323? If it is so,
> what
> do we mean by H.323?
>
> The answer is: Audio (different codecs), Video (different codecs), and
> Data
> (T.120 applications) that are used by H.323.
>
> What are the QOS/performance characteristics of audio, video, and data
> from
> the application point of view that is generated by audio codecs, video
> codecs, and data (T.120) applications?
>
> These QOS/performance characteristics come from the SOURCE codecs and data
> applications. Per transport independent H.323 specifications, an enduser
> express their QOS/performance requirements on end-to-end basis purely from
> application point of view irrespective of the transport network (e.g., IP,
> ATM, etc.).
>
> Moreover, H.323 is meant for the packet network, not for any
> circuit-switched network like PSTN or ISDN.
>
> Let us NOT go beyond this before we start debating transport layer QOS or
> service provider requirements. These are NOT the concern of H.323. H.323
> is
> the transport independent application.
>
> H.323v2/v3/v4 has also provided mechanisms how RSVP and ATM QOS can be
> used
> for H.323 audio, video, and data. So, H.323 QOS that will be defined in
> H.323 Annex N MUST provide mapping for the backward compatibility. It is a
> requirement that MUST be met per the norm of ITU-T.
>
> So, what is left for mapping? Mapping is simply a by-product of the above
> requirement. Mapping is simply a table, nothing else.
>
> Did I miss anything?
>
> Best regards,
> Radhika R. Roy
> AT&T
>
> -----Original Message-----
> From: Mike Buckley [mailto:mikebuckley@44COMMS.COM]
> Sent: Thursday, August 10, 2000 10:19 PM
> To: ITU-SG16(a)MAILBAG.INTEL.COM
> Subject: Re: H.323 QOS
>
>
> Radhika,
>
> Thanks for the input which I welcome as I will unfortunately not be
> present
> at Portland.
>
> Let me ask a few questions and make a few comments hopefully with the
> intent
> of opening up the debate.
>
> 1. I am not sure I understand your concept of a mapping table between the
> H.323 QOS and the transport layer QoS. My understanding is that QoS is on
> three levels:
>
> a) that specified from a service point of view between the user and
> service
> provider (e.g PSTN quality, conference quality etc) This is the domain of
> the speech experts and can be characterised by Listener Speech Quaklity
> (MOS), end to end delay, and absolute category rating, R.
>
> b) application specific parameters, (e.g. equipment delays, codec choice
> and performance, codec frame size, packetisation arrangements, jitter
> buffer
> design, overall packet loss etc.) Optimisation of all these will
> determine
> what can be delivered in a).
>
> c) transport parameters for a given choice of application parameters.
> This
> boils down only to three parameters as far as I cna see: tranport network
> delay, packet delay variation in the transport network and packet loss in
> the transport network. Again these parameters will determine the results
> in
> a) for a given choice of the parameters in b). These parameters are
> generic
> from the perspective of the transport network. i.e the transport network
> does not need to know the details of the application.
>
> So the sequence of cause and effect and control is:
>
> a) User requests QoS class from service provider,
> b) Service provider determines application specific parameters in
> conjunction with users equipment and other service providers,
> c) Service provider requests required delay, delay variation and packet
> loss from network provider.
>
> I see no need for mapping here. The only QoS info flows within the
> application are specific to the application and those between the
> application (service provider) and the transport network are generic. i.e.
> delay, jitter and packet loss. Have I missed something?
>
> 2. The issue of bit rate and media stream statistics I think need to be
> decoupled from QoS. These are specified to enable optimisation of
> resources
> within the transport network. They have no QoS significance from an
> application point of view. i.e the apllication does not care about the
> media stream bit rate and statistics but the transport network provider
> does
> as it eats up his resource. They may be used for policy enforcement
> however
> in the transport network so they do need to be agreed between service
> provider and network operator. i.e the network operator agrees to provide
> a
> given QoS level (delay, jitter, packet loss) provided the media properties
> are within an agreed profile (bit rate, flow statistics).
>
> 3. The next point is how can the service provider know the statistics of
> a
> particular VBR stream? These can only be specified over a large number of
> similar calls and will depend, for instance, on who is speaking, the
> nature
> of the speech interaction etc etc. They can only be measured not
> calculated. The service provider is in no better position to measure
> these
> than the transport network operator and, in fact, where no gateways are
> involved, may not be able to. On the other hand the class of signal would
> have to be signalled to the network operator for him to be able to
> distinguish which class a particular measurement belonged to. e.g
> voice/speech/data, codec type, conference, multicast etc. So I see no
> purpose in trying to exchange statistics between the service provider
> (application) and transport operator. I think peak bit rate is all that
> can
> be meaningfully excanged. The specification of media class is however
> perhaps worth exploring.
>
> 4. The controlled category has always puzzled me. I only see two
> possibilities. Either the requested QoS level is guaranteed (on a
> statistical basis e.g 95% of all connections over a specified period) or
> not
> guaranteed. Is your controlled category a way of saying guaranteed, not
> to
> 95% but to some lower figure? If you can't put a percentage on it then it
> seems it is plain and simple not guaranteed. Anything that is not
> guaranteed to some specified statistical level is best effort and you
> can't
> say anything more about it. So I only see two categories here.
>
> In summary, I think we need to do three things in Annex N.
>
> a) Figure out the QoS information to be exchanged within the Application
> between service providers and end users. This will go in H.225.0 and
> H.245.
>
> b) Figure out how we are going to signal QoS and media information between
> the application (service providers) and transport domains (IP or ATM
> networks etc). The info is basically delay, jitter, packet loss
> requirements and peak bit rate. We need a protocol for this.
>
> c) we need to work out the interactions between the application QoS
> signal
> flows and the application/transport signal flows. I don't think we need
> worry about how the transport network mechanisms assure the requested QoS
> paramerters. RSVP/Intserv, Diffserv, MPLS, ATM, over provisioning are all
> possibilities.
>
> Would welcome comments and views on the above.
>
> Mike
>
>
> Mike Buckley
> +44-1457-877718 (T)
> +44-1457-877721 (F)
> mikebuckley(a)44comms.com
>
>
> ----- Original Message -----
> From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM>
> To: <ITU-SG16(a)MAILBAG.INTEL.COM>
> Sent: Thursday, August 10, 2000 10:15 PM
> Subject: H.323 QOS
>
>
> Hi, Mike and All:
>
> It is time to discuss about H.323 QOS.
>
> I believe that we have an agreement as follows:
>
> · H.323 QOS MUST be backward compatible to support RSVP and ATM QOS as it
> exists for H.323v2/v3/v4
> · Like H.323 spec, the application level H.323 QOS MUST be independent of
> the transport layer QOS and should support all transport networks (e.g.,
> IP,
> ATM)
> · A mapping table between the H.323 QOS and the transport layer QOS (e.g.,
> IP QOS [DiffServ, RSVP, etc.], ATM QOS [CBR, rt-VBR, nrt-VBR, ABR, etc.])
> should be provided.
>
> From the H.323 multimedia application point of view, there are following
> performance parameters can be used to characterize the traffic
> characteristics:
>
> · Bitrate characteristics: Peak bit rate (PBR) or peak rate (PR),
> Sustained
> bit rate (SBR) or average rate (AR), minimum bit rate (MBR) or minimum
> rate
> (MR), and mean bust size (MBS)
> · Delay and loss characteristics: end-to-end delay (EED) or delay,
> end-to-end delay variation (EEDV) or delay variation (DV), and
> bit-error-rate (BER) or (packet) loss rate (LR)
>
> We can now form a table with all parameters as follows:
>
> Table 1: H.323 Multimedia Application Performance Matrix
> Audio (codecs)--- Video (codecs)--- Data
> (T.120)
> PBR/PR Yes/No/Value Yes/No/Value Yes/No/value
> SBR/AR Yes/No/Value Yes/No/Value Yes/No/value
> MBR/MR Yes/No/Value Yes/No/Value Yes/No/value
> MBS Yes/No/Value Yes/No/Value Yes/No/value
> EED/Delay Yes/No/Value Yes/No/Value Yes/No/value
> EEDV/DV Yes/No/Value Yes/No/Value Yes/No/value
> BER/LR Yes/No/Value Yes/No/Value Yes/No/value
>
> From the above table we will have the opportunity to choose each parameter
> for each medium (audio, video, data) that makes sense from the
> application's
> and enduser's point of view. Again, these parameters can be specified as
> follows:
>
> · Guaranteed: The value specified for each parameter MUST be guaranteed.
> · Controlled: The value specified for each parameter MAY be satisfied as
> far
> as practicable (possibly with certain range), but definitely NOT
> guaranteed.
> · Best effort: No commitment will be made.
>
> Now each medium (e.g., audio, video, or data) will have different
> categories
> of performance matrix depending on its selection criteria and this can
> also
> be mapped to RSVP, ATM QOS, and others, if needed.
>
> Once we agree on this format, the next step is to create H.323 QOS
> signaling
> messages.
>
> This is my input for discussion in the upcoming Portland Q.13 meeting for
> H.323 QOS.
>
> I like to see the comments from other members as well.
>
> Best regards,
> Radhika R. Roy
> AT&T
> +1 732 420 1580
> rrroy(a)att.com
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv(a)mailbag.intel.com
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv(a)mailbag.intel.com
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
2
1
Dear Ms. Levin and Mr. Juergen,
Your contributions are given TD number as follows:
TD-08 RADVision
Comments on H323-URL Chapter for H.323v4
TD-09 Editor (O Levin)
Comments on CPL Internet Draft for inclusion into H.323 Annex O
TD-10 RADVision
Internet TRIP - Presentation
TD-11 RADVision
Internet Draft: Extensions to the "tel" and "fax" URLs to support Number
Portability
TD-12 Siemens
Liaison statement to IETF AVT Group for Unequal Error Protection
PS to all: APC-1946 reformatted version is now available at /0008_Por
directory.
Best regards,
Sakae OKUBO
***********************************************************
Waseda Research Center
Telecommunications Advancement Organization of Japan (TAO)
5th Floor, Nishi-Waseda Bldg.
1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo
169-0051 Japan
Tel: +81 3 5286 3830 (to be transferred)
+81 3 3204 8194 (direct)
Fax: +81 3 5287 7287
e-mail: okubo(a)giti.or.jp
***********************************************************
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
1
0
Dear Mr. Okubo!
I would like to ask for four TD numbers for the following RADVision contributions:
"Comments on H323-URL Chapter for H.323v4"
"Comments on CPL Internet Draft for inclusion into H.323 Annex O" (by Editor)
"Internet TRIP - Presentation"
"Internet Draft: Extensions to the "tel" and "fax" URLs to support Number Portability"
Thank you and Best Regards,
Orit Levin
RADVision Inc.
575 Corporate Drive Suite 420
Mahwah, NJ 07430
Tel: 1 201 529 4300 (230)
Fax: 1 201 529 3516
www.radvision.com
orit(a)radvision.com
1
0
Hi, Mike:
Our aim is to extend H.323 for supporting QOS. The framework is already
there.
Please see H.323 and H.225.0 Annex G specs how the general framework is done
in the context of H.323.
Again, we are dealing with Q.13/16 and TIPHON exceeds the charter of
Q.13/16. It goes beyond H.323 and involves almost all SGs of ITU-T and IETF
that are dealing with QOS.
I understand what TIPHON is trying to do and TIPHON is just NOT limited to
Q.13/16. The same problem has been in the IETF when TIPHON presented its QOS
model for extending SIP. It appears that it exceeds the charter of SIP.
Please note that people are NOT saying that TIPHON's work is NOT needed. All
they are saying: Let us divide the work in different items and each item
will have its place in the corresponding WGs. For example, policy will be
addressed in the Policy WG, if any particular messages in SIP needs to be
extended to support QOS following the SIP charter that work may be addressed
in the SIP WG, if any particular item needs to extend in SDP to support QOS
that work needs to be done in the MMUSIC.
>From end-to-end call point of view, people will need SIP, SDP, Policy,
Security, Billing, firewalls, NATs, and others. when the standards in all
areas are done, people just use them. This is the second step. I have also
been working with Joon Maeng of VTEL in this area because Joon submitted a
contribution in Q.13/16 last Feb'99 meeting. We are waiting to complete the
H.323 QOS work first.
You can also see an IETF contribution from MCI WorldCom how the interdomain
QOS can be used by SIP using Policy, Security, etc. This work is dependent
on the standard work of Policy WG, and others. Again, this contribution for
supporting interdomain QOS by SIP using Policy, etc. does NOT need any
additional standard work is SIP, it is, rather, an implementation that shows
how an end-to-end call can use all those standards including QOS that have
been developed in different WGs.
Appendix of H.323 QOS Annex N has the general framework. Now you can go
through those items and please let us know where you like to see changes and
why.
Best regards,
Radhika R. Roy
AT&T
-----Original Message-----
From: Mike Buckley [mailto:mikebuckley@44COMMS.COM]
Sent: Tuesday, August 15, 2000 7:51 PM
To: ITU-SG16(a)MAILBAG.INTEL.COM
Subject: Re: H.323 QOS
Radhika,
My aim here is to come up with a general QoS framework in H.323 that will
handle all these situatioins not just special cases. I think we agree on
this.
I would be reluctant to solve a special case without an idea of how we are
going to solve the general case. This can only lead to backward
compatibility issues.
I believe the TIPHON approach is totally general. However I agree it need
some new interfaces defining.
Mike
Mike Buckley
+44-1457-877718 (T)
+44-1457-877721 (F)
mikebuckley(a)44comms.com
----- Original Message -----
From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM>
To: <ITU-SG16(a)MAILBAG.INTEL.COM>
Sent: Tuesday, August 15, 2000 8:21 PM
Subject: Re: H.323 QOS
Hi, Mike:
Yes, you are right that NATs and firewalls problems are yet to be solved
with complete satisfaction from address translation point of view. This may
be a separate work item all by itself.
I do not think that we will bring H.245 to address those problems. In fact,
I have not seen any proposal in that direction.
We have to separate our works step by step.
I would not like to include those general problems as a part of H.323 OQS
for now. Let a separate group or annexes deal with those special problems so
that we can use those solutions for QOS as well, if needed.
Best regards,
Radhika R. Roy
AT&T
-----Original Message-----
From: Mike Buckley [mailto:mikebuckley@44COMMS.COM]
Sent: Tuesday, August 15, 2000 1:13 PM
To: ITU-SG16(a)MAILBAG.INTEL.COM
Subject: Re: H.323 QOS
Hi Radhika,
This model is only valid I think when you have end to end address
transparency as in the Internet. When different transport network domains
are present this doesn't necessarily work. NATs and firewalls will mean
that IP addresses and port numbers in different domains will be different
for the same media stream. Terminating IP and port numbers may well be
different at each end of the call. This is one reason why H.323 will not
work through firewalls. To fix this gatekeepers will have to perform a
mediating function with the H.323 domain and the transport domains. This
mediation will not be via H.245.
SIP has the same problems by the way.
Mike
Mike Buckley
+44-1457-877718 (T)
+44-1457-877721 (F)
mikebuckley(a)44comms.com
----- Original Message -----
From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM>
To: <ITU-SG16(a)MAILBAG.INTEL.COM>
Sent: Tuesday, August 15, 2000 2:15 PM
Subject: Re: H.323 QOS
Hi, Mike:
Just for information, H.245 does many things. As I indicated earlier, one of
the most important things of H.245 is the opening and closing of the logical
channels that binds the application layer's logical connection abstractions
to all transport network connections (e.g., ATM, etc).
So, this is the fundamental mission of H.245 to provide the continuity
between the application layer and the lower layer in a transport independent
way using the universal abstractions. These abstractions can be for anything
that we can think of.
Hope this helps.
Best regards,
Radhika R. Roy
AT&T
-----Original Message-----
From: Mike Buckley [mailto:mikebuckley@44COMMS.COM]
Sent: Tuesday, August 15, 2000 8:22 AM
To: ITU-SG16(a)MAILBAG.INTEL.COM
Subject: Re: H.323 QOS
Hi Radhika,
This use of H.245 as a bridging mechanism is where I have difficulties. The
original intenmt behind H.245 was media control and negociation. Transport
mechanisms should not be signalled in H.245 or elsewhere in the application.
This is entirely the business of the transport network provider.
Unfortunately I will not be present in Portland, however, I am happy to
continue this productive dialogue on the list with a view to providing a new
draft in the next few weeks.
Regards,
Mike
Mike Buckley
+44-1457-877718 (T)
+44-1457-877721 (F)
mikebuckley(a)44comms.com
----- Original Message -----
From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM>
To: <ITU-SG16(a)MAILBAG.INTEL.COM>
Sent: Monday, August 14, 2000 7:29 PM
Subject: Re: H.323 QOS
Hi, Mike:
I guess that we have agreement on the fundamental basis. However, I have
problems when you translate this in signaling terms. As I have explained
earlier that we are following the exiting framework of H.323 which is the
application layer, and H.323 is transported over one or different transport
networks. H.323 uses H.245 as a common mechanism that helps to transports
the abstraction of H.323 application signaling messages over any networks
(e.g., IP, ATM, etc).
You may look to the H.245 spec very carefully instead of making any
generalized statement.
H.245 provides the bridging between the application layer and transport
layer mechanism. For example, H.245's OLC abstraction is the link for ATM
network layer logical connection as well as for other transport networks.
In the same token, H.323 QOS abstraction may also provide link to the lower
transport layer QOS signaling mechanisms (e.g., RSVP, DiffServ, MPLS, ATM
QOS, etc), if needed. H.323 DOES support RSVP and ATM QOS now.
Please also see my reply embedded in you email [RRR].
Again, I would suggest to bring contributions explaining the solution and we
will go from there. In absence of your contributions, I would suggest to
provide comments on Appendix of H.323 QOS Annex N. We can then answer your
questions step by step.
Best regards,
Radhika R. Roy
AT&T
-----Original Message-----
From: Mike Buckley [mailto:mikebuckley@44COMMS.COM]
Sent: Monday, August 14, 2000 12:56 PM
To: ITU-SG16(a)MAILBAG.INTEL.COM
Subject: Re: H.323 QOS
Radhika,
>However, this is only good for the single network. For example,
>end-to-end RSVP or end-to-end ATM QOS.
>If there are multiple networks or if a single IP network implements RSVP in
>one domain, DiffServ in another domain, and MPLS in another domain, there
is
>no transparent H.323 QOS signaling mechanism that is universal on
end-to-end
>basis so that it can be mapped over the RSVP, DiffServ, MPLS, ATM QOS, etc
>transparently
This is the nub of the problem and I am afraid why this approach is flawed.
[RRR] I am NOT afraid of anything. Rather we are solving all problems
including the above as well. No one should be afraid of anything. The only
thing that I can suggest is to bring contributions. We will go from there.
Please remember that H.323 QOS supports RSVP and ATM QOS and we MUST provide
backward compatibility. We will be waiting to see contributions from you to
prove your points whether things are flawed or not. Please read Appnedix of
H.323 QOS Annex N very carefully along with exiting H.323 and H.245
standard how they support H.323 QOS for RSVP and ATM QOS.
>We have shown how the H.323 QOS can
>be mapped over the RSVP, DiffServ, ATM QOS, etc. if needed.
This mapping must be done within the transport plane not by the application.
All the application needs to specify are the entries in your Table 1. i.e
delay, jitter. packet loss and peak bit rate (the latter parameter for
policy enforcement and resource reservation).
[RRR] Please see my generalized clarification how H.245 provides translation
between H.323 signaling schemes over the lower layer transport networks
(e.g., IP, ATM, etc). The mechanism already exists in H.323 and this is the
beauty of the transport independent H.323 application. Now there are two
separate things: one is what the calling side of the application demands and
what the called side of the application agrees on. This is called
negotiation capability (e.g., choosing a particular type codec that has a
certain bandwidth, jitter, and other requirements). How the choosing
criteria is determined, the H.323 application is NOT aware of those things.
It may depend on many criteria (e.g., policy, bandwidth, type of network
[e.g., IP, ATM], pricing, security, personal preferences, etc.), but H.323
is not involved. These are separate issues and we are NOT addressing at the
H.323 layer.
I am still not clkear how you propose to signal these parameters to the
transport plane.
[RRR] It is NOT new in H.323, and this mechanism already exits. Please see
the support of RSVP and ATM QOS in H.323/H.245 spec. We are not inventing
anything NEW here. Then, if you read Appendix of H.323 QOS Annex N very
carefully, you will find how it happening (whether you call it as transport
plane or something else, it does not matter).
I think we are getting loser to a common understanding.
Mike
Mike Buckley
+44-1457-877718 (T)
+44-1457-877721 (F)
mikebuckley(a)44comms.com
----- Original Message -----
From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM>
To: <ITU-SG16(a)MAILBAG.INTEL.COM>
Sent: Monday, August 14, 2000 2:37 PM
Subject: Re: H.323 QOS
Hi, Bob:
I agree completely agree with you.
In fact, we are all trying to achieve the same goal. For example, H.323 does
supports QOS today via H.245. You can easily see that RSVP and ATM QOS are
supported using H.245. The beauty of this approach is that H.245 is still
transport independent. All we have done here is: the abstraction of H.245
has been used to support the RSVP and ATM QOS to implement the network layer
QOS. However, this is only good for the single network. For example,
end-to-end RSVP or end-to-end ATM QOS.
If there are multiple networks or if a single IP network implements RSVP in
one domain, DiffServ in another domain, and MPLS in another domain, there is
no transparent H.323 QOS signaling mechanism that is universal on end-to-end
basis so that it can be mapped over the RSVP, DiffServ, MPLS, ATM QOS, etc
transparently.
In Appendix of H.323 Annex N, we have done the same. We have the abstraction
of H.323 QOS in the application layer. We have shown how the H.323 QOS can
be mapped over the RSVP, DiffServ, ATM QOS, etc. if needed. It also provides
the backward compatibility with the existing H.323 standard. However, we
have done only for the pre-call setup signaling part. We have not done the
call setup part yet. In the call setup part, we will include H.245 in a
similar way what H.323 is supporting RSVP and ATM QOS today in a monolithic
network.
I appreciate your email.
Best regards,
Radhika R. Roy
AT&T
> -----Original Message-----
> From: Callaghan, Robert [SMTP:Robert.Callaghan@icn.siemens.com]
> Sent: Monday, August 14, 2000 9:08 AM
> To: Roy, Radhika R, ALCOO
> Cc: 'Mailing list for parties associated with ITU-T Study Group 16'
> Subject: RE: H.323 QOS
>
> Roy,
>
> In my view, the network, as a minimum, needs only provide transport.
> H.323
> is an application using this transport and is not different from any other
> application being transported. Any application may request a desired
> quality of service that the network may grant based on policies, service
> level agreements, and availability. Each data connection used by an
> application may request a different QOS. Most likely H.323 is such an
> application as needing an enhanced QOS. This simple case should work.
> This
> is all that is required.
>
> In addition to transport, the network may optionally provide other
> additional services. These services may include application layer
> routing.
> These optional services should be configured and indicated independently
> from the basic transport QOS.
>
> It is correct that H.323, as an application, is (mostly) transport
> independent. However, the interface between the application and the
> transport layer is not transport independent. The interface specification
> used to request a given QOS is totally dependant on the standards body
> that
> specified the transport layer; and for this there has been little or no
> coordination.
>
> Because transport QOS over IP is based on IETF specifications, it is
> necessary that the interface used to request a given QOS conform to the
> appropriate IETF specification. If such an interface specification is not
> available, that input might be provided to the appropriate IETF body as to
> the requirements.
>
> I can see the endpoints negotiating the desired QOS base on need, price,
> and
> other considerations. For me, this is the limit to the application layer
> involvement in QOS negotiation. At this point, the application
> negotiations
> with the transport provider as to the desired and available QOS. It is up
> to the transport provider to arrange for the end-to-end QOS. (Again, it
> is
> not necessary for the transport network to know that H.323 is involved in
> the transported data. In fact it may be encrypted in order to mask the
> presence of voice transport.)
>
> For me, this is simple.
>
> Bob
>
> ------------------------------------------------------------------
> Robert Callaghan
> Siemens Enterprise Networks
> Tel: +1.561.923.1756 Fax: +1.561.923.1403
> Email: Robert.Callaghan(a)ICN.Siemens.com
> ------------------------------------------------------------------
>
> -----Original Message-----
> From: Roy, Radhika R, ALCOO [mailto:rrroy@ATT.COM]
> Sent: Friday, August 11, 2000 7:59 AM
> To: ITU-SG16(a)mailbag.cps.intel.com
> Subject: Re: H.323 QOS
>
> Hi, Mike:
>
> Let me try again.
>
> What is the reference point of H.323 QOS? Is it not H.323? If it is so,
> what
> do we mean by H.323?
>
> The answer is: Audio (different codecs), Video (different codecs), and
> Data
> (T.120 applications) that are used by H.323.
>
> What are the QOS/performance characteristics of audio, video, and data
> from
> the application point of view that is generated by audio codecs, video
> codecs, and data (T.120) applications?
>
> These QOS/performance characteristics come from the SOURCE codecs and data
> applications. Per transport independent H.323 specifications, an enduser
> express their QOS/performance requirements on end-to-end basis purely from
> application point of view irrespective of the transport network (e.g., IP,
> ATM, etc.).
>
> Moreover, H.323 is meant for the packet network, not for any
> circuit-switched network like PSTN or ISDN.
>
> Let us NOT go beyond this before we start debating transport layer QOS or
> service provider requirements. These are NOT the concern of H.323. H.323
> is
> the transport independent application.
>
> H.323v2/v3/v4 has also provided mechanisms how RSVP and ATM QOS can be
> used
> for H.323 audio, video, and data. So, H.323 QOS that will be defined in
> H.323 Annex N MUST provide mapping for the backward compatibility. It is a
> requirement that MUST be met per the norm of ITU-T.
>
> So, what is left for mapping? Mapping is simply a by-product of the above
> requirement. Mapping is simply a table, nothing else.
>
> Did I miss anything?
>
> Best regards,
> Radhika R. Roy
> AT&T
>
> -----Original Message-----
> From: Mike Buckley [mailto:mikebuckley@44COMMS.COM]
> Sent: Thursday, August 10, 2000 10:19 PM
> To: ITU-SG16(a)MAILBAG.INTEL.COM
> Subject: Re: H.323 QOS
>
>
> Radhika,
>
> Thanks for the input which I welcome as I will unfortunately not be
> present
> at Portland.
>
> Let me ask a few questions and make a few comments hopefully with the
> intent
> of opening up the debate.
>
> 1. I am not sure I understand your concept of a mapping table between the
> H.323 QOS and the transport layer QoS. My understanding is that QoS is on
> three levels:
>
> a) that specified from a service point of view between the user and
> service
> provider (e.g PSTN quality, conference quality etc) This is the domain of
> the speech experts and can be characterised by Listener Speech Quaklity
> (MOS), end to end delay, and absolute category rating, R.
>
> b) application specific parameters, (e.g. equipment delays, codec choice
> and performance, codec frame size, packetisation arrangements, jitter
> buffer
> design, overall packet loss etc.) Optimisation of all these will
> determine
> what can be delivered in a).
>
> c) transport parameters for a given choice of application parameters.
> This
> boils down only to three parameters as far as I cna see: tranport network
> delay, packet delay variation in the transport network and packet loss in
> the transport network. Again these parameters will determine the results
> in
> a) for a given choice of the parameters in b). These parameters are
> generic
> from the perspective of the transport network. i.e the transport network
> does not need to know the details of the application.
>
> So the sequence of cause and effect and control is:
>
> a) User requests QoS class from service provider,
> b) Service provider determines application specific parameters in
> conjunction with users equipment and other service providers,
> c) Service provider requests required delay, delay variation and packet
> loss from network provider.
>
> I see no need for mapping here. The only QoS info flows within the
> application are specific to the application and those between the
> application (service provider) and the transport network are generic. i.e.
> delay, jitter and packet loss. Have I missed something?
>
> 2. The issue of bit rate and media stream statistics I think need to be
> decoupled from QoS. These are specified to enable optimisation of
> resources
> within the transport network. They have no QoS significance from an
> application point of view. i.e the apllication does not care about the
> media stream bit rate and statistics but the transport network provider
> does
> as it eats up his resource. They may be used for policy enforcement
> however
> in the transport network so they do need to be agreed between service
> provider and network operator. i.e the network operator agrees to provide
> a
> given QoS level (delay, jitter, packet loss) provided the media properties
> are within an agreed profile (bit rate, flow statistics).
>
> 3. The next point is how can the service provider know the statistics of
> a
> particular VBR stream? These can only be specified over a large number of
> similar calls and will depend, for instance, on who is speaking, the
> nature
> of the speech interaction etc etc. They can only be measured not
> calculated. The service provider is in no better position to measure
> these
> than the transport network operator and, in fact, where no gateways are
> involved, may not be able to. On the other hand the class of signal would
> have to be signalled to the network operator for him to be able to
> distinguish which class a particular measurement belonged to. e.g
> voice/speech/data, codec type, conference, multicast etc. So I see no
> purpose in trying to exchange statistics between the service provider
> (application) and transport operator. I think peak bit rate is all that
> can
> be meaningfully excanged. The specification of media class is however
> perhaps worth exploring.
>
> 4. The controlled category has always puzzled me. I only see two
> possibilities. Either the requested QoS level is guaranteed (on a
> statistical basis e.g 95% of all connections over a specified period) or
> not
> guaranteed. Is your controlled category a way of saying guaranteed, not
> to
> 95% but to some lower figure? If you can't put a percentage on it then it
> seems it is plain and simple not guaranteed. Anything that is not
> guaranteed to some specified statistical level is best effort and you
> can't
> say anything more about it. So I only see two categories here.
>
> In summary, I think we need to do three things in Annex N.
>
> a) Figure out the QoS information to be exchanged within the Application
> between service providers and end users. This will go in H.225.0 and
> H.245.
>
> b) Figure out how we are going to signal QoS and media information between
> the application (service providers) and transport domains (IP or ATM
> networks etc). The info is basically delay, jitter, packet loss
> requirements and peak bit rate. We need a protocol for this.
>
> c) we need to work out the interactions between the application QoS
> signal
> flows and the application/transport signal flows. I don't think we need
> worry about how the transport network mechanisms assure the requested QoS
> paramerters. RSVP/Intserv, Diffserv, MPLS, ATM, over provisioning are all
> possibilities.
>
> Would welcome comments and views on the above.
>
> Mike
>
>
> Mike Buckley
> +44-1457-877718 (T)
> +44-1457-877721 (F)
> mikebuckley(a)44comms.com
>
>
> ----- Original Message -----
> From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM>
> To: <ITU-SG16(a)MAILBAG.INTEL.COM>
> Sent: Thursday, August 10, 2000 10:15 PM
> Subject: H.323 QOS
>
>
> Hi, Mike and All:
>
> It is time to discuss about H.323 QOS.
>
> I believe that we have an agreement as follows:
>
> · H.323 QOS MUST be backward compatible to support RSVP and ATM QOS as it
> exists for H.323v2/v3/v4
> · Like H.323 spec, the application level H.323 QOS MUST be independent of
> the transport layer QOS and should support all transport networks (e.g.,
> IP,
> ATM)
> · A mapping table between the H.323 QOS and the transport layer QOS (e.g.,
> IP QOS [DiffServ, RSVP, etc.], ATM QOS [CBR, rt-VBR, nrt-VBR, ABR, etc.])
> should be provided.
>
> From the H.323 multimedia application point of view, there are following
> performance parameters can be used to characterize the traffic
> characteristics:
>
> · Bitrate characteristics: Peak bit rate (PBR) or peak rate (PR),
> Sustained
> bit rate (SBR) or average rate (AR), minimum bit rate (MBR) or minimum
> rate
> (MR), and mean bust size (MBS)
> · Delay and loss characteristics: end-to-end delay (EED) or delay,
> end-to-end delay variation (EEDV) or delay variation (DV), and
> bit-error-rate (BER) or (packet) loss rate (LR)
>
> We can now form a table with all parameters as follows:
>
> Table 1: H.323 Multimedia Application Performance Matrix
> Audio (codecs)--- Video (codecs)--- Data
> (T.120)
> PBR/PR Yes/No/Value Yes/No/Value Yes/No/value
> SBR/AR Yes/No/Value Yes/No/Value Yes/No/value
> MBR/MR Yes/No/Value Yes/No/Value Yes/No/value
> MBS Yes/No/Value Yes/No/Value Yes/No/value
> EED/Delay Yes/No/Value Yes/No/Value Yes/No/value
> EEDV/DV Yes/No/Value Yes/No/Value Yes/No/value
> BER/LR Yes/No/Value Yes/No/Value Yes/No/value
>
> From the above table we will have the opportunity to choose each parameter
> for each medium (audio, video, data) that makes sense from the
> application's
> and enduser's point of view. Again, these parameters can be specified as
> follows:
>
> · Guaranteed: The value specified for each parameter MUST be guaranteed.
> · Controlled: The value specified for each parameter MAY be satisfied as
> far
> as practicable (possibly with certain range), but definitely NOT
> guaranteed.
> · Best effort: No commitment will be made.
>
> Now each medium (e.g., audio, video, or data) will have different
> categories
> of performance matrix depending on its selection criteria and this can
> also
> be mapped to RSVP, ATM QOS, and others, if needed.
>
> Once we agree on this format, the next step is to create H.323 QOS
> signaling
> messages.
>
> This is my input for discussion in the upcoming Portland Q.13 meeting for
> H.323 QOS.
>
> I like to see the comments from other members as well.
>
> Best regards,
> Radhika R. Roy
> AT&T
> +1 732 420 1580
> rrroy(a)att.com
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv(a)mailbag.intel.com
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv(a)mailbag.intel.com
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
2
1