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.
