Dialogic Global Call IP Benutzerhandbuch

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. 

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. 

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 

 function populates the 

with the default value for the sip_registrar_registrations field. The following code snippet