1、 ATIS-1000014 VOIP NETWORK-TO-NETWORK INTERFACE TESTING FRAMEWORK TECHNICAL REPORT The Alliance for Telecommunication Industry Solutions (ATIS) is a technical planning and standards development organization that is committed to rapidly developing and promoting technical and operations standards for
2、the communications and related information technologies industry worldwide using a pragmatic, flexible and open approach. Over 1,100 participants from over 300 communications companies are active in ATIS 22 industry committees and its Incubator Solutions Program. Notice of Disclaimer and does not as
3、sume any details about internal network architectures or systems. Describes the kinds of things to be tested, but does not provide explicit, enumerated test cases; also, it does not specify particular testing methods. Initially focuses on VoIP. This testing framework does not address: Identification
4、 of the responsible organization performing the testing. Testing for services; however, services may be used as stimuli to invoke aspects of protocols that are to be tested. Load testing. Simultaneous testing of multiple NNIs between two networks. This TR addresses testing of a single NNI at a time.
5、 Failure scenarios. Test cases that intentionally result in a protocol timeout. ATIS-1000014 2 Successful network interoperability testing should be verifiable strictly by observing what happens at the network-network interface. Test generation and some verification methods may pragmatically involve
6、 the placement of actual telephone calls and observing results from that user point of view. Before defining specific test plans, the network operators involved must agree on what subset of the VoIP NNI ANS they are implementing, according to the SLA. Testing could follow various models. For example
7、: a. Conduct a full suite of tests exercising the entire interface as defined in the VoIP NNI ANS, and verify which pass and whether that set is consistent with the aspects of the VoIP NNI ANS that are in the SLA agreed to by the network operators. An advantage of this approach is that it can discov
8、er capabilities supported across the interface that may not otherwise have been known to or agreed to by the network operators. b. Conduct a test suite that exercises a subset of the entire interface in the VoIP NNI ANS, where that subset is limited to aspects of the VoIP NNI ANS that are in the SLA
9、 agreed to by the network operators. An advantage of this approach is that it may involve less testing. The subset may depend to some degree, for example, on the nature of the two IP networks, (LEC - interexchange, or peer-to-peer, or wireless versus wireline) and/or the services being supported. Th
10、e exercise of the testing guidelines and call stimulus scenarios contained in this document are intended to have no impact on the integrity or reliability of existing services being supported in a live network. 2 DEFINITIONS For protocol-specific terminology, the reader should consult the correspond
11、ing protocol specifications. The definitions of “layer” terms in this document physical, data link, network, and transport - are as per the OSI model. 23 ABBREVIATIONS for example, IP addresses for UDP payload versus TCP payload, or IP addresses for SIP signaling payload over UDP versus RTP media pa
12、yload over UDP. 5.2 Priority Differentiation Traffic priority across the NNI may be differentiated at the IP packet level through the use of DiffServ code points. When employed, the use of such differentiation in DiffServ should be verified. The VoIP NNI may more generally be an IP NNI that carries
13、other kinds of traffic besides voice calls; for example, video, web-browsing, email, file transfer or presence information. Those other kinds of traffic may also receive differentiated treatment. 5.3 IP Payload Protocol Indication Proper indication within IP of the payload protocol should be verifie
14、d (i.e., use of the Protocol field in IPv4 or the Next Header field in IPv6). 6 SIGNALING TRANSPORT The VoIP NNI ANS identifies the use of TCP, UDP, or SCTP for SIP signaling transport. 6.1 UDP The use of UDP for SIP transport is the same as for other types of UDP payload. Therefore, there are no sp
15、ecific capabilities of UDP that need to be exercised for SIP payload. However, it should be verified that the intended UDP port numbers for SIP transport are actually used, if they differ from those for other types of UDP payload. 6.2 TCP As with UDP, there is nothing special about the use of TCP fo
16、r SIP signaling transport versus other kinds of TCP payload. However, unlike UDP, TCP involves the establishment of a connection. Therefore it should be verified that the specific TCP connection(s) for conveying SIP signaling are established, including the use of the intended TCP port numbers and th
17、e desired TCP connection characteristics of window size and maximum segment size. ATIS-1000014 5 6.3 SCTP For SCTP, the following should be verified: a. The establishment of associations between SCTP signaling endpoints (i.e., SCTP packets with INIT and INIT ACK chunks, etc.) and specific streams pe
18、r association. b. The passing of actual signaling content (SCTP packets with DATA and SACK chunks, the DATA chunks carrying SIP signaling). c. The heartbeat mechanism (SCTP packets using HEARTBEAT and HEARTBEAT ACK chunks). d. Congestion control (using procedures with the Advertised Receiver Window
19、Credit in a SACK chunk). e. Path Maximum Transmission Unit (MTU) discovery. 7 CALL CONTROL 7.1 SIP - Call Stimulus Scenarios This subsection contains a set of call scenarios that could be used as stimuli to test aspects of the SIP protocol that it would be especially desirable to verify. The set bel
20、ow does not: Exhaustively exercise all possible facets of SIP use allowed according to the VoIP NNI ANS. In particular, error scenarios eliciting 4XX, 5XX, and 6XX SIP responses are absent. Some of the scenarios below could be combined into a single stimulus call. The reason to separate out into dif
21、ferent scenarios here is to focus on the different aspects of the protocol to be tested, which are in the third column of Table 1. ATIS-1000014 6 Table 1. Call Stimulus Scenarios for SIP # Scenario Name/Description SIP aspect to be exercised destination address types Address formats in INVITE Reques
22、t-URI and To header: sip:xxhostname;user=phone tel:+xx sip:usernamehostname RFC 3261, RFC 3966, RFC 2806 The “xx” string represents telephone number information. The destination address could be domestic or international, POTS, Toll-Free or 911, etc. 2. Simple call; answered and cleared Normal SIP m
23、essaging sequence with final response of 200 OK to the INVITE, including: 183 Session Progress with SDP content 180 Ringing the use of PRACK messages RFC 3261, RFC 3262 3. Simple call; called party busy Final response of 486 Busy Here to the INVITE RFC 3261 4. Simple voice call between SIP end-devic
24、es; answered Use of a MIME-encoded message body with SDP offer content in the SIP INVITE and SDP answer content in one or more of the 183 Session Progress, 180 Alerting and 200 OK responses; with the Content-Type header containing “application/sdp”; and with the Content-Disposition header, if presen
25、t, containing “session”. RFC 3261, RFC 3264 Only the 200 OK response is required to be returned in this scenario, whereas the provisional responses 183 Session Progress and 180 Alerting are optional. Because the use of the SIP PRACK procedure is mandatory in the VoIP NNI ANS (making provisional resp
26、onses reliable), the SDP answer content is not required to be carried in a 200 OK response. 5. Audio + video multimedia call between SIP end-devices. Use of a MIME-encoded SDP body in the SIP INVITE and one or more of the 180 Alerting, 183 Session Progress or 200 OK response messages, characterizing
27、 the single multimedia offer. RFC 3264 6. Simple call; ring no answer for X seconds The call and its SIP dialog attempt should remain in progress until cleared after X seconds by one of the networks, with either a CANCEL request from the caller-side network or a 480 Temporarily Unavailable final res
28、ponse to the INVITE from the called-side network. RFC 3261 The value of X is equivalent to a PTSN network going to lockout; i.e., the call attempt should not be left up indefinitely 7. Simple call to a non-working address Final response of either 404 Not Found or 410 Gone to the INVITE RFC 3261 8. S
29、imple call, but with multiple SDP offers in the INVITE 183 Session Progress or 200 OK response, with a single SDP entry that is one of those offered in the INVITE RFC 3261, RFC 3262, RFC 3264 ATIS-1000014 7 # Scenario Name/Description SIP aspect to be exercised the upstream network has already perfo
30、rmed the toll-free translation to a routing number Routing number passed in the INVITE Req-URI, original dialed toll-free number in the To header RFC 3261 11. Call to a ported number; the upstream network has done the LNP lookup The INVITE Request URI addressing information is appropriately populate
31、d. For example, for ported number 7324201234 with location routing number 7326719998, the userinfo portion of the Request-URI would be +17324201234;npdi;rn=+17326719998 T1.679-2004 RFC 4694 Alternatively, the ported number information could be embedded in a tel: URI. The userinfo portion of the SIP
32、URI in the To header may also contain the location routing number and npdi information. 12. Simple call, PSTN-originated, IAM Calling party number parameter APRI = Presentation restricted, no Generic Address parameter INVITE P-Asserted Identity header includes the calling party number, and priv-valu
33、e=; “id”; From header carries “anonymous” display name and Anonymous URI T1.679-2004, RFC 3325 13. Simple call, PSTN-originated, IAM Calling party number parameter with APRI = Presentation allowed, no Generic Address parameter INVITE P-Asserted Identity header includes the calling party number; From
34、 header also includes the calling party number T1.679-2004, RFC 3325 14. Simple call attempt, caller hangs up before called party answers Originating network sends a CANCEL message after the INVITE. RFC 3261 15. Simple fax call, fax passed as voiceband (aka “pass-through”) Address format in INVITE T
35、o header: fax:+12234567890 and SDP content indicates audio G.711 with silence suppression off RFC 2806 There is a variety of additional information that can be conveyed as parameters with this kind of URL that is not identified here 16. Simple modem call, data passed as voiceband Address format in I
36、NVITE To header: modem:+12234567890;type=type info and SDP content indicates audio G.711 with silence suppression off RFC 2806 There is a variety of additional information that can be conveyed as parameters with this kind of URL that is not identified here 17. Call from a wireline phone to a Governm
37、ent Emergency Telecommunications Service (GETS) destination number SIP INVITE contains a Resource Priority header with namespace.value ets.X with an appropriate value for X; SIP OK message confirms that the receiving network supports that namespace.value RFC 4412 ATIS-1000010.2006 18. Call from a wi
38、reless phone to a Wireless Priority Service (WPS) access code + destination number SIP INVITE contains a Resource Priority header with a pair of namespace.values ets.X, wps.Y; SIP OK message confirms that the receiving network supports those namespace.values RFC 4412 ATIS-1000010.2006 ATIS-1000014 8
39、 # Scenario Name/Description SIP aspect to be exercised the particular response to the INVITE is not specified here RFC 3841 The response of the network receiving the INVITE will depend on what it does or doesnt do with the information in any of those caller preferences headers ATIS-1000014 9 # Scen
40、ario Name/Description SIP aspect to be exercised the called party deliberately does not answer, and the caller hangs up upon hearing ringing. After the SIP INVITE from the caller side network and 1XX a provisional response from the called side network, a SIP CANCEL request should appear from the cal
41、ler-side network, with a 200 OK response to the CANCEL and with a 487 Request Terminated final response to the INVITE. RFC 3261 27. Call to an unassigned number in the terminating PTSN network. A final response of 404 Not Found is received in response to the SIP INVITE. RFC 3261, T1.679-2004 Note: t
42、he terminating PSTN network is responding with an ISUP Release message with Cause 1 (unallocated(unassigned number) 28. Call to a number in the terminating PSTN that is recently changed and unassigned. A final response of 410 Gone is received in response to the SIP INVITE. RFC 3261, T1.679-2004 Note
43、: the terminating PSTN network is responding with an ISUP Release message with Cause 22 (number changed) 29. Call to a PSTN-connected phone that is busy (and that does not have call waiting, call forwarding, etc). A final response of 486 Busy is received in response to the SIP INVITE. RFC 3261, T1.6
44、79-2004 Note: the terminating PSTN network is responding with an ISUP Release message with Cause 17 (user busy) 30. Call to a SIP phone that can be set to temporarily refuse calls (e.g., a SIP phone do not disturb feature) A final response of 480 Temporarily Unavailable is received in response to th
45、e SIP INVITE. RFC 3261 ATIS-1000014 10 # Scenario Name/Description SIP aspect to be exercised calling IP device offers regular media in the INVITE, the called IP device accepts it in a 183 Session Progress but also offers early media, which the calling IP device accepts in the 200 OK to the 183 Sess
46、ion Progress. The caller device may be a SIP phone. The called device may be SIP equipment performing a prompt e.g., at least the port numbers would be different so the two IP end-devices can distinguish between the two media streams. The early media stream can start as soon as the early media offer
47、/answer exchange has occurred (the 183 and the 200 OK to it). The early media stream ends and the regular media stream begins once the 200 OK to the INVITE has occurred (that transitions the SIP exchange status from early dialog to regular dialog). ATIS-1000014 11 # Scenario Name/Description SIP asp
48、ect to be exercised in which case the TLS method of encrypted transport must be employed to carry all the SIP messages for that SIP dialog. The transport parameter of the SIPS Request URI must also indicate a reliable transport method (tls in the case of TCP, or tls-sctp in the case of SCTP). The Co
49、ntact header in the INVITE must contain a SIPS URI. Likewise, the Contact header in the 200 OK response must contain a SIPS URI. RFC 3261, RFC 2246, RFC 4168 TLS must be used from the caller to the domain of the called party, which in this scenario would include going across the NNI. Use of a SIPS URI and therefore TLS also means that a reliable transport must be in use (i.e., TCP or SCTP; not UDP). 35. Simple voice call between SIP end-devices that support the regular form of SIP header names. Use of the regular form
