1、 AMERICAN NATIONAL STANDARD FOR TELECOMMUNICATIONS ATIS-1000009.2006(R2011) IP Network-to-Network Interface (NNI) Standard for VoIP ATIS is the leading technical planning and standards development organization committed to the rapid development of global, market-driven standards for the information,
2、 entertainment and communications industry. More than 250 companies actively formulate standards in ATIS 18 Committees, covering issues including: IPTV, Service Oriented Networks, Energy Efficiency, IP-Based and Wireless Technologies, Quality of Service, and Billing and Operational Support. In addit
3、ion, numerous Incubators, Focus and Exploratory Groups address emerging industry priorities including “Green”, IP Downloadable Security, Next Generation Carrier Interconnect, IPv6 and Convergence. ATIS is the North American Organizational Partner for the 3rd Generation Partnership Project (3GPP), a
4、member and major U.S. contributor to the International Telecommunication Union (ITU) Radio and Telecommunications Sectors, and a member of the Inter-American Telecommunication Commission (CITEL). For more information, please visit . AMERICAN NATIONAL STANDARD Approval of an American National Standar
5、d requires review by ANSI that the requirements for due process, consensus, and other criteria 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 materiall
6、y affected interests. Substantial agreement means much more than a simple majority, but not necessarily 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 volunt
7、ary; their existence does not in any respect preclude anyone, whether he has approved the standards 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
8、 will in no circumstances give an interpretation of any American National Standard. Moreover, 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 addre
9、ssed to the secretariat or sponsor whose name appears on the title page of this standard. CAUTION 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
10、, or withdraw this standard. Purchasers of American National Standards may receive current information on all standards by calling or writing the American National Standards Institute. Notice of Disclaimer SIP call/session control signaling; Signaling and media transport; Quality of Service (QoS); A
11、ssociation between call control and media control; and Mandatory SIP URIs to be Supported. There is also an informative annex on items for consideration in SLAs. The following related topics are not defined in this document: Call Routing; Security; Session Border Controller Functions; or Call Admiss
12、ion Control and Traffic Management. Figure 1 illustrates the relationship of this document to other related IP-NNI documents. ATIS-1000009.2006 IP-IPInterconnectionRoadmapIP NNI for VoIPIP-IPInterconnectionNumbering Via another network acting as a VoIP; or Via another network acting as a Transit Net
13、work provider. 6 TRAFFIC MODEL (TYPES OF SERVICES) Figure 4 illustrates the various traffic types that could be supported on the NNI between two carriers including: PSTN originating VPN, UNI, Local, International, or Inter-Exchange traffic; PSTN terminating VPN, UNI, Local, International, or Inter-E
14、xchange traffic; IP originating VPN, UNI, Local, International, or Inter-Exchange traffic; or IP terminating VPN, UNI, Local, International, or Inter-Exchange traffic. Carrier ACarrier BPSTNGatewayPSTNGatewayLocalInter-ExchangeInternationalVPN2Virtual Private Network 1UNITG1TGnInter-ExchangeTG1TGnIn
15、ternationalLocalUNIVPN2Virtual Private Network 1LocalLocalIXCIXCVPNVPNAny/AllTrafficTypesUNIUNIFigure 4 - Traffic Type Model 11 ATIS-1000009.2006 Currently in circuit-switched networks, service processing is triggered/initiated based on various variables including: Trunk received on and/or terminate
16、d to; Signaling; and Intelligent Network processing. Typically, trunk groups segregate different types of service traffic, these include: Local; Inter-exchange; Wholesale; and Virtual Private Network. As networks evolve from interconnecting with circuit-switched technology to IP technology, there wi
17、ll still be a need to provide interoperability of services. In order to take advantage of the cost savings of IP technology, carriers will interconnect with larger IP “pipes” that contain mixed traffic types. A preferred solution would relay the traffic/service type information in the SIP call contr
18、ol signaling. The SIP mechanism described below can be used to represent the traffic group (e.g., VPN traffic, international traffic, etc.) for a call. IETF draft-ietf-iptel-trunk-group-06.txt defines a SIP mechanism to convey a trunk group identifier in a sip or tel URI. This identifier is placed i
19、n the user portion of the URI. The trunk group identifier consists of two parameters: trunk-group and trunk-context. Both of these parameters must be present to identify a trunk group. The trunk-group parameter provides a trunk group label. The trunk-context serves a purpose analogous to the phone-c
20、ontext parameter of the tel URI. The trunk group identifier can be placed in the SIP Contact header (to indicate the ingress, or originating, trunk group) or in the Request-URI (to indicate the egress, or terminating, trunk group). A SIP routing entity (e.g., a proxy or a redirect server) may insert
21、 a trunk group identifier in the Request-URI to indicate to a downstream entity which egress trunk group to use when routing the call. The trunk group identifier is applicable to both PSTN and IP call/session originations/terminations. A UAC that initiates a call may include the trunk group identifi
22、er in the Contact header to indicate the ingress (originating) trunk group used for the call. Subsequent requests destined to that UAC must copy the trunk group information from the Contact header into the Request-URI. To the UAS processing the request, a trunk group identifier in the Request-URI in
23、dicates that it should use the named trunk group for the outbound call. The trunk group identifier can reveal the network topology and the routing policies used by a carrier. Therefore, the trunk group extension may be optionally supported at the IP-IP NNI. 12 ATIS-1000009.2006 7 MEDIA AVAILABILITY
24、IN A SIP SESSION The following applies to any media session established across the NNI using SIP: a) The terminating-side network of the NNI must pass any media packets in the direction toward the originating party as soon as they are available. A primary reason is to allow the caller to hear inband
25、 call progress tones if PSTN interworking is encountered on a voice call. b) The originating-side network of the NNI: Must pass media packets from the originating party toward the terminating party no later than on receipt of a SIP 2XX response to the INVITE. May pass media packets from the originat
26、ing party toward the terminating party any time after receipt of the first SDP answer, which may be in a SIP 1XX or 2XX response to the INVITE. A network, as a policy, may choose to not send media packets from the originating party until the final SDP offer/answer has occurred in order to avoid thef
27、t-of-service in cases where usage-sensitive billing is employed. c) As per IETF RFC 3261, once a SIP dialog has ended, the flow of media packets must be halted. d) The absence of media packets across the NNI in either direction over any time interval shall not be taken by either network as a reason
28、to clear the SIP session. 8 CALL/SIGNALING FLOWS (INFORMATIVE) This section illustrates example call flows for the following scenarios: 1. PSTNIP(NNI)IPPSTN 2. PSTNIP(NNI)IPIP 3. IPIPNNIIPPSTN 4. IPIP(NNI)IPIP The example call flows for scenarios 1, 2, and 3 are based on the flows described in ANSI
29、T1.679. The interworking between ISUP and SIP is shown at the diagrammatic level to illustrate interoperability. ANSI T1.679 provides the details of interworking between ISUP (or BICC) and SIP, including the encapsulated ISUP and SIP header precedence rules. The example call flows for scenario 4 are
30、 based on IETF RFC 3261. The following symbols (Figure 5) are used in the figures in this section: 13 ATIS-1000009.2006 Tone generationLegendThrough connection of the voice path in the backward directionThrough connection of the voice path in the forward directionThrough connection of the voice path
31、 in both directionDisconnection of voice path through the nodeReservation of an incoming/outgoing call without through connection of the voice pathFigure 5 - Call/Signaling Flow Legend 8.1 PSTNIP(NNI)IPPSTN This section illustrates typical interworking scenarios between ISUP and SIP-I. The example c
32、all flows assume a call originating and terminating in the PSTN and transiting two IP networks. 8.1.1 Successful Call Setup (SIP Preconditions Not Used) Figure 6 shows a typical sequence of messages for successful call setup for an incoming ISUP call over SIP-I. The PSTN Gateway performs the through
33、-connection of the bearer path in both directions after the receipt of SDP answer in the 180 Response. 14 ATIS-1000009.2006 CCFEPSTN GatewayPSTN GatewayCCFEINVITE (SDP, IAM)INVITE (SDP, IAM)INVITE (SDP, IAM)IAMIAM100 Trying100 Trying100 Trying (Note 1)180 Ringing (SDP, ACM)180 Ringing (SDP, ACM)180
34、Ringing (SDP, ACM)ACM ACM200 OK (INVITE) (SDP, ANM)ANMANMACKACKACKNote 1 - The generation of the 100 Trying response is necessary if the PSTN Gateway knows that it will not generate a provisional or final response. 200 OK (INVITE) (SDP, ANM)200 OK (INVITE) (SDP, ANM)Figure 6 - Successful Call Setup
35、8.1.2 Normal Call Release without Tone Provision Figure 7 shows typical call release interworking procedures for normal call release without tone provision. A REL message is mapped and encapsulated into a BYE request to preserve ISUP signaling transparency. NOTE This procedure is applicable in those
36、 cases where in-band tones and announcements are not provided - e.g., 64 kbit/s unrestricted bearer service. 15 ATIS-1000009.2006 CCFEPSTN GatewayPSTN GatewayCCFEBYE (REL)BYE (REL)RELREL200 OK (BYE) (RLC)200 OK (BYE) (RLC)200 OK (BYE) (RLC)RLC BYE (REL)RLCFigure 7 - Normal Call Release without Tone
37、Provision 8.2 PSTNIP(NNI)IPIP This section illustrates typical interworking scenarios for successful call setup and release between ISUP and SIP. The call flows assume a call originating in the PSTN and terminating in an IP network. 8.2.1 Successful Call Setup (SIP Preconditions Not Used) Figure 8 s
38、hows a typical sequence of messages for successful call setup at a Gateway for an incoming ISUP call and an outgoing SIP call, without SIP preconditions. In this example, the PSTN Gateway sends the INVITE message upon receipt of an IAM containing the indication “continuity check not required”. Upon
39、receipt of the 200 OK (INVITE), the PSTN Gateway sends the ANM. 16 ATIS-1000009.2006 Note The IAM contain the indication “continuity check not required“.CCFEPSTN GatewaySIP UACCFEINVITEINVITEINVITEIAM (Note)100 Trying100 Trying100 TryingANMACKACK180 Ringing200 OK (INVITE)ACK200 OK (INVITE)200 OK (IN
40、VITE) 180 Ringing180 RingingACMFigure 8 - Successful Call Setup from ISUP to SIP 8.2.2 Normal Call Release Initiated from the ISUP Side Figure 9 shows a normal call release procedure initiated from the ISUP side of the call. This call flow assumes that no resource reservation teardown signaling is r
41、equired on the SIP side of the call. 17 ATIS-1000009.2006 CCFEPSTN GatewaySIP UACCFEBYE BYEREL200 OK (BYE)200 OK (BYE)200 OK (BYE)BYERLCFigure 9 - Normal Call Release from ISUP to SIP 8.3 IPIPNNIIPPSTN This section illustrates typical interworking scenarios for successful call setup and release betw
42、een SIP and ISUP. The call flows assume a call originating in an IP network and terminating in the PSTN. 8.3.1 Successful Call Setup (SIP Preconditions Not Used) Figure 10 shows a typical sequence of messages for successful call setup at a Gateway for an incoming SIP call and an outgoing ISUP call.
43、Since SIP preconditions are not in use, the PSTN Gateway immediately sends out the IAM. Upon receipt of the ANM, the PSTN Gateway sends the 200 OK (INVITE). 18 ATIS-1000009.2006 CCFESIP UA PSTN GatewayCCFEINVITEINVITEINVITEIAM100 Trying100 Trying100 TryingANMACKACK180 Ringing200 OK (INVITE)ACK200 OK
44、 (INVITE)200 OK (INVITE) 180 Ringing180 RingingACMFigure 10 - Successful Call Setup from SIP to ISUP 8.3.2 Normal Call Release Procedure Initiated from the SIP Side Figure 11 shows the sequence of messages for normal call release procedure initiated from the SIP side of the call. This call flow assu
45、mes that no resource reservation teardown signaling is required on the SIP side. 19 ATIS-1000009.2006 CCFESIP UA PSTN GatewayCCFEBYE BYE200 OK (BYE)200 OK (BYE)200 OK (BYE)BYERELRLCFigure 11 - Normal Call Release from SIP to ISUP 8.4 IPIP(NNI)IPIP This section illustrates typical scenarios for succe
46、ssful call setup and release at the SIP IP-IP NNI. The call flows assume a call originating and terminating in an IP network without transiting a non-IP network. 8.4.1 Successful Call Setup (SIP Preconditions Not Used) Figure 12 shows a typical sequence of messages for successful call setup for a ba
47、sic call at the SIP NNI. 20 ATIS-1000009.2006 CCFE CCFEINVITE100 Trying180 RingingACK200 OK (INVITE)Figure 12 - Successful Call Setup at IP-IP SIP NNI 8.4.2 Normal Call Release Figure 13 shows the sequence of messages for normal call release at the SIP NNI. 21 ATIS-1000009.2006 CCFE CCFEBYE200 OK (B
48、YE)Figure 13 - Normal Call Release at IP-IP SIP NNI 8.5 Usage of Trunk Group Identifier Call Flow Figure 14 shows the sequence of messages for a typical SIP call flows illustrating the usage of trunk group identifier. 22 ATIS-1000009.2006 CCFEPSTN GatewayPSTN GatewayCCFEINVITE R-URIContact (TG_IDy)I
49、AM (TG_IDy)100 Trying100 Trying100 Trying (Note 1)180 Ringing (SDP, ACM)180 Ringing (SDP, ACM)180 Ringing (SDP, ACM)ACM ACM200 OK (INVITE) (SDP, ANM)ANMANMACKACKACKNote 1 - The generation of the 100 Trying response is necessary if the PSTN Gateway knows that it will not generate a provisional or final response. 200 OK (INVITE) (SDP, ANM)200 OK (INVITE) (SDP, ANM)INVITE R-URI (TG_IDx)Contact (TG_IDy)IAM (TG_IDx)INVITE R-URI (TG_IDx)Contact (TG_IDy)RELBYER-URI (TG_IDy)BYER-U
