On Thu, 2009-10-29 at 19:34 -0400, M. Ranganathan wrote:
> Hello,
>
> For the purposes of this mail, please ignore the other traces posted
> in that issue. I have extracted the essential problem into a smaller
> trace.
>
> Here is a log for analysis:
>
>
> http://track.sipfoundry.org/secure/attachment/22364/merged2.xml
>
> Here is the scenario:
>
> An in bound call comes in from the "itsp" via sipXbridge.
>
> It is answered by sipXacd on Frame 8.
>
> ACD immediately sends a RE-INVITE without waiting for ACK on Frame 13.
>
> SipXbridge responds REQUEST PENDING.
>
> I believe sipxbridge is doing the right thing because the ACK has not
> yet been sent. I believe ACD should wait for ACK before it sends a
> RE-INVITE.
You are correct. RFC 3261 Section 14.1:
Note that a UAC MUST NOT initiate a new INVITE transaction within a
dialog while another INVITE transaction is in progress in either
direction.
1. If there is an ongoing INVITE client transaction, the TU MUST
wait until the transaction reaches the completed or terminated
state before initiating the new INVITE.
2. If there is an ongoing INVITE server transaction, the TU MUST
wait until the transaction reaches the confirmed or terminated
state before initiating the new INVITE.
The case in your trace violates the second rule, since the server
transaction does not reach the confirmed state until the ACK is
received.
_______________________________________________
sipx-dev mailing list [email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
sipXecs IP PBX -- http://www.sipfoundry.org/
