- sg16-avd - lists.packetizer.com

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