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

84 HP-UX C SIP Stack Programmer’s Guide
Call-leg Forking Support
HANDLING OF MULTIPLE 2XX RESPONSES DUE TO FORKING
Multiple 2xx responses may arrive at the UAC for a single INVITE request due
to a forking proxy. If the dialog identifier in the 2xx response matches the dialog
identifier of an existing call-leg (original or forked), the 2xx response is mapped
to this call-leg. Otherwise, a new forked call-leg is created, and the 2xx response
is mapped to the new call-leg.
In both cases, the 2xx response updates the state of the call-leg to REMOTE-
ACCEPTED. After sending the ACK request, this call-leg state will be updated
to CONNECTED.
HANDLING OF A NON-2XX FINAL RESPONSE
According to proxy rules, a single non-2xx final response may be received for
the INVITE response. The non-2xx final response is always mapped to the
original call-leg, regardless of which To tag it has. (This is because the ACK on
a non-2xx response should be sent by the original transaction, and the original
transaction is related to the original call-leg).
FORKED CALL-LEG TERMINATION
According to RFC 3261, The UAC considers the INVITE transaction
completed 64*T1 seconds after the reception of the first 2xx response. At this
point, all the early dialogs that have not transitioned to established dialogs are
terminated. Once the INVITE transaction is considered completed, no more
new 2xx responses are expected to arrive. All early dialogs are considered
terminated upon reception of the non-2xx final response.
For precise implementation, it is recommended that on reception of the first 2xx,
the application will set a timer to 64*T1 seconds, and when this timer expires,
the application will terminate all non-established calls created by the same
initial request. However, the application can also use the call-leg Forked-1xx-
Timer which is a timer that is set for every forked call-leg created by an
incoming 1xx response. If a 2xx response is received on this call-leg, the timer
is released. However, if a 2xx is not received, the call-leg will be terminated on
timer expiration. As a result, the application can be sure that all forked call-legs
that did not receive a final response will be terminated.
(Note that the original call-leg does not have the forked-1xx-timer. This call-leg
owns the invite transaction. If the original call-leg does not receive a final
response, the transaction timer will expire, and the transaction termination will
cause the call-leg to terminate as well.)