1、 International Telecommunication Union ITU-T Q.1970TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (09/2006) SERIES Q: SWITCHING AND SIGNALLING Specifications of signalling related to Bearer Independent Call Control (BICC) BICC IP bearer control protocol ITU-T Recommendation Q.1970 ITU-T Q-SERIES RE
2、COMMENDATIONS SWITCHING AND SIGNALLING SIGNALLING IN THE INTERNATIONAL MANUAL SERVICE Q.1Q.3 INTERNATIONAL AUTOMATIC AND SEMI-AUTOMATIC WORKING Q.4Q.59 FUNCTIONS AND INFORMATION FLOWS FOR SERVICES IN THE ISDN Q.60Q.99 CLAUSES APPLICABLE TO ITU-T STANDARD SYSTEMS Q.100Q.119 SPECIFICATIONS OF SIGNALLI
3、NG 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 Q.700Q.799 Q3 INTERFACE Q.800Q.849 DIGITAL SUBSCRIBER SIGNALLING SYSTEM No. 1 Q.850Q.999 PUBLIC LAND MOBILE NETWORK Q.1000Q.1099 INTERWORK
4、ING WITH SATELLITE MOBILE SYSTEMS Q.1100Q.1199 INTELLIGENT NETWORK Q.1200Q.1699 SIGNALLING REQUIREMENTS AND PROTOCOLS FOR IMT-2000 Q.1700Q.1799 SPECIFICATIONS OF SIGNALLING RELATED TO BEARER INDEPENDENT CALL CONTROL (BICC) Q.1900Q.1999 BROADBAND ISDN Q.2000Q.2999 For further details, please refer to
5、 the list of ITU-T Recommendations. ITU-T Rec. Q.1970 (09/2006) i ITU-T Recommendation Q.1970 BICC IP bearer control protocol Summary This Recommendation defines BICC IP bearer control protocol. BICC IP bearer control protocol (IPBCP) is used for the exchange of media stream characteristics, port nu
6、mbers and IP addresses of the source and sink of a media stream to establish and allow the modification of IP bearers. The information exchanged with IPBCP is done during BICC call establishment. In addition it may be exchanged after a call has been established. IPBCP uses the Session Description Pr
7、otocol (SDP) defined in RFC 4566 to encode this information. Source ITU-T Recommendation Q.1970 was approved on 13 September 2006 by ITU-T Study Group 11 (2005-2008) under the ITU-T Recommendation A.8 procedure. ii ITU-T Rec. Q.1970 (09/2006) FOREWORD The International Telecommunication Union (ITU)
8、is the United Nations specialized agency in the field of telecommunications. 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 standardiz
9、ing telecommunications 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
10、 by the procedure 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
11、 both a telecommunication 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 whe
12、n all of these 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 PROPERT
13、Y RIGHTS ITU draws 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
14、by ITU members 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
15、this may not represent the latest information and are therefore strongly urged to consult the TSB patent database at http:/www.itu.int/ITU-T/ipr/. ITU 2006 All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the prior written permission of ITU. ITU-T
16、Rec. Q.1970 (09/2006) iii CONTENTS Page 1 Scope 1 2 References. 1 3 Terms and definitions . 2 4 Abbreviations 2 5 Overview 2 6 IPBCP messages . 3 6.1 IPBCP message contents 3 6.2 IPBCP message fields. 3 7 Transport of IPBCP messages 5 8 Procedures 5 8.1 Successful IP bearer establishment 5 8.2 Succe
17、ssful IP bearer modification 7 8.3 IP bearer release . 9 8.4 Compatibility procedures . 9 8.5 Procedures for exceptional conditions 10 9 Timers. 11 Appendix I Examples of bearer establishment and modification using alternative network address types. 12 I.1 Bearer establishment and modification IPv6
18、address selected by R-BIWF 12 I.2 Bearer establishment IPv4 address selected by R-BIWF 14 ITU-T Rec. Q.1970 (09/2006) 1 ITU-T Recommendation Q.1970 BICC IP bearer control protocol 1 Scope This Recommendation defines IP bearer control protocol (IPBCP), which is suitable for use in IP network environm
19、ents where the Bearer Independent Call Control (BICC) protocol is deployed. IPBCP can be used also in other environments. BICC IPBCP is used for the exchange of media stream characteristics, port numbers and IP addresses of the source and sink of a media stream to establish and allow the modificatio
20、n of IP bearers. The exchange of information with IPBCP is done during BICC call establishment and after a call has been established. IPBCP uses the Session Description Protocol (SDP) defined in RFC 4566 10 to encode this information. 2 References The following ITU-T Recommendations and other refere
21、nces contain provisions which, through reference in this text, constitute provisions of this Recommendation. At the time of publication, the editions indicated were valid. All Recommendations and other references are subject to revision; users of this Recommendation are therefore encouraged to inves
22、tigate the possibility of applying the most recent edition of the Recommendations and other references listed below. A list of the currently valid ITU-T Recommendations is regularly published. The reference to a document within this Recommendation does not give it, as a stand-alone document, the sta
23、tus of a Recommendation. 1 ITU-T Recommendation Q.1901 (2000), Bearer Independent Call Control protocol. 2 ITU-T Recommendation Q.1902.1 (2001), Bearer Independent Call Control protocol (Capability Set 2): Functional description. 3 ITU-T Recommendation Q.1902.2 (2001), Bearer Independent Call Contro
24、l protocol (Capability Set 2) and Signalling System No. 7 ISDN User Part: General functions of messages and parameters. 4 ITU-T Recommendation Q.1902.3 (2001), Bearer Independent Call Control protocol (Capability Set 2) and Signalling System No. 7 ISDN User Part: Formats and codes. 5 ITU-T Recommend
25、ation Q.1902.4 (2001), Bearer Independent Call Control protocol (Capability Set 2): Basic call procedures. 6 ITU-T Recommendation Q.1902.5 (2001), Bearer Independent Call Control protocol (Capability Set 2): Exceptions to the Application transport mechanism in the context of BICC. 7 ITU-T Recommenda
26、tion Q.1902.6 (2001), Bearer Independent Call Control protocol (Capability Set 2): Generic signalling procedures for the support of the ISDN User Part supplementary services and for bearer redirection. 8 IETF RFC 791 (1981), Internet Protocol. 9 IETF RFC 3550 (2003), RTP: A Transport Protocol for Re
27、al-Time Applications. 10 IETF RFC 4566 (2006), SDP: Session Description Protocol. 11 IETF RFC 2460 (1998), Internet Protocol, Version 6 (IPv6) Specification. 12 IETF RFC 2833 (2000), RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals. 13 IETF RFC 3388 (2002), Grouping of Media Lines
28、in the Session Description Protocol (SDP). 2 ITU-T Rec. Q.1970 (09/2006) 14 IETF RFC 4091 (2005), The Alternative Network Address Types (ANAT) Semantics for the Session Description Protocol (SDP) Grouping Framework. 15 ITU-T Recommendation Q.1970 (2001), BICC IP Bearer Control Protocol. 3 Terms and
29、definitions For the purpose of this Recommendation, the definitions of ITU-T Rec. Q.1902.1 2 apply. In addition, this Recommendation defines the following terms: 3.1 IP bearer: A bidirectional user plane association between two BIWFs for carrying media stream information across IP networks. An IP be
30、arer is an instance of a Backbone network connection (BNC) type defined in clause 3/Q.1902.1 2. 3.2 initiating bearer interworking function (I-BIWF): A BIWF initiating the establishment of an IP bearer. 3.3 receiving bearer interworking function (R-BIWF): A BIWF receiving an IP bearer establishment
31、request. 3.4 network default address type: An address type (either IPv4 or IPv6) which is deployed in a network operating with signalling defined in IPBCP version 1 (Q.1970 (07/01) 15). 4 Abbreviations This Recommendation uses the following abbreviations: BCF Bearer Control Function BICC Bearer Inde
32、pendent Call Control BIWF Bearer InterWorking Function BNC Backbone Network Connection CSF Call Service Function DTMF Dual Tone Multi-Frequency I-BIWF Initiating BIWF IP Internet Protocol IPBCP IP Bearer Control Protocol R-BIWF Receiving BIWF RTP Real time Transport Protocol SDP Session Description
33、Protocol UDP User Datagram Protocol 5 Overview The purpose of IP bearer control protocol (IPBCP) is to exchange information between two BIWFs necessary to establish or modify IP bearers. IPBCP makes use of the Session Description Protocol (SDP) defined in RFC 4566 10 to encode the information that i
34、s exchanged. SDP descriptors used for IPBCP also contain IPBCP-specific SDP attributes. ITU-T Rec. Q.1970 (09/2006) 3 6 IPBCP messages IPBCP uses messages to convey information between peer BIWFs. IPBCP defines four messages: The Request message is sent by a BIWF to initiate an IP bearer establishme
35、nt or modification request. The BIWF that initiates an IP bearer establishment request is denoted as the I-BIWF. The Accepted message is sent by the BIWF that receives an IP bearer establishment or modification message if it accepts the request. The BIWF that receives an IP bearer establishment requ
36、est is denoted as the R-BIWF. The Confused message is sent by a BIWF in response to an IP bearer establishment or modification request if it cannot process the received Request message. The Rejected message is sent by a BIWF in response to an IP bearer establishment or modification request if it rej
37、ects the request. Either an I-BIWF or an R-BIWF may initiate an IP bearer modification request. 6.1 IPBCP message contents Each IPBCP message consists of the following SDP fields: Session and time description fields: 1) Protocol version (v); 2) Origin (o); 3) Session name (s); 4) Connection data (c)
38、; 5) Session attribute (a) The session attribute identifies IPBCP version and message type; 6) Time (t). Media description fields: 1) Media Announcement (m); 2) Media connection data (c) Additional connection data for the support of the Alternative Network Address Type; 3) Media attributes (a) Addit
39、ional attributes for the support of RTP dynamic payload types, DTMF, other tones and signals and packetization time. NOTE 1 Some of the fields and subfields are included because they are mandatory and required by SDP but not relevant to IPBCP environment. NOTE 2 The above fields must be present in t
40、he order as specified in RFC 4566 10. NOTE 3 Other SDP fields may be included in an IPBCP message; however, they are not required by this Recommendation and may be discarded by the receiver if they are not understood. NOTE 4 The Connection data field is not present if Media connection data fields ar
41、e present. 6.2 IPBCP message fields The following list describes SDP fields as used by IPBCP: 1) Protocol version v=0 SDP version 0 is used. 2) Origin o= is set to “-“; not used by IPBCP. is set to “0“; not used by IPBCP. 4 ITU-T Rec. Q.1970 (09/2006) see RFC 4566 10. type is “IN“, for Internet. is
42、“IP4“ or “IP6“. is the IP address assigned to the BIWF sending an IPBCP message. The receiver shall ignore the content of the address subfield. IPBCP has no requirements on the content of the origin field. NOTE 1 The above subfields are required to respect SDP rules. 3) Session name s= is an arbitra
43、ry string identifying the session. IPBCP has no requirements on the contents of the session name field. 4) Connection data c= is “IN“. is “IP4“ or “IP6“. is a unicast address. Only unicast streams are supported (e.g., point-to-point) in this version of IPBCP. For the details, see RFC 4566 10. NOTE 2
44、 The Connection data field is not present if Media connection data fields are present. 5) Time t= The sender shall set and according to SDP rules. The receiver shall ignore the contents of this field. Values (0,0) are allowed. IPBCP has no requirements on the contents of the Time field. 6) Session a
45、ttribute SDP session attribute “ipbcp“ provides the means to identify the IPBCP version and to distinguish between Request, Accepted, Confused and Rejected messages. a=ipbcp: = 2; this Recommendation defines IPBCP version 2. See ITU-T Rec. Q.1970 (07/01) BICC IP Bearer Control Protocol 15 for the de
46、finition of IPBCP version 1. = (“Request“/“Accepted“/“Confused“/“Rejected“) NOTE 3 Since IPBCP only supports the establishment of bidirectional bearers, these bearers are by default of type send and receive. Therefore, the SDP attribute a=sendrecv does not need to be signalled. SDP session attribute
47、 “group:ANAT“ provides the means to support the Alternative Network Address Type. For the details, see RFC 3388 13 and RFC 4091 14. a=group:ANAT = 1. = 2. 7) Media Announcement m= The “fmt list“ is limited to only one payload type. For further details, see RFC 4566 10. ITU-T Rec. Q.1970 (09/2006) 5
48、8) Media connection data To specify Alternative Network Address Types, the format of the media connection data is as follows: c= is “IN“. is “IP4“ or “IP6“. is a unicast address. Only unicast streams are supported (e.g., point-to-point) in this version of IPBCP. For the details, see RFC 4566 10. 9)
49、Media attributes To specify capabilities for DTMF digits and other tones and signals, the format of the media attribute is as follows: a=fmtp: For further details, see RFC 2833 12. To specify RTP dynamic payload types, the formats of the media attribute are: a=rtpmap: / For further details, see RFC 4566 10. To specify the packetization time, the format of the media attribute is: a=ptime: where is the media packetization time in milliseconds. For further details, about the u
