Mailing list: email@example.com [Subscribe] [Archive]
Task Force Co-Chairs: Martin Dolly / AT&T – firstname.lastname@example.org; Chris Wendt / Comcast – Chris_Wendt@cable.comcast.com
Task Group Chief Document Editor: Chris Wendt / Comcast
Meetings: Meetings take place on a schedule established by the task group. You can stay informed about upcoming meetings by subscribing to the NNI Task Force mailing list (see link above).
Important NNI Task Force Announcement
Federal Communications Commission Approves Notice of Inquiry (NOI) on the SHAKEN Call Authentication Framework Developed by the SIP Forum/ATIS NNI Task Force and the Publication of New Joint ATIS/SIP Forum SHAKEN Standard
ATIS and the SIP Forum have announced the publication of a new Joint ATIS/SIP Forum Standard, Signature-based Handling of Asserted information using toKENs (SHAKEN): Governance Model and Certificate Management that expands the SHAKEN framework, introducing a governance model and defining X.509 certificate management procedures. Certificate management provides mechanisms for validation of a certificate and verification of the associated digital signature, allowing for the identification of illegitimate use of national telecommunications infrastructure. This document represents Phase 2 of the SHAKEN Framework.
We have also announced that the United States Federal Communications Commission (FCC) has officially approved a Notice of Inquiry (NOI) on this new standard.
The development of the initial SHAKEN (Signature-based Handling of Asserted information using toKENs) specification, which represents Phase 1 of the SHAKEN Framework (see below for links to the work), is a major advancement in industry efforts to mitigate unwanted robocalls and caller ID spoofing.
Developed to efficiently implement the IETF’s STIR (Secure Telephony Identity Revisited) standard, SHAKEN defines a signature to verify the calling number and specifies how it will be transported in SIP “on the wire.” The SHAKEN framework provides guidance for service providers to implement STIR. Together, STIR/SHAKEN will offer a practical mechanism to provide verified information about the calling party as well as the origin of the call — what is known as “attestation” — for the first time in the network. Giving service providers the tools needed to sign and verify calling numbers makes it possible for consumers to know, before answering, that the calls they receive are from legitimate parties.
The ATIS/SIP Forum NNI Task Force previously completed the first standardized IP-based network-to-network interconnection (NNI) with consensus across North American Service providers. This accomplishment enables a major objective identified in the United States National Broadband Plan, to ensure that all service connections between providers occur at the Internet Protocol (IP) level. It also helps the industry advance a major business objective of achieving the interconnection needed to reliably deliver a range of exciting new IP-based services. This work is the product of the ATIS/SIP Forum Joint Task Force, which is at the forefront of conducting an industry effort to evaluate the current state of IP-IP interconnection, identify problem areas, and provide detailed protocol-level specifications to advance solutions.
Those completed documents provide a detailed, protocol-level IP-NNI specification for one service – voice. From this initial profile, further specifications can more easily be developed. The two new ratified documents are (1) IP Interconnection Profile, which describes a reference architecture and specifications for both the protocol and media as it appears “on-the-wire” at interconnect points; and (2) IP Interconnection Routing Report, which documents mechanisms for identifying the preferred IP interconnection point for a given phone number.
These four documents are available from the SIP Forum website free of charge.
- Joint ATIS/SIP Forum Standard, Signature-based Handling of Asserted information using toKENs (SHAKEN): Governance Model and Certificate Management
- Signature-based Handling of Asserted information using toKENs (SHAKEN)
- IP Interconnection Routing Report
- IP NNI Profile
IP Interconnection among service providers is significantly increasing as the Transition of the PSTN from SS7/TDM to SIP/IP networks progresses. Current deployments of SIP/IP in the core carrier networks have exposed operational and implementation differences on how IP for SIP traffic works ‘on the wire’. These differences complicate interconnection, and in some cases require ‘protocol normalization’ to achieve full interoperability. The call control protocol SIP [RFC 3261] is defined in the IETF and further refined in profiles developed by 3GPP or ATIS that reflect regional and/or national differences in implementation. There are hundreds of IETF SIP and 3GPP specifications that are open to interpretation, creating ambiguity in the detailed options that are implemented. This often requires Session Border Controllers or I-CSCF proxies to spend unnecessary processing reconciling the signaling between service providers and resolving those ambiguities. Time and effort is also required to document the differences and configure the SBC or I-CSCF proxy to implement the necessary changes to the on the wire protocol.
In addition, there is no commonly agreed methodology on how to translate E.164 numbers for routing data for IP SIP interconnections, although DNS based ENUM [RFC 6116] technologies have been deployed widely in private instantiations.
The objective of this task force is to identify a baseline set of features that should be common to all IP-NNI implementations for voice service. The Task Force may also identify gaps or ambiguities in existing standards and request that those gaps be addressed by the responsible Standards Development Organization [SDO]. The task group will produce one or more specifications that define a common set of implementation rules for SIP Service Providers [SSP] who desire to interconnect with another SSP for voice initially. Ultimately, there will be a need for specifications that cover other types of real time multimedia traffic, but that will not be explicitly considered by this Task Force. However, any specifications that the Task Force produces will not preclude or inhibit other forms of media. The specifications will define which standards and options must be supported. They will provide SSP’s with a precise description of the IP-NNI in the areas where the standards leave multiple options, or where the existing specifications are ambiguous. In addition, these specifications will increase requirements [i.e. MAY, SHOULD, MUST] where operational experience indicates that such enhancements are necessary to support full interoperability.
The ATIS/SIP Forum IP-NNI Task Force will operate under the ATIS IPR policy. See http://www.atis.org/legal/patpolicy.asp.
Phase 2 Objectives of the Task Force
With the new specification in place, work on Phase 2 of the ATIS/SIP Forum IP-NNI Joint Task Force is underway. It will address inter-carrier video calling, enhanced calling name delivery (CNAM), and develop an implementation profile for secure caller ID based on the IETF STIR (Secure Telephone Identity Revisited) Working Group. These technical initiatives represent the commitment and leadership of the industry to protect consumers and enterprises from the plague of Caller ID Spoofing and Robocalls.
The specific objectives of Phase 2 include:
Video Calling / Video Interoperability/Inter-Carrier Video Communications:
The initial Network to Network Interface specification, by design, was centered on voice communications. The ATIS SIP Forum Task Force will build on that work to enable Inter-Carrier multimedia communications between service providers over NNI interfaces, especially video communications using E.164 as well as SIP URI addressing. Initial work has begun in the SIP Forum on SIPconnect 2.0 specification to enable interoperable point-to-point (Any-To-Any video interoperability) video communications from the Enterprise to the service provider/Operators’ network. The Task Force will reach out to other Industry and Standards Development Organizations to incorporate current best practices and a set of new proposed guidelines for promoting interoperability across all segments of the Video services/platforms.
The Task force will specify:
- All relevant IETF RFC’s and standards necessary to enable end to end rich multimedia communications across service provider boundaries.
- Minimum audio/video codec needed to promote interoperability
- Define security trust mechanisms as required
- Define appropriate Quality of Service mechanisms
- Identify and consider core functionality that is common across a number of video conferencing specifications and consider these in the specification at the NNI, including identifying the potential need for interworking functions.
Completion date July, 2016
Routing – Next Steps
The task force will assess the Testbeds FG IP-NNI routing scenario(s) of interest for near term interoperability testing. Consideration will be given to scenarios that are considered potential “target” routing mechanisms. In addition, priority will be given to scenarios where multiple participants are interested in directly participating in interoperability testing.
For the priority routing scenarios, the task force will provide the following input to the Testbeds LT:
- Use case: complete description of the priority use case.
- Scope of the testing: identify the functions and call flows that should be tested to validate the routing scenario(s).
- Objective: identify interested Testbed participants and the expected outcome and success factors for the testing.
- Test plan: provide input for the detailed test plan.
The task force will receive the output from the interop testing and assess the implications for the next steps in developing an IP-NNI routing recommendation.
Target Completion: March, 2016
The task force will also evaluate ongoing IETF work that is relevant to the IP-NNI, and based on the analysis of the task force, and the results of interop testing, develop consensus positions where possible. The consensus positions would help the task force members provide coordinated input into the relevant IETF working groups. IETF WGs of interest would include, but not be limited to:
Target Completion: July, 2016
VoIP Security Whitepaper
The task force will undertake an assessment of security implications as the PSTN transitions from TDM to IP. It will specifically consider if the transition is leading to a PSTN that is more secure or less secure. The assessment will characterize the different levels of security between VoIP transported over the open Internet and VoIP over a managed IP service offered by the service provider to determine how each of these compare with the security of the TDM-based PSTN. The interaction between the resilience of the underlying transport infrastructure and the resulting security at the VoIP application layer will be included in the scope of this assessment. The task force will focus on implementable and deployable approaches to security rather than a theoretical analysis. Recognizing that security within each service provider’s network is an internal matter that is not directly affected by standards, this analysis will take an interconnection / IP-NNI perspective. Where issues are identified, the task force will discuss mitigation strategies that are being applied or evaluated.
The task force will capture the results of this analysis in a white paper that will provide an informed assessment of the actual level of VoIP security when provided over a managed service provider IP network, and describe mitigation strategies to address any remaining issues.
Target completion date: January, 2016.
The task force will develop a proposed profile for implementing a STIR solution. The profile will address the following:
- Protocol(s) used in the profile. If extensions or restrictions to the base protocol are required, these will be specified as well. This would include open APIs used in the solution.
- Reference call flows, identifying:
- All parties involved in the call flow
- The actions performed by each party
- Clearly indicate where the STIR message flow fits into the routing call flows, and where the solutions share common infrastructure or protocols.
- Proposed mechanism for key discovery, key download, and key provisioning.
- The task force will propose how the STIR profile could be tested in the ATIS testbed, including identifying:
- Functions involved in the testing
- Interfaces and/or APIs to be tested
- Call flow to be tested
- Detailed test plan
- Results expected
Target completion date: July, 2016
The Task Force will examine developing a specific service model and technical profile for an Enhanced Calling Name Delivery (CNAM) mechanism. The CNAM service in the PSTN is a well-understood Signaling System 7 service. It is currently limited by a severe restriction on the number of characters that can be displayed and the use of ASCII character set. The Task Force will focus its initial efforts on developing a mechanism to deliver Enhanced CNAM within the existing SIP signaling mechanism between trusted service providers. The Task Force will consider documenting two possible approaches.
The first approach would utilize concepts now under development by ATIS PTSC for a verbose expression of CNAM Plus data fully imbedded within the SIP signaling mechanism or by URI reference to a trusted source.
The second approach would consider the use of RFC 7095 [JSON vCard format] within the SIP signaling mechanism.
The Task Force will not address issues of trust mechanisms, data integrity or validity of the CNAM Plus data, provisioning mechanism or query response mechanisms from trusted data sources at this time.
Completion date: July, 2016
Phase 1 Objectives of the Task Force
Phase 1 Objectives, which have been met in the published specification, included the following goals:
- Define a reference architecture that sets forth the common functional entities necessary for SIP Service Provider [SSP] to SIP Service Provider Interconnection. This reference architecture will be from the perspective of the interconnection points between carriers and will not deal with implementation details inside the networks on either side of the IP-NNI.
- Specify the exact specifications (including IETF RFCs, 3GPP, and other existing standards) associated with these protocols that must or should be supported by each element of the reference architecture. Where required, the options that MUST or SHOULD be supported within a given standard will also be specified.
- Specify customary methods for negotiating protocols, protocol extensions, and exchanging capability information between SSP’s. Specify consensus methods of formulating SIP protocol messages where multiple options exist in standards.
- Specify the exact presentations of Fully Qualified Domain Names in “From:” and “To:” fields including use of TEL URI format, including PAI.
- Define the architecture and requirements for a shared “Thin” registry of NNI interconnection data.
- Specify a mechanism for determination of the terminating carrier of record irrespective of what the shared registry is and the method and format of the data retrieved from the terminating carrier.
- For IP originated Calls, specify the preferred header [SHOULD] for Calling Name data [CNAM], and specify how that data is presented to the terminating proxy including format, syntax and processing of such data. Note: The expectation is that the signaling of CNAM would not survive interworking to SS7.
- Define mandated support for underlying transport [e.g. UDP, TCP, SCTP].
- Specify an audio codec selection strategy that minimizes the need for transcoding and a transcoding strategy that balances the workload between originating and terminating carrier.
- Define strategies for DTMF and Fax support.
- Specify call loop detection and avoidance methods.
- Define common Quality of Service objectives including network overload and congestion notification and processing mechanisms.
- Investigate issues surrounding known interoperability problems (e.g. PRACK [RFC 3262], early media, ptime, etc.).
Areas that Should be Considered by the Task Force
- Role of IPv6 to IPv4 interworking among SSPs.
- Define how unknown headers [e.g. x Headers] should be handled at the IP-NNI.
- Role of DNSSEC in an all SIP/IP interconnection environment.
- Assess the level of consensus for a practical method of carrier authentication and for providing adequate security for SIP signaling.
- Consider if the Audio Codec selection strategy would also apply to Video Codec to promote interoperability in multimedia multi stream sessions.
- Handling of re-invites as calls gets transferred from endpoint to endpoint and media suspension and restart for calls on hold or muted.
- Achieve consensus on a registry approach to support routing of E.164 number-address named SIP sessions including;
a. Structure of interconnection data.
b. The manner in which the data is used within the reference architecture.
c. Anticipated responses to queries based on the defined interconnection data.
Areas That Are Explicitly Beyond the Scope of the Task Force
- Any discussion of the US Communication Act of 1934, As Amended.
- Any terms and conditions of Interconnection between service providers that are properly the role of a business negotiation.
- March 2014: Goals and Requirements for NNI Architecture.
- June 2014: Specification of “Thin” Registry data protocol and structure.
- February 2015: Network to Network interface profile.
- July 2015: Publication of the ratified NNI IP Interconnection Profile and NNI IP Interconnection Routing Reports.
While the Task Force will operate within the joint authority and oversight of both ATIS and the SIP Forum, it will operate independently pursuant to the terms of the Joint Development Agreement. The Task Force will adhere to the general principals of an open multi-stake holder consensus process in its work, similar to procedures used by ATIS, the SIP Forum and the IETF.
All participants in the Task Force are reminded of the requirements to disclose relevant Intellectual Property Rights (IPR) associated with contributions and ultimately referenced in the developed specifications.
NNI Task Force Meeting Minutes and Related Documentation
Accessing ATIS Workspace (AWS) requires an AWS account. If you do not already have an AWS account, you can get one by sending an email to Jim McEachern at email@example.com requesting one. When your account has been established, you will receive an email with a link to set your password.
Once you have set your password, you can access AWS at https://access.atis.org and sign in with your username and password.
For the next month or two we will use a manual process to upload contributions. When you are planning to submit a contribution, please use the following steps:
- Use AWS to upload contributions, using the AWS website ( https://access.atis.org/apps/org/workgroup/ipnni/).
- Detailed instructions can be found at http://www.atis.org/01_aws/faqs.asp#Upload.
- If you have any questions, please contact Jim McEachern at firstname.lastname@example.org.
For More Information
For more information, please contact Marc Robins, SIP Forum Managing Director, at email@example.com or call +1-203-829-6307.