ITU-T Q 3401 AMD 1-2008 NGN NNI signalling profile (protocol set 1) Amendment 1 Extensions of NGN NNI signalling profile including video and data services (Study Group 11)《NGN NNI信.pdf

1、 International Telecommunication Union ITU-T Q.3401TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU Amendment 1(02/2008) SERIES Q: SWITCHING AND SIGNALLING Signalling requirements and protocols for the NGN Service and session control protocols NGN NNI signalling profile (protocol set 1) Amendment 1:

2、Extensions of NGN NNI signalling profile including video and data services Recommendation ITU-T Q.3401 (2007) Amendment 1ITU-T Q-SERIES RECOMMENDATIONS SWITCHING AND SIGNALLING SIGNALLING IN THE INTERNATIONAL MANUAL SERVICE Q.1Q.3 INTERNATIONAL AUTOMATIC AND SEMI-AUTOMATIC WORKING Q.4Q.59 FUNCTIONS

3、AND INFORMATION FLOWS FOR SERVICES IN THE ISDN Q.60Q.99 CLAUSES APPLICABLE TO ITU-T STANDARD SYSTEMS Q.100Q.119 SPECIFICATIONS OF SIGNALLING SYSTEMS No. 4, 5, 6, R1 AND R2 Q.120Q.499 DIGITAL EXCHANGES Q.500Q.599 INTERWORKING OF SIGNALLING SYSTEMS Q.600Q.699 SPECIFICATIONS OF SIGNALLING SYSTEM No. 7

4、Q.700Q.799 Q3 INTERFACE Q.800Q.849 DIGITAL SUBSCRIBER SIGNALLING SYSTEM No. 1 Q.850Q.999 PUBLIC LAND MOBILE NETWORK Q.1000Q.1099 INTERWORKING WITH SATELLITE MOBILE SYSTEMS Q.1100Q.1199 INTELLIGENT NETWORK Q.1200Q.1699 SIGNALLING REQUIREMENTS AND PROTOCOLS FOR IMT-2000 Q.1700Q.1799 SPECIFICATIONS OF

5、SIGNALLING RELATED TO BEARER INDEPENDENT CALL CONTROL (BICC) Q.1900Q.1999 BROADBAND ISDN Q.2000Q.2999 SIGNALLING REQUIREMENTS AND PROTOCOLS FOR THE NGN Q.3000Q.3999 General Q.3000Q.3029 Network signalling and control functional architecture Q.3030Q.3099 Network data organization within the NGN Q.310

6、0Q.3129 Bearer control signalling Q.3130Q.3179 Signalling and control requirements and protocols to support attachment in NGN environments Q.3200Q.3249 Resource control protocols Q.3300Q.3369 Service and session control protocols Q.3400Q.3499 Service and session control protocols supplementary servi

7、ces Q.3600Q.3649 NGN applications Q.3700Q.3849 Testing for NGN networks Q.3900Q.3999 For further details, please refer to the list of ITU-T Recommendations. Rec. ITU-T Q.3401 (2007)/Amd.1 (02/2008) i Recommendation ITU-T Q.3401 NGN NNI signalling profile (protocol set 1) Amendment 1 Extensions of NG

8、N NNI signalling profile including video and data services Summary Amendment 1 to Recommendation ITU-T Q.3401 contains extensions including video and data services to Recommendation ITU-T Q.3401 (2007), which supported only voice band services in the first version. Source Amendment 1 to Recommendati

9、on ITU-T Q.3401 (2007) was approved on 29 February 2008 by ITU-T Study Group 11 (2005-2008) under Recommendation ITU-T A.8 procedure. ii Rec. ITU-T Q.3401 (2007)/Amd.1 (02/2008) FOREWORD The International Telecommunication Union (ITU) is the United Nations specialized agency in the field of telecomm

10、unications, information and communication technologies (ICTs). The ITU Telecommunication Standardization Sector (ITU-T) is a permanent organ of ITU. ITU-T is responsible for studying technical, operating and tariff questions and issuing Recommendations on them with a view to standardizing telecommun

11、ications on a worldwide basis. The World Telecommunication Standardization Assembly (WTSA), which meets every four years, establishes the topics for study by the ITU-T study groups which, in turn, produce Recommendations on these topics. The approval of ITU-T Recommendations is covered by the proced

12、ure laid down in WTSA Resolution 1. In some areas of information technology which fall within ITU-Ts purview, the necessary standards are prepared on a collaborative basis with ISO and IEC. NOTE In this Recommendation, the expression “Administration“ is used for conciseness to indicate both a teleco

13、mmunication administration and a recognized operating agency. Compliance with this Recommendation is voluntary. However, the Recommendation may contain certain mandatory provisions (to ensure e.g. interoperability or applicability) and compliance with the Recommendation is achieved when all of these

14、 mandatory provisions are met. The words “shall“ or some other obligatory language such as “must“ and the negative equivalents are used to express requirements. The use of such words does not suggest that compliance with the Recommendation is required of any party. INTELLECTUAL PROPERTY RIGHTS ITU d

15、raws attention to the possibility that the practice or implementation of this Recommendation may involve the use of a claimed Intellectual Property Right. ITU takes no position concerning the evidence, validity or applicability of claimed Intellectual Property Rights, whether asserted by ITU members

16、 or others outside of the Recommendation development process. As of the date of approval of this Recommendation, ITU had not received notice of intellectual property, protected by patents, which may be required to implement this Recommendation. However, implementers are cautioned that this may not r

17、epresent the latest information and are therefore strongly urged to consult the TSB patent database at http:/www.itu.int/ITU-T/ipr/. ITU 2008 All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the prior written permission of ITU. Rec. ITU-T Q.3401 (2

18、007)/Amd.1 (02/2008) iii CONTENTS Page 1) Clause 1 Scope. 1 2) Clause 2.1 ITU-T references 1 3) Clause 2.2.1 Service-level signalling specifications 1 4) Clause 2.2.2 Transport-level specifications. 1 5) Clause 4 Abbreviations 2 6) Clause 6 Assumptions . 2 7) Clause 7 Media Availability in a SIP Ses

19、sion . 2 8) Clause 8.1 Codec list . 2 9) Clause 10.1 RFCs to be supported. 3 10) Clause 10.2.1.13 Initiating a session . 3 11) Clause 10.2.1.20.5 Allow 3 12) Clause 10.2.1.20.11 Content-Disposition 3 13) Clause 10.2.1.20.15 Content-Type 3 14) Clause 10.2.1.20.32 Require 4 15) Clause 10.2.1.20.37 Sup

20、ported 4 16) Clause 10.2.2.1 Extended methods 4 17) Clause 10.3 SDP profile 4 18) Clause 11 Transport-level profile 4 19) Clause I.4 IP-IP-(NNI)-IP-IP in Appendix I Call/signalling flows 4 Rec. ITU-T Q.3401 (2007)/Amd.1 (02/2008) 1 Recommendation ITU-T Q.3401 NGN NNI signalling profile (protocol set

21、 1) Amendment 1 Extensions of NGN NNI signalling profile including video and data services 1) Clause 1 Scope Modify the third paragraph as follows: add the words shown underlined and delete the words shown with strike-through: For the protocol set 1 of the NGN NNI signalling profile, this Recommenda

22、tion covers the multimedia (voice, video and data) which include voiceband services such as VoIP, multimedia telephony (audio, text and so on), DTMF and, T.38 fax, and multimedia ring back and ringing tones and annoucements. 2) Clause 2.1 ITU-T references Modify the subclause title as follows: add t

23、he words shown underlined, and add the following new references: 2.1 ITU-T and ISO/IEC references ITU-T H.263 Recommendation ITU-T H.263 (2005), Video coding for low bit rate communication. ITU-T H.264 Recommendation ITU-T H.264 (2007), Advanced video coding for generic audiovisual services. ISO/IEC

24、 14496-2 ISO/IEC 14496-2:2004, Information technology Coding of audio-visual objects Part 2: Visual. ISO/IEC 14496-3 ISO/IEC 14496-3:2005, Information technology Coding of audio-visual objects Part 3: Audio. 3) Clause 2.2.1 Service-level signalling specifications Add the following new reference: IET

25、F RFC 4145 IETF RFC 4145 (2005), TCP-Based Media Transport in the Session Description Protocol (SDP). 4) Clause 2.2.2 Transport-level specifications Add the following new references: IETF RFC 3016 IETF RFC 3016 (2000), RTP Payload Format for MPEG-4 Audio/Visual Streams. IETF RFC 3711 IETF RFC 3711 (

26、2004), The Secure Real-time Transport Protocol (SRTP). IETF RFC 3984 IETF RFC 3984 (2005), RTP Payload Format for H.264 Video. 2 Rec. ITU-T Q.3401 (2007)/Amd.1 (02/2008) IETF RFC 4629 IETF RFC 4629 (2007), RTP Payload Format for ITU-T Rec. H.263 Video. 5) Clause 4 Abbreviations Add the following new

27、 abbreviations: DTMF Dual-Tone Multi-frequency MPEG Moving Picture Experts Group NGN Next Generation Network VoIP Voice over IP 6) Clause 6 Assumptions Add the following words shown underlined to the fifth and seventh items: 5) Only the nNetwork-to-network interface (NNI) is supported between two pe

28、ering VoIP and also multimedia telephony carriers. There may be an IP transit network between two peering VoIP and multimedia telephony service providers. 7) RTP or SRTP is used for voice and video transport; other transport protocols may be used for data applications. 7) Clause 7 Media Availability

29、 in a SIP Session a) Add a new clause title before the current text 7.1 Consideration related to media packets b) Add a new clause 7.2 7.2 Addition or deletion of any media stream Any media session established across the NNI using SIP starts either with one kind of media type (e.g., voice) or with d

30、ifferent kind of media types for multiple media streams (e.g., voice and video) by exchanging SDP offer/answer between the originating and terminating parties. Adding different type of media streams or removing any other kind of media streams is possible during the communication. 8) Clause 8.1 Codec

31、 list Add the text shown underlined and delete the word shown with strike-through: NOTE 4 For voice communication, wWhile any codec may be used within the codec list based on the bilateral agreement, it is recommended that the list contain AMR NB EN 301 703, EVRC TIA-127, G.729 G.729, G.729A G.729A,

32、 G.722.1 G.722.1, and G.726 G.726, and MPEG-4 Audio ISO/IEC 14496-3. To enable the provision of voice service with a superior quality, it is highly recommended that the list contain a wide-band codec such as AMR-WB G.722.2, VMR-WB TIA-1016, G.722 G.722, G.729.1 G.729.1. To support hard of hearing, i

33、t is recommended that T.140 T.140 is supported as a codec in the codec list. Where the interconnect is to an existing PSTN/ISDN, it is recommended that T.140 T.140 is adapted to be carried over G.711 A/ law G.711. For video communication, the codec list is recommended to contain H.263 H.263, H.264 H

34、.264, and MPEG-4 Visual ISO/IEC 14496-2. For data communication, it is recommended that the networks establish bilateral agreements about the data applications used over the NNI. Rec. ITU-T Q.3401 (2007)/Amd.1 (02/2008) 3 9) Clause 10.1 RFCs to be supported Insert the following new line into Table 1

35、0-1: Table 10-1 RFCs to be supported SIP Extensions Title M/O IETF RFC 4145 IETF RFC 4145 TCP-Based Media Transport in the Session Description Protocol (SDP) O 10) Clause 10.2.1.13 Initiating a session Add the following text shown underlined: When the initial INVITE includes an SDP offer, an SDP ans

36、wer may be included either in the provisional reliable non-failure response to the INVITE (e.g., 183-Session-Progress sent reliably) or in the final non-failure response to the INVITE (i.e., 2xx), and, if not included in the provisional reliable non-failure response, shall be included in the final n

37、on-failure response. If the final non-failure response includes an SDP answer, the same value of SDP may be included in the provisional unreliable non-failure response to the INVITE. 11) Clause 10.2.1.20.5 Allow Add the following texts shown underlined and delete the words shown with strike-through:

38、 The Allow header shall be supported as specified in RFC 3261 section 20.5 except as noted below. The Allow header shall be present in the initial INVITE and the 2xx response to the initial INVITE. The header value shall list all supported methods, i.e., at a minimum e.g., INVITE, ACK, CANCEL, BYE,

39、UPDATE, and PRACK. However, the SCF needs to prepare to receive messages without the Allow header field. The SCF should continue the call control even if the Allow header is not present in the initial INVITE and the 2xx response to the initial INVITE. 12) Clause 10.2.1.20.11 Content-Disposition Add

40、the following text between the second and third paragraphs: If early media is provided by the application server model defined in IETF RFC 3959, the Content-Disposition header shall include the “early-session“ value as specified in IETF RFC 3959. 13) Clause 10.2.1.20.15 Content-Type Add the followin

41、g text to the end of this subclause: If early media is provided by the application server model defined in IETF RFC 3959, the content type “multipart/mixed“ shall be supported as specified in IETF RFC 2046 to specify different session types (e.g., normal session and early session). Each Content-Type

42、 encloses its specification by using the “boundary“ tag in this header. 4 Rec. ITU-T Q.3401 (2007)/Amd.1 (02/2008) 14) Clause 10.2.1.20.32 Require Add the following text to the end of this subclause: If early media is provided by the application server model defined in IETF RFC 3959 and UAC expects

43、the UAS to support the process of the early media request, the Require header shall include the “early-session“ value as specified in IETF RFC 3959. 15) Clause 10.2.1.20.37 Supported Add the following text to the end of this subclause: If early media is provided by the application server model defin

44、ed in IETF RFC 3959, the Supported header shall include the “early-session“ value as specified in IETF RFC 3959. 16) Clause 10.2.2.1 Extended methods Add the following text to the end of this subclause: While communicating, addition of different media or removal of any media from earlier established

45、 media session should be performed by using re-INVITE instead of UPDATE with new media descriptions which contain modified SDP profiles according to the SDP offer/answer procedure. 17) Clause 10.3 SDP profile Add the following text to the end of this subclause: If a media session across the NNI util

46、izes video, the media type “video“ shall be supported. The media description specified in Table 10-7 (i.e., media codec, its attributes and values) is exchanged in a SIP/SDP message to set up a video connection. 18) Clause 11 Transport-level profile Insert the following new lines into Table 11-1: Ta

47、ble 11-1 Supported transport-level RFCs to be described in SIP/SDP messages RFC Title M/O RFC 3016 IETF RFC 3016 RTP Payload Format for MPEG-4 Audio/Visual Streams O RFC 3711 IETF RFC 3711 The Secure Real-time Transport Protocol (SRTP) O RFC 3984 IETF RFC 3984 RTP Payload Format for H.264 Video O RF

48、C 4629 IETF RFC 4629 RTP Payload Format for ITU-T Rec. H.263 Video O 19) Clause I.4 IP-IP-(NNI)-IP-IP in Appendix I Call/signalling flows Add new subclauses I.4.3 and I.4.4: I.4.3 Adding video session after a basic call setup Figure I.9 shows a sequence of SIP messages for adding new media (e.g., vi

49、deo) after call set-up has been completed across NNI. A corresponding example of this is seen when two UAs first establish a voice connection and later decide to exchange video data (e.g., pictures, images) using the same connection. In this way, a video session is added by exchanging new SDP information which contains a set of audio and video attributes. NOTE Internal signalling mes