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@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@delta-info.com
> Website: www.delta-info.com
> --------------------------------------------
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv@mailbag.intel.com
>