Agreed, 487 is the best choice. I would also opine that SIP 491 should not be a choice for this particular scenario where the intent is to tear down the call. SIP 491 Request Pending means the other side should wait a random amount of time to retry the reINVITE. Since the intent is to tear down the whole call, why bother the other side with this unnecessary computation. If BYE (and say its 1st retransmission gets lost), you may already see the reINVITE attempt coming back from the other side while BYE is still retransmitting from this side. This could be detrimental for some implementations as observed in production. Instead of every vendor coming up with its own interpretation & implementation, it would be helpful if the standard made specific recommendation for these loose cases.
On Sun, Aug 7, 2011 at 9:50 PM, Worley, Dale R (Dale) <[email protected]>wrote: > >>> Interesting, never thought about it. So, if I send a re-INVITE for > >>> which I have no final reply yet and then I send a BYE, should the UAS > >>> reply 200 for the BYE and terminate the remaining re-INVITE > >>> transasction without sending a final response? > > > >>> Or should the UAS reply a "491 Request Pending" for the BYE? Anyhow > >>> section 14.2 in RFC 3261 just indicates that 491 is useful when there > >>> is a pending re-INVITE from A to B and B sends a re-INVITE to A. In > >>> that case A should reply 491. > > A UA must send a final response for every request it receives. In the > case of a re-INVITE that is outstanding when a BYE is received, we > have to consider the sequence of the requests (which is manifest from > the CSeq values). I believe in this example, it is assumed that the > BYE follows the re-INVITE. Given that the BYE clears the dialog state > (actually, the state of the INVITE usage within the dialog), it > doesn't really matter what response code is given for the re-INVITE. > One approach is to report that the re-INVITE was rejected or aborted, > 491 or 487. > > Another approach is to give the 400 generic failure response. > > A third approach is to pretend that the re-INVITE arrived after the > BYE (the UAC can't prove it didn't!) and send a 500 Out Of Order > response. > > 487 looks particularly appropriate: > > 21.4.25 487 Request Terminated > > The request was terminated by a BYE or CANCEL request. This response > is never returned for a CANCEL request itself. > > Dale > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
