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@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@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@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@44comms.com

----- Original Message ----- From: "Roy, Radhika R, ALCOO" rrroy@ATT.COM To: ITU-SG16@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@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@44comms.com

----- Original Message ----- From: "Roy, Radhika R, ALCOO" rrroy@ATT.COM To: ITU-SG16@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@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@44comms.com

----- Original Message ----- From: "Roy, Radhika R, ALCOO" rrroy@ATT.COM To: ITU-SG16@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@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@44comms.com

----- Original Message ----- From: "Roy, Radhika R, ALCOO" rrroy@ATT.COM To: ITU-SG16@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@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@44comms.com

----- Original Message ----- From: "Roy, Radhika R, ALCOO" rrroy@ATT.COM To: ITU-SG16@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@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@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@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@44comms.com

----- Original Message ----- From: "Roy, Radhika R, ALCOO" rrroy@ATT.COM To: ITU-SG16@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@att.com

For help on this mail list, send "HELP ITU-SG16" in a message to
listserv@mailbag.intel.com

For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com

For help on this mail list, send "HELP ITU-SG16" in a message to
listserv@mailbag.intel.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com