HP-UX C SIP Stack Programmer's Guide (Novembery 2007)

288 HP-UX C SIP Stack Programmer’s Guide
Persistent Connection Handling
 Undefined persistency
(RVSIP_TRANSPORT_PERSISTENCY_LEVEL_UNDEFIN
ED)
 Transaction persistency
(RVSIP_TRANSPORT_PERSISTENCY_LEVEL_TRANSC)
 Transaction user persistency
(RVSIP_TRANSPORT_PERSISTENCY_LEVEL_TRANSC
_USER)
U
NDEFINED PERSISTENCY When the SIP Stack is configured to use an undefined persistency level, the
following two rules apply:
 SIP Stack objects do not look for suitable connections in the
hash before sending a message, and therefore always open new
connections for sending requests. (Responses are still sent on
the connection on which the request was received).
 Newly created connections are not inserted into the hash.
The above two rules actually mean that each request, and its response sent by
any of the SIP Stack objects, use a different new connection. ACK on a non-2xx
response is sent on the same connection as the INVITE. (ACK on a 2xx
response is always sent on a new connection since it is not part of the INVITE
transaction.) In any case, there is no connection reuse in the SIP Stack.
T
RANSACTION
P
ERSISTENCY
When the SIP Stack is configured to use the transaction persistency level, the
following three rules apply:
 A transaction or a transmitter that wishes to send a request will
first try to locate a suitable connection in the hash.
 If there is a suitable open connection, the transaction will use it.
If there is not, the transaction will open a new connection and
insert it into the connections hash. In both cases, the transaction
will attach itself to the connection and become the connection
owner.
 The transaction will detach from the connection only before the
transaction terminates.
The above three rules imply that at the transaction persistency level, SIP Stack
transactions that send messages to the same destination will share the same
connection. The transaction can belong to different SIP Stack objects, such as a
call-leg, register-client or subscription. As long as a connection in the hash fits,
the transaction will use it. The connection will disconnect only when the last
transaction detaches from it.