September 2000 - sg16-avd - lists.packetizer.com

Re: H.323 QOS
by Roy, Radhika R, ALCOO 02 Nov '00

02 Nov '00

Hi, Mike: I wonder when do you think that you will be agreeing with something after so many emails? Best regards, Radhika R. Roy AT&T -----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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

3 2

PV2001 Final Call for Papers
by PV2001 25 Sep '00

25 Sep '00

Please find attached Final Call for Papers of Packet Video Workshop 2001 to be held in Kyungju, Korea During 30 April - 1 May, 2001. The deadline for paper submission, 15 November 2000, is coming soon. Updated paper submissioin information is at http://pv2001.kaist.ac.kr. For further information, please send an email to pv(a)pv2001.kaist.ac.kr. We look forward to an exciting PV2001. Best Regards, Chieteuk Ahn PV2001 Organizing Committee Chair

1 0

Portland meeting report and WP2 workplan in November
by Sakae OKUBO 23 Sep '00

23 Sep '00

Dear Q12-14/16 experts, The report of the Portland meeting APC-1949 has been placed at <http://standard.pictel.com/ftp/avc-site/0008_Por/APC1949.zp> with confirmed status. I have not received any comments. Mr. Tosco's workplan of WP2 in November is available at the following place: <http://standard.pictel.com/ftp/avc-site/0011_Gen/WP2_WorkPlan_Nov_00.zip> 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

TR: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded
by SAMOU Jean-claude FTRD/DAC/ISS 22 Sep '00

22 Sep '00

Hi, Everyone: Sorry for the disturbance. This is a re-transmission due to some mailing errors. -----Message d'origine----- De: SAMOU Jean-claude FTRD/DAC/ISS [mailto:jeanclaude.samou@RD.FRANCETELECOM.FR] Date: mercredi 20 septembre 2000 18:01 À: ITU-SG16(a)MAILBAG.INTEL.COM Objet: Re: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded Hi, Everyone: Sorry for not getting into the discussion earlier since I was out of station for some time. I just logged into my PC and saw your interesting e-mail discussion on mobility management protocols (in particular between the VLF and HLF). I would like to share here some concerns of Radhika Roy on this matter. As he clearly points out, the HLF and VLF are only value-added functions which are necessary for handling mobility of users. There is nothing specific in VLF <-> HLF in terms of mobility with respect packet vs. circuit or connection oriented vs connectionless, etc. As you are probably aware of, the IMT-2000 group in ITU-T SG11 is currently working on developing a common mobility management protocol which should accomodate various users of different types of mobile systems (e.g. IS-41, UMTS, etc). This is the well known FAMILY concept in ITU-T SG11. SG16 and SG11 had one joint meeting in the last Feb'00 in Geneva. During this meeting, this mobility protocol work was briefly introduced by SG 11 and it was recognized that the requirements & major concepts identified for mobility in H.323 networks are very similar to those of IMT-2000 (since IMT-2000 should also provide packet-based multi-media services), and a close cooperation between these two groups is required on mobility and roaming aspects for the benefits of H.323 and IMT-2000 systems. In addition, this will allow the roaming of any users between different types of network (for instance an H.323 user roaming into an IS-41 or UMTS network and vice-versa). Therefore, I tend to disagree with Jaakko who says that IMT-2000 is not defining (or intended for) packet-based networks. For instance the concept of VLF and HLF are pretty much close to those of the LMFv and LMFh in IMT-2000 (see ITU-T Rec. Q.1711) for the strict reason that they are both server functions which handle mobility independently of the transport networks. Then why not a common protocol for common mobility requirements and functions? On the other hand, I agree that Extensions of H.323 (e.g. H.225.0 [RAS, Q.931, Annex G]) need to be provided by Q.13/16 since they are very specific to the H.323 type of access. Again, I would like to support Radhika in his analysis of trying to develop a common solution that fits the need of any type of mobile users rather than developing one VLF <-> HLF protocol for H.323, one VLF <-> HLF for H.321, etc. Otherwise, it will be a BIG mess for network operators (as well for manufacturers) and lead to have different protocols which may be incompatible between themselves. This will also make the inter-networking aspects very tough thereby preventing any global roaming of users. FYI, I would also like to inform you that 3GPP has selected SIP for its MULTIMEDIA stuff. In this case, how would it be possible to roam between a 3GPP network and H.323 network, and with other networks (not using SIP)unless an inter-connecting pipe such as a common MM protocol (which includes SIP mobility, H.323 mobility, IS-41 mobility, etc) is developed. Therefore, I would suggest that we should rather work with a more global picture of ITU (as supported by Radhika) than a narrow one limited to H.323 mobility only. Let me be more positive now. I would really encourage SG16 and SG11 to closely cooperate together in order to develop this common protocol jointly for the success of ITU. I believe that this step has already started at the joint SG16-SG11 meeting in February 00. Why shoudn't this be continued? Best regards, Jean-Claude Samou, PhD France Telecom R&D 38-40, rue du General Leclerc 92131 Issy les moulineaux France Tel: + 33 1 45 29 58 40 Fax: + 33 1 46 29 31 62 -----Message d'origine----- De: Roy, Radhika R, ALCOO [mailto:rrroy@ATT.COM] Date: mardi 19 septembre 2000 14:15 À: ITU-SG16(a)MAILBAG.INTEL.COM Objet: Re: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded Hi, Everyone: Let me repeat it again: We have applications H.323, H.321, etc. These are packet-based networks. There are other protocols like H.324 etc, that are optimized for PSTN/ISDN networks. Now the application/middleware layer control protocol like H.245 is applicable for all applications whether an application is sent over the packet networks or circuit-switched networks. Similarly, application/middleware layer VLF <-> HLF and other protocols are nothing do with packet vs. circuit-switched networks. It MUST be a common protocol. There is nothing specific in VLF <-> HLF with respect packet vs. circuit or connection oriented vs connectionless. People are trying to create confusions for fulfilling a VERY narrow objectives ignoring the BIG picture of the ITU. Even for the sake of argument, if we consider the applications only for the packet-switched networks, then we MUST develop the generic protocols like VLF <-> HLF and others that can be used by all protocols like H.323, H.321, etc. that are used by the packet-switched networks. The same argument is true for QOS, billing, authentication, directory, etc, and others. Let us not confuse things. Let us take another case: RSVP, DiffServ, etc. are the network layer QOS protocol. These network layer QOS services can be used by any applications (e.g., H.323, SIP, etc.) over the IP network. That is why, we MUST not develop one VLF <-> HLF protocol for H.323, one VLF <-> HLF protocol for H.321, and another VLF <-> HLF protocol for H.324, etc. It is a mess and defeats the fundamental purpose for creating of COMMON standards by the ITU. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Jaakko Sundquist [mailto:jaakko.sundquist@nokia.com] Sent: Monday, September 18, 2000 7:34 AM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded Hi Radhika, Paul & others Shortly, my understanding is that IMT-2000 is not defining protocols suitable (or intended for) packet-based networks, i.e. H.323 Systems on top of e.g. IP, but they concentrate on more general level definitions. While I do think that we need to consider IMT-2000 as well as other 3G standardization bodies (I would argue that 3GPP is the dominant one at the moment) and use as much of the specifications available as possible, I still think that we need to make our own specifications for H.323. Even if we just re-use some existing protocols, the usage of these needs to be clearly specified in the context of H.323. -Jaakko > -----Original Message----- > From: EXT Roy, Radhika R, ALCOO [mailto:rrroy@att.com] > Sent: 17. September 2000 3:48 > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: [H.323 Mobility:] A cleaned up H.323 Annex H > draft uploaded > > > Hi, Paul: > > I am glad that you have asked this question. > > HLF and VLF are value-added functions, and these server functions are > necessary for any mobile users. IMT-2000 is working to develop these > protocols. SG16 and SG11 had one joint meeting in the last > Feb'00 in Geneva. > These protocols are VLF <-> HLF and others. > > All we (Q.13/16) need to do: An interface with the VLF by the > H.323 GK. > > (An analogy can also given: H.245 is a common set of control > protocol that > is being used by H.323, H.324, and other applications.) > > If there are one or more functions are needed for any reasons that are > specific to H.323, people can always augment that particular > protocol. This > is a fact of life. > > The same is also true for QoS, authentication, accounting, > billing, and > others. > > More importantly, IMT-2000 is dedicated for mobility. > > Our (Q.13/16) primary task is to extend the H.323 protocol > for supporting > mobility (as explained many times) is as follows: > > Part 1: Within the scope of Q.13/16: Extension of H.323 > (e.g., H.225.0 [RAS, > Q.931, Annex G] and H.245 messages): Terminals, GKs/BEs, GWs. > (Contributions > are there: D.354 of SG16 Feb'00/TD-31 of Portland'00.) > > If we do NOT this part 1, we are NOT doing our primary job because the > solution will NOT fly. We are rather "building a castle in the air." > > Best regards, > Radhika R. Roy > AT&T > > -----Original Message----- > From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] > Sent: Saturday, September 16, 2000 2:45 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: [H.323 Mobility:] A cleaned up H.323 Annex H > draft uploaded > > > Radhika, et al, > > I have to confess that I have had no time to really follow > the Annex H work, > but I do have a question to toss out here: > > Why do you consider the VLF or HLF functions outside the > scope of Q13/16? I > assume that these functions are IP-based (or at least used > with the same > call signaling transport as the H.323 system) and integrate > with the H.323 > functions. > > You stated below that these functions are common for all > mobile systems. I > will not argue that point, but will a common solution be the most > appropriate for H.323 systems? I would guess that trying to > introduce a > generic mechanism may or may not be the best solution for H.323. > > I'd like to hear counter arguments to yours. Apparently > others felt that > these functions were necessary for H.323 systems and should be defined > within the H.323 framework. > > Paul > > ----- Original Message ----- > From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM> > To: <ITU-SG16(a)mailbag.cps.intel.com> > Sent: Friday, September 15, 2000 10:25 AM > Subject: Re: [H.323 Mobility:] A cleaned up H.323 Annex H > draft uploaded > > > > Hi, Everyone: > > > > The document MD-106 (H.323 Annex H) submitted by the editor remains > > basically same from the fundamentally point of view. So, > the comments > > provided on the September 8 email (copy enclosed) remains > the same as > stated > > earlier. The comments can be summarized as follows: > > > > The Annex should be divided into two parts: > > > > Part 1: Within the scope of Q.13/16: Extension of H.323 > (e.g., H.225.0 > [RAS, > > Q.931, Annex G] and H.245 messages): Terminals, GKs/BEs, GWs. > (Contributions > > are there: D.354 of SG16 Feb'00/TD-31 of Portland'00.) > > > > Part 2: Outside the scope of Q.13/16: Back-end services related to > Mobility > > (or value-added services related mobility) containing VLF and HLF. > > > > So, it can be seen clearly that MD-106 (H.323 Annex H) > submitted by the > > editor does not contain the basic part 1 which is within > the scope of > > Q.13/16 (it rather contains part 2 which is outside the > scope of Q.13/16). > > > > Best regards, > > Radhika R. Roy > > AT&T > > +1 732 420 1580 > > > > > > -----Original Message----- > > From: Roy, Radhika R, ALCOO > > Sent: Friday, September 08, 2000 10:23 AM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: Re: [H.323 Mobility:] H.323 Annex H status check > > > > Hi, Everyone: > > > > The draft does not contain the basic part: Extensions of > H.323 (e.g., > > H.225.0 messages). Contributions are there (e.g., D.354 of > SG16 Feb'00, > > Geneva - reproduced as TD-31 in Portland [August 21-15, 2000]). GRQ > messages > > need to be removed to the base spec of H.323 because there > is nothing > > specific to be done with mobility. If it is used in the context of > mobility, > > the issues related to mobile need to be pointed out so that > contributions > > can be brought to address those issues. Contributions are > there to note > the > > issues. > > > > The another suggestion is to make two parts of the Annex: 1. Basic > extension > > of H.323 (H.225.0, H.245: Terminals, GKs/BEs, GWs) and 2. Back-end > services > > related to Mobility (or value-added services related > mobility)containing > VLF > > and HLF. > > > > Part 2 clearly does not have to be specific to H.323. It is > a general > > service related to mobility. Every application that needs > mobility may > like > > to use these services. This will be addressed in the light > of the all > mobile > > applications of all questions of all SGs of the ITU-T. So, it is > > out-of-scope of Q.13/16 because Q.13/16 alone cannot makes > this decision. > > > > Please note that Security (AuF) is also needed for the > fixed users. So, > this > > is a generic service that needs to be developed for both > fixed and mobile > > users. So, it also belongs to the base H.323 spec. That is, any > > specification related to AuF should be moved to the base > H.323 spec as > well > > because it belong to both and the standard should be developed > accordingly. > > > > For rapid determination, I would suggest to address part 1 > only in the > first > > phase. > > > > More specific technical comments will be given for each > point once the > > primary objectives are clarified. > > > > Best regards, > > > > Radhika R. Roy > > AT&T > > > > > > -----Original Message----- > > From: Jaakko Sundquist [mailto:jaakko.sundquist@NOKIA.COM] > > Sent: Thursday, September 14, 2000 7:28 AM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded > > > > > > Hi all, > > > > I have uploaded MD-106 to URL: > > > ftp://standard.pictel.com/avc-site/Incoming/Mobility-AHG/Md-10 6_H323AnnexHDr > aft.zip . > The document is a cleaned up version of TD-42 of the Portland meeting and > contains only editorial changes(as the template used in the draft document > so far was, for some reason, a total mess). > The only "exeption" to this is the following correction. Section 8.1 of > TD-42 included the text: "Reference points A and B are out of the scope of > this Annex.", which has been removed and instead section 8.3 now includes > the text: "Reference points B, C and D are out of the scope of this Annex > (Hinter is included but only as an option in case that utilization of > reference point A is not practical).". > The reason for this change is that the text in TD-42 is, as I understand > from Mr. Rissanen's comments, a typo and should have mentioned reference > points B and C instead of A and B. > > ------------------------------------------------ > 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 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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

TR: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded
by SAMOU Jean-claude FTRD/DAC/ISS 21 Sep '00

21 Sep '00

Hi, Everyone: This is a re-transmission due to mailing problems. -----Message d'origine----- De: SAMOU Jean-claude FTRD/DAC/ISS [mailto:jeanclaude.samou@RD.FRANCETELECOM.FR] Date: mercredi 20 septembre 2000 18:01 À: ITU-SG16(a)MAILBAG.INTEL.COM Objet: Re: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded Hi, Everyone: Sorry for not getting into the discussion earlier since I was out of station for some time. I just logged into my PC and saw your interesting e-mail discussion on mobility management protocols (in particular between the VLF and HLF). I would like to share here some concerns of Radhika Roy on this matter. As he clearly points out, the HLF and VLF are only value-added functions which are necessary for handling mobility of users. There is nothing specific in VLF <-> HLF in terms of mobility with respect packet vs. circuit or connection oriented vs connectionless, etc. As you are probably aware of, the IMT-2000 group in ITU-T SG11 is currently working on developing a common mobility management protocol which should accomodate various users of different types of mobile systems (e.g. IS-41, UMTS, etc). This is the well known FAMILY concept in ITU-T SG11. SG16 and SG11 had one joint meeting in the last Feb'00 in Geneva. During this meeting, this mobility protocol work was briefly introduced by SG 11 and it was recognized that the requirements & major concepts identified for mobility in H.323 networks are very similar to those of IMT-2000 (since IMT-2000 should also provide packet-based multi-media services), and a close cooperation between these two groups is required on mobility and roaming aspects for the benefits of H.323 and IMT-2000 systems. In addition, this will allow the roaming of any users between different types of network (for instance an H.323 user roaming into an IS-41 or UMTS network and vice-versa). Therefore, I tend to disagree with Jaakko who says that IMT-2000 is not defining (or intended for) packet-based networks. For instance the concept of VLF and HLF are pretty much close to those of the LMFv and LMFh in IMT-2000 (see ITU-T Rec. Q.1711) for the strict reason that they are both server functions which handle mobility independently of the transport networks. Then why not a common protocol for common mobility requirements and functions? On the other hand, I agree that Extensions of H.323 (e.g. H.225.0 [RAS, Q.931, Annex G]) need to be provided by Q.13/16 since they are very specific to the H.323 type of access. Again, I would like to support Radhika in his analysis of trying to develop a common solution that fits the need of any type of mobile users rather than developing one VLF <-> HLF protocol for H.323, one VLF <-> HLF for H.321, etc. Otherwise, it will be a BIG mess for network operators (as well for manufacturers) and lead to have different protocols which may be incompatible between themselves. This will also make the inter-networking aspects very tough thereby preventing any global roaming of users. FYI, I would also like to inform you that 3GPP has selected SIP for its MULTIMEDIA stuff. In this case, how would it be possible to roam between a 3GPP network and H.323 network, and with other networks (not using SIP)unless an inter-connecting pipe such as a common MM protocol (which includes SIP mobility, H.323 mobility, IS-41 mobility, etc) is developed. Therefore, I would suggest that we should rather work with a more global picture of ITU (as supported by Radhika) than a narrow one limited to H.323 mobility only. Let me be more positive now. I would really encourage SG16 and SG11 to closely cooperate together in order to develop this common protocol jointly for the success of ITU. I believe that this step has already started at the joint SG16-SG11 meeting in February 00. Why shoudn't this be continued? Best regards, Jean-Claude Samou, PhD France Telecom R&D 38-40, rue du General Leclerc 92131 Issy les moulineaux France Tel: + 33 1 45 29 58 40 Fax: + 33 1 46 29 31 62 -----Message d'origine----- De: Roy, Radhika R, ALCOO [mailto:rrroy@ATT.COM] Date: mardi 19 septembre 2000 14:15 À: ITU-SG16(a)MAILBAG.INTEL.COM Objet: Re: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded Hi, Everyone: Let me repeat it again: We have applications H.323, H.321, etc. These are packet-based networks. There are other protocols like H.324 etc, that are optimized for PSTN/ISDN networks. Now the application/middleware layer control protocol like H.245 is applicable for all applications whether an application is sent over the packet networks or circuit-switched networks. Similarly, application/middleware layer VLF <-> HLF and other protocols are nothing do with packet vs. circuit-switched networks. It MUST be a common protocol. There is nothing specific in VLF <-> HLF with respect packet vs. circuit or connection oriented vs connectionless. People are trying to create confusions for fulfilling a VERY narrow objectives ignoring the BIG picture of the ITU. Even for the sake of argument, if we consider the applications only for the packet-switched networks, then we MUST develop the generic protocols like VLF <-> HLF and others that can be used by all protocols like H.323, H.321, etc. that are used by the packet-switched networks. The same argument is true for QOS, billing, authentication, directory, etc, and others. Let us not confuse things. Let us take another case: RSVP, DiffServ, etc. are the network layer QOS protocol. These network layer QOS services can be used by any applications (e.g., H.323, SIP, etc.) over the IP network. That is why, we MUST not develop one VLF <-> HLF protocol for H.323, one VLF <-> HLF protocol for H.321, and another VLF <-> HLF protocol for H.324, etc. It is a mess and defeats the fundamental purpose for creating of COMMON standards by the ITU. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Jaakko Sundquist [mailto:jaakko.sundquist@nokia.com] Sent: Monday, September 18, 2000 7:34 AM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded Hi Radhika, Paul & others Shortly, my understanding is that IMT-2000 is not defining protocols suitable (or intended for) packet-based networks, i.e. H.323 Systems on top of e.g. IP, but they concentrate on more general level definitions. While I do think that we need to consider IMT-2000 as well as other 3G standardization bodies (I would argue that 3GPP is the dominant one at the moment) and use as much of the specifications available as possible, I still think that we need to make our own specifications for H.323. Even if we just re-use some existing protocols, the usage of these needs to be clearly specified in the context of H.323. -Jaakko > -----Original Message----- > From: EXT Roy, Radhika R, ALCOO [mailto:rrroy@att.com] > Sent: 17. September 2000 3:48 > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: [H.323 Mobility:] A cleaned up H.323 Annex H > draft uploaded > > > Hi, Paul: > > I am glad that you have asked this question. > > HLF and VLF are value-added functions, and these server functions are > necessary for any mobile users. IMT-2000 is working to develop these > protocols. SG16 and SG11 had one joint meeting in the last > Feb'00 in Geneva. > These protocols are VLF <-> HLF and others. > > All we (Q.13/16) need to do: An interface with the VLF by the > H.323 GK. > > (An analogy can also given: H.245 is a common set of control > protocol that > is being used by H.323, H.324, and other applications.) > > If there are one or more functions are needed for any reasons that are > specific to H.323, people can always augment that particular > protocol. This > is a fact of life. > > The same is also true for QoS, authentication, accounting, > billing, and > others. > > More importantly, IMT-2000 is dedicated for mobility. > > Our (Q.13/16) primary task is to extend the H.323 protocol > for supporting > mobility (as explained many times) is as follows: > > Part 1: Within the scope of Q.13/16: Extension of H.323 > (e.g., H.225.0 [RAS, > Q.931, Annex G] and H.245 messages): Terminals, GKs/BEs, GWs. > (Contributions > are there: D.354 of SG16 Feb'00/TD-31 of Portland'00.) > > If we do NOT this part 1, we are NOT doing our primary job because the > solution will NOT fly. We are rather "building a castle in the air." > > Best regards, > Radhika R. Roy > AT&T > > -----Original Message----- > From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] > Sent: Saturday, September 16, 2000 2:45 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: [H.323 Mobility:] A cleaned up H.323 Annex H > draft uploaded > > > Radhika, et al, > > I have to confess that I have had no time to really follow > the Annex H work, > but I do have a question to toss out here: > > Why do you consider the VLF or HLF functions outside the > scope of Q13/16? I > assume that these functions are IP-based (or at least used > with the same > call signaling transport as the H.323 system) and integrate > with the H.323 > functions. > > You stated below that these functions are common for all > mobile systems. I > will not argue that point, but will a common solution be the most > appropriate for H.323 systems? I would guess that trying to > introduce a > generic mechanism may or may not be the best solution for H.323. > > I'd like to hear counter arguments to yours. Apparently > others felt that > these functions were necessary for H.323 systems and should be defined > within the H.323 framework. > > Paul > > ----- Original Message ----- > From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM> > To: <ITU-SG16(a)mailbag.cps.intel.com> > Sent: Friday, September 15, 2000 10:25 AM > Subject: Re: [H.323 Mobility:] A cleaned up H.323 Annex H > draft uploaded > > > > Hi, Everyone: > > > > The document MD-106 (H.323 Annex H) submitted by the editor remains > > basically same from the fundamentally point of view. So, > the comments > > provided on the September 8 email (copy enclosed) remains > the same as > stated > > earlier. The comments can be summarized as follows: > > > > The Annex should be divided into two parts: > > > > Part 1: Within the scope of Q.13/16: Extension of H.323 > (e.g., H.225.0 > [RAS, > > Q.931, Annex G] and H.245 messages): Terminals, GKs/BEs, GWs. > (Contributions > > are there: D.354 of SG16 Feb'00/TD-31 of Portland'00.) > > > > Part 2: Outside the scope of Q.13/16: Back-end services related to > Mobility > > (or value-added services related mobility) containing VLF and HLF. > > > > So, it can be seen clearly that MD-106 (H.323 Annex H) > submitted by the > > editor does not contain the basic part 1 which is within > the scope of > > Q.13/16 (it rather contains part 2 which is outside the > scope of Q.13/16). > > > > Best regards, > > Radhika R. Roy > > AT&T > > +1 732 420 1580 > > > > > > -----Original Message----- > > From: Roy, Radhika R, ALCOO > > Sent: Friday, September 08, 2000 10:23 AM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: Re: [H.323 Mobility:] H.323 Annex H status check > > > > Hi, Everyone: > > > > The draft does not contain the basic part: Extensions of > H.323 (e.g., > > H.225.0 messages). Contributions are there (e.g., D.354 of > SG16 Feb'00, > > Geneva - reproduced as TD-31 in Portland [August 21-15, 2000]). GRQ > messages > > need to be removed to the base spec of H.323 because there > is nothing > > specific to be done with mobility. If it is used in the context of > mobility, > > the issues related to mobile need to be pointed out so that > contributions > > can be brought to address those issues. Contributions are > there to note > the > > issues. > > > > The another suggestion is to make two parts of the Annex: 1. Basic > extension > > of H.323 (H.225.0, H.245: Terminals, GKs/BEs, GWs) and 2. Back-end > services > > related to Mobility (or value-added services related > mobility)containing > VLF > > and HLF. > > > > Part 2 clearly does not have to be specific to H.323. It is > a general > > service related to mobility. Every application that needs > mobility may > like > > to use these services. This will be addressed in the light > of the all > mobile > > applications of all questions of all SGs of the ITU-T. So, it is > > out-of-scope of Q.13/16 because Q.13/16 alone cannot makes > this decision. > > > > Please note that Security (AuF) is also needed for the > fixed users. So, > this > > is a generic service that needs to be developed for both > fixed and mobile > > users. So, it also belongs to the base H.323 spec. That is, any > > specification related to AuF should be moved to the base > H.323 spec as > well > > because it belong to both and the standard should be developed > accordingly. > > > > For rapid determination, I would suggest to address part 1 > only in the > first > > phase. > > > > More specific technical comments will be given for each > point once the > > primary objectives are clarified. > > > > Best regards, > > > > Radhika R. Roy > > AT&T > > > > > > -----Original Message----- > > From: Jaakko Sundquist [mailto:jaakko.sundquist@NOKIA.COM] > > Sent: Thursday, September 14, 2000 7:28 AM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded > > > > > > Hi all, > > > > I have uploaded MD-106 to URL: > > > ftp://standard.pictel.com/avc-site/Incoming/Mobility-AHG/Md-10 6_H323AnnexHDr > aft.zip . > The document is a cleaned up version of TD-42 of the Portland meeting and > contains only editorial changes(as the template used in the draft document > so far was, for some reason, a total mess). > The only "exeption" to this is the following correction. Section 8.1 of > TD-42 included the text: "Reference points A and B are out of the scope of > this Annex.", which has been removed and instead section 8.3 now includes > the text: "Reference points B, C and D are out of the scope of this Annex > (Hinter is included but only as an option in case that utilization of > reference point A is not practical).". > The reason for this change is that the text in TD-42 is, as I understand > from Mr. Rissanen's comments, a typo and should have mentioned reference > points B and C instead of A and B. > > ------------------------------------------------ > 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 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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

my address has changed
by Euchner Martin 20 Sep '00

20 Sep '00

To whom it may concern: My address has changed. You may find the new email/phone/fax and postal address in the signature below. Kind regards, Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 722 55790 | Martin Euchner Fax : +49 89 722 46841 | Siemens AG | ICN M NT 18 mailto:Martin.Euchner@icn.siemens.de <mailto:Martin.Euchner@icn.siemens.de> | mailto:martin.euchner@ties.itu.int <mailto:martin.euchner@ties.itu.int> | Hofmannstr. 51 Intranet: http://zt-security.mchp.siemens.de/de/Competence/Standardization/ITU-T_SG16… <http://zt-security.mchp.siemens.de/de/Competence/Standardization/ITU-T_SG16…> | D-81359 Muenchen Internet: http://www.siemens.de <http://www.siemens.de> | __________________ | Germany ----------------------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded
by SAMOU Jean-claude FTRD/DAC/ISS 20 Sep '00

20 Sep '00

Hi, Everyone: Sorry for not getting into the discussion earlier since I was out of station for some time. I just logged into my PC and saw your interesting e-mail discussion on mobility management protocols (in particular between the VLF and HLF). I would like to share here some concerns of Radhika Roy on this matter. As he clearly points out, the HLF and VLF are only value-added functions which are necessary for handling mobility of users. There is nothing specific in VLF <-> HLF in terms of mobility with respect packet vs. circuit or connection oriented vs connectionless, etc. As you are probably aware of, the IMT-2000 group in ITU-T SG11 is currently working on developing a common mobility management protocol which should accomodate various users of different types of mobile systems (e.g. IS-41, UMTS, etc). This is the well known FAMILY concept in ITU-T SG11. SG16 and SG11 had one joint meeting in the last Feb'00 in Geneva. During this meeting, this mobility protocol work was briefly introduced by SG 11 and it was recognized that the requirements & major concepts identified for mobility in H.323 networks are very similar to those of IMT-2000 (since IMT-2000 should also provide packet-based multi-media services), and a close cooperation between these two groups is required on mobility and roaming aspects for the benefits of H.323 and IMT-2000 systems. In addition, this will allow the roaming of any users between different types of network (for instance an H.323 user roaming into an IS-41 or UMTS network and vice-versa). Therefore, I tend to disagree with Jaakko who says that IMT-2000 is not defining (or intended for) packet-based networks. For instance the concept of VLF and HLF are pretty much close to those of the LMFv and LMFh in IMT-2000 (see ITU-T Rec. Q.1711) for the strict reason that they are both server functions which handle mobility independently of the transport networks. Then why not a common protocol for common mobility requirements and functions? On the other hand, I agree that Extensions of H.323 (e.g. H.225.0 [RAS, Q.931, Annex G]) need to be provided by Q.13/16 since they are very specific to the H.323 type of access. Again, I would like to support Radhika in his analysis of trying to develop a common solution that fits the need of any type of mobile users rather than developing one VLF <-> HLF protocol for H.323, one VLF <-> HLF for H.321, etc. Otherwise, it will be a BIG mess for network operators (as well for manufacturers) and lead to have different protocols which may be incompatible between themselves. This will also make the inter-networking aspects very tough thereby preventing any global roaming of users. FYI, I would also like to inform you that 3GPP has selected SIP for its MULTIMEDIA stuff. In this case, how would it be possible to roam between a 3GPP network and H.323 network, and with other networks (not using SIP)unless an inter-connecting pipe such as a common MM protocol (which includes SIP mobility, H.323 mobility, IS-41 mobility, etc) is developed. Therefore, I would suggest that we should rather work with a more global picture of ITU (as supported by Radhika) than a narrow one limited to H.323 mobility only. Let me more positive now. I would really encourage SG16 and SG11 to closely cooperate together in order to develop this common protocol jointly for the success of ITU. I believe that this step has already started at the joint SG16-SG11 meeting in February 00. Why shoudn't be continued? Best regards, Jean-Claude Samou, PhD France Telecom R&D 38-40, rue du General Leclerc 92131 Issy les moulineaux France Tel: + 33 1 45 29 58 40 Fax: + 33 1 46 29 31 62 -----Message d'origine----- De: Roy, Radhika R, ALCOO [mailto:rrroy@ATT.COM] Date: mardi 19 septembre 2000 14:15 À: ITU-SG16(a)MAILBAG.INTEL.COM Objet: Re: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded Hi, Everyone: Let me repeat it again: We have applications H.323, H.321, etc. These are packet-based networks. There are other protocols like H.324 etc, that are optimized for PSTN/ISDN networks. Now the application/middleware layer control protocol like H.245 is applicable for all applications whether an application is sent over the packet networks or circuit-switched networks. Similarly, application/middleware layer VLF <-> HLF and other protocols are nothing do with packet vs. circuit-switched networks. It MUST be a common protocol. There is nothing specific in VLF <-> HLF with respect packet vs. circuit or connection oriented vs connectionless. People are trying to create confusions for fulfilling a VERY narrow objectives ignoring the BIG picture of the ITU. Even for the sake of argument, if we consider the applications only for the packet-switched networks, then we MUST develop the generic protocols like VLF <-> HLF and others that can be used by all protocols like H.323, H.321, etc. that are used by the packet-switched networks. The same argument is true for QOS, billing, authentication, directory, etc, and others. Let us not confuse things. Let us take another case: RSVP, DiffServ, etc. are the network layer QOS protocol. These network layer QOS services can be used by any applications (e.g., H.323, SIP, etc.) over the IP network. That is why, we MUST not develop one VLF <-> HLF protocol for H.323, one VLF <-> HLF protocol for H.321, and another VLF <-> HLF protocol for H.324, etc. It is a mess and defeats the fundamental purpose for creating of COMMON standards by the ITU. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Jaakko Sundquist [mailto:jaakko.sundquist@nokia.com] Sent: Monday, September 18, 2000 7:34 AM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded Hi Radhika, Paul & others Shortly, my understanding is that IMT-2000 is not defining protocols suitable (or intended for) packet-based networks, i.e. H.323 Systems on top of e.g. IP, but they concentrate on more general level definitions. While I do think that we need to consider IMT-2000 as well as other 3G standardization bodies (I would argue that 3GPP is the dominant one at the moment) and use as much of the specifications available as possible, I still think that we need to make our own specifications for H.323. Even if we just re-use some existing protocols, the usage of these needs to be clearly specified in the context of H.323. -Jaakko > -----Original Message----- > From: EXT Roy, Radhika R, ALCOO [mailto:rrroy@att.com] > Sent: 17. September 2000 3:48 > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: [H.323 Mobility:] A cleaned up H.323 Annex H > draft uploaded > > > Hi, Paul: > > I am glad that you have asked this question. > > HLF and VLF are value-added functions, and these server functions are > necessary for any mobile users. IMT-2000 is working to develop these > protocols. SG16 and SG11 had one joint meeting in the last > Feb'00 in Geneva. > These protocols are VLF <-> HLF and others. > > All we (Q.13/16) need to do: An interface with the VLF by the > H.323 GK. > > (An analogy can also given: H.245 is a common set of control > protocol that > is being used by H.323, H.324, and other applications.) > > If there are one or more functions are needed for any reasons that are > specific to H.323, people can always augment that particular > protocol. This > is a fact of life. > > The same is also true for QoS, authentication, accounting, > billing, and > others. > > More importantly, IMT-2000 is dedicated for mobility. > > Our (Q.13/16) primary task is to extend the H.323 protocol > for supporting > mobility (as explained many times) is as follows: > > Part 1: Within the scope of Q.13/16: Extension of H.323 > (e.g., H.225.0 [RAS, > Q.931, Annex G] and H.245 messages): Terminals, GKs/BEs, GWs. > (Contributions > are there: D.354 of SG16 Feb'00/TD-31 of Portland'00.) > > If we do NOT this part 1, we are NOT doing our primary job because the > solution will NOT fly. We are rather "building a castle in the air." > > Best regards, > Radhika R. Roy > AT&T > > -----Original Message----- > From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] > Sent: Saturday, September 16, 2000 2:45 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: [H.323 Mobility:] A cleaned up H.323 Annex H > draft uploaded > > > Radhika, et al, > > I have to confess that I have had no time to really follow > the Annex H work, > but I do have a question to toss out here: > > Why do you consider the VLF or HLF functions outside the > scope of Q13/16? I > assume that these functions are IP-based (or at least used > with the same > call signaling transport as the H.323 system) and integrate > with the H.323 > functions. > > You stated below that these functions are common for all > mobile systems. I > will not argue that point, but will a common solution be the most > appropriate for H.323 systems? I would guess that trying to > introduce a > generic mechanism may or may not be the best solution for H.323. > > I'd like to hear counter arguments to yours. Apparently > others felt that > these functions were necessary for H.323 systems and should be defined > within the H.323 framework. > > Paul > > ----- Original Message ----- > From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM> > To: <ITU-SG16(a)mailbag.cps.intel.com> > Sent: Friday, September 15, 2000 10:25 AM > Subject: Re: [H.323 Mobility:] A cleaned up H.323 Annex H > draft uploaded > > > > Hi, Everyone: > > > > The document MD-106 (H.323 Annex H) submitted by the editor remains > > basically same from the fundamentally point of view. So, > the comments > > provided on the September 8 email (copy enclosed) remains > the same as > stated > > earlier. The comments can be summarized as follows: > > > > The Annex should be divided into two parts: > > > > Part 1: Within the scope of Q.13/16: Extension of H.323 > (e.g., H.225.0 > [RAS, > > Q.931, Annex G] and H.245 messages): Terminals, GKs/BEs, GWs. > (Contributions > > are there: D.354 of SG16 Feb'00/TD-31 of Portland'00.) > > > > Part 2: Outside the scope of Q.13/16: Back-end services related to > Mobility > > (or value-added services related mobility) containing VLF and HLF. > > > > So, it can be seen clearly that MD-106 (H.323 Annex H) > submitted by the > > editor does not contain the basic part 1 which is within > the scope of > > Q.13/16 (it rather contains part 2 which is outside the > scope of Q.13/16). > > > > Best regards, > > Radhika R. Roy > > AT&T > > +1 732 420 1580 > > > > > > -----Original Message----- > > From: Roy, Radhika R, ALCOO > > Sent: Friday, September 08, 2000 10:23 AM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: Re: [H.323 Mobility:] H.323 Annex H status check > > > > Hi, Everyone: > > > > The draft does not contain the basic part: Extensions of > H.323 (e.g., > > H.225.0 messages). Contributions are there (e.g., D.354 of > SG16 Feb'00, > > Geneva - reproduced as TD-31 in Portland [August 21-15, 2000]). GRQ > messages > > need to be removed to the base spec of H.323 because there > is nothing > > specific to be done with mobility. If it is used in the context of > mobility, > > the issues related to mobile need to be pointed out so that > contributions > > can be brought to address those issues. Contributions are > there to note > the > > issues. > > > > The another suggestion is to make two parts of the Annex: 1. Basic > extension > > of H.323 (H.225.0, H.245: Terminals, GKs/BEs, GWs) and 2. Back-end > services > > related to Mobility (or value-added services related > mobility)containing > VLF > > and HLF. > > > > Part 2 clearly does not have to be specific to H.323. It is > a general > > service related to mobility. Every application that needs > mobility may > like > > to use these services. This will be addressed in the light > of the all > mobile > > applications of all questions of all SGs of the ITU-T. So, it is > > out-of-scope of Q.13/16 because Q.13/16 alone cannot makes > this decision. > > > > Please note that Security (AuF) is also needed for the > fixed users. So, > this > > is a generic service that needs to be developed for both > fixed and mobile > > users. So, it also belongs to the base H.323 spec. That is, any > > specification related to AuF should be moved to the base > H.323 spec as > well > > because it belong to both and the standard should be developed > accordingly. > > > > For rapid determination, I would suggest to address part 1 > only in the > first > > phase. > > > > More specific technical comments will be given for each > point once the > > primary objectives are clarified. > > > > Best regards, > > > > Radhika R. Roy > > AT&T > > > > > > -----Original Message----- > > From: Jaakko Sundquist [mailto:jaakko.sundquist@NOKIA.COM] > > Sent: Thursday, September 14, 2000 7:28 AM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded > > > > > > Hi all, > > > > I have uploaded MD-106 to URL: > > > ftp://standard.pictel.com/avc-site/Incoming/Mobility-AHG/Md-10 6_H323AnnexHDr > aft.zip . > The document is a cleaned up version of TD-42 of the Portland meeting and > contains only editorial changes(as the template used in the draft document > so far was, for some reason, a total mess). > The only "exeption" to this is the following correction. Section 8.1 of > TD-42 included the text: "Reference points A and B are out of the scope of > this Annex.", which has been removed and instead section 8.3 now includes > the text: "Reference points B, C and D are out of the scope of this Annex > (Hinter is included but only as an option in case that utilization of > reference point A is not practical).". > The reason for this change is that the text in TD-42 is, as I understand > from Mr. Rissanen's comments, a typo and should have mentioned reference > points B and C instead of A and B. > > ------------------------------------------------ > 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 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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: ARJ reject reasons?
by Euchner Martin 20 Sep '00

20 Sep '00

Paul and others, let me shortly explain the purpose of security denial: H.235 and security profiles say, that this value is returned in the reject messages whenever the received cryptoTokens are not acceptable for some security reason. This may occur due to failed authentication, lack of authorization (= permission) or failed integrity but also as part of security negotiation when the received crypto parameters are not acceptable or understood. Of course there several more reasons why security might fail and the responder sends security denial: the password/shared secret is invalid or not available, the endpoint is not allowed to use a service, replay detected, integrity violation detected, digital signature wrong, certificate expired.... Kind regards, Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 722 55790 | Martin Euchner Fax : +49 89 722 46841 | Siemens AG | ICN M NT 18 mailto:Martin.Euchner@icn.siemens.de <mailto:Martin.Euchner@icn.siemens.de> | mailto:martin.euchner@ties.itu.int <mailto:martin.euchner@ties.itu.int> | Hofmannstr. 51 Intranet: http://zt-security.mchp.siemens.de/de/Competence/Standardization/ITU-T_SG16… <http://zt-security.mchp.siemens.de/de/Competence/Standardization/ITU-T_SG16…> | D-81359 Muenchen Internet: http://www.siemens.de <http://www.siemens.de> | __________________ | Germany ----------------------------------------------------------------------- -----Ursprüngliche Nachricht----- Von: Paul Long [SMTP:Plong@SMITHMICRO.COM] Gesendet am: Mittwoch, 20. September 2000 15:17 An: ITU-SG16(a)mailbag.cps.intel.com Betreff: Re: ARJ reject reasons? I put together a table that summarizes the meanings of the ARJ reject reasons if anyone is interested. It's at the top of this page: http://www.packetizer.com/h225impl.html. Let me know if you disagree with any of it. Paul Long Smith Micro Software, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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

Re: ARJ reject reasons?
by Ilya Freytsis 20 Sep '00

20 Sep '00

Paul, I can offer my interpretation for some of them: 1. InvalidPermission - GK may have policy rules for the different categories of endpoints (e.g. who is allowed to use gateway services etc.) 2. CallernotRegistered - EP that is not registered with the GK asks for the permission to place a call 3. SecurityDenial 4. requestDenied(no bandwidth available) - no comments 5. resourceUnavailable - e.g. no gateway resources available (my favorite) 6. callCapacityExceeded - GK has reached its call handling capacity (esp. in GK routed mode) Ilya Freytsis -----Original Message----- From: Paul Long [mailto:Plong@SMITHMICRO.COM] Sent: Tuesday, September 19, 2000 4:09 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: ARJ reject reasons? What is the difference between the three ARJ reject reasons, invalidPermission, callernotRegistered, and securityDenial? Likewise, what is the difference between the ARJ reject reasons, requestDenied (no bandwidth available), resourceUnavailable, and callCapacityExceeded? Paul Long Smith Micro Software, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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

3 3

Re: ARJ reject reasons?
by Ilya Freytsis 20 Sep '00

20 Sep '00

Our H323/H320 gateway registers with the GK the list of aliases-prefixes that indicates available gateway resource. Every time a resource is used the list is re-registered. GK may have enough built-in knowledge of the prefix scheme to be able to specify resourceUnavailable in ARJ if it cannot satisfy request. Ilya Freytsis -----Original Message----- From: Paul Long [mailto:Plong@SMITHMICRO.COM] Sent: Tuesday, September 19, 2000 6:36 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: ARJ reject reasons? Ilya, So you think that invalidPermission is the code to return if the call violates some proprietary policy within the GK that is typically set by the administrator of the network/GK? Regarding resourceUnavailable, how does a GK know whether gateway "resources" are available? Doesn't it just know whether an alias or set of aliases are registered? How can it make this distinction? Or are you referring to the capacity of the GW, in which case wouldn't callCapacityExceeded be the correct reason to return? Another respondent said that callCapacityExceeded refered to the capacity of the other EP and not to the GK itself. I suppose it could be used for both. Paul Long Smith Micro Software, Inc. -----Original Message----- From: Ilya Freytsis [mailto:ifreytsis@EZENIA.COM] Sent: Tuesday, September 19, 2000 5:02 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: ARJ reject reasons? Paul, I can offer my interpretation for some of them: 1. InvalidPermission - GK may have policy rules for the different categories of endpoints (e.g. who is allowed to use gateway services etc.) 2. CallernotRegistered - EP that is not registered with the GK asks for the permission to place a call 3. SecurityDenial 4. requestDenied(no bandwidth available) - no comments 5. resourceUnavailable - e.g. no gateway resources available (my favorite) 6. callCapacityExceeded - GK has reached its call handling capacity (esp. in GK routed mode) Ilya Freytsis ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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