ANSI ATIS 0500019-2010 Request for Assistance Interface (RFAI) Specification.pdf

《ANSI ATIS 0500019-2010 Request for Assistance Interface (RFAI) Specification.pdf》由会员分享，可在线阅读，更多相关《ANSI ATIS 0500019-2010 Request for Assistance Interface (RFAI) Specification.pdf（90页珍藏版）》请在麦多课文档分享上搜索。

1、 AMERICAN NATIONAL STANDARD FOR TELECOMMUNICATIONS ATIS-0500019.2010(R2015) Request for Assistance Interface (RFAI) Specification As a leading technology and solutions development organization, the Alliance for Telecommunications Industry Solutions (ATIS) brings together the top global ICT companies

2、 to advance the industrys most pressing business priorities. ATIS nearly 200 member companies are currently working to address the All-IP transition, network functions virtualization, big data analytics, cloud services, device solutions, emergency services, M2M, cyber security, network evolution, qu

3、ality of service, billing support, operations, and much more. These priorities follow a fast-track development lifecycle from design and innovation through standards, specifications, requirements, business use cases, software toolkits, open source solutions, and interoperability testing. ATIS is acc

4、redited by the American National Standards Institute (ANSI). The organization is the North American Organizational Partner for the 3rd Generation Partnership Project (3GPP), a founding Partner of the oneM2M global initiative, a member of and major U.S. contributor to the International Telecommunicat

5、ion Union (ITU), as well as a member of the Inter-American Telecommunication Commission (CITEL). For more information, visit www.atis.org. AMERICAN NATIONAL STANDARD Approval of an American National Standard requires review by ANSI that the requirements for due process, consensus, and other criteria

6、 for approval have been met by the standards developer. Consensus is established when, in the judgment of the ANSI Board of Standards Review, substantial agreement has been reached by directly and materially affected interests. Substantial agreement means much more than a simple majority, but not ne

7、cessarily unanimity. Consensus requires that all views and objections be considered, and that a concerted effort be made towards their resolution. The use of American National Standards is completely voluntary; their existence does not in any respect preclude anyone, whether he has approved the stan

8、dards or not, from manufacturing, marketing, purchasing, or using products, processes, or procedures not conforming to the standards. The American National Standards Institute does not develop standards and will in no circumstances give an interpretation of any American National Standard. Moreover,

9、no person shall have the right or authority to issue an interpretation of an American National Standard in the name of the American National Standards Institute. Requests for interpretations should be addressed to the secretariat or sponsor whose name appears on the title page of this standard. CAUT

10、ION NOTICE: This American National Standard may be revised or withdrawn at any time. The procedures of the American National Standards Institute require that action be taken periodically to reaffirm, revise, or withdraw this standard. Purchasers of American National Standards may receive current inf

11、ormation on all standards by calling or writing the American National Standards Institute. Notice of Disclaimer DNS is not required. 13. SIP Notification Events are not published or discovered, but used based upon business agreements. 14. Emergency calls may be routed (or bridged) between an IPSR fu

12、nction and an i3 ESInet. The routing (or bridging) method is similar to that between a legacy selective router and an i3 ESInet without signaling protocol interworking. This is assumed to use the Tandem to Tandem capability. 15. The IPSR function should implement congestion control mechanisms on inc

13、oming emergency calls. This is beyond the scope of this specification. 16. This specification recommends the use of the REFER Method for bridging/transfer in near and long term, and allows the use of the INFO Method in the near-term to support existing implementations. 17. IPV4 will initially be sup

14、ported for signaling and media, with evolution to IPV6 as the market evolves. RFAI shall support both IPv4 and IPv6 user terminal connectivity as they become available. IPv4 only, IPv6 only, and dual mode (IPv4/IPv6) user terminals should be supported. 1.4.2 RFAUA Function 1. The RFAUA is the SIP el

15、ement acting on behalf of an identifiable call taker at their workstation. It initiates and terminates SIP transactions on RFAs delivered to the call taker at their workstation. There may be other functions operating in between the RFAUA and the call taker at their workstation, but these functions a

16、nd any resulting interworking with the RFAUA is beyond the scope of this specification 2. For reliability purposes, there may be multiple RFAUAs (e.g., Proxy or ACD-like) located in the PSAP. This version of the specification does not address nuances related to those configurations. A future version

17、 of the specification will address those configurations. 3. IP-enabled PSAPs (i.e., the RFAUA) receive emergency calls over the RFAI via SIP/RTP. 4. The PSAP receives the location key (e.g., ANI, p-ANI, ESRK, ESRD, or ESQK) in the SIP INVITE message and shall format an ALI query in order to obtain l

18、ocation information. 5. IPV4 will initially be supported for signaling and media, with evolution to IPV6 as the market evolves. RFAI shall support both IPv4 and IPv6 user terminal connectivity as they become available. IPv4 only, IPv6 only, and dual mode (IPv4/IPv6) user terminals should be supporte

19、d. 2 NORMATIVE REFERENCES The following standards contain provisions which, through reference in this text, constitute provisions of this American National Standard. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based

20、on this American National Standard are encouraged to investigate the possibility of applying the most recent editions of the standards indicated below. 1 08-751, NENA i3 Technical Requirements Document (TRD), NENA, September 28, 2006.12 Document 58-001, Issue 2, NENA IP Capable PSAP Minimum Operatio

21、nal Requirements Standard, NENA, June 9, 2007.11Available at: . ATIS-0500019.2010 4 3 RFC 3265, Session Initiation Protocol (SIP)-Specific Event Notification, IETF, June 2002.24 RFC 4579, Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents, IETF, August 2006.25 RFC 4575, A

22、Session Initiation Protocol (SIP) Event Package for Conference State, IETF, August 2006.26 RFC 4119, A Presence-based GEOPRIV Location Object Format, IETF, December 2005. 27 RFC 4244, An Extension to the Session Initiation Protocol SIP) for Request History Information, IETF, November 2005.28 RFC 326

23、1, Session Initiation Protocol, IETF, June 2002.29 RFC 3262, Reliability of Provisional Responses in the SIP, IETF, June 2002.210 RFC 2327, SDP: Session Description Protocol, IETF, April 1998.211 RFC 3325, Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trust

24、ed Networks, IETF, November 2002.212 RFC 2045, Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies, IETF, November 1996.213 RFC 2046, Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types, IETF, November 1996.214 RFC 2392, Content-ID and Message-ID U

25、niform Resource Locators, IETF, August 1998.215 00-001 v13, NENA Master Glossary of 9-1-1 Terminology, NENA, March 2010.116 RFC 4353, A Framework for Conferencing with the Session Initiation Protocol (SIP), IETF, February 2006.217 75-001, NENA Security for Next-Generation 9-1-1 Standard (NG-SEC), NE

26、NA, February 2010. 118 RFC 4733, RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals, IETF, December 2006.219 RFC 5031, A Uniform Resource Name (URN) for Emergency and Other WellKnown Services, IETF, January 2008.220 RFC 3966, The tel URI for Telephone Numbers, IETF, December 2004.22

27、1 G.711.1, RTP Payload Format for ITU-T Recommendation, ITU-T, November 2008.322 ATIS-1000029.2008, NGN Security Requirements.423 ATIS-1000030.2008, Authentication and Authorization Requirements for Next Generation Network (NGN).524 ATIS-1000035.2009, Next Generation Network (NGN) Identity Managemen

28、t (IdM) Framework.525 RFC 4103, RTP Payload for Text Conversation, IETF June 2005.23 DEFINITIONS, ACRONYMS, Additional call context based information delivered to the request handling position; A robust and highly available processing environment; A foundation for future capabilities and services; a

29、nd A potential evolution path from the existing Emergency Services Network to an NG9-1-1 network. The RFAI is implemented with standards-based protocols including IP and Session Initiation Protocol (SIP). Information content delivery and feature capabilities are enhanced beyond existing legacy model

30、s. A foundation is established that will lead to support of new capabilities for voice calls, and new types of emergency RFA services (e.g., instant messaging, automated devices, sensors, and future forms of communication). The requirements in this section are divided into two sub-sections. The firs

31、t sub-section highlights the NENA requirements that are applicable and pertinent to the RFAI specification. Specific requirements are included in whole and clarification or rationale is provided for each requirement. The second sub-section includes requirements that are specifically related to the R

32、FAI specification. 4.1 NENA Requirements Two NENA requirements documents are referenced in this sub-section. The first is NENA i3 Technical Requirements Document (TRD) 1, and the second is NENA IP Capable PSAP Minimum Operational Requirements Standard 2. 4.1.1 NENA i3 TRD Specific requirements that

33、are applicable and pertinent to the RFAI specification from the NENA i3 TRD 1 are included in this section. ATIS-0500019.2010 7 “Signaling 0100-0100: Session initiation (call) signaling for IP connected callers shall initially be SIP based. Other protocols are permitted if they are interworked to SI

34、P for presenting to the PSAP. PSAPs shall not be required to accept IP calls using any protocol other than SIP. The architecture shall permit evolution to future protocols.” Rationale: RFAI shall only support SIP. “Signaling 0200-0100: Signaling shall be supportable over UDP and TCP with or without

35、TLS security. PSAP policy shall govern which of these transport mechanisms are acceptable.” Rationale: Further NENA recommendations have stated TCP as the primary delivery mechanism for SIP with a fall back to UDP. Also, the various ATIS NGN standards recommend TCP. Therefore, it is appropriate for

36、the RFAI to support both TCP and UDP. “Signaling 0600-0100: The PSAP shall be able to optionally control disconnect.” Rationale: Future versions of the RFAI will support this requirement after it is finalized by the appropriate SDO(s). “Signaling 1000-0100: It shall be possible to determine the comp

37、lete call chain of a call, including the identity of each signaling element in the path, and the reason it received the call, e.g., alternate routed. (This is an existing SIP mechanism, Call History).” Rationale: RFAI will support this requirement as it relates to alternate routing. Note that not “e

38、ach signaling element” is identified (e.g., not each router), but salient entities that made alternate routing decisions will be identified. These are often referred to as “Layer 5” entities, and are typically what is meant when mentioning “signaling elements” in the path. Logging may be used to cor

39、relate elements in a signaling path for normal RFA processing, but is out of scope of this document. “Signaling 1500-0100: Voice Activity Detection shall be disabled for emergency calls.” Rationale: This specification provides for optional support of this requirement because PSAP call takers sometim

40、es get information on what is happening in the background to determine how to process the call. “Media 0100-0100: PSAPs shall accept voice, video, and text media streams on RTP transport.“ Rationale: This version of the specification supports voice, TTY over voice, and Real Time Text 25. “Media 0200

41、-0100: The Emergency Services IP Network or the PSAP shall support existing TTY devices.” Rationale: RFAI supports this requirement within the ES-NGN. “Media 0400-0100: It shall be possible for PSAPs to supply ringback media to callers.” Rationale: RFAI supports this requirement. “CallBack 0100-0100

42、: Calls to 9-1-1 shall supply a call back address (URI, which includes the possibility of an E.164 TN expressed as a tel URI) with the call.” Rationale: RFAI supports this requirement. “Routing 3400-0100: There shall be mechanisms to carry the reason for alternate routing (differentiating for exampl

43、e on incoming call queue busy from failure of an element) and make different routing decisions based on the reason.” Rationale: RFAI supports this requirement. ATIS-0500019.2010 8 “Connections 0200-0100: PSAPs shall have functions to determine the status of the Emergency Services IP Network.” Ration

44、ale: While the RFAI does not support the general requirement of determining the status of the Emergency Services IP network, it does support the status of the two functional elements involved in RFAI by using a heartbeat-like message exchange that would be an application layer ping. “Existing 0100-0

45、100: Backwards compatibility of existing wireline and wireless callers shall be implemented.” Rationale: RFAI supports this requirement. One of the major intents of RFAI is to assure backward compatibility and delivery of calls from existing networks. “Existing 0200-0100: Support mechanisms for back

46、wards compatibility may evolve, but at all times it shall be possible to accommodate existing originating offices and mobile switching centers without requiring changes to such switches.” Rationale: RFAI supports this requirement. One of the major intents of RFAI is to assure backward compatibility

47、and delivery of calls from existing networks. “Bridge 0100-0100: Bridge services may be provided as a service on the ESInet, or may be provided internal to the PSAP.” Rationale: This standard assumes that inter-PSAP bridging is supported via ES-NGN bridges. In addition, bridges (conference servers)

48、may be at the PSAP, but are out of scope of this specification. “Bridge 0200-0100: All participants in the bridge shall have access to the call identifier of the original call.” Rationale: RFAI supports this requirement. “Bridge 0400-0100: Any agency on the call shall be made aware of any other agen

49、cies (or external participant) bridged to the call.” Rationale: RFAI supports this ability per RFC 4575 5. “Bridge 0500-0100: Provision for bridging agencies that are only accessible via Selective Router or PSTN shall be defined.” Rationale: RFAI supports this requirement. “Bridge 0600-0100: An i3 PSAP shall be able to transfer or bridge a call to or from any PSAP, including internationally, with all data that accompanied the call (e.g., location).” Rationale: RFAI supports location reference to the ALI only, but d