Sanjay Sinha (sanjsinh) wrote:
>>> 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.
It may indeed be the best choice. The problem with 481 is that it mixes
up dialogs and dialog usages. It might be confusing if you have a dialog
that is being used for a subscription, and when you try to send an
INVITE on it you get a 481.
In spite of that, I guess it probably beats the other alternatives.
Paul
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
