> From: neil corcoran [[email protected]] > > We've come across a situation where we as the UAS challenge INVITE(A) > with a 401, and the > second INVITE(B) containing the credentials arrives before the ACK for > INVITE(A).
This is always possible, because the UAC is sending two messages in succession, the ACK and the second INVITE, and the network is allowed to re-order them. > INVITE(B)'s transaction gets linked to INVITE(A)'s dialog which makes > it complicated to resolve when the re-transmissions arrive. 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. > For me the best solution I think would be to respond to INVITE(B) with > 500 and include a Retry-After header but I've > not been able to spot anything definitive in the RFCs other than this > which isn't quite the same. > > >From RFC 3261 > > "14.2 UAS Behavior > > ... > > A UAS that receives a second INVITE before it sends the final > response to a first INVITE with a lower CSeq sequence number on the > same dialog MUST return a 500 (Server Internal Error) response to the > second INVITE and MUST include a Retry-After header field with a > randomly chosen value of between 0 and 10 seconds. " > > Is this a reasonable action to take in this situation. 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). Dale _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
