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

Latest draft H.245
by OKUBO Sakae 09 May '01

09 May '01

Dear SG16 experts, The following draft by Mr. Mike Nilsson, Editor, is now available for your review toward the Porto Seguro meeting: http://standard.pictel.com/ftp/avc-site/0105_Por/h245wcmp.zip Best regards, OKUBO Sakae ********************************************************* Global Information and Telecommunication Institute (GITI) Waseda University 29-7 Waseda University Bldg. 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan e-mail: okubo(a)giti.waseda.ac.jp Tel: +81 3 3204 8194 Fax: +81 3 5286 3832 ********************************************************* My contract with TAO finished on 31 March. Please change my e-mail address as above, though okubo(a)giti.or.jp will continue to work for some time. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 3

H.248 Implementors' Guide Additions V5 Update
by Christian Groves 07 May '01

07 May '01

G'Day all, I have come up with an interim version of the H.248 Implementors' Guide Additions v5. It contains additional correction to ones reviewed at the SG16 Launceston meeting. It can be found at: ftp://standard.pictel.com/avc-site/Incoming/ filenames: TD-xxx_H248_Implementors_Additions_v5.doc TD-xxx_H248_Implementors_Additions_v5.pdf Please check it for correctness and that it contains the points discussed on the list. There were also some corrections added that were not discussed on the list. If you have an issue please propose a solution giving the wording that you would like to see. As mentioned in the introduction this document is liable to change until final approval. v4 was my own edition and was not published to any external network/list so please don't look for it. Let the editor bashing begin. Cheers, Christian

5 6

Emergency Services and Service classes
by Gary Thom 03 May '01

03 May '01

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 1

Re: Latest H.245
by OKUBO Sakae 30 Apr '01

30 Apr '01

Dear Mike and all, >Dear Mr Bigi, > >Please find attached text for H.245 version 8. Please enter this as a WP2TD. > >As usual the zip file contains clean text, full delta document and minimal >delta document. Changes are relative to version 7. > >Best regards The file H245_P.zip has been placed at the 0105_Por directory. Best regards, Sakae OKUBO ********************************************************** Global Information and Telecommunication Institute (GITI) Waseda University Waseda University Bldg. 29-7 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan e-mail: okubo(a)giti.waseda.ac.jp Tel: +81 3 3204 8194 Fax: +81 3 5286 3832 ********************************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Binary Encoding of H.245 Related Properties given in Table C/ H.248
by Tom-PT Taylor 30 Apr '01

30 Apr '01

H.248 Annex C uses BER. > -----Original Message----- > From: Muhammad Mukarram Bin Tariq [mailto:mmukarrams@YAHOO.COM] > Sent: Monday, April 16, 2001 6:53 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Binary Encoding of H.245 Related Properties given in Table > C/H.248 > > > Dear All, > > My question is regarding the encoding of the H.245 related > properties listed in > Table C/H.248. I presume that all these property values are > encoded according > to PER. Also that the entire MultimediaSystemControlPDU is > encoded, instead of > just the message structure. e.g to encode an OLC, we should > encode the entire > MultimediaSystemControlPDU that contains the OLC message, or > just the OLC > message structure. > > I am asking this question because in the presence of "Tags" > it is quite > possible to live without encoding the entire > MultimediaSystemControlPDU. > > Regards, > > Muhammad Mukarram Bin Tariq > > > > __________________________________________________ > Do You Yahoo!? > Get email at your own domain with Yahoo! Mail. > http://personal.mail.yahoo.com/ > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com >

3 2

Re: FW: Emergency Services and Service classes
by Folts, Harold 30 Apr '01

30 Apr '01

Ken, Many thanks for your comments. I think that they are very important to be inclusive of the many considerations for emergency communications including 911/999/211 calls as well MLPP (preemption). I am also sending this to the SG16 experts list as there has been quite a bit of discussion to Gary's Email there. Hal > -----Original Message----- > From: Ken Carlberg [mailto:K.Carlberg@cs.ucl.ac.uk] > Sent: Thursday, April 26, 2001 5:20 AM > To: Folts, Harold > Cc: Gary Thom (E-mail) > Subject: Re: FW: Emergency Services and Service classes > > > > Hello, > > My apologies for the tardiness of this response. In looking at Gary's > original message, I thought I might chime in and introduce some food > for thought. > > in Gary's message, he suggested the following: > > > 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 > > } > > } > > I was thinking that it may be better to add another value in the > 'priority' field in order to distinguish 'authorized' emergency calls > like GETS, versus generic emergency calls like 911 that would be used > by the general public and not require special PIN numbers, or other > additional measures to denote authentication and authorization. > > so, perhaps one might have something like: > > > priority CHOICE > > { > > authorized-emergency, > > emergency, > > high, > > normal, > > low > > } > > also, would it be of value to have a separate field that distinguishes > "classification" of priority? For instance, the above would be the > generic > type used for global/national PSTN. But there is also the MLPP (from > ANSII?) that has 5 levels of priority, but is not used in the > PSTN, but > rather private voice nets like Autovon. > > My feeling is that having a separate field that differentiates normal > PSTN versus private-MLPP may be helpful and less confusing than having > a single "priority" field that covers all defined values of priority. > > However, if you think this may be too cumbersome, then maybe we should > look into adding 5 additional values that relate directly to MLPP, > thus having a field of 10 values in the above. > > For the following... > > > 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. > > I was wondering if it might be better to start off by saying that > the values in the priority field denote a "distinction" of the types > of calls that can be made. The reason I state this is that there may > be cases where traffic engineering separates the routes that calls > make, but does not place any additional resources per type. This > line of thinking would reflect the cases where preemption is not used, > but rather higher probability is. > > After stating the point on distinction, then one could talk about > the allocation of resource with respect to preemption and quality, > on which you talk about next. > > > > quality CHOICE ;per TIPHON definition > > { > > best, > > high, > > medium, > > bestEffort > > } > > for the above, you may want to inc;ude a value called > "BelowBestEffort". > I have a paper that makes an arguement for doing this at times, and I > have recently come across others that are trying to promote this. In > addition, it may correlate nicely to the above priority of "low". It > may also correlate to the drop precedence field in IP packets (for > diff-serv) when a flow/call exceeds the traffic rate originally > negotiated for it. > > regards, > > -ken > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: version
by Al Varney 27 Apr '01

27 Apr '01

1 0

Re: version
by Michael Brown 27 Apr '01

27 Apr '01

Based on the date on the download page at the ITU site, the English version was posted Feb 8, 2001. They have PDF, Word and zipped Word files. For those interested, the French and Spanish versions are also available at that site. The cost shown for the document is 55 Swiss Francs. -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] Sent: Friday, April 27, 2001 10:51 AM To: Brown, Michael [NC1:GW10:EXCH]; megaco(a)fore.com Cc: ITU-SG16(a)mailbag.cps.intel.com Subject: RE: version Really? When did that happen? Brian -----Original Message----- From: Michael Brown [mailto:C.Michael.Brown@nortelnetworks.com] Sent: Friday, April 27, 2001 9:55 AM To: megaco(a)fore.com Subject: RE: version Actually, I was looking at the ITU web site and noticed that H.248 has now been published. -----Original Message----- From: Rosen, Brian [ mailto:Brian.Rosen@marconi.com <mailto:Brian.Rosen@marconi.com> ] Sent: Friday, April 27, 2001 8:51 AM To: 'mu lj'; megaco(a)fore.com Subject: RE: version RFC3015 is the only "official" released version of Megaco/H.248, and is called "Version 1". Recommendation H.248 has not yet emerged from the publication queue at ITU, but is identical (except for boilerplate) to RFC3015. Brian > -----Original Message----- > From: mu lj [ mailto:dtxlymlj@hotmail.com <mailto:dtxlymlj@hotmail.com> ] > Sent: Friday, April 27, 2001 5:22 AM > To: megaco(a)fore.com > Subject: version > > > hi > which h.248's version refer to rfc3015. > which's h.248's version now. > > Regards > Lingjiang Mu > ______________________________________________________________ > ___________ > Get Your Private, Free E-mail from MSN Hotmail at > http://www.hotmail.com <http://www.hotmail.com> . >

1 0

Re: version
by Rosen, Brian 27 Apr '01

27 Apr '01

Really? When did that happen? Brian -----Original Message----- From: Michael Brown [mailto:C.Michael.Brown@nortelnetworks.com] Sent: Friday, April 27, 2001 9:55 AM To: megaco(a)fore.com Subject: RE: version Actually, I was looking at the ITU web site and noticed that H.248 has now been published. -----Original Message----- From: Rosen, Brian [ mailto:Brian.Rosen@marconi.com <mailto:Brian.Rosen@marconi.com> ] Sent: Friday, April 27, 2001 8:51 AM To: 'mu lj'; megaco(a)fore.com Subject: RE: version RFC3015 is the only "official" released version of Megaco/H.248, and is called "Version 1". Recommendation H.248 has not yet emerged from the publication queue at ITU, but is identical (except for boilerplate) to RFC3015. Brian > -----Original Message----- > From: mu lj [ mailto:dtxlymlj@hotmail.com <mailto:dtxlymlj@hotmail.com> ] > Sent: Friday, April 27, 2001 5:22 AM > To: megaco(a)fore.com > Subject: version > > > hi > which h.248's version refer to rfc3015. > which's h.248's version now. > > Regards > Lingjiang Mu > ______________________________________________________________ > ___________ > Get Your Private, Free E-mail from MSN Hotmail at > http://www.hotmail.com <http://www.hotmail.com> . >

1 0

AW: B.3.1/H.245v8 - Error in the description of the encryptionSyn c field
by Euchner Martin 27 Apr '01

27 Apr '01

Frank, below is the full text what H.245 Section B.3.1 says about the encryptionSync field: The encryptionSync field shall be used by the master when acknowledging the opening of a channel by a slave. It is used to provide the encryption key value and the synchronization point at which the key should be used. For H.323, the syncFlag shall be set to the RTP dynamic payload number which matches the key. H.235 Section 8.5 describes the use and purpose of encryptionSync: During the protocol exchange that establishes the logical channel, the encryption key shall be passed from the master to the slave (regardless of who initiated the OpenLogicalChannel). For media channels opened by an endpoint (other than the master), the master shall return the initial encryption key and the initial synchronization point in the OpenLogicalChannelAck (in the encryptionSync field). For media channels opened by the master, the OpenLogicalChannel shall include the initial encryption key and the synchronization point in the encryptionSync field. My understanding is that encryptionSync is part of the OLC-Ack message. As such, encryptionSync implicitly acknowledges the OpenLogicalChannel, although of course actually the OpenLogicalChannelAck is intended to explicitly acknowledge the OpenLogicalChannel. Thus, I do not really see an error. Does this answer your question? Do you see need for further clarification of either passage? Kind Regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 722 55790 | Martin Euchner Fax : +49 89 722 46841 | Siemens AG | ICN M NT 5 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://intranet.icn.siemens.de/marketing/network_technology/security/pki.htm | D-81359 Muenchen Internet: http://www.siemens.de <http://www.siemens.de> | __________________ | Germany ----------------------------------------------------------------------- -----Ursprüngliche Nachricht----- Von: Frank Derks [SMTP:frank.derks@PHILIPS.COM] Gesendet am: Freitag, 27. April 2001 10:44 An: ITU-SG16(a)mailbag.cps.INTEL.COM Betreff: B.3.1/H.245v8 - Error in the description of the encryptionSync field B.3.1/H.245 describes the use of fields in the openLogicalChannel message. The text about the encryptionSync field looks like a literal copy of the corresponding text for the OpenLogicalChannelAck message. This would not seem to be correct, because it talks about the acknowledgement of the opening of a channel by the slave. Shouldn't the text read: "The encryptionSync field is (shall?) used by the master to provide the ebcryption key value and the synchronization point at which the key should be used. ....." 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

B.3.1/H.245v8 - Error in the description of the encryptionSync field
by Frank Derks 27 Apr '01

27 Apr '01

B.3.1/H.245 describes the use of fields in the openLogicalChannel message. The text about the encryptionSync field looks like a literal copy of the corresponding text for the OpenLogicalChannelAck message. This would not seem to be correct, because it talks about the acknowledgement of the opening of a channel by the slave. Shouldn't the text read: "The encryptionSync field is (shall?) used by the master to provide the ebcryption key value and the synchronization point at which the key should be used. ....." Regards, Frank ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Two documents at /0105_Por
by OKUBO Sakae 26 Apr '01

26 Apr '01

Dear Mr. Sayre, > > 2) WhitePaperMMGateway.zip -- "Multimedia Support Using the > > Decomposed $B!! (BGateway Architecture" by Mr. Clifford Sayre et al > >I just wanted to clarify the status and intent of item #2. I do intend to >present this document at the Porto Seguro meeting. It will be a Delay >Contribution with a source of Lucent Tech. Lucent needs to have this >approved by the US government process (SGD) for approving company >contributions to ITU SG 16 meetings and I am working this process in >conjunction with Terry Anderson (the lead Lucent delegate). > >The purpose of the document is to answer some delegate questions and >issues raised in the Launceston meeting on contribution AVD-2057. Thus it >is for discussion and the text will not go directly into the draft H.248 >annex that I am working on. Sorry about using the term "white paper". I >realized after reading your email that the term white paper has had a >different meaning in the context of SG 16 documents. Thank you for your clarification. When your delayed contribution is provided, I will replace WhitePaperMMGateway.zip with that. Best regards, OKUBO Sakae ********************************************************* Global Information and Telecommunication Institute (GITI) Waseda University 29-7 Waseda University Bldg. 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan e-mail: okubo(a)giti.waseda.ac.jp Tel: +81 3 3204 8194 Fax: +81 3 5286 3832 ********************************************************* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

silenceSuppression in h2250LogicalChannelParameters
by Frank Derks 25 Apr '01

25 Apr '01

Can any one explain what the meaning of the silenceSuppression element in h2250LogicalChannelParameters is? If set to TRUE, does this indicate that silence suppression is supported on the channel, but that this is actually dependent on the support of this functionality by the codec? So why duplicate the information? Regards, Frank ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

potential change to SCTP
by Glen Freundlich 25 Apr '01

25 Apr '01

Dear Colleagues, There are apparently are some problems with the checksum mechanism defined in SCTP. If a new mechanism is deemed necessary, a new RFC could be issued and it would likely not be backward compatible with RFC 2960. This may effect any work in SG16 that references SCTP. Discussions of SCTP are taking place over either the sigtran mailing list or the tsv mailing list. Check the IETF site to find contact info on these working groups. Regards, Glen

1 0

Message from Mr. Bigi
by OKUBO Sakae 25 Apr '01

25 Apr '01

Dear SG16 experts, We have been advised as follows: >Dear Colleagues, > >I am leaving for Study Group 13 meeting in Caracas on 11 May. I would >appreciate if you could send your documents, if possible, by 10 May. I >would also be thankful if you could let the editors and other participants >know. > >Best regards > >Fabio Bigi >TSB, Senior Counsellor Your kind cooperation is requested. Best regards, OKUBO Sakae ********************************************************* Global Information and Telecommunication Institute (GITI) Waseda University 29-7 Waseda University Bldg. 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan e-mail: okubo(a)giti.waseda.ac.jp Tel: +81 3 3204 8194 Fax: +81 3 5286 3832 ********************************************************* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: H.MMS.3: Presence and IM for H.323 Mobile systems.
by SAMOU Jean-claude FTRD/DAC/ISS 24 Apr '01

24 Apr '01

Hi, Folks: I fully support what Roy is saying here. I assume that H.MMS.3 as well as H.MMS.2 will be based on H.MMS.1 protocol extensions. My understanding is that this 'new' H.MMS.1 protocol should be designed in a way that it is applicable not only to H.323 but to other applications protocols (e.g., H.234, H.310) as well. This will give more flexibility since it will not be specific to a particular application (i.e. no need of having a specific mobility management protocol for H.323, another one for H.324, etc.). Therefore, this 'new' protocol should be made independent as much as possible of others and not be called as H.225.0 annex G or its extension. Please also see an earlier message sent by François Bougant which gives more clarification on these issues. I appreciate this good start of Q5/16 work. Best regards, Jean-Claude Samou FTR&D -----Message d'origine----- De: Roy, Radhika R, ALCOO [mailto:rrroy@ATT.COM] Date: mardi 17 avril 2001 15:25 À: ITU-SG16(a)MAILBAG.INTEL.COM Objet: Re: H.MMS.3: Presence and IM for H.323 Mobile systems. Hi, Manoj: I am providing a very quick comment. It is a good proposal and you are assuming that H.MMS.1 will be the base protocol to be used. With respect to H.MMS.1 protocol, I like to mention that the mobility management part of H.MMS.1 will be "called" a NEW protocol and will NOT be called as "H.225.0 Annex G or its extension." Based on this assumption, probably you can start your work. As time goes on, more comments will be provided. I appreciate your work. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Paul, Manoj [mailto:mpaul@TRILLIUM.COM] Sent: Monday, April 16, 2001 10:28 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: H.MMS.3: Presence and IM for H.323 Mobile systems. Hi All, The purpose of this mail is to initiate work on H.MMS.3 standard, which is a part of H.MMS series for H.323 mobility systems. H.MMS.3 will address Presence and Instant Messaging services in H.323 Mobility multimedia systems. H.MMS.3 standard shall address the architecture, procedures and new message/ information elements to enable H.323 as the transport protocol for Presence and Instant Messaging in mobile environment. As editor of H.MMS.3 document, I solicit contributions and discussions to begin work in this area. Enclosed is the Scope and Terms of Reference document that was presented in SG16 Launceston meeting for H.MMS.3. thanks Manoj Paul. Trillium Digital Systems, (an Intel company). ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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: H.MMS.3: Presence and IM for H.323 Mobile systems.
by Paul, Manoj 22 Apr '01

22 Apr '01

Hi Chern, According to my understanding, when you say "Context Transfer", it refers to some protocol having procedures and methods to trasfer the "Context". And in IM and Presence, this context is the relevant IM and Presence information. Is that understanding correct? If yes, then the H.MMS.3 will define the methods and procedures in H.323 protocol to enable H.323 to act as a "Context Transfer" protocol.(Like SIP defines new methods SUBSCRIBE etc. to act as transport protocol for IM and Presence). I think the concept of IM and Presence shall be derived from IETF IMPP, but work needs to be done to define their mapping in context of H.323 signalling. Could you elaborate when you said "Hopefully some meaningful protocol name would be link to it.Example (M.RCTP - Robust Context Transfer Protocol)". thanks Manoj. -----Original Message----- From: cny [mailto:cny@DCS.SHEF.AC.UK] Sent: Saturday, April 21, 2001 12:58 PM To: ITU-SG16(a)mailbag.cps.INTEL.COM Subject: Re: H.MMS.3: Presence and IM for H.323 Mobile systems. Hi all, May I know how much this thing will link to IETF BXXP (Blocks Extensible Exchange Protocol), and IETF IMPP (Instant Messaging and Presence Protocol) ????? As for the new protocol mentioned below, I suppose what is normally involved is known as Context Transfer, Hopefully some meaningful protocol name would be link to it. Example (M.RCTP - Robust Context Transfer Protocol) When is the dead line for the Brazil Meeting, I am still rushing out some spec of this new protocol. Cheers Chern Nam Yap ----- Original Message ----- From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM> To: <ITU-SG16(a)mailbag.cps.intel.com> Sent: Tuesday, April 17, 2001 3:24 PM Subject: Re: H.MMS.3: Presence and IM for H.323 Mobile systems. > Hi, Manoj: > > I am providing a very quick comment. It is a good proposal and you are > assuming that H.MMS.1 will be the base protocol to be used. > > With respect to H.MMS.1 protocol, I like to mention that the mobility > management part of H.MMS.1 will be "called" a NEW protocol and will NOT be > called as "H.225.0 Annex G or its extension." > > Based on this assumption, probably you can start your work. > > As time goes on, more comments will be provided. > > I appreciate your work. > > Best regards, > Radhika R. Roy > AT&T > > -----Original Message----- > From: Paul, Manoj [mailto:mpaul@TRILLIUM.COM] > Sent: Monday, April 16, 2001 10:28 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: H.MMS.3: Presence and IM for H.323 Mobile systems. > > > Hi All, > The purpose of this mail is to initiate work on H.MMS.3 standard, which > is > a part of H.MMS series for H.323 mobility systems. H.MMS.3 will address > Presence > and Instant Messaging services in H.323 Mobility multimedia systems. > H.MMS.3 standard shall address the architecture, procedures and new > message/ > information elements to enable H.323 as the transport protocol for Presence > and > Instant Messaging in mobile environment. > As editor of H.MMS.3 document, I solicit contributions and discussions > to > begin work in this area. Enclosed is the Scope and Terms of Reference > document > that was presented in SG16 Launceston meeting for H.MMS.3. > > thanks > Manoj Paul. > Trillium Digital Systems, (an Intel company). > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 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

Two documents at /0105_Por
by OKUBO Sakae 21 Apr '01

21 Apr '01

Dear SG16 experts, I have placed the following two documents at the Porto Seguro meeting directory http://standard.pictel.com/ftp/avc-site/0105_Por/, 1) H323_AnnexQ.zip -- Draft H.323 Annex Q "Far End Camera Control and H.281 / H.224" by Editor Roni Even 2) WhitePaperMMGateway.zip -- "Multimedia Support Using the Decomposed Gateway Architecture" by Mr. Clifford Sayre et al I wonder if 2) has been, or will be submitted for the Porto Seguro meeting as "white contribution" or is an informational document for the study of experts on the mailing list. For safety, I have dealt it as above. Best regards, OKUBO Sakae ********************************************************* Global Information and Telecommunication Institute (GITI) Waseda University 29-7 Waseda University Bldg. 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan e-mail: okubo(a)giti.waseda.ac.jp Tel: +81 3 3204 8194 Fax: +81 3 5286 3832 ********************************************************* My contract with TAO finished on 31 March. Please change my e-mail address as above, though okubo(a)giti.or.jp will continue to work for some time. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: H.MMS.3: Presence and IM for H.323 Mobile systems.
by Roy, Radhika R, ALCOO 21 Apr '01

21 Apr '01

Hi, Manoj: I am providing a very quick comment. It is a good proposal and you are assuming that H.MMS.1 will be the base protocol to be used. With respect to H.MMS.1 protocol, I like to mention that the mobility management part of H.MMS.1 will be "called" a NEW protocol and will NOT be called as "H.225.0 Annex G or its extension." Based on this assumption, probably you can start your work. As time goes on, more comments will be provided. I appreciate your work. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Paul, Manoj [mailto:mpaul@TRILLIUM.COM] Sent: Monday, April 16, 2001 10:28 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: H.MMS.3: Presence and IM for H.323 Mobile systems. Hi All, The purpose of this mail is to initiate work on H.MMS.3 standard, which is a part of H.MMS series for H.323 mobility systems. H.MMS.3 will address Presence and Instant Messaging services in H.323 Mobility multimedia systems. H.MMS.3 standard shall address the architecture, procedures and new message/ information elements to enable H.323 as the transport protocol for Presence and Instant Messaging in mobile environment. As editor of H.MMS.3 document, I solicit contributions and discussions to begin work in this area. Enclosed is the Scope and Terms of Reference document that was presented in SG16 Launceston meeting for H.MMS.3. thanks Manoj Paul. Trillium Digital Systems, (an Intel company). ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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

Architectures for Multimedia Gateways
by Sayre, Clifford L, III (Clifford) 20 Apr '01

20 Apr '01

Dear SG 16 Experts, At the Launceston meeting two contributions, AVD-2057 & AVD-2056, were presented proposing enhancements to support interworking for H.324 Annex C terminals and multimedia gateways. AVD-2057 describes several H.248 packages that can be used in a decomposed gateway with an MGC and MG to support this type of multimedia interworking. The delegates in Launceston requested additional information on the background behind these packages; consequently, we have prepared the attached white paper. The white paper describes some of the issues behind supporting multimedia interworking gateways for H.324 & H.323 and thus the rationale for the work behind AVD-2057. <<WhitePaperMultimediaGateways.zip>> Comments are welcome. The co-authors of the white paper are listed on the footer of the paper. Regards, Cliff Sayre Clifford Sayre Lucent Technologies Phone (732) 332-6060 clsayre(a)lucent.com

1 0

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

H.450 - "Loose" specification of SyntaxList in X.681?
by Frank Derks 19 Apr '01

19 Apr '01

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

1 0

AW: Emergency Services and Service classes
by Horvath Ernst 19 Apr '01

19 Apr '01

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

1 0

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

18 Apr '01

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

1 0

Re: Emergency Services and Service classes
by Tom-PT Taylor 18 Apr '01

18 Apr '01

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] > 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] > 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 >

1 0

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

18 Apr '01

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

1 0

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

18 Apr '01

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

1 0

H.MMS.2: Global Mobility Management Interoperability between H.32 3 and mobile networks.
by BOUGANT Fran�ois FTRD/DAC/ISS 17 Apr '01

17 Apr '01

Dear experts, The purpose of this mail is to initiate also work on H.MMS.2 standard, which is a part of H.MMS series for H.323 mobility systems. H.MMS.2 introduces new functionalities (interfaces, protocol and user data) for user, terminal, service, and service provider global mobility management interoperability between H.323 systems and mobile systems. The concept of global mobility is defined here as the ability for a H.323 mobile user to access and manage services in a foreign mobile network with any terminal and a foreign user to access and manage services in a H.323 network with any H.323 terminal. As editor of H.MMS.2 document, I solicit you to make discussions in this area and bring contributions for the upcoming SG16 meeting. Please find enclosed the H.MMS.2 scope and terms of reference document presented in SG16 Launceston meeting. Best regards. Francois Bougant France Télécom R&D 38, 40 rue du Général Leclerc 92794 Issy Moulineaux Cedex 9 FRANCE Phone : (33) 1 45 29 51 84 Fax : (33) 1 46 29 31 42

1 0

None
by Venkata Subba Rao Manne 17 Apr '01

17 Apr '01

Hi, where can I get the timer values of h.245( T103, T102 etc...). I couldn't get these values from either h.323 spec. or h.245 spec. any kind of help will be appreciated. thanks. mvsr

1 0

H.MMS.3: Presence and IM for H.323 Mobile systems.
by Paul, Manoj 16 Apr '01

16 Apr '01

Hi All, The purpose of this mail is to initiate work on H.MMS.3 standard, which is a part of H.MMS series for H.323 mobility systems. H.MMS.3 will address Presence and Instant Messaging services in H.323 Mobility multimedia systems. H.MMS.3 standard shall address the architecture, procedures and new message/ information elements to enable H.323 as the transport protocol for Presence and Instant Messaging in mobile environment. As editor of H.MMS.3 document, I solicit contributions and discussions to begin work in this area. Enclosed is the Scope and Terms of Reference document that was presented in SG16 Launceston meeting for H.MMS.3. thanks Manoj Paul. Trillium Digital Systems, (an Intel company). begin 600 TD-59a.zip M4$L#!!0````(`*.^9RJ0D?@>_R8```#"```*````5$0M-3EA+F1O8^Q<:Y`< MU74^O>^5U))66A18\VA`*)BL%B20`!6FA%[HO4*[PMC!0KTS/3NM[9D>^K&K MP?PA5CE`4HE#JE+825R`94CBE(L\_"./`D$28I(89!L<$[L2P)2<V`F%2>R` M`6V^<^[MGNZ9621(*E6V]^(SW;?[WG//^YQ[>ZT3SPZ\^.`?#;U$3>UZZJ13 ML_W4DWEF`&Y-.DN)#NIGIV9G9_G1+P)FY]M/5/OWSS]!5UO]741O+'L\U2P: MGIRZF&@Q31R>.'Q@Q8$5U-+ZNU;015<177VG@D]>0#33.BQML[-+3GN?-$]^ M_[J/TBO#`MP_@^LB7/])O\M>!S,87M7/;UXZ]Y7''\9U96;\*[N(UL*L/Z/' M9:\LA$=U/[G^^D#[:P%X.G!U=JG^F5R9CA5[B"Q,7#^*-=&_!\_/HM:6\)VL MU]Q^94"4."=]]^AU/Z&%UBS/A+^D<?];N'YVEY)#,J_YROB_W09/<[^@UT_: M)[+*>P\M*V]NC.=$=P/?V!#17LCS+VXD^CVCE<_WVT;U>@D_O[94V>4#.S<] M<^R1XP;;4[FW86]3RXC@)%38071%$QXF]4]WJ>>O:+R_B7%_"7I/C*K^=S'_ M=S+]T2;])?;[:A-_<UT[Z`7\[A@_8*VVQAW/*?B52EQU"W;D^E5K++*K13LH MNG?HOE.(_,!*VA:_$%><:F2-;UF][EK;'!L_L.4CUHW[1P_LL]:L-V\:V3)L M;1NV;ARVUJY>=_F:]=9^NU;S@\B)`VN/XT1N==(T=]MQM>"$D5\=MM99OV5= M:^VQ@T+96GO%%6M,<VSTP/[-6R_KV-"_M>AB;=,<WS&^>^N&_NTC>_:,C5QI M66,%O^98H!/T!Y70\DO6?J?D!`ZPFOL.[-\W.H;A^P*_YH>V9][6TDS3O&$B MC`*[$&TPQ\MN:!43O@I^-;+=:FC95DT0.,5W7<\J03J:LI'DQ@K+MN=91:?D M5AUK7^"$,I0Q[*B&D'`$882A/0EQ6`6[9D^XGANY3BC8*CZZ#G!=N1:8ZF'D M\)K33F#5[,*4$UD3-E-5=:(9?RH<,7/MAB@"&]#<!DL8P_^J?H2E+=9X+9[P M$DU7[")(FK9=SY[`<I%O165'CQBV)F*9Y%8C)ZC:GLQ.E<]/JT70X%>]NM`< MAXXU41<,>YS*!&B%(46.R(H?\G1F'V/<*$RL2@T-Y0U&N8$%4=7PSIUV+,BI M5))7!=\#C7Y@8PXXJNJQC#-P/"Q3M&;\8&K$VA%IR3/+$TXKB\."+V;Q3=2Y M4[=\((-D088/K8,H%I_H8L:-RC[$(&()7+R:"5P6+QM)R')H,#=B+A(K@36! M<K$7O$S,`4J`>.UB$>R%,D64%TQ9;/=N!([C0%00QN(NI[.92W?L^2`+HIVI MB!AF7$C!+3(O):46YP@H#UUF$NLHRM98EZJI>WRQP/H'V>@C'P+G015[RFEO MC7GR]B(a);]IS&TK87-C,,F;.EL,RKSHSE^9.P1$\PE!`/V";13:4/[M2:FH!$ M8ADA`2_,KN38+#UVA'&G4*X*UAUA&#NA^6&H4-E+JU*&^3&D;K/DTXFN3$RY M?V_LFV-`H9RYGKUG`["M`JQ'UICT\<.R:,:C&1NQQL7D?`3)D-7-KRNI\CW? M9L]37#G!-'N0YU;<2/.9+CNB0H",+\"9X1&WQS`D]P[H@L621+,PG@A!74WB M`B\&_W%+2:!(UFNF=DRM/0*[+)3MJAL"F:@9PL-2VOI<]8#)<K0KS<%7$R%A M"R5XDBA=\9U:BY)8:N)6)0XE`&C%,.J*RCY96V/\<'QHHF(S7X%S>^P&#H<X M+*7M-I9HQ@BREN"H,-*(7<@@%<D;;K40.`C0,,<;"LRHM1DI)?"]IBX(2J6F M@A;`GTF64<@AN((>+KK-ZLFM"N'ZOJ',F;(OVM:#)Y2^9LJ07=&.[,020L>I MZC=.51P7IC+I5)T`=""H.Q[+&I/>C6P_]HJL:)DB2&MV(`&Y%/@5H3E&H@B\ M.HN^EAA0$F2&+9A!0<RB+GX(Y11MEK\@M*T9N\XR`*M>K&;ZR$YU9-:"*[%L MQ!J+43DT/U:1'\DFM5EMK`GW6JJ><H0*!Z6B6Y*<'O&JC%CQPN*%5)ND(.RU M\,,WTQ`'\KCG''&U\XN5^\78LP-Q2B7J,)(076&'Y^#./A+%Q;HUC6%^#-W7 M:RI_VFII37*HM*+YT`L6D_2=,U(V"1>&KE*9<CX?GL<>T5#CB+E7A]9QU#L( MR_7T0:0?))H6CPJ<4LS:X22(I0.G*"Q5;+&`JL/$VH'6&R@NQI"0U!$5I^C" M.-)0CN)3^9KG3@DK1]Q,Z$U5IR*:I^Q8$DM)TG1Q-3O)?>R"?K5>4;)ENX=! M%."!X7`^\:FHH+R,?311[>F"SK1K*Z0-)@*).=M`QHX]P]G4F@2>I*0*G9;\ MC5"!(%.(($+,!_*19L0FRJ.8;<54IH+1_F15HK;H/M2O55J!6<-HW"A)7LJ@ MI]CAWEON'D6M:DOY)5+)+%+1A&-:4&]D"3N&?*N1%I2*P7-@;XZ>.LFKP)>1 M5P:ERA;@W4$UF.0)Y\RR#=0A!15+2VI4T3K>P:5EX8+8,XQ`!>\4N91O">>9 M4*=-AXL:L1\.&`7/=93C<O6KT-BJO-+KPRY7%_P@B$5FP]*O>79]`G6\RCZ! M.VT7ZJK<ULE111)9D,M8G904+RPMM6R8+!HFR^K7D5MA$TKUL$V2A+E9>ZNN M_;693D*T52:X;*/B!@8/J8M%QA&R4L'(-,:I9(-LX<(3>*%TA;8J;L0>CE22 M!-@)BCI@VW/A3U)AZ&?-`OO3VV,'>LR5M(J"B%6%I!<Z#62YW,@.)'O0EL7U MF@WE3J3A(K%'T3;FZZ6X:"EB6ZH*B,PRPRI$H&I(B4CVE&(1I3B`)94AI$!D M6T."R,X?,>=REH8DE6P:LAQF5T=L0NV'W,)9#-E[V&JK1]XS)OQR^&R*26$J MFD3/G)T2_TJE/N'K/,)QS0G2XB?=$,)=W1K;9S,^$2_C"U5B*'AQ,?%PE._5 M=+/`Q&4</^#AD+]73$I'DDZ0]3G`AZX%">)#YL9P\3F2I>9C$('*O-,(HA2 M?%N#4L,9.8;*?K)65)M0A"YH`6$V(a)-AKB!!89C*SDRRX`4QB.C$DE=>#V'-D MXYD/IY=G@FTV6>]K%*PZ/61V%ID*ELF4/*9$2%%[X;F8BPM&E$J!7;-+7IU MSF\%IQ8I]M)2C2D-V"6!BCF2+76.IR1!YDXX5$Z.`D0LV<,ATS0I,`U.85Q" M$F9CPBI"3$,Q;"6P[!(73^PQ*$:XO+.37>21A%_.9&5>J)(8NFFJHRQ5$:[V MF%YL#55D#&4#GTJG43NDI@O"5''GY3;LC62@[TY758@-5_UD)Z.B-XC;[W!@ M!]E8(XQ4V9SD!+%GI'LA,I.=HG?;J]<:[J"BBR[F;!<%NC]C!T4.D*M/O^HP MZNN:Y]>=H@0P!!?$-HY!I0`V'\3J$(,YY7V&%(5VK>;8,*4J;]%M.500D291 M(S=3CF58L6X5II*69_GS26`H@D*8:-Q^0"CG3B)(STWVXKG=H8HQL$LQM"04 M9?<UOLZV2;S1Q;;R%3[V*EE2$K*MHQB&7#Q7RC!^46TQ:)_/M6QUOE2R2K;K M@=TS*&3$X4H<^QLK,'MQ>JPW5?5GD#H0\K"G+O(IB#+NQK8G:X7F#1G_5A&> MM9[;5=923&IYEU-!6%9UN8[)R'+U:J$<^%7>IS3MT"<XT$E$2+:3.C2H:.U/ M'$:!F:0;/2[9E.5CE&@R.6-3\X8M?8*DD/$628QV6F><1O!JJ2PY-#IALU]R M0+&2Y![5[PO;1L9A62$-(a))D)K(C1.%)FB&UK`60TE)&O+/()INCPL9_"F26! M.<QHJ8R*8I+SN)]?I9'E=OO^5%P3O]N;586YHY2IDO06V,654>:E(.=RV9,' MR&$.0:B,#^=HFT&T!H?S.2;4"XLTM"5CO=PA$T<&!)HLZU+<<#F+\*]J&]0^ M$JYS*2>O$-X.9G.0:8Z/[S;'Y)BA*20CY(1^*=(18YA-76]BL8-W@\1PIARG MI@GAKJ<<(/0+KDKZ',=SF/4N(K=88P.-[3.(Y=)APBGY4MC#AIPC-5?7YJY2 M6Y)&Y)A`"'+4B53.757,F+8]MPA6MSF15#SI3<Z=W?2,*3U<FG34M@,;'CGY M:*@L\;U4LK+CW>LWNWL@M:"J*5'CBEO.56L(4I!YH)IHF6EM'Y32,2UA27RY MXD\W22*I&]N%'H07%3\X5#8^@9C[,LPEU376S@QI6CBNR6%H)-\?YJJA6FQ? M#DG'R_F!"I5LZ0,_GBQGO\U(?!>]^%Q81RHU1G+P48GYBT>[74::%S-(<]H" M]^DG!//#*O#D2@:VBTRXY^S7+I]QT-3%-\\8SISA9L35B,`UE-Z*?E!=LW61 M(-CUN4H./WMPX#=]*-%R5=FPL<LP>6.+!,YYW1P/['1KEOMVT-A"V1[O^>MS M*%)%`JF<];+)^3J'IZI$!.;X\@2A6B`YY"LPP\@Q&`<95B0GJ1(]%U!J<5A^ MUR)<WCDP[+*N*9H$(8=7F>E*FJ'4J9G:J1C;GOX$@)&Q%X5ZOYA)WFGAJT]B M&Z)(JD<F5LZ-5<6F-(50J9V\\<U37%=_,WT_7YN:/WTEF-<@Z134ADF9A&QE MTYGL]PG5P]D@9ZN]=LV?P8XI9J-!+7?'M'!=$ETY,E-_R`U3%3I._INL1/C6 M+4$SZRV?O'*?$UKV.6!HQ.RP+MNL$OH&LW\/G.JPM<^.O?[^_G''V]#_"VNL M*]=<85UUS1IKW;JU5UO]6U?O0?6XP5IN;?_(OJW[=^_8N\NZJ()'D;^A4L/, MC8@`GN?&E1%4Q1=9QF#KT[-,TZ3Y]K/>NHA&`%<#-@)N!(P!;@9\''`_X#.` M!P$/`3X'^$/`'P/^!/!-P`N`E_COQ0`+NHG^$?!-P,N`E3U$UP%NZB5ZKH_H M><#-_403@.)"HA"P:#'1>8".GR,Z!_!IP&.`E\\F>A7PO7-Q!3Q_'M$_`^X\ MG^A>P)N`[@N(_AM@6$2?O)CHEP%W`^X!/`9X''`2\%W`OP)^#'@+\`Z]^0[] M\#_IU9/?/OGJF_3F<V_2L_3LT_B/GJ3'Z4L"^?^^2%^@A^FS#__VP]1UQ4[0 MM:2C[Z[.PRS$GC[C0)_1KSJXP_NE1*;J\SV>+5O7=]?HS@ZZ"7!KWUT'<:&N MS8QGD8W?RO;^KA!`"S$NZ?2E3Q?CZ:V-%[2\@1MO@!XOTS&+,&91%_6E=YUX MW(NWFW>>2SUJ%'7B2A\BK?-$WW<"/JUU_@6M:];O][5^9P'4K?3\]X!_`'P% M\`S@C:Q=_6#.SK]D.]_(=KZ:[3P[9^?OLIV_RG8>RW:^F.U\?L[.Y]Y'IZ49 M1/UGT8)5M'`;T?)C1VCP&-'20>I<:9A/=1GW=M.2HT0#@(.`0P![I<&RQP#< M]2XC\ZF^SJ'.1<O/7@6SX(D8`;R#U+V<&$7O$%%?>KO\V)=I(T8.I$\6'_WZ M.:N*/089^Y[BO_":[3$,^A@>]F8F?0>FRMU>=(U'+GF2EC$-[#?O,+SSKCS. MMY^JUM5%AM'!?OMLM_J+R:\"O(a);X.N`YP/.`;V3B.<?P6S)Q_&0FEA<6YN-Y MSI3^OSJO9SO/9#M/9SM_F^WD0L;<P[XTYYLS[%!_9Q(?!HZ6C4.`_IS7+T?$ M(,.B;B,91Q>OH)7BTI?(KW+OGY??O0TG'VW<9ES_IL8M+>"%EG3P,IV/=%W5 M\T3O\>/'Y4_WSTIR[^\N(7H8\.(`T6N`^Y83?6N0Z&W`GYU%]#>`MU:@OT+E MZ/LS>?JELQNY^BOG0/*`%P`_!#SQ`:(?9<7P7]G.^WGSOT:0LY)<9^YU_F\[ M_Y'MO#CGL#-I9FI52XZ>Z!@X>L4[!W$]A&O&CEC3AM7&`NELUL]W`/]V;J/. M>NZ\1JWU\?,;]=8;F9KK1YFZZ\N`IP'/62J7W`=X6^<4_O\0Y&3\VD]SY_MS MOCDY9^>5;"<WYSTUUG'7@*X;LKJW6FSD_E/*1NX_16>_I74TWWXFFV'1FD^5 MC0L>/7&Y]>B+'[KPT;[>BP`7?^J![I6`2QX]'8+Y]I/=>&.UY;2C3M-.//V] M^IM__LS`K_X2_0'M^OV%_'][0EU`J"&H0C6R*2:/-E)$`;FX\_`;X\T(%<C' M%4FP"<-5,M.6T1'&;#A#//-MOLVW^3;?YMM\FV_S;;[-M_DVW^;;?&O3!NE" M6D`&-M)+J#-]>@W1QA_,=N"ZB'IH+S;7@6S'^5]EX<W]V<0?KF_;;G1E/UU' M@(^2L='`F(]B9C]M)P>SBL!>I4FR:`WQP8!!/2L-.9%<0,N/O4:#QZZ3CYGG MDWRBMFC7=HN:/I7;>'PK\#+N6]OB7BNX.Q1N(X_;P'O@7J^^@&=0?RS!?B[= M3)U"^<UML5\IV#L5]HX\]@X:4I0/M5(]1#NI2ZC>V1;O58*W2^'MS./MI,6D M/]H#'].XF[H%U^ZVN-:)/KMIP:JN/**NP93[(<TU4[8-NF5LV]IB6R_8>H"M M.X^M6U.U0E&U`E;2*WBN:8OG:L'3"SP]>3P]_*],]<G,Z]O.O$9F]F%F;WYF M;P^M%RYV8];<\KA6YO=C?E]^?M\@,?F)LI2F5M!U=,/&UV<?Q'41K:`MP%;2 M1TX1L.W#?0"8E-\:E?%L&SRCBK?9=HA.+6&:#@'+LISO6/@M8;2#)Q:N+L!# MC^@\]KZ5G>93BZEKJ/&)[OCR8QL->V4G,-D[!]G/^N!G?=?1JHT/D6%<)RLP M#3XP5>77`>;]0CFOXN!I05;H`\=+:>OV'E!^'NQ\F5'#;+/-[''\'A&>KB3^ MGM#9S7_#,,"6ER7M^)*CLS1PU)CEOW8XB/M#N&=:EXILL_1NHE.C!EUD;,** M?;25;H=,;>&?I<<ZXN^3"TE_"3W^Q).,,\_S>L&QUEB/YUVIIOD?JUJN)`?R M>H>.(a)X#\O-TR;Y/!%M)+.[!>":L6`07,MF@PG7UO-UBZMWO@Z/2/#^)Z"-<6 M;+<(M@ZZ1;#=`&Q5D=9VB3Z7TEF,3:*/06V4R?9WA(!U"7M0%C&BSJG1VXT) M@Z//8AJ#EAQ0Z&J[2;3$.N5XL4)1O:CCQ:7'+^QX;MDCEQ@=B>R7Y2@>)@O: M#HQAB>1Y/"8PF4_UD6`Q.*Z/T`%8UEW&B/:GNM`1R$%KE::(_X6CZR\S-EW6 M42L3S<)'3HT^1+]A;(%.^B&/,=C[&KJ-9L3J63\7,J>;+M/^1O`WHJGMKW15 MME-7%1#W&9#F&GCQ0P9+=2%\V:50/&ZO'.Y.:&I7(LJ*=)$WS';2%<GF];53 M^R+'WF[QBP*HNU@\[@,$P^YAVV[!]*)!K1JZ6W`]:=P-7$.T63@,!&-BR1;X M=^28.A#[]L7/-^'9I,B/$.W/Y;_XP:J+CS[0O02@C.(U6E5<U/C3G47RISL/ M=!\$V!B;1N]!X6Y<*/F:,2[^Q#[.<N)(,BT9=C6X:Q=-EAP=ZAPX>O+MY<?V MP6.'.@_AGJVF2[!N!-;;C9>-C2(KI<L1P3>(S,Q_/\!FTEDV3G1<TR6>Q[8V MNK,3.NT4#-<@ZQOTNL%Y8`'BY?^T=^W!=53G_=N[]Z4'UI5L25?"V`IM'4%` MD0%3F?`0-F`[P4:.1'$RQ)9M*6-G9"1L.=B._U`:)W$9F@`!0A)"E=8#I*'4 M39C63#NM4\C$">"XQ31VVC+.8SINDF%NTC*IG[>_WSEG]^Z]=U?WKC#!9/;3 M_+2[9_?[SF//X_O._<[9$36!?U=1GQ*3N8IS5A'GM;*88V^,/5H&)<86NMW# MUZ%:[I#**Z74(J1AUP9K-7_#EJ\AY.Q<_1.HH`P$O)H8FF2Q(X_<[8YA2X`_ M`CXA>C^N+XG>9^T;P-,`=\7B[[AG^2;(0`<*X$7@)>!EX"#P`^`0\"_`OP*O M`(>!5X%_`WX('`%60JU:!1Q&H;T*_!>][1(BZX#U*9$A8`M07XM:"7RU3N0) MX-@%(CG@P0:1?\^(G`:>:Q3Y#G"J"==`VTR11X$O`?\(_'B6R$^`UX&7FY%. MX"CP!O#M5I&?`O]-CTKCK7&X#6D"7@,^T8[R`.X%_@\X`23HO0'\!K!FBQP` MOD</@=EZM[\'@=-`'G@41373V=AL@IA>2+K",WQO#)DUK9"FLA"I@JNYBI"" M'#%I+I?\NQ%27H8M12%\@U99:724A13DW&!7Q]6)?[8;0G]D?\F%D+9$Z3/E M(5*EY'/U3'BNPS.H750GN?"^OME0^@:=D([0(5^6RKD('T+)Y>^].*>+FDK3 ML[RIM#3*GUDPZW<S1*HLYTKOBY*K:7%?[A5I+'ZF+(2[LKIU3%-<>]G3LXA. M`&TFC-ZF]#BDUQGO(1%J+U$Z"V3-,_0:XWZG/<!:@.,]Q_.9JV;EFR=087(] M*HIDCARQM)Z1("P#"($V,^=7&>'>LGPV+Q,3$_(;*BT-$LL]*#Q+Y]*&P08' M#+`<\]`@\5RG"J_)9:2<8E*K^!A+PCR_",<F$VXQ=F2Q7^IR<W#Z3Q;C>E'I M)GF+A1ZW:W!^@VVIN!MS<9,**BND7H">6]"PE>)+)>4SHIL@59T]HI65?P;3 M]X`7$-M!H!ZEF`6N`Y8`GS<NF@=13C\".C&@7V4&^3\!)H%GS"#?"+0B_HOF MZH']"QS0S<">0E934%PU$@:S0T#_)_&%[C!Y^4O@6\"W@9,H!!O%^??&]?A/ MH0!]!3B*]_T:T(=:-`BT(Q^79G4:==JN-.FY<@KHN!>;<AU'F=T+_#GPU\!3 M&'R>!UX&7@&ZD98%<;TL8@7P`O`*\%ZDZRK@%F`Y\#G@8>"[P(&$7N:R&'@. MV`]\!S(a)(+$3TUP.OX;7_%%B,?#T&_!+X%0";16J!M<`&X!Y@)_!AO-,UP&KD M?PWP`/`C5,DA='8G@?^@P@<<0RMZB4H>WN%WC9+V:?,>'S!*VL/`5X$G(a)%.F M[*CXOQU(E5SE\^P&$AX/G_EX5]?(G3`O::;3N-&*_Q;A%`H-`6UJC2O3BY,] M6_!T@?].-7FS!08KC;`Q7`\@Y'(8FJM@TFCC_^V,;_6;CN]&G(\ILWR]9RJE M`Q)YM19/+%?W-B-\"\!IISOE#F.6DW^K2JLVB4=A--'(ILFU!=P?5Q-!Y.HH MRLE:W!V*<A+EY+>4D[>J72[`WV^S'U@@"\^+^*YX"^-;Z\;8+#OS^?SC]^U_ MKGQ??TMVX]ZLU3+8+OF&XC]+GES49V>N[EQ7>B??D)%%@^FZGWSQ\=KR>R)[ M-SY<+W_QL3<XU<<Q)2%)C"MIH9ZU??ZJS+K$HQ_TDWFH<_)=3W]MUU?\9-9> M>MVE.^Z>5>?'-^^"9^8_GMUQO=^]_ZG;MW#U\B?.^.5]Z\JCU^^XMOYN/[Y; M/]1ZXZ&^H5_ZI>5SLX=O>OKWKC[B=V_GNFMNV9-N?]WOWO-+&VX+BJ_E(]\? M>F3)(S_TNW?DXK_==/R^7__83V9O;6XL*"W;Y^_<,J_]_H_ZR?QZX^OC07SI MEK^YY^=?O_<__?@L4W9EE.5RAG2*RQF:.7^?3B57XYK+&O14]M2<&RR7<X.5 M7*T6Q!1Q9@J<&YS3;&$)A>(\%$LZ2RD*G/'[@S@G$R[G9"+)V5W-:1G.V(-! MG&/IQEVWYA7G6!J<8^E!7,=0WTUJ`^/LK7/C[*T#9V^=CM.NF-K,#)<S,P.< MF1F:,UXQM<<R;FJ/9<!Y+*-3FZB8VKTSW3CWS@3GWIDZSF3%U$ZTN)P3+>"< M:-&<J8JI[6MS4]O7!LZ^-IW:M.&T5#]20HI3K^@MU#Y1*WMK,?YM5CWH>C4I MWR%.S6B)U]15E*1JAI94IWIC[P\,6I(J"67R^LEB_>PKJ9]]9VWI!,<ENBQB M0;R#=N.N,5T6@S9X!^U!7)/7-KS!+2IGN_'FR)NS&2_KRR4FQ4&<$W&7<R+. M=Q?7G`DWO4&<&;2H8Z:.LMPR:%''5'VI%"?;8E])6^SSUI?`.+N3;AEU)\'9 MG609%>J+7PG9NG9;;IQ[V>?LM1CG:*>.D,^EK;(WHUE[\5+WGU&L/2RB7KS4 M_6?`RCD("YI$%T9WS6O9B3(1,7=Y8'&]Z'9$=*E.*.9DP$ZD2D78IGI,GBZN M'I.G(2+E$=&%NE(04]QV[&S<U)3,Z>*:DJ&8FA(Q7>X+5***&H^=39BJ,W&J MN.I,G(*H.A]17<I]HB#.N_^)G4V:^I0[65R?<B<A[H(`<5W*A$CTC/LV]F4 MJ6B#)XLKVB!%-DPALDM2)6(+7_FQLVE3"P^=**Z%ATY`;&,%L5VHJ-K3)ZB: M^@]PHYVJ?IEV-3%5NYIRC/OC(,Z*8UQ@G!7'N$#.BF-<8&HKCG&!<58<XP(Y M*XYQ@:FM-,8%:SM5Z$FNWU@Q9[8P'F39RK-J/(B+4ST=;J>W*N8^@(:=]M2C M`VC8Z;-)\59N5T+*3$^M)!M9PKU:3]:R+8S:2EM'@4I-3Y2]J%6'M=]U9$: M2-F'6GG\=&V9E'BQI+IR27MK&W>MTI*>JN=[KQW$=;VOI$2)M`O*I#U5W[CK M@.[XMC5`VE/U@[B>$2(a)M62JQH4P[15OH.56HT9-H"SVG,E-*3)5);?31!4WW MIVH[V\D@IR\K2'5J9JMG$MZ17#=%-W7;^RU9":A1]>]R2L3]02+\.RO',T&) M&)6I1;#7,B+<7HLBXA`1UR*>K)`*_^XK5$;\^[%0&>&+,B+<#BUD1OQ[ME`9 M\>_B0F6$?9T1X?9UOAEY$R9>(&=DXE5*[?EFXBGJ+7!ZR3(([H1ZXFZ:E%[> M$P^J\H$B_.<P0E7Y(S6N"#5(':D)W78YGA@1:G3B>!*R[6YK<$6H(6E;0^B, M+&UR12QM@HBE3:$SDFUV162;J78TA\[(\597Q/%6B#C>&CHC^]I=$?O:J3:T M^V2$NI!C*Q61$N&9$U":EYX3<*JD2,%=WZ%D*9_JO#3?@K1U=1H-^V;56#J4 MC'R!M6!V9@HR'%Z)GO9YVEC;4DK:B/+7FXT19?I(L<K>H9VU)$AU!G-<BK3G M0%O?7WN&`!\%.M#:]U>@(21`APZT]_UU:`B:0HT.M/C]U6@(JZ!)!]K\_IHT M!%:A3`=;_;[*-(16J4\'VOW^^C0$5Z]2!U?:*2>HIJZRG@FJ7O8ZO<X$%9]G MO%-7V/-R<DJ-Z.=F<DJUPG,W.:44A7,[.:5$GOO)*=5SA)J<HNA@!3OX%Y]+ M*G#Z*TFL59HSO&X40BL)THU":"5!NE$(K21(-PJ1D2#=*$1&@G2C$!G9?9$K M8O=%$+'[HJ",!*K=T?1!040T?5`04=7T@=+]?'J:ZG4_GVG3<+J?S\QI>-W/ M9_)T>KJ?S_SI]'4_GRG4-Z?[^<RBOGG=SV<B]=SH?CYSJ>=$]XL,ELA@>6<: M+-.?J`V<3(PF:BNE]GR;J(VZKZC[>D=V7Y$-$MD@;X$-PD5R]!H6#]$SV7M- M+V;O-3UMO=?TN/9>TT/9>TT/XL+5S<ICVGN?7MG>:^6)[2%Z!!=?K_(T!E'> MX-[KG:77ZZZYQ7M-[VKO-;V8O=?T7/9>TUO9>TTO9.\U/:N]U_FWA)HE#!6> M;Y(&J8FW`1<"0>?ZR2<^]?V'*CU9G;PFU*Z:N`TD@*#S:M-6G30GOZTX;ZT8 M<W7IJZ9$JB_CZF+]C&=#!!);=;[7FK#4RD.BYZ$MPLEPIUK?;(XQIUUP&>@@ MUXGVLBI00$IN%^Z^PCUZ[L%_AJ:E0/HIO=8UYJQX]9Q395G20FTM%DO:B7@B M9L<_NT,Z$#SAR#$B9$`VJF4A7!*R`L=[A/L)<7-M+A`160`Y4!X35LQ*)6.N M'N-MU!/\UR_;A7NWC`KW#+MRGHJ]+AF/D0)COU%M[*WW&;MA@>))V36Q6"(6 M#^3A3BQ;%9_>5TFG6N1]2952*:&RE-YAEKH,N4M>1"[&6'YW>G=6<H=B3M_\ MQG7]'R5>__G*>?JGB,^C6IQMXTNFDA,7._.''N'Z%P^32'F7+;[+B2.JAM*I MR<2S\JQ\\I-7=/,5MJF]A;BJ_!=S*_%6IL+OO/57?&HEWY.W=?E1/M]DSKID M&=K,[:AWEXO>KV;$+'K;A+^MJ%&EB^CZU1(Z+K9:JY;+;90=)?>UR_^H6OQ- M\B[A\IZ?"SJ;I_SRY0"LM\<^_6>_/G';ALPW'DC+>][]K:,H>MECB=)\>?]1 MT64W"5"+.")Z[?W/1/<Y_)A-T@AC1U%OZ3T'9N-(L^4R(ZO'$F69#.!(;6+0 M$F5<C%BB6M8V2ZVHEUTX4O&_S]+-^"%+[R[PF*73\;,X]Q`4>2^P;.#VCLL[ M!H9'AHL_"]\_OO:NH;6;AS;N,-?#Z\='-TOW'),G`=\<DV[US4P9&';OX;KT MG/E:P8^VXK47\^EKINL*T<\RK<LW\INV_-ST':.;ASH6=G7+>"_EW?*\^@J+ M.J\_VG[9O?LM=?[(7[VXY\GB<]ND@4?V03RR'RIW"(DHHH@BBBBBB"*****( M(HHH(DU!]C]#8J^^_.IC71=FOO!%V/^7G7B&,^6)DC!NIM9M['7:I-RTCC8Z M9]TY!_"0:)OX,8`_K>T!N-L?=]JEK?^L:%O^'T3;QR^(WA'P)=&V_V'1LAM* M;/QVX*;AD9&.Q:.;QK:.#V_&R>:QT<W*JI<190MS-LXV<GC\Q5Q]G*RM$>=7 MBZ#CG(S.SS3F$NHS.JG.=,#`QO&187&,=M%Y=FSU#A/<(YJIUUSSG/E>T[?L MIC5+;UVVX@/];OYOQ''$"*><C\L25Y[WR/+G]!C+:CH?4YPK?C^W1Q111!%% M%%%$$44444011?1.),?6I+W(W^YI,]*NY._:_*V>O]/SMWG:Q;1':4OSMWC: M^+3;:=/S-WS:[MS&FZYKWAW]Z:-!^_-L/I^?+?SNDC:,:5MV"+\/16\;??_W M<?P#8![P;M'?>+@$H`?C>X#+A-\VHL^%MLOICT!O1WY[B]_GNPK@-_#XY3K: M_K2IZ2UX#?`^X%K@.N%7YT1N$&UKTY9>)'IS>,YOT!V+KEG\2M!28!GP?M'I MNQ7'Y<`*@%Z1?<!*X(/F_@".MXO^NM`=P"K@0\"'S?TSP$?,N8.WF^C;Q2^" M=2#G=ZFY`.?;2=51BR0L1Q;K4+)&SR7MU[>+G#<[?C!XD/X+:\2X7HFX6TI/ MEVHEYL9/JLPA<B'_&6>L^3*`V->)_@Y?>)HAVA<L3/QT]#ADW&J=3;-+MV2N MEMJ1?[97MMMJXR==?)4^)J1?Q;I)>2-M=[^0I[]96/A&7Q!U3J/\/\!_IOP3 M93D/EYX>Q,]^*TS\_?QGXK>4_R#GPVY#+?C85&R^U(3X6>/97X8I?R<F':OV M^.I3;3&<7U<+<E"I_)UVYQR]]WAQ/O1#$;T]9.'MV[6Z[I;VW1R_2_S5;AI= MOW73\%WC2B=8WL\P!*G&Q/,NYWY7C_SOPF_>+1&=Y_3_4$L!`A0`%`````@` MH[YG*I"1^![_)@```,(```H````````````@`+:!`````%1$+34Y82YD;V-0 52P4&``````$``0`X````)R<````` ` end ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Binary Encoding of H.245 Related Properties given in Table C/H.248
by Muhammad Mukarram Bin Tariq 16 Apr '01

16 Apr '01

Dear All, My question is regarding the encoding of the H.245 related properties listed in Table C/H.248. I presume that all these property values are encoded according to PER. Also that the entire MultimediaSystemControlPDU is encoded, instead of just the message structure. e.g to encode an OLC, we should encode the entire MultimediaSystemControlPDU that contains the OLC message, or just the OLC message structure. I am asking this question because in the presence of "Tags" it is quite possible to live without encoding the entire MultimediaSystemControlPDU. Regards, Muhammad Mukarram Bin Tariq __________________________________________________ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Documents for the SG16 meeting in Porto Seguro
by OKUBO Sakae 15 Apr '01

15 Apr '01

Dear SG16 experts, The next Study Group 16 meeting will be held during 28 May - 8 June in Porto Seguro, Brazil (see <http://www.itu.int/itudoc/itu-t/com16/coll/01-04/001_ww9.doc>). Since this is an official SG16 meeting, all the documents are managed by ITU-TSB. There are three types of document: White Contributions from the members, Delayed Contributions from the members and Temporary Documents from Rapporteurs. To facilitate the advance review of experts, please upload your document to ftp://standard.pictel.com/avc-site/Incoming or e-mail it to me when you have submitted your document to ITU-TSB. These documents will not be AVD-numbered as in our autonomous Rapporteur meetings, but placed at http://standard.pictel.com/ftp/avc-site/0105_Por/ without changing the file name. Best regards, OKUBO Sakae ********************************************************* Global Information and Telecommunication Institute (GITI) Waseda University 29-7 Waseda University Bldg. 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan e-mail: okubo(a)giti.waseda.ac.jp Tel: +81 3 3204 8194 Fax: +81 3 5286 3832 ********************************************************* My contract with TAO finished on 31 March. Please change my e-mail address as above, though okubo(a)giti.or.jp will continue to work for some time. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Question on presence
by Paul, Manoj 13 Apr '01

13 Apr '01

Dear Mr. Okubo, As you pointed out, the item (3) still needs to be worked on and the intention is what you mentioned during the end of your mail. In addition, the Presence signalling shall be carried out using the genericData field in RAS messages (using H.323 Generic Extensibility Framework), instead of adding new IEs to RAS messages. The ASN.1 synatx of CommunicationState may be further enhanced/modified to be more generic and reflect the necessary information that Presence is required to support (e.g user information in a standard presence format). The work on this is to be carried out further and presented as AVDs in subsequent SG16 meetings. best regards Manoj Paul. -----Original Message----- From: OKUBO Sakae [mailto:okubo@GITI.WASEDA.AC.JP] Sent: Thursday, April 12, 2001 8:10 PM To: ITU-SG16(a)mailbag.cps.INTEL.COM Subject: Question on presence Dear Mr. Manoj Paul, I am trying to understand the concept of H.323 presence. In AVD-2087, communication states to be exchanged are listed as: 1) status of the user, 2) its reachable address, 3) user's means of communication, including the preferred mode. The ASN.1 syntax CommunicationState in AVD-2087 includes newAliasAddress (corresponding to 2) above, I understand) and availableForCall, busy (both corresponding to 1) above). I wonder how 3) is handled. Is it going to be added in the course of work? Or as H.323 has the H.245 capability exchange procedure, H.323 presence needs only 1) and 2) above? Or still we would like to indicate e.g. being ready to communicate with fixed H.323 terminal at office, mobile phone like H.323 or H.323 on PDA on the road before the actual communication? Best regards, OKUBO Sakae ********************************************************* Global Information and Telecommunication Institute (GITI) Waseda University 29-7 Waseda University Bldg. 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan e-mail: okubo(a)giti.waseda.ac.jp Tel: +81 3 3204 8194 Fax: +81 3 5286 3832 ********************************************************* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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: ras address in RRQ/GRQ
by Francois Audet 13 Apr '01

13 Apr '01

The reason I was thinking about this is that if it was NOT included in the RRQ/GRQ, and the gatekeeper would be force to use the source IP address for any other messages (from GK to GW), the same as if it had been explicitly indicated in the GRQ/RRQ, then it would be possible to use a gatekeeper on one side of a NAT while both endpoints are on the other side. I guess not. Thanks Terry. > -----Original Message----- > From: Terry L Anderson [mailto:tla@LUCENT.COM] > Sent: Friday, April 13, 2001 6:31 AM > To: ITU-SG16(a)mailbag.cps.INTEL.COM > Subject: Re: ras address in RRQ/GRQ > > > This is of course the opposite of H.248 where replies must go > to source > address. But remember that there are requests (as opposed to confirms > and rejects) that are sent from GK to GW and the GK must know what > address to use. If no rasaddress were registered and ARQs > (for example) > came from various port numbers, the GK would have no idea > where to send > a DRQ, URQ, IRQ, etc. > > rasaddress is not optional in GRQ and so cannot be omitted. It is > probably not intended to be optional in RRQ although since it > is defined > as SEQUENCE OF TransportAddress and SEQUENCES can be of zero > length, it > is in effect optional. A comment probably should be added to make it > required for the above reason. > > "Paul E. Jones" wrote: > > > Francois, There is no requirement that RAS messages sent to a > > Gatekeeper have to be sent from the same port that it will > receive RAS > > messages. If it is not included, I would expect that the > results will > > be unpredictable. Some devices will probably assume an address and > > others will probably just reject the request. Paul > > > > ----- Original Message ----- > > From: Francois Audet > > To: ITU-SG16(a)mailbag.cps.INTEL.COM > > Sent: Thursday, April 12, 2001 8:17 PM > > Subject: ras address in RRQ/GRQ > > Guys,What is the purpose of the rasAddress in GRQ and > > RRQ?Shouldn't it just be the originating IP address? Is the > > gatekeeper supposed to send the GCF and RCF to IP address > > indicated in the GRQ/RRQ, or is it supposed to send it to > > the source IP address (at the IP layer)?What if the RAS > > address is not included in the RRQ/GRQ?----François AUDET, > > Nortel Networksmailto:audet@nortelnetworks.com, tel:+1 408 > > 495 3756 > > > -- > ------------------------------------------------------------ > Terry L Anderson mailto:tla@lucent.com > Tel:908.582.7013 Fax:908.582.6729 > Pager:800.759.8352 pin 1704572 1704572(a)skytel.com > Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp > Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 > http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla > >

1 0

ras address in RRQ/GRQ
by Francois Audet 13 Apr '01

13 Apr '01

Guys, What is the purpose of the rasAddress in GRQ and RRQ? Shouldn't it just be the originating IP address? Is the gatekeeper supposed to send the GCF and RCF to IP address indicated in the GRQ/RRQ, or is it supposed to send it to the source IP address (at the IP layer)? What if the RAS address is not included in the RRQ/GRQ? ---- François AUDET, Nortel Networks mailto:audet@nortelnetworks.com <mailto:audet@nortelnetworks.com> , tel:+1 408 495 3756

3 2

Is the capability set also a delta for MultiplexCapability?
by Frank Derks 13 Apr '01

13 Apr '01

There is general consensus that received capability sets should be treated as deltas (unfortunately H.323 is not really explicit about this). This certainly applies to the capabilityTable and CapabilityDescriptors elements in the TerminalCapabilitySet message, but does this also apply to the multiplexCapability? If I first send a TCS with a nonStandard element and then a TCS with a h225Capability element should this be treated as a delta or a replacement? If I send two TCSs, both with a h225Capability element, should anything that is present in the second, but not in the first TCS be "added" and anything that was present in the first but not present in the second be removed? Regards, Frank ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Merchant Status Account #6DA0
by Victor Simmons 13 Apr '01

13 Apr '01

***** This is an HTML Message ! *****

1 0

All VIP'S
by Earnie Preston 13 Apr '01

13 Apr '01

Dear Candidate, You have been selected as a potential candidate for a free listing in the 2001 Edition of the International Executive Guild Registry. Please accept our congratulations for this coveted honor. As this edition is so important in view of the new millennium, the International Executive Guild Registry will be published in two different formats; the searchable CD-ROM and the Online Registry. Since inclusion can be considered recognition of your career position and professionalism, each candidate is evaluated in keeping with high standards of individual achievement. In light of this, the International Executive Guild thinks that you may make an interesting biographical subject. We look forward to your inclusion and appearance in the International Executive Guild's Registry. Best wishes for your continued success. International Executive Guild Listing Dept.  If you wish to be removed from our list, please submit your request at the bottom of this email.   0); // returns false if empty } // --> International Executive Guild Registration Form (US and Canada Only) Please fill out this form if you would like to be included in The International Executive Guild's Registry. For accuracy and publication purposes, please complete and send this form at the earliest opportunity. There is no charge or obligation to be listed in The International Executive Guild's Registry. Your Name Your Company Title Address City State or Province Country USACanada ZIP/Postal Code Day Time Telephone Home Phone (Not To Be Published) Email TO HELP US IN CONSIDERING YOUR APPLICATION, PLEASE TELL US A LITTLE ABOUT YOURSELF... Your Business (Financial Svcs, Banking, Computer Hardware, Software, Professional Svcs, Chemicals, Apparel, Aerospace, Food, Government, Utility, etc.) Type of Organization (Mfg, Dist/Wholesaler, Retailer, Law Firm, Investment Bank, Commercial Bank, University, Financial Consultants, Ad Agency, Contractor, Broker, etc.) Your Business Expertise (Corp.Mgmt, Marketing, Civil Engineering, Tax Law, Nuclear Physics, Database Development, Operations, Pathologist, Mortgage Banking, etc.) Major Product Line (Integrated Circuits, Commercial Aircraft, Adhesives, Cosmetics, Plastic Components, Snack Foods, etc.) Note: Submitting this form will be made by email, not by use of  www.  Confirmation of its delivery is made by browsing your outgoing mail. Thank you for filling in this form, we will contact you with more information. List Removal Click Here

1 0

EndSessionCommand?
by Paul, Manoj 13 Apr '01

13 Apr '01

Hi, Does an endpoint using Tunnelling to exchange H.245 messages with peer, need to send EndSessionCommand message during call termination? There are two different texts relating to this: H.245 Specification(V7), Section B.13.4: "This command indicates the end of the h245 session. After tx EndSessionCommand, the terminal shallnot send any more of the messages defined in this Recommendation". H.323 Specification (V4), Section 8.5: Phase E-Call Termination "..It shall transmit H.245 endSessionCommand message in the H.245 Control Channel..." First statement seems to indicate that notwithstanding how H.245 messages are exchanged, an EndSessionCOmmand should be sent to stop any further exchange. Second statement seems to mean that EndSessionCommand is sent only when H.245 Control Channel exists (tunnelling not used). Could someone clarify? thanks Manoj Paul. Trillium Digital Systems. -----Original Message----- From: Nehru, Archana [mailto:archie@TRILLIUM.COM] Sent: Thursday, April 12, 2001 5:34 PM To: ITU-SG16(a)mailbag.cps.INTEL.COM Subject: H.323 v1 problem hi all, I have a doubt about ARQ message in H.323 -V1. The H.323 specs for V1 say that "srcCallSignalAddress" and "destCallSignalAddress" are optional. But there were some mails exchanged somtime back on the mailing list which said that these two fields are MANDATORY for v1, since without these fields it is not possible to identify a call in H.323 V1. E.g: Let us say we have an endpoint EP1, and EP2 and a GK and a call is Gk-routed. When EP1 wants to make a connection to EP2, it finishes RAS with GK and then sends a SETUP to GK. When EP2 receives the incoming SETUP from the GK, it send an ARQ to the GK. At this point the Gk needs to identify the "call " associated with the incoming ARQ. As there was no "callId" in V1, the only parameters that can give the GK a clue are the "srcCallSignalAddress" and "destCallSignalAddress" tuple. But if these are treated optional, then what parameters can the GK use to find the "associated call"? I believe for this reason it was suggested that "srcCallSignalAddress" and "destCallSignalAddress" would always be present in ARQ from a V1. Can someone please confirm this?. Many thanks, -Archana Archana Nehru, Engineering Project Manager, Trillium Digital Systems Inc., an Intel Company. http://www.trillium.com Ph:310-481-5525 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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

H.323 v1 problem
by Nehru, Archana 13 Apr '01

13 Apr '01

hi all, I have a doubt about ARQ message in H.323 -V1. The H.323 specs for V1 say that "srcCallSignalAddress" and "destCallSignalAddress" are optional. But there were some mails exchanged somtime back on the mailing list which said that these two fields are MANDATORY for v1, since without these fields it is not possible to identify a call in H.323 V1. E.g: Let us say we have an endpoint EP1, and EP2 and a GK and a call is Gk-routed. When EP1 wants to make a connection to EP2, it finishes RAS with GK and then sends a SETUP to GK. When EP2 receives the incoming SETUP from the GK, it send an ARQ to the GK. At this point the Gk needs to identify the "call " associated with the incoming ARQ. As there was no "callId" in V1, the only parameters that can give the GK a clue are the "srcCallSignalAddress" and "destCallSignalAddress" tuple. But if these are treated optional, then what parameters can the GK use to find the "associated call"? I believe for this reason it was suggested that "srcCallSignalAddress" and "destCallSignalAddress" would always be present in ARQ from a V1. Can someone please confirm this?. Many thanks, -Archana Archana Nehru, Engineering Project Manager, Trillium Digital Systems Inc., an Intel Company. http://www.trillium.com Ph:310-481-5525 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

All VIP'S
by Perry Thomas 12 Apr '01

12 Apr '01

Dear Candidate, You have been selected as a potential candidate for a free listing in the 2001 Edition of the International Executive Guild Registry. Please accept our congratulations for this coveted honor. As this edition is so important in view of the new millennium, the International Executive Guild Registry will be published in two different formats; the searchable CD-ROM and the Online Registry. Since inclusion can be considered recognition of your career position and professionalism, each candidate is evaluated in keeping with high standards of individual achievement. In light of this, the International Executive Guild thinks that you may make an interesting biographical subject. We look forward to your inclusion and appearance in the International Executive Guild's Registry. Best wishes for your continued success. International Executive Guild Listing Dept. _____ If you wish to be removed from our list, please submit your request at the bottom of this email. _____ International Executive Guild Registration Form (US and Canada Only) _____ Please fill out this form if you would like to be included in The International Executive Guild's Registry. For accuracy and publication purposes, please complete and send this form at the earliest opportunity. There is no charge or obligation to be listed in The International Executive Guild's Registry. _____ Your Name Your Company Title Address City State or Province Country USACanada ZIP/Postal Code Day Time Telephone Home Phone (Not To Be Published) Email _____ TO HELP US IN CONSIDERING YOUR APPLICATION, PLEASE TELL US A LITTLE ABOUT YOURSELF... _____ Your Business (Financial Svcs, Banking, Computer Hardware, Software, Professional Svcs, Chemicals, Apparel, Aerospace, Food, Government, Utility, etc.) Type of Organization (Mfg, Dist/Wholesaler, Retailer, Law Firm, Investment Bank, Commercial Bank, University, Financial Consultants, Ad Agency, Contractor, Broker, etc.) Your Business Expertise (Corp.Mgmt, Marketing, Civil Engineering, Tax Law, Nuclear Physics, Database Development, Operations, Pathologist, Mortgage Banking, etc.) Major Product Line (Integrated Circuits, Commercial Aircraft, Adhesives, Cosmetics, Plastic Components, Snack Foods, etc.) Note: Submitting this form will be made by email, not by use of www. Confirmation of its delivery is made by browsing your outgoing mail. _____ Thank you for filling in this form, we will contact you with more information. _____ List Removal Click <mailto:nvbobr@netscape.net?subject=remove> Here

1 0