Filter
Top Products
271
Dialogic Corporation
When using SIP, it is important to note that RFC3261 specifies that the “host” portion of a URI that
is given as a numeric IPv4 address (for example, 123.211.40.90) and one given as a domain name
(for example, example.com) are treated as unique even if they actually resolve to the same entity.
Applications should be careful to ensure that the “host” portions of any URIs in all subsequent
operations on that binding are consistent with way they were specified during the initial
registration.
4.22.2 Registration Operations
Applications perform all types of registration operations (registering, deregistering, querying, and
modifying or deleting registration information) using the gc_ReqService( ) function. The specific
operation to perform and the information necessary for that operation are specified in parameter
elements in a GC_PARM_BLK that is passed to the gc_ReqService( ) function. The specific
parameters to use for each type of operation are described in the following subsections.
In addition to the parameter elements that are required for H.323 or SIP registrations, there are two
mandatory parameter elements that are required by the generic service request mechanism even
though they have no meaning in the context of H.323/SIP endpoint registration. These two
parameters, GCSET_SERVREQ / PARM_REQTYPE and GCSET_SERVREQ / PARM_ACK,
must always be present in the GC_PARM_BLK.
The gc_ReqService( ) function operates in the asynchronous mode, and the application receives a
GCEV_SERVICERESP termination event if the call control library succeeds in communicating
with the registration server. It is important to note that a GCEV_SERVICERESP event indicates
that the requested registration operation was completed successfully only if the event’s result code
(the ccValue field in the GC_INFO structure from a gc_ResultInfo( ) function call) is IPERR_OK.
If the result code is any other value, there was some sort of error during the registration.
4.22.2.1 Configuring the Maximum Number of Registrations (SIP)
Because internal stack resources are required to monitor each unique binding that is set to auto-
refresh, and because auto-refresh is the default mode for SIP registration, the Global Call call
control library allows the application to configure the maximum number of registrations for each
virtual board when the system is started. If an application requests a registration that exceeds the
configured maximum number of registrations for the virtual board, the application’s request is
rejected by the call control library, which generates a GCEV_SERVICERESP event with the
response code IPEC_REG_FAIL_insufficientInternalResources.
The configuration of the maximum number of registrations is accomplished on a virtual board basis
by setting the sip_registrar_registrations field in the IP_VIRTBOARD structure for each virtual
board before gc_Start( ) is called. The default value for this field sets the maximum number of
registrations to be the same as the maximum number of SIP calls (the sip_max_calls field in
IP_VIRTBOARD), which is appropriate in most situations. If the application needs to register all
or most users with more than one Registrar, or to register multiple transport addresses for all or
most users, it needs to increase this configuration parameter from the default value.
The mandatory INIT_IP_VIRTBOARD( ) function populates the IP_VIRTBOARD structure
with the default value for the sip_registrar_registrations field. The following code snippet