Well, I wouldn't. I found a bug in my stack's logic the other day where a session object wouldn't accept a(n in-dialog) a BYE because the BYE's Request-URI's GRUU wasn't the GRUU used in the INVITE (because another UA had a bug). Then I was rereading the transfer stuff, and I thought, well, this is a big wide world and someone somewhere WILL send my stack an out-of-dialog BYE, and what should I do about it.
As you and Michael and my gut all say, though, if the BYE's not in-dialog, just chuck it. frank "Paul Kyzivat" <[EMAIL PROTECTED]> wrote: > Why would you want to accept an out of dialog BYE? > > I think somewhere there was a 3pcc case where it made some sense to tell > a remote user to do a BYE on some session it had. In that case I think > it was proposed to use a REFER where the the Refer-To had a message=BYE. > > Paul > > Frank Shearar wrote: > > draft-ietf-sipping-cc-transfer section 5 tells us that we can use GRUUs to > > associate an out-of-dialog REFER to an INVITE dialog usage. > > > > Using that same logic, could one do the same with a BYE? That is, if I've > > set up a call using a GRUU (*) and I receive an out-of-dialog BYE sent to > > that GRUU. Should I just drop the BYE saying "sorry, 481"? Should I accept > > the BYE as being "equivalent" to an in-dialog BYE (in the sense that an > > in-dialog REFER and an out-of-dialog REFER are equivalent: doing the same > > thing)? > > > > REFER uses Target-Dialog as a means of authorising the request, so what if > > one received an out-of-dialog BYE targetting one's call's GRUU, with > > Target-Dialog? > > > > I'm tempted to just say "it's not an in-dialog BYE; reject it"; after all, > > RFC 3261 says > > > > 15.1.1 UAC Behavior > > > > A BYE request is constructed as would any other request within a > > dialog, as described in Section 12. > > > > Any thoughts? > > > > frank > > > > (*) Confession: my stack only implements version -10, not -11 (at the > > moment, at least). Perhaps I use obsolete terminology above; I hope not! > > > > _______________________________________________ > > 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
