April 2001 - sg16-avd - lists.packetizer.com

Re: Emergency Services and Service classes
by Roy, Radhika R, ALCOO 20 Apr '01

20 Apr '01

Hi, Mike and all: It is good that we have got Question F/16 in SG16 to address end-to-end QOS of multimedia systems. We are now in a position to define the scope of Q.F/16 and then divide the work according to the scope. We have very good insights, as Mike pointed out, after looking into all QOS works across all different ITU-T SGs (e.g., SG16, SG12, SG13), IETF, TIPHON, and other fora. Let us bring contributions in accordance to the charter of Q.F/16 (not just generic contributions) customized per Q.F/16's needs without giving or citing preferences for any particular groups. In this context, H.323 QOS will be a subset of the overall QOS protocol that will used by all multimedia applications. So, the important mind set is that Q.F/16 will develop the end-to-end QOS standards that will be used by all multimedia applications/systems including H.323 (not just only for H.323, IP, or for a particular medium). Let us bring contributions customizing per Q.F/16's needs. Hope this will clarify the things. Best regards, Radhika R. Roy -----Original Message----- From: Mike Buckley [mailto:mikebuckley@44COMMS.COM] Sent: Friday, April 20, 2001 8:57 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Emergency Services and Service classes Gary, Radhika, Tom, Sorry to be a little slow in joining to this interesting thread - I have been out of email contact over the last couple of days. I think we all agree there are two distinct issues here: 1. The Quality of the media stream (this is what we usually refer to when we talk of QoS) 2. The Grade of Service - that is the probability that the call will connect successfully. This is a concept well understood in the circuit switched world but which now needs reinterpreting for IP telephony. I think Gary's comments are correct in that the issue of emergency services is primarily a grade of service issue rather than an issue of the quality of the media stream. As Radhika points out I hope Q.F will qive some guidance on the classification system to be adopted for media stream QoS. The TIPHON categories are a good starting point for speech. So far though TIPHON has not addressed Multimedia and is only just beginning to look at this. Work is also underway in this area in SG12 and SG13 (the latter group from a network perspective). Another important group interested in multimedia classification is 3GPP. So we need to co-ordinate the work of Q.F wilth all these groups which will take a little time. The idea of maybe referring to media classes by number to start with until we can define what these numbers mean is probably a good starting point. Radhika and I were planning to propose a new work item on multimedia classification Q.class at the next Sg16 meeting. The GoS issue is really one of priority in resource reservation within the transport network. Once the resource is committed then the QoS class chosen not the GoS class will determine network performance. Gary's idea of signalling the priority of the call between the User and Service Provider seems a good approach. Within the service provider's domain this request will need to translated to an indication of priority associated with a request for resource reservation to the transport domain at the time of media stream establishment. In a multi domain environment which is very much part of the terms of reference for the work in Q.F) this will involve signalling between service domains and transport domains and possibly between transport domains, and we will need to ensure mechanisms for SD to SD as well as SD to TD. TD to TD is very much the role of the IETF so co-ordination will also be needed here. Again I was planning to start work on defining these signalling require! ments in Q.F. Finally, I agree work has got off to a slow start on Q.F since Geneva. Lack of time to discuss QoS at the last two WG2 meetings has not helped, also my inability to attend the Launceston meeting and the lack of contributions in this area. We will be holding a Q.F session in Brazil though and I hope then to start work on two or three new work items. Hopefully we can make some progress on these and Annex N. All contributions would be very welcome. Mike -----Original Message----- From: Roy, Radhika R, ALCOO [SMTP:rrroy@ATT.COM] Sent: Wednesday, April 18, 2001 6:34 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Emergency Services and Service classes Hi, Tom and All: I have few comments on: 1. Priority Class, 2. Quality/QOS Class, and 3. Dependency between Priority and Quality 1. Priority Class of a Call Let us define priority classes for a call across all ITU SGs (not ONLY in SG16). If the SG16 is allowed to do define the priority class that will be followed by other SGs, we may then define this in this SG and will be sending liaison to other SGs (because the emergency services standard works span multiple SGs. In addition, there are other areas that we need to look into. For example, the present ISDN standard also defines MLPP where several kinds of priority are offered. (Recently, contributions have also been presented to define priority is SIP in accordance to the MLPP.) 2. Quality/QOS Class of a Call To define quality of a call is being undertaken in Q.F/16. It will take time to define QOS classes or anything like this in Q.F because the definitions of QOS provided in various cases (e.g., SG 13 [Q.4], BICC, TIPHON, IETF, etc) are problematic at the application layer because they are often tied to the network layer. Suggestions are also there whether best, high, medium, or best-effort will mean anything unless we call guaranteed, controlled, or best-effort. The point is that let us continue the discussion of quality in Q.F/16 so that we agree on this. By the way, in Q.F/16, we are considering the quality at the medium level as opposed the per call level. (At one point, we found that classes are becoming problematic. So, we have started to use a matrix where a user will define how each medium will be treated - a kind of preferences [e.g., guaranteed, controlled, or best-effort] without defining explicit classes.) 3. Dependency between Priority and Quality I do not clearly whether there will be any dependency between the priority and quality of a call. Hope this helps. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Gary Thom [mailto:gthom@delta-info.com] Sent: Wednesday, April 18, 2001 12:41 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Emergency Services and Service classes I would like to re-open the discussion started at the Nov 2000 Geneva meeting and continued at the March 2001 Launceston meeting relating to Emergency Services. In order to support Emergency Services, there are three services that are desired: 1)Priority Dial Tone - this is a line or endpoint dedicated to emergency calls. 2)Priority Call Setup - this allows an emegency call to be made from any endpoint. 3)Priority Call transit through packet network - this requires interworking existing ISUP high probability of completion call marking with H.323, H.323 Annex M.2, h.246 Annex C, and H.248. An emergency call may be pre-emptive or may just improve the probability of call completion without pre-emption depending on national policy. Authentication issues also need to be worked out. Currently, in the US, this is handled like a calling card authentication. At the Geneva meeting, it was decided that this work was closely related to contribution D.4 from Cicso on reserving resources and also Annex N/H.323 on QOS. Also included were liaison statements from SG11 on QOS for BICC, and an ETSI TIPHON document on signaling end-to-end-qos. All of these items require a method of signaling the desired quality of service. One way of doing this that seems to be common to all requirements is to specify a Service Class parameter and to send this parameter in the various RAS and Call Signaling exchanges. I would like to propose the following Service Class parameter. ServiceClass ::= SEQUENCE { priority CHOICE { emergency, high, normal, low } quality CHOICE ;per TIPHON definition { best, high, medium, bestEffort } } The priority field is used to indicate the importance of the call. This is used not only for assuring that resources can be allocated, but also to improve the probability of completion of the call. The quality field is taken from the ETSI TIPHON QOS Class definitions, and relate to bitrate, codec type, and voice or video quality. High or emergency priority calls may not require best audio quality, medium may be sufficient (even prefered because of the lower bandwidth requirement), while normal priority calls may desire high or best audio quality. The Service Class parameter would then be added to the necessary RAS and Call Signalling messages. At a minimum this would include the ARQ and Setup messages, but might also be applied to others. It is necessary in the ARQ and Setup messages so that High Probability of Completion calls comming into the network from the PSTN can be given priority treatment. For priority dial tone, perhaps the Service Class should be included in the RRQ to indicate the desired priority, once authenticated by the Gatekeeper and confirmed in the RCF, this endpoint could then include that Service Class in subsequent ARQ and Setup messages. Is a token required from the Gatekeeper to indicate that the endpoint has been granted priority status???? For priority call completion, an authentication authority and procedure needs to be defined. One approach is for the call to be made to an access number, the user is then queried for a PIN and the called endpoint number. After authentication, the call would be transfered to the called endpoint. The transfered call would be placed using the Service Class provided by the athentication authority. This would be the same procedure for any calling card call made on the packet network. The Service Class would be based on teh service level agreement between the card user and the provider. In the case of an emergency caller, the SLA would indicate Emergency Priority. How are calling card calls handled on packet networks now???? Is this consistent??? I would appreciate any input that you could provide. 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(a)delta-info.com Website: www.delta-info.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: Emergency Services and Service classes
by Mike Buckley 20 Apr '01

20 Apr '01

Gary, Radhika, Tom, Sorry to be a little slow in joining to this interesting thread - I have been out of email contact over the last couple of days. I think we all agree there are two distinct issues here: 1. The Quality of the media stream (this is what we usually refer to when we talk of QoS) 2. The Grade of Service - that is the probability that the call will connect successfully. This is a concept well understood in the circuit switched world but which now needs reinterpreting for IP telephony. I think Gary's comments are correct in that the issue of emergency services is primarily a grade of service issue rather than an issue of the quality of the media stream. As Radhika points out I hope Q.F will qive some guidance on the classification system to be adopted for media stream QoS. The TIPHON categories are a good starting point for speech. So far though TIPHON has not addressed Multimedia and is only just beginning to look at this. Work is also underway in this area in SG12 and SG13 (the latter group from a network perspective). Another important group interested in multimedia classification is 3GPP. So we need to co-ordinate the work of Q.F wilth all these groups which will take a little time. The idea of maybe referring to media classes by number to start with until we can define what these numbers mean is probably a good starting point. Radhika and I were planning to propose a new work item on multimedia classification Q.class at the next Sg16 meeting. The GoS issue is really one of priority in resource reservation within the transport network. Once the resource is committed then the QoS class chosen not the GoS class will determine network performance. Gary's idea of signalling the priority of the call between the User and Service Provider seems a good approach. Within the service provider's domain this request will need to translated to an indication of priority associated with a request for resource reservation to the transport domain at the time of media stream establishment. In a multi domain environment which is very much part of the terms of reference for the work in Q.F) this will involve signalling between service domains and transport domains and possibly between transport domains, and we will need to ensure mechanisms for SD to SD as well as SD to TD. TD to TD is very much the role of the IETF so co-ordination will also be needed here. Again I was planning to start work on defining these signalling require! ments in Q.F. Finally, I agree work has got off to a slow start on Q.F since Geneva. Lack of time to discuss QoS at the last two WG2 meetings has not helped, also my inability to attend the Launceston meeting and the lack of contributions in this area. We will be holding a Q.F session in Brazil though and I hope then to start work on two or three new work items. Hopefully we can make some progress on these and Annex N. All contributions would be very welcome. Mike -----Original Message----- From: Roy, Radhika R, ALCOO [SMTP:rrroy@ATT.COM] Sent: Wednesday, April 18, 2001 6:34 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Emergency Services and Service classes Hi, Tom and All: I have few comments on: 1. Priority Class, 2. Quality/QOS Class, and 3. Dependency between Priority and Quality 1. Priority Class of a Call Let us define priority classes for a call across all ITU SGs (not ONLY in SG16). If the SG16 is allowed to do define the priority class that will be followed by other SGs, we may then define this in this SG and will be sending liaison to other SGs (because the emergency services standard works span multiple SGs. In addition, there are other areas that we need to look into. For example, the present ISDN standard also defines MLPP where several kinds of priority are offered. (Recently, contributions have also been presented to define priority is SIP in accordance to the MLPP.) 2. Quality/QOS Class of a Call To define quality of a call is being undertaken in Q.F/16. It will take time to define QOS classes or anything like this in Q.F because the definitions of QOS provided in various cases (e.g., SG 13 [Q.4], BICC, TIPHON, IETF, etc) are problematic at the application layer because they are often tied to the network layer. Suggestions are also there whether best, high, medium, or best-effort will mean anything unless we call guaranteed, controlled, or best-effort. The point is that let us continue the discussion of quality in Q.F/16 so that we agree on this. By the way, in Q.F/16, we are considering the quality at the medium level as opposed the per call level. (At one point, we found that classes are becoming problematic. So, we have started to use a matrix where a user will define how each medium will be treated - a kind of preferences [e.g., guaranteed, controlled, or best-effort] without defining explicit classes.) 3. Dependency between Priority and Quality I do not clearly whether there will be any dependency between the priority and quality of a call. Hope this helps. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Gary Thom [mailto:gthom@delta-info.com] Sent: Wednesday, April 18, 2001 12:41 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Emergency Services and Service classes I would like to re-open the discussion started at the Nov 2000 Geneva meeting and continued at the March 2001 Launceston meeting relating to Emergency Services. In order to support Emergency Services, there are three services that are desired: 1)Priority Dial Tone - this is a line or endpoint dedicated to emergency calls. 2)Priority Call Setup - this allows an emegency call to be made from any endpoint. 3)Priority Call transit through packet network - this requires interworking existing ISUP high probability of completion call marking with H.323, H.323 Annex M.2, h.246 Annex C, and H.248. An emergency call may be pre-emptive or may just improve the probability of call completion without pre-emption depending on national policy. Authentication issues also need to be worked out. Currently, in the US, this is handled like a calling card authentication. At the Geneva meeting, it was decided that this work was closely related to contribution D.4 from Cicso on reserving resources and also Annex N/H.323 on QOS. Also included were liaison statements from SG11 on QOS for BICC, and an ETSI TIPHON document on signaling end-to-end-qos. All of these items require a method of signaling the desired quality of service. One way of doing this that seems to be common to all requirements is to specify a Service Class parameter and to send this parameter in the various RAS and Call Signaling exchanges. I would like to propose the following Service Class parameter. ServiceClass ::= SEQUENCE { priority CHOICE { emergency, high, normal, low } quality CHOICE ;per TIPHON definition { best, high, medium, bestEffort } } The priority field is used to indicate the importance of the call. This is used not only for assuring that resources can be allocated, but also to improve the probability of completion of the call. The quality field is taken from the ETSI TIPHON QOS Class definitions, and relate to bitrate, codec type, and voice or video quality. High or emergency priority calls may not require best audio quality, medium may be sufficient (even prefered because of the lower bandwidth requirement), while normal priority calls may desire high or best audio quality. The Service Class parameter would then be added to the necessary RAS and Call Signalling messages. At a minimum this would include the ARQ and Setup messages, but might also be applied to others. It is necessary in the ARQ and Setup messages so that High Probability of Completion calls comming into the network from the PSTN can be given priority treatment. For priority dial tone, perhaps the Service Class should be included in the RRQ to indicate the desired priority, once authenticated by the Gatekeeper and confirmed in the RCF, this endpoint could then include that Service Class in subsequent ARQ and Setup messages. Is a token required from the Gatekeeper to indicate that the endpoint has been granted priority status???? For priority call completion, an authentication authority and procedure needs to be defined. One approach is for the call to be made to an access number, the user is then queried for a PIN and the called endpoint number. After authentication, the call would be transfered to the called endpoint. The transfered call would be placed using the Service Class provided by the athentication authority. This would be the same procedure for any calling card call made on the packet network. The Service Class would be based on teh service level agreement between the card user and the provider. In the case of an emergency caller, the SLA would indicate Emergency Priority. How are calling card calls handled on packet networks now???? Is this consistent??? I would appreciate any input that you could provide. 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(a)delta-info.com Website: www.delta-info.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: Emergency Services and Service classes
by Roy, Radhika R, ALCOO 20 Apr '01

20 Apr '01

Hi, Bob and Paul: I went through H.225.0v4 and did NOT find any reference to the "Generic Extensibility Framework." Was this accepted in H.323 standard? Am I missing in reading H.225.0v4? I would appreciate if Bob Callaghan or Paul Jones could help us here. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Roy, Radhika R, ALCOO Sent: Thursday, April 19, 2001 10:57 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Emergency Services and Service classes Hi, Bob: Many thanks for pointing out this. I remember the contribution provided by Pete Cordell, but was not sure when H.225.0v4 incorporated this. Hope that Pete (pl. send us your contribution number if possible) is reading this mail and will provide more suggestions how we can use the framework for various applications that need to be supported by H.323. I am providing couple of examples as follows that need to extend the base H.225.0 protocol (It is troublesome to change the exiting H.225.0 messages and will really be extremely helpful to use the general framework): 1. H.323 QOS: Extension of H.225.0 (RAS, Q.931) for supporting QOS (as well as H.245) 2. H.323 Mobility: Extension of H.225.0 (RAS, Annex G) for supporting QOS 3. Extension of H.225.0 (RAS, Annex G) to support of Presence and Instant Messaging 4. Emergency services 5. Others (in the future) I personally feel that it is NOT wise to extend the fields (or create new messages) in the exiting H.225.0 RAS, Annex G and Q.931 messages each time we need to add new capabilities or services in H.323. One point though - I do not know whether this framework can also be applicable for Annex G (Pete - pl. help us here too). Thank you again for your valuable suggestions. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Callaghan, Robert [mailto:Robert.Callaghan@icn.siemens.com] Sent: Thursday, April 19, 2001 10:36 AM To: Roy, Radhika R, ALCOO; ITU-SG16(a)mailbag.cps.INTEL.COM Subject: RE: Emergency Services and Service classes Roy, The Generic Extensibility Framework is new for H.225.0 v4. This addition was promoted by British Telecom with guidance by Pete Cordell. They would be a better source of information. I, myself, am not fully aware of all of its strengths. For me, it is simply a framework that allows for the transport of features and feature negotiation in a container without changing H.225.0. Features can then be added through independent recommendations, each with their own schedule. It also should be possible to do a search on contribution to Q.13/16 over the last two years. Bob -------------------------------------------------------------- Robert Callaghan Siemens Enterprise Networks 5500 Broken Sound Blvd, Boca Raton, Fl 33487 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: Thursday, April 19, 2001 8:59 AM To: Callaghan, Robert; ITU-SG16(a)mailbag.cps.INTEL.COM Subject: RE: Emergency Services and Service classes Hi, Bob: I will appreciate if you could tell more about the "Generic Extensibility Framework." Is it something within the H.323 spec? Best regards, Radhika R. Roy -----Original Message----- From: Callaghan, Robert [mailto:Robert.Callaghan@ICN.SIEMENS.COM] Sent: Wednesday, April 18, 2001 1:23 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Emergency Services and Service classes Gary, I suggest that this feature use the "Generic Extensibility Framework." This has the ability to transport the needed information over any H.225.0 message. It allows for the addition of the service without waiting for H.225.0 v5. Bob -------------------------------------------------------------- Robert Callaghan Siemens Enterprise Networks 5500 Broken Sound Blvd, Boca Raton, Fl 33487 Tel: +1 561 923-1756 Fax: +1 561 923-1403 Email: Robert.Callaghan(a)ICN.Siemens.com ----------------------------------------------------------------- -----Original Message----- From: Gary Thom [mailto:gthom@delta-info.com] Sent: Wednesday, April 18, 2001 12:41 PM To: ITU-SG16(a)mailbag.cps.INTEL.COM Subject: Emergency Services and Service classes I would like to re-open the discussion started at the Nov 2000 Geneva meeting and continued at the March 2001 Launceston meeting relating to Emergency Services. In order to support Emergency Services, there are three services that are desired: 1)Priority Dial Tone - this is a line or endpoint dedicated to emergency calls. 2)Priority Call Setup - this allows an emegency call to be made from any endpoint. 3)Priority Call transit through packet network - this requires interworking existing ISUP high probability of completion call marking with H.323, H.323 Annex M.2, h.246 Annex C, and H.248. An emergency call may be pre-emptive or may just improve the probability of call completion without pre-emption depending on national policy. Authentication issues also need to be worked out. Currently, in the US, this is handled like a calling card authentication. At the Geneva meeting, it was decided that this work was closely related to contribution D.4 from Cicso on reserving resources and also Annex N/H.323 on QOS. Also included were liaison statements from SG11 on QOS for BICC, and an ETSI TIPHON document on signaling end-to-end-qos. All of these items require a method of signaling the desired quality of service. One way of doing this that seems to be common to all requirements is to specify a Service Class parameter and to send this parameter in the various RAS and Call Signaling exchanges. I would like to propose the following Service Class parameter. ServiceClass ::= SEQUENCE { priority CHOICE { emergency, high, normal, low } quality CHOICE ;per TIPHON definition { best, high, medium, bestEffort } } The priority field is used to indicate the importance of the call. This is used not only for assuring that resources can be allocated, but also to improve the probability of completion of the call. The quality field is taken from the ETSI TIPHON QOS Class definitions, and relate to bitrate, codec type, and voice or video quality. High or emergency priority calls may not require best audio quality, medium may be sufficient (even prefered because of the lower bandwidth requirement), while normal priority calls may desire high or best audio quality. The Service Class parameter would then be added to the necessary RAS and Call Signalling messages. At a minimum this would include the ARQ and Setup messages, but might also be applied to others. It is necessary in the ARQ and Setup messages so that High Probability of Completion calls comming into the network from the PSTN can be given priority treatment. For priority dial tone, perhaps the Service Class should be included in the RRQ to indicate the desired priority, once authenticated by the Gatekeeper and confirmed in the RCF, this endpoint could then include that Service Class in subsequent ARQ and Setup messages. Is a token required from the Gatekeeper to indicate that the endpoint has been granted priority status???? For priority call completion, an authentication authority and procedure needs to be defined. One approach is for the call to be made to an access number, the user is then queried for a PIN and the called endpoint number. After authentication, the call would be transfered to the called endpoint. The transfered call would be placed using the Service Class provided by the athentication authority. This would be the same procedure for any calling card call made on the packet network. The Service Class would be based on teh service level agreement between the card user and the provider. In the case of an emergency caller, the SLA would indicate Emergency Priority. How are calling card calls handled on packet networks now???? Is this consistent??? I would appreciate any input that you could provide. 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(a)delta-info.com Website: www.delta-info.com -------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Re: Emergency Services and Service classes
by Roy, Radhika R, ALCOO 19 Apr '01

19 Apr '01

Hi, Bob: Many thanks for pointing out this. I remember the contribution provided by Pete Cordell, but was not sure when H.225.0v4 incorporated this. Hope that Pete (pl. send us your contribution number if possible) is reading this mail and will provide more suggestions how we can use the framework for various applications that need to be supported by H.323. I am providing couple of examples as follows that need to extend the base H.225.0 protocol (It is troublesome to change the exiting H.225.0 messages and will really be extremely helpful to use the general framework): 1. H.323 QOS: Extension of H.225.0 (RAS, Q.931) for supporting QOS (as well as H.245) 2. H.323 Mobility: Extension of H.225.0 (RAS, Annex G) for supporting QOS 3. Extension of H.225.0 (RAS, Annex G) to support of Presence and Instant Messaging 4. Emergency services 5. Others (in the future) I personally feel that it is NOT wise to extend the fields (or create new messages) in the exiting H.225.0 RAS, Annex G and Q.931 messages each time we need to add new capabilities or services in H.323. One point though - I do not know whether this framework can also be applicable for Annex G (Pete - pl. help us here too). Thank you again for your valuable suggestions. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Callaghan, Robert [mailto:Robert.Callaghan@icn.siemens.com] Sent: Thursday, April 19, 2001 10:36 AM To: Roy, Radhika R, ALCOO; ITU-SG16(a)mailbag.cps.INTEL.COM Subject: RE: Emergency Services and Service classes Roy, The Generic Extensibility Framework is new for H.225.0 v4. This addition was promoted by British Telecom with guidance by Pete Cordell. They would be a better source of information. I, myself, am not fully aware of all of its strengths. For me, it is simply a framework that allows for the transport of features and feature negotiation in a container without changing H.225.0. Features can then be added through independent recommendations, each with their own schedule. It also should be possible to do a search on contribution to Q.13/16 over the last two years. Bob -------------------------------------------------------------- Robert Callaghan Siemens Enterprise Networks 5500 Broken Sound Blvd, Boca Raton, Fl 33487 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: Thursday, April 19, 2001 8:59 AM To: Callaghan, Robert; ITU-SG16(a)mailbag.cps.INTEL.COM Subject: RE: Emergency Services and Service classes Hi, Bob: I will appreciate if you could tell more about the "Generic Extensibility Framework." Is it something within the H.323 spec? Best regards, Radhika R. Roy -----Original Message----- From: Callaghan, Robert [mailto:Robert.Callaghan@ICN.SIEMENS.COM] Sent: Wednesday, April 18, 2001 1:23 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Emergency Services and Service classes Gary, I suggest that this feature use the "Generic Extensibility Framework." This has the ability to transport the needed information over any H.225.0 message. It allows for the addition of the service without waiting for H.225.0 v5. Bob -------------------------------------------------------------- Robert Callaghan Siemens Enterprise Networks 5500 Broken Sound Blvd, Boca Raton, Fl 33487 Tel: +1 561 923-1756 Fax: +1 561 923-1403 Email: Robert.Callaghan(a)ICN.Siemens.com ----------------------------------------------------------------- -----Original Message----- From: Gary Thom [mailto:gthom@delta-info.com] Sent: Wednesday, April 18, 2001 12:41 PM To: ITU-SG16(a)mailbag.cps.INTEL.COM Subject: Emergency Services and Service classes I would like to re-open the discussion started at the Nov 2000 Geneva meeting and continued at the March 2001 Launceston meeting relating to Emergency Services. In order to support Emergency Services, there are three services that are desired: 1)Priority Dial Tone - this is a line or endpoint dedicated to emergency calls. 2)Priority Call Setup - this allows an emegency call to be made from any endpoint. 3)Priority Call transit through packet network - this requires interworking existing ISUP high probability of completion call marking with H.323, H.323 Annex M.2, h.246 Annex C, and H.248. An emergency call may be pre-emptive or may just improve the probability of call completion without pre-emption depending on national policy. Authentication issues also need to be worked out. Currently, in the US, this is handled like a calling card authentication. At the Geneva meeting, it was decided that this work was closely related to contribution D.4 from Cicso on reserving resources and also Annex N/H.323 on QOS. Also included were liaison statements from SG11 on QOS for BICC, and an ETSI TIPHON document on signaling end-to-end-qos. All of these items require a method of signaling the desired quality of service. One way of doing this that seems to be common to all requirements is to specify a Service Class parameter and to send this parameter in the various RAS and Call Signaling exchanges. I would like to propose the following Service Class parameter. ServiceClass ::= SEQUENCE { priority CHOICE { emergency, high, normal, low } quality CHOICE ;per TIPHON definition { best, high, medium, bestEffort } } The priority field is used to indicate the importance of the call. This is used not only for assuring that resources can be allocated, but also to improve the probability of completion of the call. The quality field is taken from the ETSI TIPHON QOS Class definitions, and relate to bitrate, codec type, and voice or video quality. High or emergency priority calls may not require best audio quality, medium may be sufficient (even prefered because of the lower bandwidth requirement), while normal priority calls may desire high or best audio quality. The Service Class parameter would then be added to the necessary RAS and Call Signalling messages. At a minimum this would include the ARQ and Setup messages, but might also be applied to others. It is necessary in the ARQ and Setup messages so that High Probability of Completion calls comming into the network from the PSTN can be given priority treatment. For priority dial tone, perhaps the Service Class should be included in the RRQ to indicate the desired priority, once authenticated by the Gatekeeper and confirmed in the RCF, this endpoint could then include that Service Class in subsequent ARQ and Setup messages. Is a token required from the Gatekeeper to indicate that the endpoint has been granted priority status???? For priority call completion, an authentication authority and procedure needs to be defined. One approach is for the call to be made to an access number, the user is then queried for a PIN and the called endpoint number. After authentication, the call would be transfered to the called endpoint. The transfered call would be placed using the Service Class provided by the athentication authority. This would be the same procedure for any calling card call made on the packet network. The Service Class would be based on teh service level agreement between the card user and the provider. In the case of an emergency caller, the SLA would indicate Emergency Priority. How are calling card calls handled on packet networks now???? Is this consistent??? I would appreciate any input that you could provide. 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(a)delta-info.com Website: www.delta-info.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: AW: Emergency Services and Service classes
by Chip Sharp 19 Apr '01

19 Apr '01

FWIW, Concerning MLPP's application to packet networks, the following two I-Ds are currently proposed in IETF SIP WG: Title: SIP Precedence mapping to MLPP Interworking http://search.ietf.org/internet-drafts/draft-polk-sip-mlpp-mapping-01.txt abstract: This document describes an extension to the Session Initiation Protocol [1] to allow SIP (and IP) into existing Voice Backbone Infrastructures that require Multi-Level Precedence and Preemption [2] Service throughout those networks. This document will also allow MLPP networks that are ISDN-based now to evolve/ migrate or be replaced by a SIP-based Voice Signaling network with no loss in capability of that original network. More likely is the case that additional functionality and capabilities can be realized such as mobility and reduced user headaches (explained later) with SIP being MLPP enabled within a network infrastructure. Title: Multi-Level Precedence and Preemption over IP draft-polk-mlpp-over-ip-00.txt Summary abstract: This document describes how the ANSI specification T1.619- 1992[1] and its extension T1.619a-1994 [2] should be mapped or correlated or migrated over to either a mixed TDM and IP network (with Gateways in between) or a pure IP network that requires the functionality of these two specs as Standard Operating Procedure. At 03:35 AM 4/19/2001, Horvath Ernst wrote: >Roy, > >as you say, call priority and QoS are different issues, but over a packet >network both come down to the same problem, expedited transport of packets >with minimal packet loss. So the mechanisms used in both cases may well be >the same. > >The ISDN MLPP service is very complex and would be over-kill in a packet >network which should not run into the same blocking situations as a circuit >switched network. The complexity of MLPP was also the reason why ISO did not >adopt it for QSIG (QSIG has a simpler call priority service called CPI, call >priority interruption). > >Regards, >Ernst Horvath >Siemens AG > > > -----Ursprüngliche Nachricht----- > > Von: Roy, Radhika R, ALCOO [mailto:rrroy@ATT.COM] > > Gesendet am: Mittwoch, 18. April 2001 21:30 > > An: ITU-SG16(a)mailbag.cps.INTEL.COM > > Betreff: Re: Emergency Services and Service classes > > > > Hi, Tom: > > > > Good that MLPP was discussed in the last Rap. meeting. > > > > One suggestion comes to my mind that we can define "Priority" > > field in such > > a way keeping options for all kinds of priority (civilian, > > interworking with > > ISDN, etc.) levels and let people choose as it is needed. > > > > Best regards, > > Radhika R. Roy > > AT&T > > > > -----Original Message----- > > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] > > Sent: Wednesday, April 18, 2001 3:16 PM > > To: Roy, Radhika R, ALCOO; ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: RE: Emergency Services and Service classes > > > > > > > > I just wanted to note that MLPP came up in the Launceston > > discussion. The > > point was made at that time that MLPP (the M stands for > > "Military") is a > > separate issue, since what Gary and company are talking about > > is civilian > > emergency services. > > > > Beyond that, we are committed to working with other Study > > Groups on this > > issue. > > > > > -----Original Message----- > > > From: Roy, Radhika R, ALCOO [ mailto:rrroy@ATT.COM > > <mailto:rrroy@ATT.COM> > > ] > > > Sent: Wednesday, April 18, 2001 1:34 PM > > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > > Subject: Re: Emergency Services and Service classes > > > > > > > > > Hi, Tom and All: > > > > > > I have few comments on: 1. Priority Class, 2. Quality/QOS > > > Class, and 3. > > > Dependency between Priority and Quality > > > > > > 1. Priority Class of a Call > > > > > > Let us define priority classes for a call across all ITU SGs > > > (not ONLY in > > > SG16). If the SG16 is allowed to do define the priority class > > > that will be > > > followed by other SGs, we may then define this in this SG > > and will be > > > sending liaison to other SGs (because the emergency services > > > standard works > > > span multiple SGs. > > > > > > In addition, there are other areas that we need to look into. > > > For example, > > > the present ISDN standard also defines MLPP where several > > > kinds of priority > > > are offered. (Recently, contributions have also been > > > presented to define > > > priority is SIP in accordance to the MLPP.) > > > > > > 2. Quality/QOS Class of a Call > > > > > > To define quality of a call is being undertaken in Q.F/16. It > > > will take time > > > to define QOS classes or anything like this in Q.F because > > > the definitions > > > of QOS provided in various cases (e.g., SG 13 [Q.4], BICC, > > > TIPHON, IETF, > > > etc) are problematic at the application layer because they > > > are often tied to > > > the network layer. Suggestions are also there whether best, > > > high, medium, or > > > best-effort will mean anything unless we call guaranteed, > > > controlled, or > > > best-effort. > > > > > > The point is that let us continue the discussion of quality > > > in Q.F/16 so > > > that we agree on this. > > > > > > By the way, in Q.F/16, we are considering the quality at the > > > medium level as > > > opposed the per call level. (At one point, we found that classes are > > > becoming problematic. So, we have started to use a matrix > > > where a user will > > > define how each medium will be treated - a kind of > > preferences [e.g., > > > guaranteed, controlled, or best-effort] without defining > > > explicit classes.) > > > > > > 3. Dependency between Priority and Quality > > > > > > I do not clearly whether there will be any dependency between > > > the priority > > > and quality of a call. > > > > > > Hope this helps. > > > > > > Best regards, > > > Radhika R. Roy > > > AT&T > > > > > > -----Original Message----- > > > From: Gary Thom [ mailto:gthom@delta-info.com > > <mailto:gthom@delta-info.com> ] > > > Sent: Wednesday, April 18, 2001 12:41 PM > > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > > Subject: Emergency Services and Service classes > > > > > > > > > I would like to re-open the discussion started at the Nov > > 2000 Geneva > > > meeting and continued at the March 2001 Launceston meeting > > relating to > > > Emergency Services. > > > > > > In order to support Emergency Services, there are three > > > services that are > > > desired: > > > 1)Priority Dial Tone - this is a line or endpoint dedicated > > > to emergency > > > calls. > > > 2)Priority Call Setup - this allows an emegency call to be > > > made from any > > > endpoint. > > > 3)Priority Call transit through packet network - this > > > requires interworking > > > existing ISUP high probability of completion call marking > > > with H.323, H.323 > > > Annex M.2, h.246 Annex C, and H.248. > > > > > > An emergency call may be pre-emptive or may just improve the > > > probability of > > > call completion without pre-emption depending on national policy. > > > Authentication issues also need to be worked out. Currently, > > > in the US, this > > > is handled like a calling card authentication. > > > > > > At the Geneva meeting, it was decided that this work was > > > closely related to > > > contribution D.4 from Cicso on reserving resources and also > > > Annex N/H.323 on > > > QOS. Also included were liaison statements from SG11 on QOS > > > for BICC, and an > > > ETSI TIPHON document on signaling end-to-end-qos. > > > > > > All of these items require a method of signaling the desired > > > quality of > > > service. > > > One way of doing this that seems to be common to all > > > requirements is to > > > specify a Service Class parameter and to send this parameter > > > in the various > > > RAS and Call Signaling exchanges. > > > > > > I would like to propose the following Service Class parameter. > > > > > > ServiceClass ::= SEQUENCE > > > { > > > priority CHOICE > > > { > > > emergency, > > > high, > > > normal, > > > low > > > } > > > quality CHOICE ;per TIPHON definition > > > { > > > best, > > > high, > > > medium, > > > bestEffort > > > } > > > } > > > > > > The priority field is used to indicate the importance of the > > > call. This is > > > used not only for assuring that resources can be allocated, > > > but also to > > > improve the probability of completion of the call. > > > > > > The quality field is taken from the ETSI TIPHON QOS Class > > > definitions, and > > > relate to bitrate, codec type, and voice or video quality. > > > > > > High or emergency priority calls may not require best audio > > > quality, medium > > > may be sufficient (even prefered because of the lower bandwidth > > > requirement), while normal priority calls may desire high or > > > best audio > > > quality. > > > > > > > > > The Service Class parameter would then be added to the > > > necessary RAS and > > > Call Signalling messages. At a minimum this would include the > > > ARQ and Setup > > > messages, but might also be applied to others. > > > > > > It is necessary in the ARQ and Setup messages so that High > > > Probability of > > > Completion calls comming into the network from the PSTN can be given > > > priority treatment. > > > > > > For priority dial tone, perhaps the Service Class should be > > > included in the > > > RRQ to indicate the desired priority, once authenticated by > > > the Gatekeeper > > > and confirmed in the RCF, this endpoint could then include > > > that Service > > > Class in subsequent ARQ and Setup messages. Is a token > > > required from the > > > Gatekeeper to indicate that the endpoint has been granted priority > > > status???? > > > > > > For priority call completion, an authentication authority and > > > procedure > > > needs to be defined. One approach is for the call to be made > > > to an access > > > number, the user is then queried for a PIN and the called > > > endpoint number. > > > After authentication, the call would be transfered to the > > > called endpoint. > > > The transfered call would be placed using the Service Class > > > provided by the > > > athentication authority. This would be the same procedure for > > > any calling > > > card call made on the packet network. The Service Class would > > > be based on > > > teh service level agreement between the card user and the > > > provider. In the > > > case of an emergency caller, the SLA would indicate Emergency > > > Priority. How > > > are calling card calls handled on packet networks now???? Is this > > > consistent??? > > > > > > > > > I would appreciate any input that you could provide. > > > > > > 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(a)delta-info.com > > > Website: www.delta-info.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 ------------------------------------------------------------------- Chip Sharp Consulting Engineering Cisco Systems ------------------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Emergency Services and Service classes
by Callaghan, Robert 19 Apr '01

19 Apr '01

Roy, The Generic Extensibility Framework is new for H.225.0 v4. This addition was promoted by British Telecom with guidance by Pete Cordell. They would be a better source of information. I, myself, am not fully aware of all of its strengths. For me, it is simply a framework that allows for the transport of features and feature negotiation in a container without changing H.225.0. Features can then be added through independent recommendations, each with their own schedule. It also should be possible to do a search on contribution to Q.13/16 over the last two years. Bob -------------------------------------------------------------- Robert Callaghan Siemens Enterprise Networks 5500 Broken Sound Blvd, Boca Raton, Fl 33487 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: Thursday, April 19, 2001 8:59 AM To: Callaghan, Robert; ITU-SG16(a)mailbag.cps.INTEL.COM Subject: RE: Emergency Services and Service classes Hi, Bob: I will appreciate if you could tell more about the "Generic Extensibility Framework." Is it something within the H.323 spec? Best regards, Radhika R. Roy -----Original Message----- From: Callaghan, Robert [mailto:Robert.Callaghan@ICN.SIEMENS.COM] Sent: Wednesday, April 18, 2001 1:23 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Emergency Services and Service classes Gary, I suggest that this feature use the "Generic Extensibility Framework." This has the ability to transport the needed information over any H.225.0 message. It allows for the addition of the service without waiting for H.225.0 v5. Bob -------------------------------------------------------------- Robert Callaghan Siemens Enterprise Networks 5500 Broken Sound Blvd, Boca Raton, Fl 33487 Tel: +1 561 923-1756 Fax: +1 561 923-1403 Email: Robert.Callaghan(a)ICN.Siemens.com ----------------------------------------------------------------- -----Original Message----- From: Gary Thom [mailto:gthom@delta-info.com] Sent: Wednesday, April 18, 2001 12:41 PM To: ITU-SG16(a)mailbag.cps.INTEL.COM Subject: Emergency Services and Service classes I would like to re-open the discussion started at the Nov 2000 Geneva meeting and continued at the March 2001 Launceston meeting relating to Emergency Services. In order to support Emergency Services, there are three services that are desired: 1)Priority Dial Tone - this is a line or endpoint dedicated to emergency calls. 2)Priority Call Setup - this allows an emegency call to be made from any endpoint. 3)Priority Call transit through packet network - this requires interworking existing ISUP high probability of completion call marking with H.323, H.323 Annex M.2, h.246 Annex C, and H.248. An emergency call may be pre-emptive or may just improve the probability of call completion without pre-emption depending on national policy. Authentication issues also need to be worked out. Currently, in the US, this is handled like a calling card authentication. At the Geneva meeting, it was decided that this work was closely related to contribution D.4 from Cicso on reserving resources and also Annex N/H.323 on QOS. Also included were liaison statements from SG11 on QOS for BICC, and an ETSI TIPHON document on signaling end-to-end-qos. All of these items require a method of signaling the desired quality of service. One way of doing this that seems to be common to all requirements is to specify a Service Class parameter and to send this parameter in the various RAS and Call Signaling exchanges. I would like to propose the following Service Class parameter. ServiceClass ::= SEQUENCE { priority CHOICE { emergency, high, normal, low } quality CHOICE ;per TIPHON definition { best, high, medium, bestEffort } } The priority field is used to indicate the importance of the call. This is used not only for assuring that resources can be allocated, but also to improve the probability of completion of the call. The quality field is taken from the ETSI TIPHON QOS Class definitions, and relate to bitrate, codec type, and voice or video quality. High or emergency priority calls may not require best audio quality, medium may be sufficient (even prefered because of the lower bandwidth requirement), while normal priority calls may desire high or best audio quality. The Service Class parameter would then be added to the necessary RAS and Call Signalling messages. At a minimum this would include the ARQ and Setup messages, but might also be applied to others. It is necessary in the ARQ and Setup messages so that High Probability of Completion calls comming into the network from the PSTN can be given priority treatment. For priority dial tone, perhaps the Service Class should be included in the RRQ to indicate the desired priority, once authenticated by the Gatekeeper and confirmed in the RCF, this endpoint could then include that Service Class in subsequent ARQ and Setup messages. Is a token required from the Gatekeeper to indicate that the endpoint has been granted priority status???? For priority call completion, an authentication authority and procedure needs to be defined. One approach is for the call to be made to an access number, the user is then queried for a PIN and the called endpoint number. After authentication, the call would be transfered to the called endpoint. The transfered call would be placed using the Service Class provided by the athentication authority. This would be the same procedure for any calling card call made on the packet network. The Service Class would be based on teh service level agreement between the card user and the provider. In the case of an emergency caller, the SLA would indicate Emergency Priority. How are calling card calls handled on packet networks now???? Is this consistent??? I would appreciate any input that you could provide. 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(a)delta-info.com Website: www.delta-info.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: Emergency Services and Service classes
by Tom-PT Taylor 19 Apr '01

19 Apr '01

As we've seen from subsequent discussion, we probably have to review the requirements before discussing specific solutions. Radhika has brought out two requirements: - the service has to work across multiple transport, signalling, and administrative domains - the mechanisms provided should be reusable for other services. The first requirement implies the need to identify the boundaries of our solution and define means to interwork across them. The second requirement was already brought out in Launceston, and will work to spread out the cost burden of implementing any new mechanisms. > -----Original Message----- > From: Gary Thom [mailto:gthom@DELTA-INFO.COM] > Sent: Wednesday, April 18, 2001 12:41 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Emergency Services and Service classes > > > I would like to re-open the discussion started at the Nov 2000 Geneva > meeting and continued at the March 2001 Launceston meeting relating to > Emergency Services. > > In order to support Emergency Services, there are three > services that are > desired: > 1)Priority Dial Tone - this is a line or endpoint dedicated > to emergency > calls. > 2)Priority Call Setup - this allows an emegency call to be > made from any > endpoint. > 3)Priority Call transit through packet network - this > requires interworking > existing ISUP high probability of completion call marking > with H.323, H.323 > Annex M.2, h.246 Annex C, and H.248. > > An emergency call may be pre-emptive or may just improve the > probability of > call completion without pre-emption depending on national policy. > Authentication issues also need to be worked out. Currently, > in the US, this > is handled like a calling card authentication. > > At the Geneva meeting, it was decided that this work was > closely related to > contribution D.4 from Cicso on reserving resources and also > Annex N/H.323 on > QOS. Also included were liaison statements from SG11 on QOS > for BICC, and an > ETSI TIPHON document on signaling end-to-end-qos. > > All of these items require a method of signaling the desired > quality of > service. > One way of doing this that seems to be common to all > requirements is to > specify a Service Class parameter and to send this parameter > in the various > RAS and Call Signaling exchanges. > > I would like to propose the following Service Class parameter. > > ServiceClass ::= SEQUENCE > { > priority CHOICE > { > emergency, > high, > normal, > low > } > quality CHOICE ;per TIPHON definition > { > best, > high, > medium, > bestEffort > } > } > > The priority field is used to indicate the importance of the > call. This is > used not only for assuring that resources can be allocated, > but also to > improve the probability of completion of the call. > > The quality field is taken from the ETSI TIPHON QOS Class > definitions, and > relate to bitrate, codec type, and voice or video quality. > > High or emergency priority calls may not require best audio > quality, medium > may be sufficient (even prefered because of the lower bandwidth > requirement), while normal priority calls may desire high or > best audio > quality. > > > The Service Class parameter would then be added to the > necessary RAS and > Call Signalling messages. At a minimum this would include the > ARQ and Setup > messages, but might also be applied to others. > > It is necessary in the ARQ and Setup messages so that High > Probability of > Completion calls comming into the network from the PSTN can be given > priority treatment. > > For priority dial tone, perhaps the Service Class should be > included in the > RRQ to indicate the desired priority, once authenticated by > the Gatekeeper > and confirmed in the RCF, this endpoint could then include > that Service > Class in subsequent ARQ and Setup messages. Is a token > required from the > Gatekeeper to indicate that the endpoint has been granted priority > status???? > > For priority call completion, an authentication authority and > procedure > needs to be defined. One approach is for the call to be made > to an access > number, the user is then queried for a PIN and the called > endpoint number. > After authentication, the call would be transfered to the > called endpoint. > The transfered call would be placed using the Service Class > provided by the > athentication authority. This would be the same procedure for > any calling > card call made on the packet network. The Service Class would > be based on > teh service level agreement between the card user and the > provider. In the > case of an emergency caller, the SLA would indicate Emergency > Priority. How > are calling card calls handled on packet networks now???? Is this > consistent??? > > > I would appreciate any input that you could provide. > > 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(a)delta-info.com > Website: www.delta-info.com > -------------------------------------------- > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com >

1 0

Re: Emergency Services and Service classes
by Roy, Radhika R, ALCOO 19 Apr '01

19 Apr '01

Hi, Ernst: In SG16, we are focusing on the application layer on end-to-end basis, independent of the underlying transport mechanisms. The call level abstraction is NOT associated with the network layer. However, as I pointed out (as you have also indicated for the packet layer), there may be dependency between the call layer priority and the application layer QOS. We hope that we will address this in Q.F/16. The same can also be abstracted over the packet layer for implementation knowing the relationship between the two right at the application layer at the time of call setup. (Please note that an end-to-end call may include one or multiple networks [e.g., IP, ATM]. Even in one network, there can be different network layer QOS schemes [e.g., RSVP domain, DiffServ QOS domain].) (With respect to MLPP, people from various countries discussed this in the last IETF SIP meeting as well and some work is moving along that line.) The point that I am trying to make is this: Let the priority field should be flexible enough to meet different needs without limiting to only one kind of priority scheme. For example, it may include QSIG CPI, civilian emergency schemes, etc. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Horvath Ernst [mailto:ernst.horvath@SIEMENS.AT] Sent: Thursday, April 19, 2001 3:36 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: AW: Emergency Services and Service classes Roy, as you say, call priority and QoS are different issues, but over a packet network both come down to the same problem, expedited transport of packets with minimal packet loss. So the mechanisms used in both cases may well be the same. The ISDN MLPP service is very complex and would be over-kill in a packet network which should not run into the same blocking situations as a circuit switched network. The complexity of MLPP was also the reason why ISO did not adopt it for QSIG (QSIG has a simpler call priority service called CPI, call priority interruption). Regards, Ernst Horvath Siemens AG > -----Ursprüngliche Nachricht----- > Von: Roy, Radhika R, ALCOO [mailto:rrroy@ATT.COM] > Gesendet am: Mittwoch, 18. April 2001 21:30 > An: ITU-SG16(a)mailbag.cps.INTEL.COM > Betreff: Re: Emergency Services and Service classes > > Hi, Tom: > > Good that MLPP was discussed in the last Rap. meeting. > > One suggestion comes to my mind that we can define "Priority" > field in such > a way keeping options for all kinds of priority (civilian, > interworking with > ISDN, etc.) levels and let people choose as it is needed. > > Best regards, > Radhika R. Roy > AT&T > > -----Original Message----- > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] > Sent: Wednesday, April 18, 2001 3:16 PM > To: Roy, Radhika R, ALCOO; ITU-SG16(a)MAILBAG.INTEL.COM > Subject: RE: Emergency Services and Service classes > > > > I just wanted to note that MLPP came up in the Launceston > discussion. The > point was made at that time that MLPP (the M stands for > "Military") is a > separate issue, since what Gary and company are talking about > is civilian > emergency services. > > Beyond that, we are committed to working with other Study > Groups on this > issue. > > > -----Original Message----- > > From: Roy, Radhika R, ALCOO [ mailto:rrroy@ATT.COM > <mailto:rrroy@ATT.COM> > ] > > Sent: Wednesday, April 18, 2001 1:34 PM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: Re: Emergency Services and Service classes > > > > > > Hi, Tom and All: > > > > I have few comments on: 1. Priority Class, 2. Quality/QOS > > Class, and 3. > > Dependency between Priority and Quality > > > > 1. Priority Class of a Call > > > > Let us define priority classes for a call across all ITU SGs > > (not ONLY in > > SG16). If the SG16 is allowed to do define the priority class > > that will be > > followed by other SGs, we may then define this in this SG > and will be > > sending liaison to other SGs (because the emergency services > > standard works > > span multiple SGs. > > > > In addition, there are other areas that we need to look into. > > For example, > > the present ISDN standard also defines MLPP where several > > kinds of priority > > are offered. (Recently, contributions have also been > > presented to define > > priority is SIP in accordance to the MLPP.) > > > > 2. Quality/QOS Class of a Call > > > > To define quality of a call is being undertaken in Q.F/16. It > > will take time > > to define QOS classes or anything like this in Q.F because > > the definitions > > of QOS provided in various cases (e.g., SG 13 [Q.4], BICC, > > TIPHON, IETF, > > etc) are problematic at the application layer because they > > are often tied to > > the network layer. Suggestions are also there whether best, > > high, medium, or > > best-effort will mean anything unless we call guaranteed, > > controlled, or > > best-effort. > > > > The point is that let us continue the discussion of quality > > in Q.F/16 so > > that we agree on this. > > > > By the way, in Q.F/16, we are considering the quality at the > > medium level as > > opposed the per call level. (At one point, we found that classes are > > becoming problematic. So, we have started to use a matrix > > where a user will > > define how each medium will be treated - a kind of > preferences [e.g., > > guaranteed, controlled, or best-effort] without defining > > explicit classes.) > > > > 3. Dependency between Priority and Quality > > > > I do not clearly whether there will be any dependency between > > the priority > > and quality of a call. > > > > Hope this helps. > > > > Best regards, > > Radhika R. Roy > > AT&T > > > > -----Original Message----- > > From: Gary Thom [ mailto:gthom@delta-info.com > <mailto:gthom@delta-info.com> ] > > Sent: Wednesday, April 18, 2001 12:41 PM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: Emergency Services and Service classes > > > > > > I would like to re-open the discussion started at the Nov > 2000 Geneva > > meeting and continued at the March 2001 Launceston meeting > relating to > > Emergency Services. > > > > In order to support Emergency Services, there are three > > services that are > > desired: > > 1)Priority Dial Tone - this is a line or endpoint dedicated > > to emergency > > calls. > > 2)Priority Call Setup - this allows an emegency call to be > > made from any > > endpoint. > > 3)Priority Call transit through packet network - this > > requires interworking > > existing ISUP high probability of completion call marking > > with H.323, H.323 > > Annex M.2, h.246 Annex C, and H.248. > > > > An emergency call may be pre-emptive or may just improve the > > probability of > > call completion without pre-emption depending on national policy. > > Authentication issues also need to be worked out. Currently, > > in the US, this > > is handled like a calling card authentication. > > > > At the Geneva meeting, it was decided that this work was > > closely related to > > contribution D.4 from Cicso on reserving resources and also > > Annex N/H.323 on > > QOS. Also included were liaison statements from SG11 on QOS > > for BICC, and an > > ETSI TIPHON document on signaling end-to-end-qos. > > > > All of these items require a method of signaling the desired > > quality of > > service. > > One way of doing this that seems to be common to all > > requirements is to > > specify a Service Class parameter and to send this parameter > > in the various > > RAS and Call Signaling exchanges. > > > > I would like to propose the following Service Class parameter. > > > > ServiceClass ::= SEQUENCE > > { > > priority CHOICE > > { > > emergency, > > high, > > normal, > > low > > } > > quality CHOICE ;per TIPHON definition > > { > > best, > > high, > > medium, > > bestEffort > > } > > } > > > > The priority field is used to indicate the importance of the > > call. This is > > used not only for assuring that resources can be allocated, > > but also to > > improve the probability of completion of the call. > > > > The quality field is taken from the ETSI TIPHON QOS Class > > definitions, and > > relate to bitrate, codec type, and voice or video quality. > > > > High or emergency priority calls may not require best audio > > quality, medium > > may be sufficient (even prefered because of the lower bandwidth > > requirement), while normal priority calls may desire high or > > best audio > > quality. > > > > > > The Service Class parameter would then be added to the > > necessary RAS and > > Call Signalling messages. At a minimum this would include the > > ARQ and Setup > > messages, but might also be applied to others. > > > > It is necessary in the ARQ and Setup messages so that High > > Probability of > > Completion calls comming into the network from the PSTN can be given > > priority treatment. > > > > For priority dial tone, perhaps the Service Class should be > > included in the > > RRQ to indicate the desired priority, once authenticated by > > the Gatekeeper > > and confirmed in the RCF, this endpoint could then include > > that Service > > Class in subsequent ARQ and Setup messages. Is a token > > required from the > > Gatekeeper to indicate that the endpoint has been granted priority > > status???? > > > > For priority call completion, an authentication authority and > > procedure > > needs to be defined. One approach is for the call to be made > > to an access > > number, the user is then queried for a PIN and the called > > endpoint number. > > After authentication, the call would be transfered to the > > called endpoint. > > The transfered call would be placed using the Service Class > > provided by the > > athentication authority. This would be the same procedure for > > any calling > > card call made on the packet network. The Service Class would > > be based on > > teh service level agreement between the card user and the > > provider. In the > > case of an emergency caller, the SLA would indicate Emergency > > Priority. How > > are calling card calls handled on packet networks now???? Is this > > consistent??? > > > > > > I would appreciate any input that you could provide. > > > > 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(a)delta-info.com > > Website: www.delta-info.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: Emergency Services and Service classes
by Roy, Radhika R, ALCOO 19 Apr '01

19 Apr '01

Hi, Bob: I will appreciate if you could tell more about the "Generic Extensibility Framework." Is it something within the H.323 spec? Best regards, Radhika R. Roy -----Original Message----- From: Callaghan, Robert [mailto:Robert.Callaghan@ICN.SIEMENS.COM] Sent: Wednesday, April 18, 2001 1:23 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Emergency Services and Service classes Gary, I suggest that this feature use the "Generic Extensibility Framework." This has the ability to transport the needed information over any H.225.0 message. It allows for the addition of the service without waiting for H.225.0 v5. Bob -------------------------------------------------------------- Robert Callaghan Siemens Enterprise Networks 5500 Broken Sound Blvd, Boca Raton, Fl 33487 Tel: +1 561 923-1756 Fax: +1 561 923-1403 Email: Robert.Callaghan(a)ICN.Siemens.com ----------------------------------------------------------------- -----Original Message----- From: Gary Thom [mailto:gthom@delta-info.com] Sent: Wednesday, April 18, 2001 12:41 PM To: ITU-SG16(a)mailbag.cps.INTEL.COM Subject: Emergency Services and Service classes I would like to re-open the discussion started at the Nov 2000 Geneva meeting and continued at the March 2001 Launceston meeting relating to Emergency Services. In order to support Emergency Services, there are three services that are desired: 1)Priority Dial Tone - this is a line or endpoint dedicated to emergency calls. 2)Priority Call Setup - this allows an emegency call to be made from any endpoint. 3)Priority Call transit through packet network - this requires interworking existing ISUP high probability of completion call marking with H.323, H.323 Annex M.2, h.246 Annex C, and H.248. An emergency call may be pre-emptive or may just improve the probability of call completion without pre-emption depending on national policy. Authentication issues also need to be worked out. Currently, in the US, this is handled like a calling card authentication. At the Geneva meeting, it was decided that this work was closely related to contribution D.4 from Cicso on reserving resources and also Annex N/H.323 on QOS. Also included were liaison statements from SG11 on QOS for BICC, and an ETSI TIPHON document on signaling end-to-end-qos. All of these items require a method of signaling the desired quality of service. One way of doing this that seems to be common to all requirements is to specify a Service Class parameter and to send this parameter in the various RAS and Call Signaling exchanges. I would like to propose the following Service Class parameter. ServiceClass ::= SEQUENCE { priority CHOICE { emergency, high, normal, low } quality CHOICE ;per TIPHON definition { best, high, medium, bestEffort } } The priority field is used to indicate the importance of the call. This is used not only for assuring that resources can be allocated, but also to improve the probability of completion of the call. The quality field is taken from the ETSI TIPHON QOS Class definitions, and relate to bitrate, codec type, and voice or video quality. High or emergency priority calls may not require best audio quality, medium may be sufficient (even prefered because of the lower bandwidth requirement), while normal priority calls may desire high or best audio quality. The Service Class parameter would then be added to the necessary RAS and Call Signalling messages. At a minimum this would include the ARQ and Setup messages, but might also be applied to others. It is necessary in the ARQ and Setup messages so that High Probability of Completion calls comming into the network from the PSTN can be given priority treatment. For priority dial tone, perhaps the Service Class should be included in the RRQ to indicate the desired priority, once authenticated by the Gatekeeper and confirmed in the RCF, this endpoint could then include that Service Class in subsequent ARQ and Setup messages. Is a token required from the Gatekeeper to indicate that the endpoint has been granted priority status???? For priority call completion, an authentication authority and procedure needs to be defined. One approach is for the call to be made to an access number, the user is then queried for a PIN and the called endpoint number. After authentication, the call would be transfered to the called endpoint. The transfered call would be placed using the Service Class provided by the athentication authority. This would be the same procedure for any calling card call made on the packet network. The Service Class would be based on teh service level agreement between the card user and the provider. In the case of an emergency caller, the SLA would indicate Emergency Priority. How are calling card calls handled on packet networks now???? Is this consistent??? I would appreciate any input that you could provide. 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(a)delta-info.com Website: www.delta-info.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

AW: H.450 - "Loose" specification of SyntaxList in X.681?
by Horvath Ernst 19 Apr '01

19 Apr '01

Frank, the syntax for a given object class (e.g. OPERATION) is not loose. It must be exactly as specified in the definition of the object class after the key words "WITH SYNTAX". For the purposes of H.450, the two object classes OPERATION and ERROR are imported from X.880. All operations and error values are specified using the syntax of X.880 (alternatively the "raw" form could be used when specifying an operation or error, but this has not been done in any H.450 recommendation). Your example with commas is no valid syntax according to X.880. Regards, Ernst > -----Ursprüngliche Nachricht----- > Von: Frank Derks [mailto:frank.derks@PHILIPS.COM] > Gesendet am: Donnerstag, 19. April 2001 11:09 > An: ITU-SG16(a)mailbag.cps.INTEL.COM > Betreff: H.450 - "Loose" specification of SyntaxList in X.681? > > Dear experts, > > since H.450 heavily relies on Information Object Classes and since > the H.450 supplementary services use the user-friendly syntax, I > have a question relating to the syntax of the specification of this > syntax. > > X.681 defines SyntaxList as: > > SyntaxList ::= "{" TokenOrGroupSpec empty + "}" > > Other definitions from X.681, that "complete" this specification, > are: > > TokenOrGroupSpec ::= RequiredToken | OptionalGroup > OptionalGroup ::= "[" TokenOrGroupSpec empty + "]" > RequiredToken ::= Literal | PrimitiveFieldName > Literal ::= word | "," > > For "required" fields from the class, the "syntax list" would > usually contain phrases consisting of some uppercase description > consisting of one or more words (separated by spaces),followed by > one of the fields from the class, etc. > > Obviously, this is covered by the above BNF of X.681, but (as an > example) "RETURN ,, &ResultType RESULT" would be just as valid as > "RETURN RESULT &ResultType" with this definition. > > Do I interpret the BNF wrongly, or is this indeed the case? > > Regards, > > Frank > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 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