Filter
Top Products
269
Dialogic Corporation
• specifying one-time or periodical registration (RAS message: RRQ)
• changing registered information (RAS message: RRQ)
• removing registered information by value (RAS message: RRQ)
• sending non-standard registration message (RAS message: NonStandardMessage)
• deregistering (RAS messages: URQ/UCF/URJ)
• handling calls according to the gatekeeper policy for directing and routing calls (RAS
messages: ARQ/ACF/ARJ, DRQ/DCF/DRJ)
Note: For detailed information on RAS negotiation, see ITU-T Recommendation H.225.0.
When using the Dialogic
®
Global Call API to perform H.323 Gatekeeper registration, the
following conditions and restrictions apply in addition to the general conditions noted above:
• An H.323 application must perform registration only when there are no active calls.
• Once an H.323 application chooses to be registered with a Gatekeeper, it can change its
Gatekeeper by deregistering and reregistering with another Gatekeeper.
• Once an H.323 application is registered and has active calls, deregistration or switching to a
different Gatekeeper will disconnect all active calls and cause GCEV_DISCONNECTED
events to be sent to the application. The gc_ResetLineDev( ) function can be used to put
channels in the Idle state before deregistering.
• Once an H.323 application chooses to be registered with a Gatekeeper, it cannot handle calls
without being registered with some Gatekeeper or explicitly deregistering. If the Gatekeeper
connection is lost, for example, the application cannot handle calls until it either reregisters or
deregisters.
• Once an application is registered, if it wishes to handle calls without the registration protocol
(that is, return to the same mode as before registration), it can simply deregister. When the
application deregisters, all existing calls are dropped and GCEV_DISCONNECTED events
are sent to the application, and new calls may be blocked for a short time while the H.323 stack
restarts in manual RAS mode.
SIP Registration
The SIP REGISTER method is used to register associations between a media endpoint alias and its
real (transport) address. These associations are commonly referred to as bindings, each of which
represents a unique tuple of several items, including:
• the Registrar’s address, which is specified as the Request-URI
• the Address of Record (a “name” that will be used to easily locate the SIP endpoint), which is
specified as the To header field
• the Transport address (the actual URI of the SIP endpoint), which is specified as the Contact
header field
• the Sender’s Address of Record (only used in third-party call control environments), which is
specified as the From header field
An application can register as many bindings as it wants, so that a given SIP endpoint may have
multiple AORs or aliases. When a Proxy receives an INVITE request addressed to a registered
AOR, it routes the request to the endpoint address identified in the binding. For example, if a