Dialogic 05-2239-009 User Manual
When UDP is used as the transport protocol, the SIP stack automatically retries the request on the
same address until a timeout occurs or a response is received. When such a timeout occurs there is
generally no point in retrying further on the same address, but having the stack automatically retry
on any additional addresses that are contained in the DNS server may be useful. All request retry
configuration options that enable retry include this type of retry using DNS entries.
same address until a timeout occurs or a response is received. When such a timeout occurs there is
generally no point in retrying further on the same address, but having the stack automatically retry
on any additional addresses that are contained in the DNS server may be useful. All request retry
configuration options that enable retry include this type of retry using DNS entries.
When TCP is used as the transport protocol, a request may fail because the destination is not able to
accept TCP in addition to other failure causes. When a TCP request fails, it is generally desirable to
have the stack retry the request using UDP, but because a UDP request is retried automatically until
a response is received or the request times out, the time interval before the application receives a
final fatal transport error may be significantly extended. Because of this, the options for enabling
request retry allow retry using UDP on the same address for a TCP failure to be enabled separately
in addition to retrying using addresses from the DNS server. Additionally, the SIP stack only retries
TCP requests on the same address using UDP if the failure reason indicates that there is a
reasonable possibility that the UDP request will succeed. In particular, there is little point in
retrying if the failure was a 503 Service Unavailable because sending a UDP request to a busy
server is no more likely to succeed than the failed TCP request. Another case where retrying a
failed TCP request is not appropriate is if the failed connection was a connection to a proxy, since a
failed connection to a proxy indicates that the proxy is not able to accept TCP or that the proxy is
down—a fatal error in either case.
accept TCP in addition to other failure causes. When a TCP request fails, it is generally desirable to
have the stack retry the request using UDP, but because a UDP request is retried automatically until
a response is received or the request times out, the time interval before the application receives a
final fatal transport error may be significantly extended. Because of this, the options for enabling
request retry allow retry using UDP on the same address for a TCP failure to be enabled separately
in addition to retrying using addresses from the DNS server. Additionally, the SIP stack only retries
TCP requests on the same address using UDP if the failure reason indicates that there is a
reasonable possibility that the UDP request will succeed. In particular, there is little point in
retrying if the failure was a 503 Service Unavailable because sending a UDP request to a busy
server is no more likely to succeed than the failed TCP request. Another case where retrying a
failed TCP request is not appropriate is if the failed connection was a connection to a proxy, since a
failed connection to a proxy indicates that the proxy is not able to accept TCP or that the proxy is
down—a fatal error in either case.
An important third case occurs when an application attempts a request using UDP, but the request
is forced to TCP because of its size. In this case, the application supplies an address that is valid for
UDP transport because that is the protocol it assumes will be used. If the connection fails because
the destination cannot accept TCP, it is appropriate for the SIP stack to retry the same address over
UDP without the application’s intervention, because a UDP request is what the application
expected to be sent in the first place. A separate configuration option is provided to accommodate
this specific circumstance while disabling retry on the same address for requests explicitly sent
over TCP.
is forced to TCP because of its size. In this case, the application supplies an address that is valid for
UDP transport because that is the protocol it assumes will be used. If the connection fails because
the destination cannot accept TCP, it is appropriate for the SIP stack to retry the same address over
UDP without the application’s intervention, because a UDP request is what the application
expected to be sent in the first place. A separate configuration option is provided to accommodate
this specific circumstance while disabling retry on the same address for requests explicitly sent
over TCP.
When a request retry occurs, the Global Call IP library generates a GCEV_EXTENSION event that
contains the following parameter element:
contains the following parameter element:
IPSET_SIP_REQUEST_ERROR
IPPARM_SIP_DNS_CONTINUE
•
data structure
If retry is not enabled in a particular circumstance, or if the retry attempt failed, the Dialogic
®
Global Call API library generates a GCEV_EXTENSION event containing the following
parameter element:
parameter element:
IPSET_SIP_REQUEST_ERROR
IPPARM_SIP_SVC_UNAVAIL
•
data structure
In both the “retry continuing” and “no retry” cases, REQUEST_ERROR.error is an enumerated
error code value, and REQUEST_ERROR.method is an array that contains up to
IP_SIP_METHODSIZE characters of the method name. The defined values for the error field are:
error code value, and REQUEST_ERROR.method is an array that contains up to
IP_SIP_METHODSIZE characters of the method name. The defined values for the error field are:
IP_SIP_REQUEST_503_RCVD
Connection failed due to 503 Service Unavailable or other fatal error cause.