Emergency Services and Service classes

Thu Apr 19 14:41:52 EDT 2001

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 at 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 at icn.siemens.com]
Sent: Thursday, April 19, 2001 10:36 AM
To: Roy, Radhika R, ALCOO; ITU-SG16 at 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 at ICN.Siemens.com
-----------------------------------------------------------------

-----Original Message-----
From: Roy, Radhika R, ALCOO [mailto:rrroy at att.com]
Sent: Thursday, April 19, 2001 8:59 AM
To: Callaghan, Robert; ITU-SG16 at 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 at ICN.SIEMENS.COM]
Sent: Wednesday, April 18, 2001 1:23 PM
To: ITU-SG16 at 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 at ICN.Siemens.com
-----------------------------------------------------------------

-----Original Message-----
From: Gary Thom [mailto:gthom at delta-info.com]
Sent: Wednesday, April 18, 2001 12:41 PM
To: ITU-SG16 at 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 at delta-info.com
 Website: www.delta-info.com
--------------------------------------------

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com