![]() 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: 7200RRQ 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.
To:
From:
Request-URI:
Call-ID:
Cseq:
Contact:
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.
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).
|
||
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:
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. 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 } |
||
  |