Vovida

Ian Cahoon
$Id: registration.html,v 1.2 2000/05/22 09:06:45 icahoon Exp $

Registration


Registration Policy Design Introduction
The H.323 Gatekeeper (H323GK) portion of Vovida's SIP - H.323 Call Signalling Gateway will receive and process registration requests (GRQ) from other addressable H.323 endpoints (clients).

Administered data needed
The H323GK will be administered with the maximum number of registrations it is able to accept.

The H323GK will be administered with it's gatekeeper identifier.

Which response to send


REGISTER deatils

Given:
SIP Marshal:      marshal.vovida.com         192.168.5.10 : 5060
H.323 Translator: h323translator.vovida.com  192.168.5.20 : 3498
H.323 Endpoint:   swirl.vovida.com           192.168.5.30
    RAS Port:         1719
    Q.931 Port:       1720

Ideal
-----
REGISTER sip:vovida.com SIP/2.0
Via: SIP/2.0/UDP h323translator.vovida.com:3498
Via: RAS/H.225.0(2/98)/UDP swirl.vovida.com:1719
To: sip:1234@vovida.com; callSignalAddress="192.168.5.30:1720"
From: sip:1234@h323translator.vovida.com
Call-ID: 70710@vovida.com
CSeq: 1 REGISTER
Contact: <sip:1234@h323translator.vovida.com:3498;transport=udp>
Expires: 7200

Current implementation
----------------------
REGISTER sip:192.168.5.10:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.5.20:3498
To: sip:1234@192.168.5.10
From: sip:1234@192.168.5.10
Call-ID: 70710@vovida.com
CSeq: 1 REGISTER
Contact: <sip:1234@192.168.5.20:3498;transport=udp>
Expires: 7200

Compromise implementation
-------------------------
REGISTER sip:192.168.5.10:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.5.20:3498
Via: SIP/2.0/UDP 192.168.5.30:1719
To: sip:1234@192.168.5.10; callSignalAddress="198.168.5.30:1720"
From: sip:1234@192.168.5.10
Call-ID: 70710@vovida.com
CSeq: 1 REGISTER
Contact: <sip:1234@192.168.5.20:3498;transport=udp>
Expires: 7200
RRQ details
The following fields from a RRQ will be used:

	    
	    RCF details
If a RCF is sent the following will be sent:


	    RRJ details
If a RRJ is sent the following will be sent:
	    
	
Registration description,

from draft-ietf-sip-rfc2543bis-00.pdf, Section 1.4.7, Section 4.2..6
1.4.7 Registration Services

The REGISTER request allows a client to let a proxy or redirect server know at which address(es) it can be reached. A client MAY also use it to install call handling features at the server.

4.2.6 REGISTER

A client uses the REGISTER method to register the address listed in the To header field with a SIP server.

A user agent SHOULD register with a local server on startup and periodically thereafter by sending a REGISTER request. The period is given by the expiration time indicated in the registration response. It is RECOMMENDED that the UA registers via multicast and send a registration to its "home" address, i.e., the server for the domain that it uses as its From address in outgoing requests.

Multicast registrations are addressed to the well-known "all SIP servers" multicast address "sip.mcast.net" (224.0.1.75). This request SHOULD be scoped to ensure it is not forwarded beyond the boundaries of the administrative system. This MAY be done with either TTL or administrative scopes [25], depending on what is implemented in the network. SIP user agents MAY listen to that address and use it to become aware of the location of other local users [20]; however, they do not respond to the request.

Since registrations expire, clients need to periodically refresh their registrations. Such refreshes SHOULD be sent to the same address as the original registration, unless redirected.

Registration requests may be redirected by a 3xx response, or with a Contact header in a non-200 response (typically, 401) to a REGISTER request. Refreshes for the same address of record SHOULD be directed to this new address for all subsequent registrations. A client MAY revert to the original address upon reboot or upon an administratively configured lifetime. This implies that servers MUST be prepared to accept registrations on the original configured address and the redirected address.

It is RECOMMENDED that clients ignore redirection responses from untrusted hosts or require that such redirection responses are cryptographically signed.

    Multicast registration may be inappropriate in some environments, for example, if multiple businesses share the same local area network.

Requests are processed in the order received. Clients SHOULD avoid sending a new registration (as opposed to a retransmission) until they have received the response from the server for the previous one.

    Clients may register from different locations, by necessity using different Call-ID values. Thus, the CSeq value cannot be used to enforce ordering. Since registrations are additive, ordering is less of a problem than if each REGISTER request completely replaced all earlier ones.

The meaning of the REGISTER request-header fields is defined as follows. We define "address-of-record" as the SIP address that the registry knows the registrand, typically of the form "user@domain" rather than "user@host". In third-party registration, the entity issuing the request is different from the entity being registered.

To:
    The To header field contains the address-of-record whose registration is to be created or updated.


From:
    The From header field contains the address-of-record of the person responsible for the registration. For first-party registration, it is identical to the To header field value.


Request-URI:
    The Request-URI names the destination of the registration request, i.e., the domain of the registrar. The user name MUST be empty. Generally, the domains in the Request-URI and the To header field have the same value; however, it is possible to register as a "visitor", while maintaining one's name. For example, a traveler sip:alice@acme.com (To) might register under the Request-URI sip:atlanta.hiayh.org, with the former as the To header field and the latter as the Request-URI. The REGISTER request is no longer forwarded once it has reached the server whose authoritative domain is the one listed in the Request-URI.


Call-ID:
    All registrations from a client SHOULD use the same Call-ID header value, at least within the same reboot cycle.


Cseq:
    Registrations with the same Call-ID MUST have increasing CSeq header values. However, the server does not reject out-of-order requests.


Contact:
    The request MAY contain a Contact header field. Future non-REGISTER requests for the URI given in the To header field SHOULD be directed to the address(es) given in the Contact header. If the request does not contain a Contact header, the registration remains unchanged.

      This is useful to obtain the current list of registrations in the response.

    If a SIP URI in a registration Contact header field differs from existing registrations according to the rules in Section 2.1, it is added to the list of registration. If it is equivalent, according to these rules, to an existing registration, all Contact header field parameters for this entry are updated accordingly. URIs other than SIP URIs are compared according to the standard URI equivalency rules for the URI schema.

    All current registrations MUST share the same action value. Registrations that have a different action than current registrations for the same user MUST be rejected with status of 409 (Conflict).

    A proxy server ignores the q parameter when processing non-REGISTER requests, while a redirect server simply returns that parameter in its Contact response header field.
      Having the proxy server interpret the q parameter is not sufficient to guide proxy behavior, as it is not clear, for example, how long it is supposed to wait between trying addresses.

    If the registration is changed while a user agent or proxy server processes an invitation, the new information SHOULD be used.

      This allows a service known as "directed pick-up". In the telephone network, directed pickup permits a user at a remote station who hears his own phone ringing to pick up at that station, dial an access code, and be connected to the calling user as if he had answered his own phone.

    Responses MAY contain a Contact header field. Its interpretation differs depending on the response status. If contained within a 2xx response, the header field indicates the list of current registrations. In 3xx and 4xx responses, it indicates where future REGISTER requests should be directed.

A server MAY choose any duration for the registration lifetime. Registrations not refreshed after this amount of time SHOULD be silently discarded. Responses to a registration SHOULD include an Expires header (Section 6.22) or expires Contact parameters (Section 6.13), indicating the time at which the server will drop the registration. If none is present, one hour is assumed. Clients MAY request a registration lifetime by indicating the time in an Expires header in the request. A server SHOULD NOT use a higher lifetime than the one requested, but MAY use a lower one. A single address (if host-independent) MAY be registered from several different clients.

A client cancels an existing registration by sending a REGISTER request with an expiration time (Expires) of zero seconds, either for a particular Contact or the wildcard Contact designated by a "*" if it wants to cancel all registrations. Registrations are matched based on the user, host, port and maddr parameters.

The server SHOULD return the current list of registrations in the 200 response as Contact header fields. It is particularly important that REGISTER requests are authenticated since they allow to redirect future requests (see Section 13.2).

    Beyond its use as a simple location service, this method is needed if there are several SIP servers on a single host. In that case, only one of the servers can use the default port number.

Support of this method is RECOMMENDED.

Registration description,

from H.323 (2/98), Section 7.2.2
7.2.2 Endpoint registration

Registration is the process by which an endpoint joins a Zone, and informs the Gatekeeper of its Transport Addresses and alias addresses. As part of their configuration process, all endpoints shall register with the Gatekeeper identified through the discovery process. Registration shall occur before any calls are attempted and may occur periodically as necessary (for example, at endpoint power-up).

A Gateway or MCU may register a single Transport Address or multiple Transport Addresses as its call signalling address, and may register a single Transport Address or multiple Transport Addresses as its RAS address. The use of multiple Transport Addresses shall indicate a prioritized list of addresses to try when communicating with a given endpoint through either its RAS or Call Signalling Channel.

An endpoint shall send a Registration Request (RRQ) to a Gatekeeper. This is sent to the Gatekeeper's RAS Channel Transport Address. The endpoint has the Network Address of the Gatekeeper from the Gatekeeper discovery process and uses the well-known RAS Channel TSAP

Identifier. The Gatekeeper shall respond with either a Registration Confirmation (RCF) or a Registration Reject (RRJ). See Figure 8. An endpoint shall only register with a single Gatekeeper. The RRQ may be repeated periodically (i.e. at terminal power-up), so the Gatekeeper shall be able to handle multiple requests from the same endpoint. If a Gatekeeper receives an RRQ having the same alias address (or list of alias addresses) and the same Transport Addresses as an active registration, it shall respond with RCF. If a Gatekeeper receives an RRQ having the same alias address (or list of alias addresses) as an active registration and different Transport Addresses, it may confirm the request, if it complies with the Gatekeeper's registration policy. If the request does not comply with the Gatekeeper's registration policy, the Gatekeeper should reject the registration indicating a duplicate or invalid registration. If the Gatekeeper receives an RRQ having the same Transport Addresses as an active registration and a different alias address (or list of alias addresses), it should replace the translation table entries. The Gatekeeper may have a method to authenticate these changes.

An endpoint may indicate a backup, redundant, or alternate Transport Addresses using the alternateEndpoint structure within the RAS messages. This allows an endpoint to have a secondary network interface or a secondary H.323 endpoint as a backup. The Gatekeeper shall reject ambiguous registrations. The Gatekeeper may reject the registration for other reasons, such as changes in discovery or security issues.

If the endpoint does not include an alias address in the RRQ message, the Gatekeeper may assign one. The Gatekeeper shall return the assigned alias address to the terminal in the RCF message.

An endpoint may cancel its registration by sending an Unregister Request (URQ) message to the Gatekeeper. The Gatekeeper shall respond with an Unregister Confirmation (UCF) message. This allows endpoints to change the alias address associated with its Transport Address, or vice versa. If the endpoint was not registered with the Gatekeeper, it shall return an Unregister Reject (URJ) message to the endpoint.

A Gatekeeper may cancel the registration of an endpoint by sending an Unregister Request (URQ) message to the endpoint. The endpoint shall respond with an Unregister Confirmation (UCF) message. The endpoint shall re-register with a Gatekeeper prior to initiating any calls. This may require the endpoint to register with a new Gatekeeper.

An endpoint which is not registered with a Gatekeeper is called an unregistered endpoint. This type of endpoint does not request admission permission from a Gatekeeper and so cannot participate in admissions control, bandwidth control, address translation and other functions performed by the Gatekeeper.

7.2.2.1 Use of Lightweight RRQ

An endpoint's registration with a Gatekeeper may have a finite life. An endpoint may request a timeToLive in the RRQ message to the Gatekeeper. The Gatekeeper may respond with an RCF containing the same timeToLive or a shorter timeToLive. After this time, the registration shall be expired. The timeToLive is expressed in seconds. Prior to the expiration time, the endpoint may send an RRQ message having the keepAlive bit set. The keep-alive RRQ may include a minimum amount of information as described in H.225.0. The keep-alive RRQ shall reset the time to live timer in the Gatekeeper, allowing the registration to be extended. After the expiration time, the endpoint must re-register with a Gatekeeper using a full RRQ message.

If the Gatekeeper does not include a timeToLive value in the RCF, the registered endpoint shall consider that the Gatekeeper is not supporting the keep-alive mechanism. Endpoints shall not send RRQs with the keepAlive field set to Gatekeepers which have indicated that they are not supporting the keep-alive mechanism.

Gatekeepers should not treat an RRQ with the keepAlive field set as a full registration (i.e. for updating or intializing its translation tables).

Endpoints should consider messaging and processing delays when determining when their registration will expire (i.e. the duration of their own time-to-live timer) at the Gatekeeper. Expiration of the time-to-live timer in the Gatekeeper results in the expiration of the registration of the endpoint. A Gatekeeper may send a URQ to the endpoint as a notification of such expiration. This allows for loss of synchronization between the time-to-live timers of the Gatekeeper and the endpoint. It also indicates a need for re-registration to endpoints which do not support the keep-alive mechanism.

An endpoint which sends a lightweight RRQ to its Gatekeeper after the time-to-live timer has expired in the Gatekeeper will receive an RRJ response with rejectReason of either fullRegistrationRequired or discoveryRequired, depending on Gatekeeper requirements. An endpoint which sends an ARQ to its Gatekeeper after the time-to-live timer has expired in the Gatekeeper will receive an ARJ with rejectReason of either callerNotRegistered or calledPartyNotRegistered. An endpoint which initiates a new call through its Gatekeeper after expiration of the Gatekeeper's time-to-live timer will receive a Release Complete message with a reason of callerNotRegistered or calledPartyNotRegistered.

Disposition of existing calls upon expiration of the time-to-live timer is implementation dependent.

Semantic description of RRQ, RCF and RRJ,

from H.225.0 (2/98), Section 7.9
7.9 Terminal and Gateway Registration messages

The RRQ is a request from a terminal to a gatekeeper to register. If the gatekeeper responds with a RCF, the terminal shall use the responding gatekeeper for future calls. If the gatekeeper responds with a RRJ, the terminal must seek another gatekeeper to register with.

7.9.1 RegistrationRequest (RRQ)


The RRQ message includes the following:

requestSeqNum - – This is a monotonically increasing number unique to the sender. It shall be returned by the receiver in any response associated with this specific message. protocolIdentifier – Identifies the H.225.0 vintage of the sending endpoint. nonStandardData – Carries information not defined in this Recommendation (for example, proprietary data).

discoveryComplete - – Set to TRUE if the requesting endpoint has preceded this message with the gatekeeper discovery procedure; set to FALSE if registering only. Note that registration may age, and the endpoint will get a failure on an RRQ or ARQ with a reason code of discoveryRequired or notRegistered respectively. This indicates that the endpoint should perform the discovery procedure (either dynamic or static) before issuing the RRQ with discoveryComplete set to TRUE.

callSignalAddress - – This is the call signalling transport address for this endpoint. If multiple transports are supported, they must be registered all at once.

rasAddress - – This is the registration and status transport address for this endpoint.

terminalType - – This specifies the type(s) of the endpoint that is(are) registering; note that the MC bit shall not be set by itself; either the terminal, MCU, gateway, or gatekeeper bit shall also be set. If vendor information is provided, this information shall be identical to that in endpointVendor.

terminalAlias --This optional value is a list of alias addresses, by which other terminals may identify this terminal. If the terminalAlias is null, or an E.164 address is not present, an E.164 address may be assigned by the gatekeeper, and included in the RCF. If an email-ID is available for the endpoint, it should be registered. Note that multiple alias addresses may refer to the same transport addresses. All of the endpoint's aliases shall be included in each RRQ.

gatekeeperIdentifier - – String to identify the gatekeeper that the terminal wishes to register with.

endpointVendor - – Information about the endpoint vendor.

alternateEndpoints - – A sequence of prioritized endpoint alternatives for callSignalAddress, rasAddress, terminalType, or terminalAlias.

timeToLive - – Duration of the validity of the registration, in seconds. After this time the gatekeeper may consider the registration stale.

tokens - – This is some data which may be required to allow the operation. The data shall be inserted into the message if available.

cryptoTokens - – Encrypted tokens.

integrityCheckValue - – Provides improved message integrity/message authentication of the RAS messages. The cryptographically based integrity check value is computed by the sender applying a negotiated integrity algorithm and the secret key upon the entire message. Prior to integrityCheckValue computation, this field shall be ignored and shall be empty. After computation, the sender puts the computed integrity check value in the integrityCheckValue field and transmits the message.

keepAlive - – If set to TRUE indicates that the endpoint has sent this RRQ as a "keep alive". An endpoint can send a lightweight RRQ consisting of only 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.

endpointIdentifier - – The endpointIdentifier provided by the gatekeeper during the original RCF.

willSupplyUUIEs - – If set to TRUE, this indicates that the endpoint will supply Q.931 message information in IRR messages if requested by the gatekeeper.


7.9.2 RegistrationConfirm (RCF)

The RCF message includes the following:

requestSeqNum - – This shall be the same value that was passed in the RRQ.

protocolIdentifier - – Identifies the vintage of the accepting gatekeeper.

nonStandardData - – Carries information not defined in this Recommendation (for example, proprietary data).

callSignalAddress - – This is an array of transport addresses for H.225.0 call signalling messages; one for each transport that the gatekeeper will respond to. This address includes the TSAP identifier.

terminalAlias - – This optional value is a list of alias addresses, by which other terminals may identify this terminal.

gatekeeperIdentifier - – String to identify the gatekeeper that has accepted the terminals registration.

endpointIdentifier - – A gatekeeper assigned terminal identity string; shall be echoed in subsequent RAS messages.

alternateGatekeeper - – Sequence of prioritized alternateGatekeeper for gatekeeperIdentifer and rasAddress. The client should use these alternateGatekeeper in the future, should a request to the gatekeeper not respond or return a reject without redirect.

timeToLive - – Duration of the validity of the registration, in seconds. After this time the gatekeeper may consider the registration stale.

tokens - – This is some data which may be required to allow the operation. The data shall be inserted into the message if available.

cryptoTokens - – Encrypted tokens.

integrityCheckValue - – Provides improved message integrity/message authentication of the RAS messages. The cryptographically based integrity check value is computed by the sender applying a negotiated integrity algorithm and the secret key upon the entire message. Prior to integrityCheckValue computation, this field shall be ignored and shall be empty. After computation, the sender puts the computed integrity check value in the integrityCheckValue field and transmits the message.

willRespondToIRR - – True if the Gatekeeper will send an IACK or INAK message in response to an unsolicited IRR message with its needsResponse field set to TRUE.

preGrantedARQ - – Indicates events for which the gatekeeper has pre-granted admission. This allows for faster call setup times in environments where admission is guaranteed through means other than the ARQ/ACF exchange. Note that even if these fields are set to TRUE, an endpoint can still send an ARQ to the gatekeeper for reasons such as address translation, or the endpoint does not support this modified signalling mode. If the preGrantedARQ sequence is not present, then ARQ signalling shall be used in all cases. The flags are:

    makeCall - – If the makeCall flag is TRUE then the gatekeeper has pre-granted permission to the endpoint to initiate calls without first sending an ARQ. If the makeCall flag is FALSE, the endpoint shall always send ARQ to get permission to make a call.

    useGKCallSignalAddressToMakeCall - – If the makeCall and useGKCallSignalAddressToMakeCall flags are both set to TRUE, then if the endpoint does not send an ARQ to the gatekeeper to make a call, the endpoint shall send all H.225 call signalling to the gatekeeper call signalling channel.

    answerCall - – If the answerCall flag is TRUE then the gatekeeper 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.

    useGKCallSignalAddressToAnswer - – If the answerCall and useGKCallSignalAddressToAnswer flags are both set to true, then when an endpoint does not send an ARQ to the gatekeeper to answer a call, the endpoint shall ensure that all H.225.0 call signalling comes from the gatekeeper. If an endpoint has been instructed to use the gatekeeper when answering, but it does not know whether an incoming call has come from the gatekeeper (which may involve looking at the transport address), the endpoint shall issue ARQ irrespective of the state of the useGKCallSignalAddressToAnswer flag.

7.9.3 RegistrationReject (RRJ)

The RRJ message includes the following:

requestSeqNum - – This shall be the same value that was passed in the RRQ.

protocolIdentifier - – Identifies the vintage of the rejecting gatekeeper.

nonStandardData - – Carries information not defined in this Recommendation (for example, proprietary data).

rejectReason - – The reason for the rejection of the registration.

gatekeeperIdentifier - – String to identify the gatekeeper that has rejected the terminal's registration.

altGKInfo - – Optional information about alternative gatekeepers.

tokens - – This is some data which may be required to allow the operation. The data shall be inserted into the message if available.

cryptoTokens - – Encrypted tokens.

integrityCheckValue - – Provides improved message integrity/message authentication of the RAS messages. The cryptographically based integrity check value is computed by the sender applying a negotiated integrity algorithm and the secret key upon the entire message. Prior to integrityCheckValue computation, this field shall be ignored and shall be empty. After computation, the sender puts the computed integrity check value in the integrityCheckValue field and transmits the message.46 Recommendation H.225.0 (02/98)

keepAlive - – If set to TRUE indicates that the endpoint has sent this RRQ as a "keep alive". An endpoint can send a lightweight RRQ consisting of only 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.

endpointIdentifier - – The endpointIdentifier provided by the gatekeeper during the original RCF.

willSupplyUUIEs - – If set to TRUE, this indicates that the endpoint will supply Q.931 message information in IRR messages if requested by the gatekeeper.

ASN.1 Definition of RRQ, RCF and RRJ,

from H.225.0 (2/98), Annex H
RegistrationRequest ::= SEQUENCE --(RRQ)
{
    requestSeqNum   	    RequestSeqNum,
    protocolIdentifier      ProtocolIdentifier,
    nonStandardData 	    NonStandardParameter OPTIONAL,
    discoveryComplete 	    BOOLEAN,
    callSignalAddress 	    SEQUENCE OF TransportAddress,
    rasAddress      	    SEQUENCE OF TransportAddress,
    terminalType    	    EndpointType,
    terminalAlias   	    SEQUENCE OF AliasAddress OPTIONAL,
    gatekeeperIdentifier    GatekeeperIdentifier OPTIONAL,
    endpointVendor  	    VendorIdentifier,
    ...,
    alternateEndpoints      SEQUENCE OF Endpoint OPTIONAL,
    timeToLive      	    TimeToLive OPTIONAL,
    tokens  	    	    SEQUENCE OF ClearToken OPTIONAL,
    cryptoTokens    	    SEQUENCE OF CryptoH323Token OPTIONAL,
    integrityCheckValue     ICV OPTIONAL,
    keepAlive 	    	    BOOLEAN,
    endpointIdentifier      EndpointIdentifier OPTIONAL,
    willSupplyUUIEs 	    BOOLEAN
}

RegistrationConfirm ::= SEQUENCE --(RCF)
{
    requestSeqNum   	    RequestSeqNum,
    protocolIdentifier      ProtocolIdentifier,
    nonStandardData 	    NonStandardParameter OPTIONAL,
    callSignalAddress 	    SEQUENCE OF TransportAddress,
    terminalAlias   	    SEQUENCE OF AliasAddress OPTIONAL,
    gatekeeperIdentifier    GatekeeperIdentifier OPTIONAL,
    endpointIdentifier      EndpointIdentifier,
    ...,
    alternateGatekeeper     SEQUENCE OF AlternateGK OPTIONAL,
    timeToLive TimeToLive   OPTIONAL,
    tokens  	    	    SEQUENCE OF ClearToken OPTIONAL,
    cryptoTokens    	    SEQUENCE OF CryptoH323Token OPTIONAL,
    integrityCheckValue     ICV OPTIONAL,
    willRespondToIRR 	    BOOLEAN,
    preGrantedARQ   	    SEQUENCE
    {
	makeCall    	    	    	    BOOLEAN,
	useGKCallSignalAddressToMakeCall    BOOLEAN,
	answerCall  	    	    	    BOOLEAN,
	useGKCallSignalAddressToAnswer      BOOLEAN,
	...
    } OPTIONAL
}

RegistrationReject ::= SEQUENCE --(RRJ)
{
    requestSeqNum   	    RequestSeqNum,
    protocolIdentifier      ProtocolIdentifier,
    nonStandardData 	    NonStandardParameter OPTIONAL,
    rejectReason    	    RegistrationRejectReason,
    gatekeeperIdentifier    GatekeeperIdentifier OPTIONAL,
    ...,
    altGKInfo AltGKInfo     OPTIONAL,
    tokens  	    	    SEQUENCE OF ClearToken OPTIONAL,
    cryptoTokens    	    SEQUENCE OF CryptoH323Token OPTIONAL,
    integrityCheckValue     ICV OPTIONAL
}

RegistrationRejectReason ::= CHOICE
{
    discoveryRequired 	    	NULL, -- registration permission has aged
    invalidRevision 	    	NULL,
    invalidCallSignalAddress 	NULL,
    invalidRASAddress 	    	NULL, -- supplied address is invalid
    duplicateAlias  	    	SEQUENCE OF AliasAddress,
        -- alias registered to another endpoint

    invalidTerminalType     	NULL,
    undefinedReason 	    	NULL,
    transportNotSupported   	NULL, -- one or more of the transports
    ...,
    transportQOSNotSupported 	NULL, -- endpoint QOS not supported
    resourceUnavailable     	NULL, -- gatekeeper resources exhausted
    invalidAlias    	    	NULL, -- alias not consistent with gatekeeper rules
    securityDenial  	    	NULL
}