RE: [Ieprep] re-charter

["Dolly, Martin C, ALABS" <[e-mail]>]

Hello Dick,

The items that you listed are already being addressed by ATIS-PTSC and
ITU. If a new IP capability or extension (e.g., RPH) is needed, then
draft(s) will be submitted to the IETF.

Cheers,

Martin

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]]On Behalf
> Of Richard F Kaczmarek
> Sent: Wednesday, July 13, 2005 5:20 PM
> To: [e-mail]
> Subject: Re: [Ieprep] re-charter
> 
> 
> 
> 
> 
> 
> I think rechartering the ieprep wg is a good idea. In 
> rechartering, I would
> like the group to consider the following.
> 
> Based upon testing of IP/GSTN interoperability under conditions of
> congestion, there are a number of IP network requirements and 
> mechanisms
> needed to ensure a GETS-like service works across a congested 
> IP network.
> For example, fidelity of DTMF tones for PIN authentication is 
> an issue at
> high utilizations.
> 
> The requirements associated with emergency communications (e.g., a
> GETS-like service) fall into four broad categories:
> 
> 1. Signaling. Signaling requirements can be divided into two 
> types: (a)
> Signaling a request for emergency communications to an 
> authentication /
> authorization entity for approval, and (b) Signaling an authorized /
> authenicated request from the source to destination. Within 
> the IP network,
> SIP was found to be resilient in the face of congestion, so 
> no distinction
> may be required between the two signaling types. However, the delays
> associated with SIP under heavy congestion impacted its successful
> interoperation with SS7 signaling in the PSTN.
> 
> 2. Resource Provisioning. Providing the necessary resources for
> authenticated emergency communications. With G711 codecs, 
> VoIP was found to
> be intelligible up to an offered load of 150% of the bottleneck link
> capacity. Thus a Call Admission Control mechanism that allows for
> "oversubscription" for emergency communications may be 
> appropriate (e.g.,
> CAC set to 80% of link capacity, with emergency 
> communications allowed an
> additional 10% of link capacity). If oversubscription is not 
> acceptable,
> guaranteed bandwith is also possible. With the Cisco routers 
> we were using,
> we could allocate bandwidth in the EF queue for emergency 
> communications
> and for normal traffic. In this latter case, some sort of 
> marker (e.g.,
> DSCP) may be needed for emergency traffic, but a unique per 
> hop behavior
> may not be needed.
> 
> 3. Security. Issues include authentication within the IP 
> network and across
> network  boundaries. In particular, if a GETS-like service is 
> authenticated
> in the GSTN through DTMF tones transmitted across the IP 
> network (as is
> currently done), there are issues of PIN intercept and PIN 
> transmission
> errors associated with delayed and dropped packets at high 
> utilizations.
> RFC 2833 and the KeyPad Markup Language (KPML) may provide 
> solutions. A
> second issue concerns inter-domain trust to allow "prioritization" of
> emergency communications end-to-end, both between IP domains, 
> and between
> IP and GSTN domains.
> 
> 4. Network engineering and provisioning "best practices." For 
> example, for
> IP/GSTN interoperation, the number of SIP retries should be 
> set to "x."
> 
> While the documents already produced by the ieprep wg 
> address, at varying
> levels, many of these areas, there are additional "GETS-like"
> service-unique requirements that are not documented. It is 
> likely that a
> majority of these additional requirements can be satisfied by 
> using the
> mechanisms (being) developed by the other working groups.
> 
> As such, I believe the charter should allow for the creation 
> of additional
> "to be specified" I-D documents by the working group. If this 
> is allowed
> and the working group is rechartered, then I am willing to work in the
> group to define and create the appropriate documents discussing the
> "GETS-like" requirements, mechanisms and best practices.
> 
> 
> _______________________________________________
> Ieprep mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ieprep
> 

_______________________________________________
Ieprep mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ieprep