>> 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 > >What I suggest above amounts to the same thing as sending some >error for > INVITEs with a To-tag that don't match an existing invite >dialog usage. Its just a matter of figuring out what error >code is best. I'm dubious of 481 because it is already quite >overloaded, but it might be ok. Another possibility is 403.
According to RFC 3261, 481 is the correct response code here. Here is what sec. 12.2.2 mentions: If the UAS wishes to reject the request because it does not wish to recreate the dialog, it MUST respond to the request with a 481 (Call/Transaction Does Not Exist) status code and pass that to the server transaction. Sanjay. _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
