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

90 HP-UX C SIP Stack Programmer’s Guide
Additional Functionality Of Call-leg Layer
If the SIP Stack is configured to enable merging support, only the first request
will create a transaction. All other requests will be rejected with a 482 response.
Otherwise, a new server transaction will be created for each request. For more
information, see Transaction Merging Support in the the Working with
Transactions chapter.
Since all the new transactions have the same request identifiers, the first
transaction will create a new call-leg and all other transactions will also be
mapped to this call-leg for handling. The call-leg default behavior on receiving
nested initial INVITE transactions for the same call-leg is to handle only the
first transaction, and to reject all others with a 400 response.
Applications that want to create a separate call-leg for every nested transaction
may use the callback function, RvSipCallLegNestedInitialReqRcvdEv(). If this
callback is implemented, call-leg behavior will be as follows:
 First transaction case
1. Create a call-leg.
2. Insert this call-leg to the call hash table. Note that this call-leg
has no To tag parameter yet.
3. Change call-leg state to OFFERING.
 Second transaction case
1. Call the RvSipCallLegNestedInitialReqRcvdEv() callback
function.
2. If the application chooses not to create a new call-leg, reject
with 400.
3. If the application chooses to create a new call-leg, create the
new call-leg to handle the nested Invite transaction. Note that
this call-leg is not in the hash table yet, because this new call-
leg has the same call identifiers as the first call-leg.
4. Change call-leg state to OFFERING.
5. When the application sends 1xx or a final response to this call-
leg, the call-leg will be inserted into the call-legs hash table,
because now it has a To tag parameter that identifies it from the
first call-leg.