[RRR] Certainly it is NOT the case. It is H.323, and nothing to do with service providers or network operators. H.323 spec only deals with the application on end-to-end basis.
[PMB] The problem is ALL to do with service providers and network operators and their business relations with each other and their customers. See my comments below on architecture. H.323 is signalling between a user and an IP telephony service provider (assuming we use the gatekeeper model). If a network operator provides H.323 support he is by definition also a service provider. A network operator's role by my definition is to provide generic IP Transport. There are QoS issues to be resolved in both the application layer (service provider) and transport layer (IP transport network). There needs to be co-ordination between the two although the two must be mechanism independent.
[RRR] It is NOT true. Please see H.245 spec how each medium is signaled along with QOS parameters (e.g., RSVP, ATM QOS). It already exits in H.323/H.245 on end-to-end basis if there is only one kind of network. We are just extending the same concept on end-to-end basis if there is one or multiple networks. If there is only one network either IP or ATM, H.323 QOS does NOT need any additional work per se. For IP network, H.323 provides the support of RSVP and more work may be needed if DiffServ or MPLS needs to be supported. For ATM QOS, H.323 QOS spec is also complete. But if there are combinations of IP and ATM (and/or other networks), there is no end-to-end H.323 QOS signaling mechanism that can be used as an universal set across all networks. In fact, as I told before, we are SOLVING this problem in H..323 Annex N.
[PMB] There are a lot of issues here. In the multiple network case there is no point in signalling properties related to the transport QoS mechanisms. You yourself agreed that the apllication signalling should be independent of transport mechanism. This can also be the case for the single domain which is just a special case of the multiple domain situation. The existing H.323 mechanisms make a number of simplifying assumptions that would not work in practice. There are issues of control, trust, policy enforcement and business relations that are not taken into account in the existing model. I believe Annex N is about solving the general case and providing an H.323 solution for ends to end control in mixed multi-domain networks where multiple operators are involved and multiple service providers. If we don't solve the general case I believe the Standard will be failing the market.
Incidentally you say my comments about media stream statistics are not true but the points you make are orthogonal to the points I am making.
[RRR] Please see the Appendix of H.323 Annex N how the QOS classes and the corresponding signaling messages have been created, and how the signaling will be done. There are two stages of H.313 QOS signaling: 1. Pre-call setup phase and 2. Call setup phase. In pre-call setup, it is the empty signaling messages sets that will be sent to determine whether these kind of QOS classes are supported on end-to-end basis. It is called the discovery phase. So far, it has been the ONLY goal for H.323 QOS.
[PMB] Could you eloborate on the objectives at the discovery phase. Is this done on a per call basis? If you are saying there needs to be signalling end to end between service providers to find out whether a particular QoS request can be supported before the call can be set up I am in basic agreement. I don't see this as an issue of QoS classes however but one of QoS budgets.
[RRR] For the call setup phase, the actual values of all those parameters are needed. We expect that the values can be chosen by endusers if there are no standards. However, if other SGs or forums (e.g., TIPHON, IMTC, SLA agreements, etc.) define those values, people can also use those specific values. Then the H.323 QOS signaling messages can use those implementation specific values. H.323 QOS will only have the place holder for those values.
[PMB] Yes, I agree in principle. But the user will usually only specify the QoS class he wants as agreed between him and his service provider. He will not be specifying end to end delay, jitter and packet loss, although I agree he could. In either case these parameters can only be calculated once a compatible codec has been chosen.
The next problem is allocating budgets across domains once the end to end budgets have been extablished. This has to be done by some network or service provider based entity.
[RRR] H.245 is currently using RSVP and ATM QOS and we will use the similar approach. No new work is needed here.
[PMB] This is a contradiction of your axiom that the application level techniques must be independent of the transport domain QoS mechanism. You can't signal the transport QoS mechanism where there are multiple domains. And I think there are a lot of unresolved issues in doing this in the single domain case. I thought you had made this point yourself above.
[RRR] the order of events are shown in Appendix of H.323 Annex N.
[PMB] Please could you explain in words what is happening. Once we close on the principles we can start to look at the code.
[RRR] H.323 does not define anything related to service providers, application providers, or network providers. It is implementation specific. It will only deal with the H.323 QOS signaling messages on end-to-end basis as it has been dong for RSVP and ATM QOS. Let other SGs or forums do some implementation specific agreement/standard for H.323 QOS.
[PMB] We have to resolve the roles of these parties to figure out what we are going to put in H.323 messages. You are bundling them all together and pretending there is only one entity to coinsider - the network. This approach will not provide the solutions we are looking for in the multiple domain case or where there are business relations and issues of trust and control to take into account between different entities. This is not just an issue of implementation. Terminal registration is a real issue and some QoS elements will almost certainly have to be added to RAS.
[RRR] Again a GK can signal QOS parameters, but H.323 does not recognize service providers, applications providers, or network providers. However, the GK will signal using the H.323 QOS messages. The QOS signaling messages will contain many parameters (I do not think that it will contain QOS level per se).
[PMB] H.323 is a protocol. But you can't decide how you are going to use a protocol to solve a problem until you have an architecture in mind. That's what we are discussing. Service providers and network operators inevitably enter into the architecture. I agree with your last two sentences. My previous comments have been addressing what goes into the H.323 QoS fields.
[RRR] H.245 has well established negotiation capabilities. We do not need to do any additional work here.
[PMB] Agreed. But we need to take into account when this info is available because the decision effects QoS budgets.
[RRR] Please see my answers provided above. Currently, Appendix of H.323 Annex N has it completed how the pre-call setup signaling messages can be exchanged. The call setup phase will use the same mechanism as it exists today for RSVP and ATM QOS. We will only augment this using NEW parameters of H.323 QOS.
[PMB] Again you seem to be contradicting yourself here. How can we use the same approach across heterogeneous domains and be transport mechanism independent?
[RRR] The pre-call setup and call setup phase that will use H.323 QOS messages (as shown in Appendix of H.323 QOS) will meet the QOS requirements. I do not think that we should "INVENT" any new security mechanisms ONLY specific to H.323 QOS. Security should be dealt for H.323 in general. This work MUST be de-coupled from H.323 QOS.
[PMB] I believe we have to invent something new here if we are to solve the problem of multiple domains. Authorisation is not new however. Policy decision on H.323 QoS is in the application and policy enforcement in the transport network. They have to talk to one another. We don't have a solution to this today. Without a solution to this we have not solved the problem we have set ourself on controlling end to ends QoS.
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: Friday, August 11, 2000 7:46 PM Subject: Re: H.323 QOS
Hi, Mike:
Please see my response stated below [RRR].
Best regards, Radhika
-----Original Message----- From: Mike Buckley [mailto:mikebuckley@44COMMS.COM] Sent: Friday, August 11, 2000 1:24 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: H.323 QOS
Radhika,
Sorry , I am not following your arguments here. I thought your Table 1 was a description of the QoS requirements and media stream properties that would be signalled by the application/service provider to the network operator. This is transport QoS mechansm independent. [RRR] Certainly it is NOT the case. It is H.323, and nothing to do with service providers or network operators. H.323 spec only deals with the application on end-to-end basis.
I maintain that the media statistic parameters can not in general be signalled on a per media stream basis. Only peak bit rate has any meaning to the application and derives from the choice of codec and packetisation arrangements. [RRR] It is NOT true. Please see H.245 spec how each medium is signaled along with QOS parameters (e.g., RSVP, ATM QOS). It already exits in H.323/H.245 on end-to-end basis if there is only one kind of network. We are just extending the same concept on end-to-end basis if there is one or multiple networks. If there is only one network either IP or ATM, H.323 QOS does NOT need any additional work per se. For IP network, H.323 provides the support of RSVP and more work may be needed if DiffServ or MPLS needs to be supported. For ATM QOS, H.323 QOS spec is also complete. But if there are combinations of IP and ATM (and/or other networks), there is no end-to-end H.323 QOS signaling mechanism that can be used as an universal set across all networks. In fact, as I told before, we are SOLVING this problem in H..323 Annex N.
In agree the values in the Table do not need to be specified in the protocol. I am happy with YES/NO/Value with Value being optional in the case of YES. [RRR] I am glad to hear that we are in agreement here.
So, the first problem is to express performance/QOS parameters that do NOT contain any values. That is, it will have only the parameters without any value. For example, all audio/video codecs will have their parameters expressed that will have only a limited set (in the previous case as can be seen in Appendix of Annex N - there has been only 4 sets, etc.). These are universal sets and does not matter what the codec type is.
You have lost me here. What is the point signalling empty sets? [RRR] Please see the Appendix of H.323 Annex N how the QOS classes and the corresponding signaling messages have been created, and how the signaling will be done. There are two stages of H.313 QOS signaling: 1. Pre-call setup phase and 2. Call setup phase. In pre-call setup, it is the empty signaling messages sets that will be sent to determine whether these kind of QOS classes are supported on end-to-end basis. It is called the discovery phase. So far, it has been the ONLY goal for H.323 QOS.
[RRR] For the call setup phase, the actual values of all those parameters are needed. We expect that the values can be chosen by endusers if there are no standards. However, if other SGs or forums (e.g., TIPHON, IMTC, SLA agreements, etc.) define those values, people can also use those specific values. Then the H.323 QOS signaling messages can use those implementation specific values. H.323 QOS will only have the place holder for those values.
The order of events must surely be: [RRR] the order of events are shown in Appendix of H.323 Annex N.
a) User requests QoS level of service provider: gold, silver etc. [RRR] Again, this is implementation specific and SG16 is not the right place to define gold, silver, etc. for H.323.
b) Application uses H.225.0 and H.245 to establish compatible codecs and packetisation arrangements consistent with a), [RRR] H.245 is currently using RSVP and ATM QOS and we will use the similar approach. No new work is needed here.
c) Application computes delay, delay variation and bit error rate required of transport network and signalls these to transport network operator. [RRR] We do not need to do anything NEW other than the similar thing what H.245 is doing currently for RSVP and ATM QOS.
H.225.0 and h.245 will be used to:
a) register a terminal's QoS characteristics with the service provider (gatekeeper). [RRR] H.323 does not define anything related to service providers, application providers, or network providers. It is implementation specific. It will only deal with the H.323 QOS signaling messages on end-to-end basis as it has been dong for RSVP and ATM QOS. Let other SGs or forums do some implementation specific agreement/standard for H.323 QOS.
b) for user to request gold, silver or bronze or the end to end QoS parameters from a service provider (gatekeeper), [RRR] Again, it is an implementation issue, not a H.323 QOS protocol issue: gold, silver, etc. My response for item a is applicable.
c) for service providers (gatekeepers) to signal QoS parameters to each other to enable end to end QoS levels to be achieved. [RRR] Again a GK can signal QOS parameters, but H.323 does not recognize service providers, applications providers, or network providers. However, the GK will signal using the H.323 QOS messages. The QOS signaling messages will contain many parameters (I do not think that it will contain QOS level per se).
d) to establish compatible codecs and packetisation at both ends of a media stream. [RRR] H.245 has well established negotiation capabilities. We do not need to
do any additional work here.
Registration will take place prior to call set up. The rest of the QoS information flows must take place at call set up. [RRR] Please see my answers provided above. Currently, Appendix of H.323 Annex N has it completed how the pre-call setup signaling messages can be exchanged. The call setup phase will use the same mechanism as it exists today for RSVP and ATM QOS. We will only augment this using NEW parameters of H.323 QOS.
We need a new protocol for signalling QoS requirements and authorisations to the network operator. [RRR] The pre-call setup and call setup phase that will use H.323 QOS messages (as shown in Appendix of H.323 QOS) will meet the QOS requirements. I do not think that we should "INVENT" any new security mechanisms ONLY specific to H.323 QOS. Security should be dealt for H.323 in general. This work MUST be de-coupled from H.323 QOS.
Let's continue the debate on this lists - this is the best way of arriving at an agreed approach. Documenting it once we have agreement on what the problem is and how we are going to solve it should be quite straightforward. I hope we will have something to determine in November. [RRR] Yes, this has been the main purpose of my email. Moreover, emails go to all people throughout the whole world. Each one of us can participate. This is the MOST convenient way for resolving issues. I appreciate your response.
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: Friday, August 11, 2000 5:09 PM Subject: Re: H.323 QOS
Hi, Mike:
Please note the following:
Table 1 shows all parameters that are observed in digitization form. (There may be similarity with some transport level parameters, but these are expressed in a transport independent way.)
A given codec/data (appln.) may or may have all the parameters. If not, those parameters will be NOT be used.
Each parameter contain: Yes/No and Value.
So, the first problem is to express performance/QOS parameters that do NOT contain any values. That is, it will have only the parameters without any value. For example, all audio/video codecs will have their parameters expressed that will have only a limited set (in the previous case as can be seen in Appendix of Annex N - there has been only 4 sets, etc.). These are universal sets and does not matter what the codec type is.
In H.323, we are NOT defining values of the parameters because values are subjective and implementation dependent. The values of any given QOS parameter or a set of QOS parameters are beyond the scope of H.323 (Q.13/16). The values are being defined in other SGs or organizations (e.g., TIPHON, IMTC, etc.).
You are right that the values for each codec will be different. People may define many classes based on values as well. For example, 100ms delay is gold service, 150ms delay is silver service, etc. In Annex N, we will not be addressing those values.
The same is also true for data.
Defining of QOS values of any given parameters is OUT of scope of H.323.
It appears that there is a mis-understanding. I do not any intention for any personal attack other than to complete the work on time (if it appears so, I apologize for this).
Hope this clarifies your questions.
Best regards, Radhika R. Roy
-----Original Message----- From: Mike Buckley [mailto:mikebuckley@44COMMS.COM] Sent: Friday, August 11, 2000 11:08 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: H.323 QOS
Radhika,
The basic problem is to express the end-to-end H.323 QOS parameters of each medium (audio, video, data) that are applicable no matter what the underlying transport network (or networks) is.
The answer of this problem is Table 1 that I have provided.
We agree on the first paragraph. The problem I have with your Table 1 relates to media statistics (see my earlier comments). Incidentally the columns are the properties of transport media streams. the values will be dependent on media type, codec, packetisation etc. So I am not sure what the relevance of codec or T.120 is in the heading. The parameters in each column are what I regard as the generic bearer descriptor.
Now we have to group those parameters in different combinations for each medium that makes sense from the enduser point of view to satisfy their requirements.
This is the simple problem.
The values follow from the users QoS service request, and the choices made by the application in achieving this (codec type, packetisation, jitter buffer design). Once the application has figured out what these parameters are then the entries in your table can be computed by the application and flagged to the transport operator on a domain by domain basis or end-to-end if there is one homogeneous transport space.
A by-product of this solution needs to satisfy RSVP and ATM QOS as H.323v2/v3/v4 spec is doing today.
I see no conflict with the use of these transport mechanisms in the transport plane. You seem terribly worried about this. What is the problem?
I am surprised to see that you are still saying that your are NOT familiar with H.323. If it is so, we have problems. An editor needs to be on the top of everything because the last editor did a good amount of job in a very short period of time addressing all issues. We are now going backward and losing our valuable time just because the editor is NOT familiar with
H.323.
If you ask questions, I would be happy to answer as much as I can.
You are putting words into my mouth here that I never used. Why the personal attack? I thought the discussion had been quite constructive up to this point.
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: Friday, August 11, 2000 2:41 PM Subject: Re: H.323 QOS
Hi, Mike:
The basic problem is to express the end-to-end H.323 QOS parameters of each medium (audio, video, data) that are applicable no matter what the underlying transport network (or networks) is.
The answer of this problem is Table 1 that I have provided.
Now we have to group those parameters in different combinations for each medium that makes sense from the enduser point of view to satisfy their requirements.
This is the simple problem.
A by-product of this solution needs to satisfy RSVP and ATM QOS as H.323v2/v3/v4 spec is doing today.
I am surprised to see that you are still saying that your are NOT familiar with H.323. If it is so, we have problems. An editor needs to be on the top of everything because the last editor did a good amount of job in a very short period of time addressing all issues. We are now going backward and losing our valuable time just because the editor is NOT familiar with H.323. If you ask questions, I would be happy to answer as much as I can.
I like to see other members also provide comments on this.
Best regards, Radhika
-----Original Message----- From: Mike Buckley [mailto:mikebuckley@44COMMS.COM] Sent: Friday, August 11, 2000 9:01 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: H.323 QOS
Radhika,
I think we are in total agreement until your last two paragraphs. Lets figure out what problem we are solving and what we need to do to achieve this, then examine the issues of backward compatibility.
You are a lot more familiar than I am with the existing H.323 mechansims. Why are these not transport mechansm independent as per your model?
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: Friday, August 11, 2000 12:58 PM 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@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