Hi all, 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). INVITE(B) has the same Call-Id and From Tag and the CSeq is +1. This happens because even though the UAC sends ACK(A) followed by INVITE(B) (on UDP), an proxy sends INVITE(B) using TCP which occasionally wins the race to get to the UAS.
INVITE(A) <-------------- UDP 100 -------------->UDP 401 -------------->UDP INVITE(B) <-------------- TCP ACK(A) <-------------- UDP INVITE(B)'s transaction gets linked to INVITE(A)'s dialog which makes it complicated to resolve when the re-transmissions arrive. 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. Neil _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
