Emergency Services and Service classes

Sahasrangshu Pal Choudhury sahasrangshu at YAHOO.COM
Fri Apr 20 00:35:56 EDT 2001


I'm planning to do conference using Openh323 stack , all I need is a bit of
help from you all and let me know how to create,join e.t.c conference using
Openh323 stack.
Awaiting for HELP....Angshu
________________________________
Sahasrangshu Pal Choudhury
Astralsys Software(India) Pvt .Ltd.
SDF Building,Module No.323-336,
Block-GP,Sector V,Salt Lake
Phone:
(Office) :357 4994-97
(Home) :537 8040
(Cell )   :98300 48983
Alternate Email :
angshu at astralsys.com.
ceaserp at usa.net



----- Original Message -----
From: "Roy, Radhika R, ALCOO" <rrroy at ATT.COM>
To: <ITU-SG16 at MAILBAG.INTEL.COM>
Sent: Friday, April 20, 2001 12:11 AM
Subject: Re: Emergency Services and Service classes


> 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

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



More information about the sg16-avd mailing list