RAS Protocol

Overview of RAS

RAS is a part of H.225.0, which is used between endpoint and GK, and implements management function. It includes the following seven categories of procedures:

I. GK discovery

An endpoint uses multicast mode to discover the homed GK. Afterwards, all RAS messages will be transmitted between the endpoint and its homed GK.

II. Terminal and GW registration

It is used by an endpoint to register its information with the GK, including alias and transmission layer address of call control channel. This procedure also includes deregistration procedure.

III. Location request

It is used by endpoint or GK to request from corresponding GK the transmission layer address of the call control channel of a certain endpoint.

IV. Terminal to GK admission

It is the first operation when a call is initiated, to request the GK whether the call can be originated.

V. Disengage

After a call is over, this procedure is used to notify the GK that the endpoint exits the call and resumes free.

VI. Terminal to GK requests for changes in bandwidth

During a call, the endpoint can request to GK for changes in bandwidth, and the GK determines whether to change.

VII. Status request

It is used by GK to request the power on/off status of terminal.

VIII. GW resource availability

It is used to report the available resources of a gateway to the GK.

RAS Messages

I. RAS message abbreviations

Table 4-1 Terminal and GK discovery messages

Message name	Message description	Message type
GRQ	Gatekeeper Request	Request
GCF	Gatekeeper Confirm	Response
GRJ	Gatekeeper Reject	Response

Table 4-2 Terminal and GW registration messages

Message name	Message description	Message type
RRQ	Registration Request	Request
RCF	Registration Confirm	Response
RRJ	Registration Reject	Response

Table 4-3 Terminal/GK unregistration messages

Message name	Message description	Message type
URQ	Unregistration Request	Request
UCF	Unregistration Confirm	Response
URJ	Unregistration Reject	Response

Table 4-4 Terminal to GK admission messages

Message name	Message description	Message type
ARQ	Admission Request	Request
ACF	Admission Confirm	Response
ARJ	Admission Reject	Response

Table 4-5 Location request messages

Message name	Message description	Message type
LRQ	Location Request	Request
LCF	Location Confirm	Response
LRJ	Location Reject	Response

Table 4-6 Disengage messages

Message name	Message description	Message type
DRQ	Disengage Request	Request
DCF	Disengage Confirm	Response
DRJ	Disengage Reject	Response

Table 4-7 Status request messages

Message name	Message description	Message type
IRQ	Info Request	Request
IRR	Info Request Response	Response
IACK	Info Acknowledgement	Response
INAK	Information Negative Acknowledgement	Response

Table 4-8 Terminal to gatekeeper requests for changes in bandwidth

Message name	Message description	Message type
BRQ	Bandwidth Request	Request
BCF	Bandwidth Confirm	Response
BRJ	Bandwidth Reject	Response

Table 4-9 GW resource availability messages

Message name	Message description	Message type
RAI	Resource Availability Indication	Request
RAC	Resource Availability Confirmation	Response

II. RAS message format

A RAS message is in text format, and consists of message name and some mandatory and optional parameters. These parameters vary in different messages. Figure 4-6 illustrates a generic architecture of RAS message.

Figure 4-6 Generic architecture of RAS message

III. RAS common message elements

This section describes ASN.1 structures that are used in more than one RAS messages.

1) RequestSeqNum

All RAS messages include requestSeqNum. It is assigned by the request party and increments by 1. Any associated response messages (success or failure) shall have the corresponding requestSeqNum returned with it. Retransmitted messages shall have the same requestSeqNum. For instance, GRQ message and the triggered GCF or GRJ share the same requestSeqNum.

2) ProtocolIdentifier

The protocolIdentifier “determines the vintage of the implementations involved”. It defines the version number of the H.225 Recommendation used.

3) NonStandardData

It carries the non-standard information such as proprietary data that is not defined in H.225 Recommendation.

4) RasAddress

This is the registration and status transport address for this endpoint. RAS messages are transmitted on top of UDP in well-known port 1719.

5) EndpointType

It specifies the type of the endpoint—terminal, GW or MCU. If the H.323 element has an MC, then the mc Boolean would be true.

6) GatekeeperIdentifier

For RAS request messages, it identifies the GK that will respond to the request. If it is not supplied, the request message is valid to all reachable GKs.

For RAS response messages, it identifies the GK that returns the response message.

7) CallServices

It provides information on support of optional Q-series protocols to GK and called terminal.

8) EndpointAlias

It is a list of alias addresses, by which other terminals may identify this terminal. An alias address can be an E.164 address or an H.323 identifier. An E.164 address contains access code and telephone number, the latter of which identifies the GW. An H.323 identifier is a string of subscriber name, E-mail name or other identifier name. One endpoint can have multiple alias addresses corresponding to PRQ messages. All these alias addresses are sent to GK in the PRQ messages, and are translated to the same transport-layer address.

9) AlternateEndpoints

When an endpoint calls another or an alias, GK returns a prioritized endpoint as called party. Alternatively, the GK can also return a sequence of prioritized endpoint alternatives for rasAddress, endpointType, or endpointAlias. This parameter is used to improve call connection rate.

10) DiscoveryComplete

It is included in RRQ message. Set to TRUE if the requesting endpoint has preceded this message with the gatekeeper discovery procedure; set to FALSE if registering only.

11) CallSignalAddress

This is the registration and status transport address for this endpoint. Q.931 messages are transmitted on top of TCP in well-known port 1720.

12) VendorIdentifier

The VendorIdentifier structure allows a vendor to identify a product. The vendor element allows identification in terms of country code, extension, and manufacturer code. productId and versionId are text strings that can provide product information.

For instance:

VendorIdentifier

Vendor

T35CountryCode:82

T35Extension:0

manufacturerCode:2290

productId:Cns H.323v2

versionId:2.0

13) TimeToLive

TimeToLive is a number seconds that a registration is to be considered valid. The parameter is included in PRQ and PCF messages.

14) KeepAlive

An endpoint can send a lightweight RRQ consisting of only rasAddress, keepAlive, endpointIdentifier, gatekeeperIdentifier, tokens and timeToLive. A gatekeeper in receipt of RRQ with a keepAlive field set to TRUE should ignore fields other than endpointIdentifier, gatekeeperIdentifier, tokens and timeToLive.

15) EndpointIdentifier

16) WillRespondToIRR

When it is set to True, the Gatekeeper will send an IACK or INAK message in response to an unsolicited IRR message with its needsResponse field set to TRUE.

17) RejectReason

It is included in RRJ message, and identifies the reason for the rejection of the registration.

18) CallType

Using this value, called party's GK can attempt to determine 'real' bandwidth usage. The default value is pointToPoint for all calls.

19) CallModel

H.323 Recommendation defines two transmission models for end-to-end (E2E) call signaling. When the callModel is gatekeeperRouted, the endpoint is requesting the GK mediated model. Either end knows the address of the other end, thus protecting the privacy of subscribers. The GK participates in the call signaling procedure. When the callModel is direct, the endpoint is requesting the direct terminal to terminal call model. After GK provides the transport-layer address of the called party, it no longer involves in the call signaling procedure.

20) EndpointIdentifier

It is a GK-assigned terminal identity string, such as E.164 addresses or H323_IDs.

21) DestCallSignalAddress

It is the translated call signaling transport address of destination terminal or GK itself. It includes IP address and port number of Q.931 messages.

22) SrcInfo

It is a sequence of alias addresses for the source endpoint, such as E.164 addresses or H323_IDs.

23) SrcCallSignalAddress

It is the transport address used at the source for call signaling.

24) BandWidth

The parameter is used by GK to control the number of H.323 terminals accessing PBN at the same time. The GK can reject a call when there is not enough bandwidth to support the call.

In ARQ and ACF messages, BandWidth is the number of 100 bits requested for the bidirectional call. For example, a 128 kbit/s call would be signalled as a request for 256 kbit/s. The bandwidth defined by GK in ACF can be less than the one defined in ARQ.

25) CallReferenceValue (CRV)

It is the CRV cited from Q.931. The call reference value is chosen at the side originating the call and has to be locally unique. This is used by a GK to associate the ARQ with a particular call. For instance: The call model in gatekeeperRouted, CRV at the two signaling segment—source terminal-GK and GK-destination terminal—are different. GK establishes the association between two CRVs, and ensures accurate transmission of signaling messages. Nevertheless, in the same signaling segment, all H.225.0 messages of a particular call, such as call admission, call establishment, supplementary service, bandwidth change, and call termination share the same CRV.

26) ConferenceID

It is the unique identification of the conference to which the call belongs. CID consists of three parts—endpoint network address, conference initiation time and protocol version. Each call of a particular conference has its own call ID. All calls shares the same conferenceID, which is adopted for all H.225.0 messages in the conference.

27) Call ID

It identifies a call. Unlike CRV, the call ID is a global parameter. In other words, from source endpoint to GK, from source endpoint to destination endpoint, and from destination endpoint to GK, all RAS messages and call signaling messages of a particular call share the same call ID. The call ID serves for E2E message transmission. It can be encapsulated and transmitted in the Q.931 user-to-user messages. It can be used in supplementary services. The call ID is assigned by the source endpoint.

28) ActiveMC

It defines whether the source endpoint has an active MC.

29) AnswerCall

If the answerCall flag is TRUE then the GK has pre-granted permission to the endpoint to answer calls without first sending an ARQ. If the answerCall flag is FALSE, the endpoint shall always send ARQ to get permission to answer a call.

30) WillSupplyUUIEs

If it is set to TRUE, it indicates that the endpoint will supply Q.931 message information in IRR messages if requested by the Gk.

IV. A typical example of RAS message

This is an example of RRQ message.

registrationRequest

requestSeqNum: 969

protocolIdentifier: 0.0.8.2250.0.3

discoveryComplete: True

callSignalAddress (TransportAddress)

Item 0 (ipAddress)

ipAddress

ip: 191.169.200.31 (191.169.200.31)

port: 1720

rasAddress (TransportAddress)

Item 0 (ipAddress)

ipAddress

ip: 191.169.200.31 (191.169.200.31)

port: 1719

terminalType (EndpointType)

terminal (TerminalInfo)

mc: False

undefinedNode: False

terminalAlias (AliasAddress)

Item 0 (h323_ID)

h323_ID: 666302

Item 1 (e164)

e164: 666302

endpointVendor (VendorIdentifier)

vendor (H221NonStandard)

t35CountryCode: 82

t35Extension: 0

manufacturerCode: 2290

productId: CnS H.323v2

versionId: 2.0

timeToLive: 3600

keepAlive: True

endpointIdentifier: 24-3

Line 1 indicates that the message is RRQ.

Line 2 indicates that the request sequence number is 969. The requestSeqNum is the same as the ones in the response messages RCF and RRJ, and is used to associate RRQ, RCF and RRJ.

Line 3 is protocolIdentifier, which defines the version number of the H.225 Recommendation used.

Line 4 is discoveryComplete, which is included in RRQ only. It is set to TRUE, which indicates that the requesting endpoint has preceded this message with the GK discovery procedure;

Line 5 to line 9 list the information of the endpoint that is transmitting Q.931 messages. IP address: 191.169.200.31; port number: 1720.

Line 10 to line 14 list the information of the endpoint that is transmitting RAS messages. IP address: 191.169.200.31; port number: 1719.

Line 15 to line 18 specify the type of the endpoint that is registering. In this example, it is an H.323 terminal.

Line 19 to 23 are content of the terminalAlias. It can be an E.164 address or an H.323 identifier. Here, the E.164 address is a telephone number 666302, and the H.323 identifier is also 666302.

Line 24 to 30 specify information about the endpoint vendor. Here, the country code is 82, extension is 0 and manufacturer code is 2290. productId and versionId are text strings that can provide product information.

Line 31 indicates that the registration is valid for 3600 seconds.

Line 32 has the following implications. An endpoint can send a lightweight RRQ consisting of only rasAddress, keepAlive, endpointIdentifier, gatekeeperIdentifier, tokens and timeToLive. A gatekeeper in receipt of RRQ with a keepAlive field set to TRUE should ignore fields other than endpointIdentifier, gatekeeperIdentifier, tokens and timeToLive. Therefore, keepAlive is set to False in the first RRQ message, and True for all the subsequent ones.

Line 32 is endpointIdentifier.

Basic Procedures

I. Overview of basic procedures

This section introduces three procedures:

l GK discovery

l Terminal registration and unregistration

l Terminal to GK admission and disengagement

Each procedure is explained with a generic example of several events. Each process step represents an individual event.

II. GK discovery

Figure 4-7 Message flow diagram of GK discovery procedure

Here is the generic process of a GK discovery procedure:

1) When the endpoint initiates, it sends a GRQ message, searching for GK.

The GRQ message includes parameters endpointType, rasAddress, and gatekeeperIdentifier.

2) GK analyzes the endpoint information, determines that it is a local endpoint, and returns a GCF message. Alternatively, GK rejects the registration request of the endpoint, and returns a GRJ message with cause of rejection.

III. Terminal registration and unregistration

An endpont must register itself in the GK discovery procedure before it can start and receive calls. The registration of endpoint to the GK includes the former under the control of the latter.

Figure 4-8 Message flow diagram of terminal registration and unregistration

Here is the generic process of a terminal registration and unregistration procedure:

1) The endpoint sends a RRQ message to the RAS address of GK. The RRQ message includes two important parameters: endpontAlias and callSignalAddress.

2) The GK analyzes the endpoint information, determines that it is a local endpoint, and returns a GCF message. The endpoint then informs the GK of its call signaling transport address. The GK will then record the endpointAlias and callSignalAddress in translation table. When the GK finds that the endpoint is not a locla one, it returns an RRJ message to reject the call.

3) When the endpoint is to end the service, or change the mapping relation between alias and address, it sends a URQ message to GK and requests for unregistration.

4) In normal cases, GK returns a URF message for confirmation. When GK finds no registration information of the endpoint, it returns a URJ message.

IV. Terminal to GK admission and disengagement

ARQ/ACF and DRQ/DCF are the first and last pair of messages in the whole call control procedure. The first pair indicates the start and the last pair indicates the end of the call.

Figure 4-9 Message flow diagram of terminal to GK admission and disengagement

1) When the endpoints initiates a call, it sends an ARQ message to GK for authentication and address resolution. In the ARQ message, the endpoint specifies the destination information and required bandwidth.

2) If the GK admits the call, it returns an ACF message. The ACF message includes two key parameters—bandWidth which specifies the allowed maximum bandwidth for the call, and destCallSignalAddress, which might be an endpoint or GK address depending on the call model in use. Alternatively, the GK rejects the call with an ARJ message.

3) When the call completes, the endpoint sends a DRQ message to the GK, requesting to disengage the call.

4) In normal cases, GK returns a DCF message for confirmation. If the GK refuses the request, it returns a DRJ message.