1、 TECHNICAL REPORT ATIS-1000040 PROTOCOL SUITE PROFILE FOR IP NETWORK TO NETWORK INTERCONNECTION RELEASE 1.0 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 commu
2、nications 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 addition, numerous Incubators
3、, 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 member and major U.S. co
4、ntributor 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 . Notice of Disclaimer however, additional work will be required to develop actual test scrip
5、ts based on the test scenarios, configurations, and protocol suites presented 3. It is understood that test SIP device endpoint E.164 addresses will need to be exchanged prior to testing. SIP URIs converted from TEL URI format will be used to convey the E164 addresses. (See ATIS-1000009.2006 for exa
6、mple URIs.) 4. IPv4 is assumed unless otherwise stated. 5. The term Provider is used to generically represent all types of parties. 2 REFERENCES The following standards contain provisions which, through reference in this text, constitute provisions of this ATIS Standard. At the time of publication,
7、the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this ATIS Standard are encouraged to investigate the possibility of applying the most recent editions of the standards indicated below. 2.1 ATIS1(normative) ATIS-1000009.2006, IP Network-to-N
8、etwork Interface (NNI) Standard for VoIP. ATIS-1000026.2008, Session/Border Control Functions and Requirements. 2.2 IETF2(normative) RFC 4244, An Extension to the Session Initiation Protocol (SIP) for Request History Information. 2.3 ATIS3(informative) PTSC-SAC-2010-033R1, TR on History Info in Carr
9、ier Network. 1These documents are available from the Alliance for Telecommunications Industry Solutions (ATIS), 1200 G Street N.W., Suite 500, Washington, DC 20005. 2This document is available from the Internet Engineering Task Force (IETF). 3This reference is a committee contribution. PTSC committe
10、e participants can access this document at . Copies of this contribution will be made available to all other interested parties upon request. Such request should be made to the ATIS Document Center Administrator at . ATIS-1000040 3 3 ACRONYMS user=phone” Other formats are out of scope for Release 1.
11、0. ATIS-1000040 7 IETF RFC 3911, The Session Initiation Protocol (SIP) “Join“ Header, September 2004. 1. Testing of this RFC is out of scope for Release 1.0. The support of RFC 3911 is contingent upon whether Call Center Transfer Services are supported. IETF RFC 3892, The SIP Referred-By Mechanism,
12、September 2004. 1. Testing of this RFC is out of scope for Release 1.0. The support of RFC 3892 is contingent upon whether Call Center Transfer Services are supported. IETF RFC 3891, The Session Initiation Protocol (SIP) “Replaces“ Header, September 2004. 1. Testing of this RFC is out of scope for R
13、elease 1.0. The support of RFC 3891 is contingent upon whether Call Center Transfer Services are supported. IETF RFC 4412, Communications Resource Priority for the Session Initiation Protocol (SIP), February 2006. 1. Testing of this RFC will be supported; however, there are no specific requirements
14、to be highlighted or excluded. IETF RFC 4028, Session Timers in SIP, February 2005. 1. The SIP Timer refresh mechanism is out of scope for Release 1.0. IETF RFC 3960, Early Media and Ringback Tone Generation in the Session Initiation Protocol, December 2004. 1. After a SIP method Invite with offer h
15、as been sent or received across the NNI, the Media Ports on both sides of the NNI shall be open accordingly. 2. The SIP 180 Ringing with no SDP shall be accepted (and a local ring back tone is assumed to be generated accordingly). 3. When an SIP 180 Ringing with SDP is sent or received, the Media Po
16、rts on both sides of the NNI shall be open for the specified media packets. 4. When an SIP 183 Session Progress is received, the Media Port may only admit the media packets associated with the first RTP stream until a subsequent response is received. 5. The RFC 2543 call hold mechanism using the hol
17、d SDP (c=0.0.0.0) may be ignored. Testing of this RFC is out of scope for Release 1.0. IETF RFC 4694, Number Portability Parameters for the “tel” URI. 1. Testing of this RFC is out of scope for Release 1.0. IETF RFC 3311, The Session Initiation Protocol (SIP) UPDATE method. 1. This is out of scope f
18、or Release 1.0. Draft-ietf-levy-diversion-11 (expired August 2010) 1. This is out of scope for Release 1.0. IETF RFC 4244, An Extension to SIP for Request History Information. 1. This is out of scope for Release 1.0. 4.1.1.2 SDP ATIS-1000040 8 IETF RFC 4566, SDP: Session Description Protocol. 1. SDP
19、 unicast session shall be supported. 2. SDP address via IPv4 format shall be supported. 3. SDP for multi-cast sessions is out of scope for Rel. 1.0. 4. SDP address format via FQDN is out of scope for Rel. 1.0. 4.1.2 Media 4.1.2.1 Voice Codec Profile Section 9 of ATIS-1000009.2006: o The ITU-T G.711
20、codec shall be tested during SIP media session negotiation via SDP. o The ITU-T G.729 codec shall be tested during SIP media session negotiation via SDP. o The ITU-T T.38 fax over UDPTL over UDP shall be tested during SIP media session negotiation via SDP. 4.1.2.2 RTP Profile for SIP based VoIP Serv
21、ice Interconnection (RTP/ RTCP) References: 1. IETF RFC 3550 (2003), RTP: A Transport Protocol for Real-Time Applications. 2. IETF RFC 3551 (2003), RTP Profile for Audio and Video Conferences with Minimal Control. 3. IETF RFC 3389 (2002), RTP Payload for Comfort Noise.4.2 DTMF over RTP 4.2.1. Signal
22、ing Reference: IETF RFC 4733, RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals. 1. SDP shall support the use of dynamic payload type to specify telephone-event for events 0-11 covering 0-9, #, and *. 4.2.2. Media Reference: IETF RFC 4733, RTP Payload for DTMF Digits, Telephony Ton
23、es, and Telephony Signals. 1. The DTMF Named Events for 0-9, * and # in RFC 4733 shall be tested. 2. The dynamic payload type of RFC 4733 shall be tested. 3. The same dynamic payload type first offered shall be used in both directions. ATIS-1000040 9 4. The SDP answer shall indicate the list of supp
24、orted named events. 4.3 Basic Fax Service with T.38 Support 4.3.1. Signaling Same as those in Basic Voice Service with the following: In the SIP Offer and Answer messages, SDP shall support AVP image/t38. In the SIP Offer and Answer messages, SDP may support AVP audio/t38. 4.3.2 Media 4.3.2.1 ITU-T
25、T.38 T.38 is an ITU-T standards recommendation for protocols used for the transmission of Group 3 fax over an IP network. This section defines a T.38 protocol profile to be used in conjunction with the T.38 Fax Test Suites as defined in ATIS-1000041. A summary of the key requirements and exceptions
26、is listed below in section 4.3.3.1.1. Annex A, T.38 Protocol Normative Reference, specifies variances to the T.38 recommendations and is assumed as a base. Fax Service references are included in section 4.3.3.1.2. 4.3.3.1.1 T.38 NNI Protocol Profile To support the exchange of fax documents over a ne
27、twork to network interface, the following requirements are defined for this document. T.38 Protocol Service Profile at the network to network interface (NNI): 1. SIP v.2 (RFC 3265) shall be supported to set up or tear down T.38 Fax connections. 2. Transport of T.38 fax data via UDP using the UDP tra
28、nsport layer (UDPTL) shall be supported. 3. Transport of T.38 fax data via RTP over UDP or TCP may be supported. 4. Transport of T.38 fax data over TCP may be supported. 5. The media gateway Autonomous Transition Method described in T.38 Annex E may be supported. 6. The negotiation for T.38 Error Co
29、rrection Mode (ECM) for UDPTL connections shall be supported so that an Invite (or re-Invite) with ECM parameters will not be rejected by default. 7. The use of the parity based forward error correction described in T.38 Annex C for UDPTL connections may be supported. 8. A G.711 u-Law Fall-Back and
30、Pass-Through negotiation shall be supported if a T.38 fax connection negotiation failed. 9. When a T.38 or G.711 Pass-Through fax connection is successfully negotiated, the existing media (voice) connection shall be dropped. 10. Upon completion of a T.38 or G.711Pass-Through fax transmission, a new
31、re-Invite negotiation for re-Invite to restore the voice connection shall be supported. ATIS-1000040 10 11. If the originating endpoint rejects the re-Invite for a T.38 connection for reasons such as 415 “Unsupported Media Type” response or 606/488 “Not Acceptable Response”, the existing media (voic
32、e) connection shall be kept alive. 12. The nominal maximum bit rate for fax transmission at 14.4 Kbits/s shall be supported. Operation at a higher bit rate is not precluded subjecting to the capabilities of the endpoints. 4.3.3.1.2 Basic Fax Service References ITU-T: ITU-T Recommendation T.38 (2007)
33、, Procedures for real-time Group 3 facsimile communication over IP networks. ITU-T Recommendation T.30 (1996), Procedures for document facsimile transmission in the general switched telephone network. IETF: IETF RFC 2833 (2000), RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals. IET
34、F RFC 3261 (2002), SIP: Session Initiation Protocol. IETF RFC 3362 (2002), Real-time Facsimile (T.38) - image/t38 MIME Sub-type Registration. IETF RFC 3264 (2002), An Offer/Answer Model with the Session Description Protocol (SDP). IETF RFC 4566 (2006), SDP: Session Description Protocol. IETF RFC 461
35、2 (2006), Real-Time Facsimile (T.38) - audio/t38 MIME Sub-type Registration. 1. This RFC is out of scope for Rel. 1.0. 5 TRANSPORT, NETWORK, TUNNEL/LINK AND TRANSPORT LAYERS This clause provides a generic list of transport/network protocols to support the VoIP service in Release 1.0. 5.1 Transport 5
36、.1.1 UDP IETF RFC 768, User Datagram Protocol. 5.1.2. TCP IETF RFC 769, Transmission Control Protocol. 5.1.3 TLS IETF RFC 5246, The Transport Layer Security (TLS) Protocol, Version 1.2. 5. 2 IP Network 5.2.1 IP Routing and Control Static Route is assumed for Release 1.0. 5.2.2 IP Forwarding IETF RFC
37、 791, Internet Protocol. ATIS-1000040 11 ATIS-1000007.2006, Generic Signaling and Control Plane Security Requirements for Evolving Networks defines the options for IPSEC. 5.3 Tunneling or Link Layer 5.3.1 Ethernet IEEE 802.3, LAN/MAN CSMA/CD (Ethernet) Access Method. 5.4 Physical Layer 5.4.1 Etherne
38、t IEEE 802.3, LAN/MAN CSMA/CD (Ethernet) Access Method. ATIS-1000040 12 Annex A A T.38 PROTOCOL NORMATIVE REFERENCE The following normative reference to ITU-T Recommendation T.38 (2007), Procedures for real-time Group 3 facsimile communication over IP networks, specifies the sections that are inform
39、ational, will be supported, or are in scope for the ANS IP Network-to-Network Interface (NNI) Standard for VoIP. All sections that are not explicitly mentioned are deemed to be out of scope. Sections 1 thru 5 are informational. Section 6.1, Internet Protocol TCP or UDP, only UDP will be supported. T
40、he sections that follow are deemed to be in scope: 6.2 Gateway facsimile data transfer functions 7 IFT protocol definition and procedures 9.1 IFT over UDP transport using UDPTL protocol: IFT/UDPTL/UDP 10.1 V.8 negotiation 10.3 Facsimile mode. 10.4 Compatibility with equipment conforming to prior versions of this Recommendation Annex A ASN.1 notation Annex D SIP/SDP call establishment procedures Appendix V.3.3 (V.3.3 Incorrect use of the colon (“:“) in several T.38 attributes in Annex D) Appendix V.3.4 (Case sensitivity of udptl and T38MaxBitRate in SIP and H.248.1)
