[reSIProcate] DUM and ending InviteSessions Fixes

[Scott Godin <slgodin@xxxxxxxxxxxx>]

I just checked in the following changes concerning ending an InviteSession and queued BYE scenarios:

 

1. If end() being called by a UAS sometime between sending the 200 and receiving the ACK - the BYE is now queued and send out either when the ACK is received or we timeout waiting for the ACK.  This applies to both initial invites and reinvites.
2. ACK is now sent before the BYE in the ReInvite if a BYE was queued when waiting for a response to an outbound reInvite.  This is to comply with 13.2.2 - technically it is only required if ACK contains an answer body - but we will do it regardless for consistency.
3. Inbound BYE is now handled in ReInvite state - incase it crosses with the outbound reinvite request.  Thanks Kaiduan!

 

Behavior now conforms to the following RFC3261 snippets:

 

RFC3261 - 15 - "The caller's UA MAY send a BYE for either confirmed or early dialogs, and the callee's UA MAY

send a BYE on confirmed dialogs, but MUST NOT send a BYE on early dialogs. However, the callee's UA

MUST NOT send a BYE on a confirmed dialog until it has received an ACK for its 2xx response or until the

server transaction times out."

 

RFC3261 - 13.2.2 - "If the 2xx contains an offer (based on the

rules above), the ACK MUST carry an answer in its body. If the offer in the 2xx response is not acceptable,

the UAC core MUST generate a valid answer in the ACK and then send a BYE immediately."

 

Scott