On 2 August 2012 16:41, Worley, Dale R (Dale) <[email protected]> wrote: > > I imagine that if your stack can't keep requests with different CSeq's > separate, it would make things difficult. > > E.g., how does your stack handle two non-INVITE requests arriving > quickly, where the second request arrives before the response to the > first request has been sent? How does it handle retransmissions of a > first (non-INVITE) request after a second (non-INVITE) request is > processed? > > Your stack cannot operate successfully if it assumes that one > transaction will be completely finished before another request > arrives. >
The situations above are fine as far as I am aware. I'll double check. Just in this situation the second INVITE got matched to the same entity that processed the first INVITE (as it matched the Call-Id and >From tag) which at that point was waiting for the ACK and ignored the INVITE. Because it got incorrectly associated in the first instance when the retransmissions occurred the INVITE was ignored as it had already been processed. This INVITE should have been associated with a different entity and treated as a new and separate attempt to establish a dialog. We're going to fix can fix this by fixing the way transactions are associated. > > This is not at all reasonable in this situation. The UAS *has* sent > the final response to the first INVITE (the 401), and the UAC *knows* > that (because it has sent the second INVITE due to receiving the 401). Noted. We're not going to do this. > > Dale Thanks Neil _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
