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 numbers 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 Protocol (SDP) defined in RFC 2327 to encode this information.

1.Scope

This Recommendation defines IP Bearer Control Protocol (IPBCP), which is suitable for use in IP network environments 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 modification 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 2327 [10] to encode this information.

2.References

The following ITU-T Recommendations and other references 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; all users of this Recommendation are therefore encouraged to investigate the possibility of applying the most recent edition of the Recommendations and other references listed below. A list of currently valid ITU-T Recommendations is regularly published.

1. ITU-T Recommendation Q.1901 (2000), Bearer Independent Call Control Protocol, CS1.
2. ITU-T Recommendation Q.1902.1 (2000), Bearer Independent Call Control Protocol (CS2) Functional Description.
3. ITU-T Recommendation Q.1902.2 (2000), Bearer Independent Call Control Protocol (CS2) and Signalling System No. 7 - ISDN User Part General Functions of Messages and Parameters.
4. ITU-T Recommendation Q.1902.3 (2000), Bearer Independent Call Control Protocol (CS2) and Signalling System No. 7 - ISDN User Part Formats and Codes.
5. ITU-T Recommendation Q.1902.4 (2000), Bearer Independent Call Control Protocol (CS2) Basic Call Procedures.
6. ITU-T Recommendation Q.1902.5 (2000), Exceptions to the Application Transport Mechanism in the Context of Bearer Independent Call Control.
7. ITU-T Recommendation Q.1902.6 (2000), Generic Signalling Procedures and Support of ISDN User Part (ISUP) Supplementary Services with the Bearer Independent Call Control (BICC) Protocol (CS2).
8. IETF RFC 791, Internet Protocol (IP v4).
9. IETF RFC 1889, RTP A Transport Protocol for Real Time Applications.
10. IETF RFC 2327, SDP: Session Description Protocol.
11. IETF RFC 2460, Internet Protocol (IP v6).
12. IETF RFC 2833, RTP payload for DTMF Digits, Telephony Tones and Telephony Signals.

3. Terms and definitions

For the purpose of this Recommendation, the definitions of Q.1902.1 [2] apply. In addition, the following definitions apply: IP bearer: A bidirectional user plane association between two BIWFs for carrying media stream information across IP networks. An IP bearer is an instance of a Backbone network connection (BNC) type defined in Recommendation Q.1902.1 [2] clause 3.

Initiating Bearer Inter-Working Function (I-BIWF): A BIWF initiating the establishment of an IP bearer. Receiving Bearer Inter-Working Function (R-BIWF): A BIWF receiving an IP bearer establishment request.

4.Abbreviations

This Recommendation uses the following abbreviations:

• BCF Bearer Control Function
• BICC Bearer Independent Call Control
• BIWF Bearer Inter-Working Function
• BNC Backbone Network Connection
• CSF Call Service Function
• DTMF Dual Tone Multi-Frequency
• IP Internet Protocol
• IPBCP IP Bearer Control Protocol
• I-BIWF Initiating BIWF
• RTP Real time Transport Protocol
• SDP Session Description Protocol
• R-BIWF Receiving BIWF
• 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 2327 [10] to encode the information that is exchanged. SDP descriptors used for IPBCP also contain IPBCP-specific SDP attributes.

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 establishment 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 request 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 rejects 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)
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 attributes (a) - Additional 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 the order as specified in RFC 2327 [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.

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=<username> <session id> <version> <network type> <address type> <address>

<username> is set to "-"; not used by IPBCP.

<session id> is set to "0"; not used by IPBCP.

see RFC 2327 [10].

type is "IN"; for Internet.

<address type> is "IP4" or "IP6".

<address> 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 - The above subfields are required to respect SDP rules.

3) Session name

s=<session name> an arbitrary string identifying the session. IPBCP has no requirements on the contents of the session name field.

4) Connection data

c=<network type> <address type> <connection address>

<network type> is "IN".

<address type> is "IP42" or "IP6".

<connection address> is a unicast address. Only unicast streams are supported (e.g. point-to-point) in this version of IPBCP. For the details see RFC 2327 [10].

5) Time

t=<start time> <stop time>

The sender shall set <start time> and <stop time> 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 attribute

SDP session attribute "ipbcp" provides the means to identify the IPBCP version and to distinguish between Request, Accepted, Confused and Rejected messages.

a=ipbcp: <version> <type>

<version> = 1; this Recommendation defines IPBCP version 1.

<type> = ("Request"/"Accepted"/"Confused"/"Rejected")

NOTE - 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.

7) Media Announcement

m=<media> <port> <transport> <fmt list>

The "fmt list" is limited to only one payload type. For further details see RFC 2327 [10].

8) Media attributes

To specify capabilities for DTMF digits and other tones and signals, the format of the media attribute is as follows:

a=fmtp:<format> <format specific parameters>

For further details see RFC 2833 [12].

To specify RTP dynamic payload types, the formats of the media attribute are:

a=rtpmap:<payload> <encoding name>/<clock rate>

For further details see RFC 2327 [10].

To specify the packetization time, the format of the media attribute is:

a=ptime:<packet time>

where <packet time> is the media packetization time in milliseconds. For further details about the use of the ptime attribute with RTP see RFC 2327 [10].

7.Transport of IPBCP messages

IPBCP assumes a reliable, sequenced, point-to-point signalling transport service between peer BIWFs.

8.Procedures

8.1 Successful IP Bearer establishment

8.1.1 Initiating BIWF

When an I-BIWF receives a request from a control entity to establish an IP bearer, it shall send a Request message to the R-BIWF and start timer T1. The Request message must include one Media Announcement ("m" field). The "c" field shall include an interface address within the I-BIWF, which specifies the intended source and sink of the media stream at the I-BIWF. The request message may also contain optional media attribute fields such as tone and signal capabilities and packetization time.

Upon reception of an Accepted message from the R-BIWF, the I-BIWF shall stop timer T1 and shall check the Accepted message. Successful IP bearer establishment requires that:

The received Media Announcement is the same as the one included in the Request message, except for the port subfield which can be different.

Except for the ptime and tone and signal capabilities, the media attribute fields must be the same as the ones included in the Request message.

The optional ptime, tone and signal capabilities, if included in the Accepted message, are acceptable values.

If the I-BIWF accepts the contents of the Accepted message, the IP bearer is successfully established at both BIWFs, and the control entity that initiated the establishment request shall be notified.

8.1.2 Receiving BIWF

Upon reception of a Request message from the I-BIWF, the R-BIWF examines the information in the Request message, and if it is acceptable, shall reply to the I-BIWF with an Accepted message. The Accepted message must include one SDP "m" field. The "c" field shall include an interface address within the R-BIWF, which will be the source and sink of the media stream at the R-BIWF. Except for the port subfield, the "m" field must be identical to the one received in the Request message. The Accepted message may also contain optional media attribute fields such as tone and signal capabilities and packetization time. Returning an Accepted message to the I-BIWF implies that the IP bearer has been established at the R-BIWF.

8.2 Successful IP Bearer modification

Once an IP bearer is established, it can be modified at the request of a control entity at the I-BIWF or the R-BIWF. Only the "fmt list" of the media announcement field and the media attributes being used for an IP bearer can be modified.

8.2.1 BIWF initiating IP bearer modification

The BIWF initiating the modification request sends a Request message to its peer BIWF and starts timer T2. The Request message must include a single Media Announcement ("m" field) and the media attributes to be changed.

Upon reception of an Accepted message from the peer BIWF, the BIWF that initiated the IP bearer modification request stops timer T2 and checks the Accepted message. Successful IP bearer modification requires that:

The received Media Announcement is the same as the one included in the Request message, except for the port subfield which can be different.

Except for the ptime and tone and signal capabilities, the media attribute fields must be the same as the ones included in the Request message.

The optional ptime, tone and signal capabilities, if included in the Accepted message, are acceptable values.

If the BIWF accepts the contents of the Accepted message, the IP bearer is successfully modified at both BIWFs and the control entity that initiated the modification request shall be notified.

8.2.2 BIWF receiving IP bearer modification

Upon reception of a Request message that applies to an existing IP bearer, the BIWF checks the Request message and, if acceptable, replies with an Accepted message. The Accepted message must contain a single Media Announcement ("m" field). Except for the "port" subfield, this Media Announcement must be identical to the one received in the Request message. The ptime, tone and signal capabilities may be different from the values received in the Request message. Returning an Accepted message implies that the IP bearer has been successfully modified at the BIWF.

8.3 IP Bearer release

There are no IPBCP messages exchanged between the two BIWFs to release an IP bearer. NOTE - When IPBCP is used in BICC environment, IP bearer release is triggered by CSF.

8.4 Compatibility Procedures

IPBCP uses a basic compatibility mechanism based on version numbers, included in each IPBCP message. Each future revision of this Recommendation shall support the version subfield. Peer BIWFs must use the same version of IPBCP in all messages related to the same IP bearer, except for the Confused message, when the R-BIWF does not support IPBCP version of the I-BIWF. An R-BIWF receiving an IPBCP message with an unsupported version shall return a Confused message with the version it supports. An I-BIWF receiving a Confused message shall examine the IPBCP version number indicated in the message. If the version number indicated in the Confused message is supported by the I-BIWF, it may re-initiate an IP bearer establishment request using this version number. Otherwise, the I BIWF notifies the control entity that initiated IP bearer establishment request.

8.5 Procedures for exceptional conditions

8.5.1 IP Bearer establishment

8.5.1.1 Initiating BIWF

Upon reception of a Rejected message or an incorrect or erroneous Accepted message from the R BIWF, the I-BIWF shall stop timer T1, release the resources allocated to the IP bearer and notify the control entity that the IP bearer establishment has failed.

8.5.1.2 Receiving BIWF

Upon reception of a Request message from the I-BIWF, the R-BIWF shall check the contents of the message. If they are incorrect or the Media Announcement that is offered in the Request message is not supported, the R-BIWF shall reply to the I-BIWF with a Rejected message.

8.5.2 IP Bearer Modification

8.5.2.1 BIWF initiating IP bearer modification

When the BIWF that initiated a bearer modification receives a Rejected message or an incorrect Accepted message from the peer BIWF, the BIWF initiating the IP bearer modification request shall stop timer T2 and notify the control entity that the modification request attempt has failed.

8.5.2.2 BIWF receiving the IP bearer modification

When a BIWF receives a Request message that applies to an existing IP bearer, the request is considered a bearer modification request. The receiving BIWF checks the contents of the message. If the contents are incorrect or the Media Announcement that is offered in the Request message is not supported, the BIWF shall reply to the peer BIWF with a Rejected message and the BIWF that received the modification request shall continue to use the existing IP bearer.

8.5.2.3 Simultaneous IP bearer modification requests

When both BIWFs attempt to modify an IP bearer simultaneously, the request from the I-BIWF shall take precedence over the one from the R-BIWF. The I-BIWF shall discard the R-BIWF request and continue to process the I-BIWF IP bearer modification request by following the procedures of IP bearer modification of subclause 8.2. The R-BIWF shall abandon its request and respond to the control entity of the failure of the modification attempt; it shall continue to process the modification request from the I-BIWF.

8.5.3 Reception of an unexpected message

If a BIWF receives an unexpected message from its peer, it shall discard the message.

9 Timers

Table 9-1/Q.1970 lists IPBCP timers.

Timer	Range	Default value	Cause for start	Cause for stop	Action at expiry
T1	1 to 30 s (in increments of 1 s)	5 s	Request message sent for IP bearer establishment	Accepted, Rejected or Confused message received or call cleared	Notify the control entity that initiated IP bearer establishment
T2	1 to 30 s (in increments of 1 s)	5 s	Request message sent for IP bearer modification	Accepted, Rejected or Confused message received or call cleared	Notify the control entity that initiated IP bearer modification