Paul, The worst case I had in mind is for a UAC sending reINVITE and then immediately BYE over UDP, where due to reordering the BYE arrives first. The goal is then to avoid that the reINVITE creates a new dialog at the UAS. Lingering for as long as the BYE transaction lives would normally suffice. Alternatively, if the dialog is destroyed upon sending 200 OK for BYE, the UAS can have a policy to send 481 for INVITEs with a to-tag. But if that is for some reason not possible, keeping the state around seems the only option
Regards, Jeroen Paul Kyzivat wrote: > Jeroen van Bemmel wrote: >>> *Dialog* state must be reference counted. It will stay around at >>> least as long as any dialog usages remain. I think Jeroen really >>> means to suggest that the invite dialog usage state should stay >>> round as long as the BYE transaction. That *may* not be necessary. >>> What is required is enough state to reissue the BYE in the case >>> that it is challenged. But I don't think dialog usage state is >>> required to do that. But clearly one way to do that is to keep the >>> invite dialog usage until the 200 for the BYE arrives or the >>> transaction times out. >> >> I was talking about the UAS side. Just like the BYE ServerTransaction >> stays around to catch any retransmitted BYEs (and to resend OK), the >> dialog / dialog usage should stay around to catch any pending new >> transactions (and reply 481). Markus was saying that dialog state is >> destroyed as soon as the 200 OK for BYE is sent, my point was that it >> needs to stay around a little longer to handle this case > > I don't think it is at all clear that this is required. > > How long would you have this go on? If it is to happen at all, I would > be inclined to keep the dialog usage around as long as any > transactions associated with it linger. But as long as the > transactions linger, they can handle associated retransmissions even > without retaining the usage. So the purpose of keeping it would > apparently be to handle new transactions within the dialog or dialog > usage. I don't see any reason to do that. Returning 481 for those > should be just fine. > Paul _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
