Gary,

after skimming over your contribution, two immediate comments:

1) QoS signalling within your serviceClass may overlap (or even conflict) with what will eventually appear in H.323 annex N. We should try to have QOS information in one place only. ServiceClass is one possible place, but then we should make sure that it covers also the requirements of annex N.

2) For the terminating side, the primary goal should be protection. In other words, the called party would be protected against calls below a certain class of service ("do not disturb unless it's urgent"), and existing calls would not be affected unless resources are needed for a call with higher priority. It may even be worthwhile to specify separate protection levels separate from priority levels. For example, the call intrusion supplementary service recently approved by SG16 (Rec. H.450.11) follows such a concept: the caller is only allowed to intrude on an established call if his capability level is higher than the combined protection levels of the called party and the remote party of the established call.

Ernst Horvath Siemens AG

-----Ursprüngliche Nachricht----- Von: Gary Thom [mailto:gthom@delta-info.com] Gesendet am: Donnerstag, 03. Mai 2001 17:07 An: ITU-SG16@mailbag.cps.INTEL.COM Betreff: Emergency Services and Service classes

All,

Attached is a preliimary copy of a contribution to the upcomming Brazil meeting. It still needs US approval.

It defines service classes using the generic extensible framework, and should be more applicable than just emergency services. Extension markers were put in to allow addition of new priority and quality values.

Let me know if you have any comments, suggestions, or questions.

Thanks Gary

---

Name : Gary A. Thom Company: Delta Information Systems, Inc. Address: 300 Welsh Rd., Bldg 3 Horsham, PA 19044 USA Phone : +1-215-657-5270 x123 Fax : +1-215-657-5273 E-mail : gthom@delta-info.com Website: www.delta-info.com

---