> UAC UAS > > ---- INVITE (1) ----> > > <--- 401 (1) ----- > > ---- ACK (1) -X ACK packet lost in transit > > ---- INVITE (2) ----> (with Auth. credentials) > > What should the UAS do with INVITE (2) before it > receives the ACK for the 1st transaction? > > I'm assuming that INVITE (2) has incremented the CSeq, but > it has the same Call-ID and From tag as the INVITE (1). > > I've heard two answers: > > > > 1) UAS sends 491 to UAC > > 2) UAS processes INVITE (2) > > > > Which one is correct?
Similar race conditions are discussed within draft-ietf-sipping-race-examples. Since Paul and I are currently in disagreement about using 491 Pending Request when not actually a pending request, I thought that I'd mention the following thread to hopefully spark more discussion about 491 versus 500 with Retry-After. http://www1.ietf.org/mail-archive/web/sipping/current/msg13657.html Concerning your specific question... Option 2 is the better solution when the race condition corresponds with 401 related ACK. If you follow rfc3261 and don't retry the 401 response until ACK, you definitely should not reject the INVITE. _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
