HP-UX C SIP Stack Programmer's Guide (Novembery 2007)
Working with Call-legs (Dialogs) 83
Call-leg Forking Support
RFC 3261 defines that when multiple 1xx or 2xx responses are received from
different remote UAs (because the INVITE forked), each 2xx establishes a
different dialog. This section describes the forking support for call-legs in the
SIP Stack.
TERMINOLOGY Original call-leg—The call-leg that sent the original INVITE
request. The original call-leg owns the invite transaction It will
handle the first response that is received from the proxy.
Forked call-leg—A call-leg that was created by a response
message. After the initial response was handled by the original
call-leg, further responses that were received from other UA
Servers due to a forking proxy will create new call-legs. These
call-legs are referred to as forked call-legs. A forked call-leg
might be an early-dialog (in the PROCEEDING state), or a
confirmed dialog (in the CONNECTED state). The forked call-
leg does not own an invite transaction.
OVERVIEW OF
OPERATION
A User Agent Client (UAC) sends an INVITE request as usual. It creates a call-
leg, sets the session parameters, and sends the initial INVITE request. This call-
leg is identified by its Call-ID, and From tag values. The To tag value is empty,
until a response message (provisional or final) will be received from a UAS.
HANDLING OF MULTIPLE 1XX RESPONSES DUE TO FORKING
Zero, one or multiple provisional responses may arrive before one or more final
responses are received. Each response is distinguished by the tag parameter in
the To header field. Provisional responses for an INVITE request create “early
dialogs”. The first 1xx response will be mapped to the original call-leg, and will
update the To tag value of that call-leg. Further responses from the same UAS
server will contain the same to tag parameter, and therefore will be mapped to
the original call-leg.
Any 1xx response sent by a different user-agent-server contains a different To
tag value. Therefore, it creates a new forked call-leg in the PROCEEDING state.
If a matching forked call-leg was already created (by a previous 1xx response),
the response message will not create a new call-leg, but will be mapped to the
already existing forked call-leg.