[reSIProcate] DUM and ending InviteSessions Fixes

[Scott Godin]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20041001/12536149/attachment.htm>