ATIS 1000032-2008 SIP User-Network Interface Testing Framework.pdf

1、 TECHNICAL REPORT ATIS-1000032 SIP USER-NETWORK INTERFACE TESTING FRAMEWORK ATIS is the leading technical planning and standards development organization committed to the rapid development of global, market-driven standards for the information, entertainment and communications industry. More than 20

2、0 companies actively formulate standards in ATIS Committees, covering issues including: IPTV, Cloud Services, Energy Efficiency, IP-Based and Wireless Technologies, Quality of Service, Billing and Operational Support, Emergency Services, Architectural Platforms and Emerging Networks. In addition, nu

3、merous Incubators, Focus and Exploratory Groups address evolving industry priorities including Smart Grid, Machine-to-Machine, Networked Car, IP Downloadable Security, Policy Management and Network Optimization. ATIS is the North American Organizational Partner for the 3rd Generation Partnership Pro

4、ject (3GPP), a 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). ATIS is accredited by the American National Standards Institute (ANSI). For more informat

5、ion, please visit . Notice of Disclaimer and also does not specify particular testing methods This testing framework does not address identification of the responsible organization performing the testing testing for services; however, services may be used as stimuli to invoke aspects of protocols th

6、at are to be tested load testing simultaneous testing of multiple UNIs between a network and customer equipment. This TR addresses testing of a single UNI at a time. failure scenarios test cases that intentionally result in a protocol timeout Successful interoperability testing should be verifiable

7、strictly by observing what happens across the UNI. Test generation and some verification methods may pragmatically involve the placement of actual telephone calls and observing results from that user point of view. Before defining specific test plans, the network operator and CE operator involved sh

8、all agree on what subset of the SIP UNI ANS they are implementing. Testing could follow various models. For example: a. Conduct a full suite of tests exercising the entire interface as defined in the SIP UNI ANS, and verify which pass. An advantage of this approach is that it can discover capabiliti

9、es supported across the interface that may not otherwise have been known to or agreed to by the network operator and CE operator. b. Conduct a test suite that exercises a subset of the entire interface in the SIP UNI ANS, where that subset is limited to aspects of the SIP UNI ANS that are agreed to

10、by the network operator and CE operator. An advantage of this approach is that it may involve ATIS-1000032 -6- less testing. The subset may depend to some degree, for example, on the nature of the IP network or CE. The exercise of the testing guidelines and call stimulus scenarios contained in this

11、document are intended to have no impact on the integrity or reliability of existing services being supported in a live network. 1.1 Types of Users The SIP UNI ANS describes two SIP profiles, one for each of the basic User types of the UNI: Device, where the devices can be, e.g., SIP phones, software

12、 applications that run on PCs and provide a SIP UA interface, or analog terminal adaptors that provide a SIP UA interface, Enterprise Network The difference between the two profiles in the SIP UNI ANS is in which protocol aspects are mandatory, as opposed to optional. Therefore, all of the material

13、in this TR potentially pertains to both types. 2 Definitions For protocol-specific terminology, the reader should consult the corresponding protocol specifications. 3 Abbreviations AIB Authenticated Identity Body ANS American National Standard APRI Address Presentation Restricted Indicator AS Applic

14、ation Server ATIS Alliance for Telecommunications Industry Solutions CE Customer Equipment CPIM Common Presence and Instant Messaging DHCP Dynamic Host Configuration Protocol DiffServ Differentiated Service DNS Domain Name System DTMF Dual Tone Multi-Frequency ETS Emergency Telecommunications Servic

15、e FQDN Fully Qualified Domain Name IAM Initial Address Message ICE Interactive Connectivity Establishment IETF Internet Engineering Task Force IFP Internet Fax Protocol IP Internet Protocol ISDN Integrated Services Digital Network ISUP ISDN User Part ITU International Telecommunication Union LEC Loc

16、al Exchange Carrier MIME Multi-part Internet Mail Extensions MS Media Server NAPTR Naming Authority Pointer NAT Network Address Translator NI Network Interconnect NP Number Portability OSI Open Systems Interconnect POTS Plain Old Telephone Service PSTN Public Switched Telephone Network RFC Request F

17、or Comments RR Resource Record RTCP Real-Time Control Protocol RTP Real-time Transport Protocol SACK Selective ACKknowledge SCTP Stream Control Transmission Protocol SDP Session Description Protocol SIP Session Initiation Protocol SIPS SIP-Secure SLA Service Level Agreement S/MIME Secure MIME SNTP S

18、imple Network Time Protocol SRV Service Location STUN Simple Traversal of UDP over NATs TCP Transmission Control Protocol TLS Transport Layer Security TR Technical Report TURN Traversal Using Relay NAT UDP User Datagram Protocol UNI User-Network Interface URI Uniform Resource Identifier URL Uniform

19、Resource Locator VoIP Voice over IP WPS Wireless Priority Service XR Extended ReportsATIS-1000032 -7- 4 Physical and Data Link Layers At the physical and data link layers there is no distinctive treatment of SIP or media versus data, or among SIP or media traffic types, and thus nothing specific to

20、test in regard to SIP or media. Tests should be conducted to verify the satisfactory operation of those layers, but since there is no distinction from treatment of data traffic, testing at those layers is not addressed in this document. 5 Network Layer Aspects of the network layer that may involve t

21、reatment of SIP or media different from data are addressed in this TR. 5.1 IP Addresses The use of the IP addresses and port numbers as required and agreed to by the network and/or CE operator should be verified. Note that IP addresses for different types of IP packet payload may be different; for e

22、xample, IP addresses for UDP payload versus TCP payload, or IP addresses for SIP signaling payload over UDP versus RTP media payload over UDP. 5.2 Priority Differentiation Traffic priority across the UNI may be differentiated at the IP packet level through the use of DiffServ code points. When emplo

23、yed, the use of such differentiation in DiffServ should be verified. The SIP UNI may more generally be an IP UNI that carries 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 diff

24、erentiated treatment. 5.3 IP Payload Protocol Indication Proper indication within IP of the payload protocol should be verified (i.e., use of the Protocol field in IPv4 or the Next Header field in IPv6). 6 Signaling Transport The SIP UNI ANS identifies the use of TCP, UDP, or TLS over TCP for SIP si

25、gnaling transport. In addition, TCP, TLS over TCP and especially UDP may be used for other rudimentary signaling-related activity across the UNI, as indicated in later sections in this TR; for examp le, for initial IP address acquisition, DNS server location, time acquisition, or NAT traversal. 6.1

26、UDP The use of UDP for SIP transport is the same as for other types of UDP payload. Therefore, there are no specific 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 fr

27、om those for other types of UDP payload. Likewise, there is nothing special to test for other uses of UDP transport in the SIP UNI ANS. ATIS-1000032 -8- 6.2 TCP As with UDP, there is nothing special about the use of TCP for SIP signaling transport versus other kinds of TCP payload. However, unlike U

28、DP, 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 the desired TCP connection characteristics of window size and maximum segment si

29、ze. Likewise, there is nothing special to test for other uses of TCP transport in the SIP UNI ANS. 6.3 TLS over TCP TLS is an encryption method for security. See section 17. 7 Configuration The primary references for this section are - RFC 4504 SIP Telephony Device Requirements and Configuration - R

30、FC 3263 Session Initiation Protocol (SIP): Locating SIP Servers - RFC 4330 Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI 7.1 Automatic IP Address Acquisition A device needs to acquire an IP address for itself before it can do anything else across the UNI. DHCP is used for that

31、 purpose. DHCP uses the User Datagram Protocol (UDP), i.e., DHCP messages ride as payload in UDP datagrams. The DHCP server may supply other information in addition to a device IP address, such as domain name, DNS server address, SNTP (time) server address, or TCP/IP subnet mask and default gateway.

32、 1) The device sends a DHCPDISCOVER message that includes among other things UDP source address of 0.0.0.0 UDP destination address typically 255.255.255.255 the device MAC address a Magic Cookie value 0x63825363 2) One or more DHCP servers may respond to the device with DHCPOFFER messages that inclu

33、des UDP source address as the IP address of the DHCP server UDP destination address as the offered IP address that may be assigned to the device the device MAC address the same Magic Cookie value duration of the IP address lease other TCP/IP configuration information such as subnet mask and default

34、gateway possibly other information such as domain name, DNS server addresses, SNTP server addresses The device chooses an offer from one of the DHCP servers. 3) The device broadcasts a DHCPREQUEST message (that basically informs all the DHCP servers which offer the device is accepting) that includes

35、 UDP source address is 0.0.0.0 UDP destination address is 255.255.255.255 the device MAC address ATIS-1000032 -9- the same Magic Cookie value the IP address of the DHCP server whose offer the device is accepting the IP address that that DHCP server is offering 4) The DHCP server whose offer the devi

36、ce is accepting sends a DHCPACK message to the (IP address of) the device; the message content reconfirms what was in the original offer from that DHCP server. 7.2 Locating a SIP Server It is assumed that the device has a SIP request that it wants to send to a resource identified by a SIP or SIPS UR

37、I (e.g., a called party). The device needs to locate a SIP server to which it can send the request. The device needs to discover an IP address and port number of such a SIP server, along with the transport protocol(s) the server supports. Once a device discovers a SIP server, it may remember that se

38、rvers address, port number and transport protocol so that it does not have to re-discover that information for each subsequent SIP request pertaining to the same domain.1One or more SIP servers may be located. The description here assumes the device has no knowledge of a SIP server protocol or addre

39、ss/port number. Discovery happens in two steps (a) transport protocol and then (b) address/port number. For both steps the device will utilize a DNS server (known, e.g., through the devices IP address acquisition by a DHCP query as described in Section 7.1 above.) DNS queries may use either UDP or T

40、CP for transport. 7.2.1 Transport Protocol Discovery 1) The device sends a NAPTR-type DNS query2to the DNS server, where the key information contained is the “target” (in RFC 3263 jargon, which is the value of the URI maddr parameter, else the value of the domain part of the URI). The target informa

41、tion is passed in a “Question” field within the DNS query. 2) The DNS server sends a response with NAPTR resource records (RRs) in “Answer” fields. Those NAPTR RRs provide a mapping from the “target” (i.e, the called domain) to the set of transport protocols that target/domain prefers to use, and th

42、e addresses of corresponding SIP servers supporting those transport protocols. A given server may appear multiple times with multiple transport protocols. (With the received information, the device can determine the intersection of its own transport protocol capabilities with what transport protocol

43、 it preferentially would use with some SIP server.) 7.2.2 SIP Server IP Address / Port Number Discovery 1) The device sends a SRV-type DNS query3to the DNS server, where the key information contained is the URI type plus the target value plus the transport protocol type (e.g., _sip._). That informat

44、ion is passed in a “Question” field within the DNS query. 1It may also be that, e.g., a SIP URI includes identification of a transport protocol (say SCTP) that the currently known SIP server doesnt support. In that case the device would have to attempt to discover another SIP server that can support

45、 that transport protocol. 2Binary coding of decimal 1 or 28 in the Type field of the DNS query header indicates a NAPTR-type DNS query for servers with IPv4 addresses or with IPv6 addresses, respectively. Such queries are also referred to as A and AAAA, respectively, which are the codepoint labels f

46、or 1 and 28, respectively. 3Binary coding of decimal 33 in the Type field of the DNS query header indicates a SRV-type DNS query. ATIS-1000032 -10- 2) The DNS server returns a DNS response that contains SRV RRs in “Answer” fields, where each RR has a server IP address, port number and other informat

47、ion. There may be multiple SRV RRs (i.e., multiple SIP servers) for reliability and load-sharing purposes. (Note that the IP address may typically be in FQDN format such as “”, as opposed to numeric format.) 7.2.3 Relationship of “Outbound Proxy” to Locating a SIP Server The UNI Specification includ

48、es the concept of an “Outbound Proxy”. It is a SIP server in the network to which the user-side device or enterprise network would send all SIP requests. That Outbound Proxy either - may be provisioned into the device/enterprise network as such, in which case the method above for locating a SIP serv

49、er is not performed or - may be located by the method described above, because the network DNS data is such that there is only one logical SIP server. 7.3 Time Acquisition SNTP uses the User Datagram Protocol (UDP), i.e., DHCP messages ride as payload in UDP datagrams. The description here assumes the device is using the SNTP unicast mode, where the device sends a request to a specific server.4The device may periodically send SNTP request messages. 1) The Device sends a SNTP request in a UDP datagram