1、i ATIS-1000067.2015 American National Standard for Telecommunications IP NGN Enhanced Calling Name (eCNAM) Alliance for Telecommunications Industry Solutions Approved August 11, 2015 American National Standards Institute, Inc. Abstract: This American National Standard defines a Calling Name Delivery
2、 service in the IP-based Next Generation Network (NGN). The enhanced CNAM (eCNAM) service includes a mandatory longer name field and optional additional information about the caller. ATIS-1000067.2015 2 Foreword The information contained in this Foreword is not part of this American National Standar
3、d (ANS) and has not been processed in accordance with ANSIs requirements for an ANS. As such, this Foreword may contain material that has not been subjected to public review or a consensus process. In addition, it does not contain requirements necessary for conformance to the Standard. The Alliance
4、for Telecommunication Industry Solutions (ATIS) serves the public through improved understanding between providers, customers, and manufacturers. The Packet Technologies and Systems Committee (PTSC) develops and recommends standards and technical reports related to services, architectures, and signa
5、ling, in addition to related subjects under consideration in other North American and international standards bodies. PTSC coordinates and develops standards and technical reports relevant to telecommunications networks in the U.S., reviews and prepares contributions on such matters for submission t
6、o U.S. ITU-T and U.S. ITU-R Study Groups or other standards organizations, and reviews for acceptability or per contra the positions of other countries in related standards development and takes or recommends appropriate actions. ANSI guidelines specify two categories of requirements: mandatory and
7、recommendation. The mandatory requirements are designated by the word SHALL and recommendations by the word SHOULD. Where both a mandatory requirement and a recommendation are specified for the same criterion, the recommendation represents a goal currently identifiable as having distinct compatibili
8、ty or performance advantages. Suggestions for improvement of this document are welcome. They should be sent to the Alliance for Telecommunications Industry Solutions, PTSC, 1200 G Street NW, Suite 500, Washington, DC 20005. At the time of consensus on this document, PTSC, which was responsible for i
9、ts development, had the following leadership: M. Dolly, PTSC Chair (AT ATIS-1000067.2015 5 2. The originating service provider could insert certain data elements about the caller from its network in each outgoing SIP INVITE; 3. The service provider of the called customer could obtain the callers inf
10、ormation from authoritative databases based on the received calling number; or 4. The called users device could display information on some callers (if the calling number matches an entry in the devices contact list which is created and managed solely by the user). The eCNAM service described in thi
11、s standard will deliver information that is retrieved by the terminating service provider from authoritative databases to increase the reliability of the eCNAM service for its subscribers (item 3 above). However, while the terminating service provider is responsible for the eCNAM portion of the data
12、 delivered, the end user may receive additional information in separate SIP headers from some of the other sources listed above. The eCNAM subscriber expects the data provided by the terminating service provider (Extended Name + CNAM Plus) to take precedence over most of the other incoming SIP heade
13、rs with the exception of emergency services headers. Further work outside the scope of this standard may be necessary to implement such prioritization. 4.4.1 Anonymity The FCCs initial ruling on 91-281, released in March 1994, emphasized the importance of Calling Party Number (CPN) availability for
14、the range of CLASSSM5services, including Calling Number Delivery (CND). Because CPN was necessary for other new services, the 1994 order required all capable carriers to transport CPN without any additional consideration or compensation. For callers who wished to preserve their anonymity, the order
15、further mandated what came to be known as “per-call blocking” by use of the dialing code *67 as the only method for implementing presentation restriction. Subsequent orders mandated that the *82 dialing code must be provided so that CPN can be “unblocked” on a call-by-call basis. Carriers are requir
16、ed to forward the blocking/unblocking information without modification, and terminating carriers must abide by the instructions of the caller regarding availability of number and name. In the 1995 order, the FCC ruled that name should be treated the same as number. That is, if the number is blocked,
17、 the name SHOULD also be blocked. If number is permitted, name SHOULD also be permitted. eCNAM delivery in the NGN is expected to adhere to the same presentation and privacy requirements. 4.4.2 User Equipment Contact Lists The information delivered to the end user under the CNAM service described in
18、 this document is offered by the service provider and is not to be mistaken for contact lists or device-based caller information repositories. The sources that the service provider uses to retrieve the name information are discussed in Clause 4.5. 4.4.3 Migration from Conventional Name Service to En
19、hanced Name Service The timeline for offering eCNAM will vary among service providers. It is assumed that service providers will migrate their traditional CNAM subscribers to eCNAM, but there is no requirement to do so. During the transition phase, each service provider is expected to manage a mix o
20、f customers: those who subscribe to eCNAM and others who continue to subscribe to conventional CNAM. As a result, the terminating service provider is expected to support launching the pertinent IP queries to retrieve the necessary data for each of these Name services. As for the authoritative databa
21、ses, the Extended Name will be stored in an additional field that co-exists with the Generic Name field (15 characters) in each customer record. Authoritative database providers are expected to maintain both fields throughout the transition. The Generic Name and the Extended Name fields SHALL each b
22、e independently retrievable from the authoritative databases via IP queries. 5CLASSSMare services that depend on the transport of CPN information to provide the end users with additional functionalities. ATIS-1000067.2015 6 During the migration to eCNAM, availability of the Extended Name is expected
23、 to occur gradually. Therefore, it would be useful to provide the traditional 15-character Generic Name as a default in the absence of the Extended Name instead of delivering no name In the absence of an Extended Name, and given no anonymity restrictions, the database SHALL be capable of returning t
24、he Generic Name in response to eCNAM IP queries instead of a null Extended Name. In that scenario, the Service Trigger Point SHALL deliver the Generic Name in the name-display filed of the INVITE. 4.4.4 Wireless User Equipment As a new generation of services, such as eCNAM, is implemented in the NGN
25、, new requirements and guidelines for the User Equipment should be defined. Part of the service quality perceived by the end user is the UE presentation. Therefore, requirements on the physical input media and the output, such as indicators and displayed information, must be defined in the relevant
26、Standards Development Organizations. The work should include specifications of the appropriate encoding, string sizes, and the preferred ordering of incoming headers. 4.5 Sources of Extended Name i.e., the QO is not authorized to access the database. ATIS-1000067.2015 8 - “user”, - “id”. In summary,
27、 the presentation and delivery of the Extended Name must align with the presentation status of the calling number in the Privacy header. The Service Trigger Point SHALL deliver the Extended Name to the subscriber according to the following table: Table 4.1 Summary of eCNAM Display SIP Privacy Header
28、 Action ENPI Display Missing Launch query to database Allowed Extended Name Restricted “Anonymous” (No data found/ timeout)8“Unavailable” “none” Launch query to database Allowed Extended NameRestricted Extended Name (No data found/ timeout)9“Unavailable” “header” Do NOT launch query N/A “Anonymous”
29、“user” “id” 4.7 CNAM Plus (Additional Caller Information) Each service provider may offer a different set of data in the CNAM Plus portion of eCNAM. For example, one provider may deliver a full Address of a business caller, while another delivers only a location that displays the City, State/Provinc
30、e, or ZIP Code/Canadian Postal Code. Another CNAM Plus example may include the preferred household language of the caller or the identity of the Service Provider of the caller. The determination of the number and type of data elements is subject to privacy and business considerations. The database m
31、ay apply different filters for the different query originators (i.e., the terminating service providers). Many of the authoritative databases that exist today already apply what is known as “Data Screening” procedures. Additional examples of data elements that may be available for retrieval from som
32、e authoritative databases, such as LIDB, are described in the data catalog of GR-1158-CORE. 5 Enhanced CNAM Message Description The eCNAM information delivered to the subscriber consists of: a. The Extended Name mandatory, and b. CNAM Plus optional additional calling party information. 5.1 Extended
33、Name Format The Extended Name SHALL be delivered to the eCNAM subscriber in the display-name portion of the header used to deliver the eCNAM message (e.g., PAI or From header). 8This is not a value of ENPI; the table entry simply represents the case when no data was returned. 9This is not a value of
34、 ENPI; the table entry simply represents the case when no data was returned. ATIS-1000067.2015 9 The Service Trigger Point SHALL encode the Extended Name string in UTF8 for delivery in the display-name portion thus supporting both the ASCII Standard Character Set (32-127) and the ASCII Extended Char
35、acter Set (128-255). The extended ASCII codes contain more special symbols and Latin characters than the basic ASCII printable characters. The requirement in this standard to use the extended character set serves to support the Language Laws for displaying the French alphabet (with acute, grave, cir
36、cumflex accents, etc.) in Canada. If the Extended Name is longer than 35 characters AND the eCNAM Trigger Point or intermediate node(s) can only support a length of 35 characters, the name SHALL NOT be discarded. Instead, it SHALL be truncated at 35 characters and inserted in the INVITE message to t
37、he subscriber. 5.2 CNAM Plus Format The eCNAM Service Trigger Point SHALL support the retrieval and delivery of additional information (CNAM Plus) about the calling party to the eCNAM subscriber. The eCNAM Service Trigger Point SHALL NOT retrieve or deliver the additional information (CNAM Plus) if
38、the presentation of the calling number is restricted. It is conceivable that the databases would assign individual privacy flags per data element in the future. However, for the purpose of this standard, the delivery and display of the additional information will align with the presentation restrict
39、ion of the calling party number. The terminating service provider is expected to: a) either pre-select the additional data elements that will be delivered to all its eCNAM subscribers, or b) offer different elements to different subscribers. The database provider will apply the capability to filter
40、the data elements the terminating service provider is authorized to receive. These data elements will be identified in contractual agreements between the terminating service provider and the database providers that host the information. The Service Trigger Point SHALL deliver the additional calling
41、party information (CNAM Plus) in a SIP Call-Info header. The SIP Call-Info header is described in RFC 3261 as Call-Info = “Call-Info“ HCOLON info *(COMMA info) info = LAQUOT absoluteURI RAQUOT *( SEMI info-param) info-param = ( “purpose“ EQUAL ( “icon“ / “info“ / “card“ / token ) ) / generic-param T
42、his eCNAM standard focuses on using the “info” parameter to deliver the CNAM Plus (plain text containing one or more data elements, such as address, postal code, or type of caller). However, since the Call-Info header syntax only supports a URI, a different scheme is needed to deliver plain text. RF
43、C 2397 describes a “data” URL scheme that allows the inclusion of data items of up to 1KB directly inline. The URLs are of the form: data:;base64, For the purpose of delivering the CNAM Plus data, the Service Trigger Point SHALL utilize the “data” URL scheme of RFC 2397 to encode the CNAM Plus infor
44、mation in the Call-Info header “info” parameter. The mediatype SHALL be omitted. As a result, the charset will default to text/plain; US-ASCII. The following is an example of using the data URL to encode an address and a type of line. ATIS-1000067.2015 10 EXAMPLE 64 Zoo Lane Bronx, NY 10460 Hospital
45、 translates into 64+Zoo+Lane%0D%0ABronx%2C+NY+10460%0D%0AHospital The number and length of elements a service provider includes in the CNAM Plus portion may vary, therefore several Call-Info headers may be used to deliver the CNAM Plus information in its entirety. The eCNAM Service Trigger Point SHA
46、LL populate each of the CNAM Plus data elements in a separate Call-Info header to the terminating end user. While it is typical for a session to deliver multiple call-info headers to the end user, the priority needs to be given to the information related to the services that the called end user has
47、subscribed to. The terminating service provider is expected to manage the order of delivering and displaying the various Call-Info headers to the called end user. The eCNAM Call-Info headers generated by the terminating service provider SHALL (1) be displayed to the called end user ahead of other no
48、n-subscription Call-Info headers, and (2) bear and indicator10of the terminating service provider as the sender of the service-related Call-info headers. It is assumed that a PSAP would not have eCNAM service active (i.e., there would not be any feature interaction between eCNAM and emergency servic
49、es). Intermediate nodes may reorder headers and there is no guarantee that one header will receive higher priority than others. However, the Call-Info headers generated to deliver the CNAM Plus information per this standard will be created closer to the terminating user. Therefore, the assumption is that the Call-Info header is less likely to undergo re-ordering, which increases. In the absence of User Equipment (UE) guidelines on displaying caller information, a higher order for a given CNAM Plus Call-Info header compared to other non-emerge
