Jeroen van Bemmel wrote:
> 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.
I think the simplest way to solve that is to declare that a new invite
dialog usage establishing request may not be sent within an existing
dialog - that it may only be sent as a dialog establishing request (when
there is no pre-existing dialog.)
That removes some of the potential flexibility of shared dialogs, which
a lot of people will consider a good thing. I doubt that it removes any
functionality that is actually supported by any existing deployment.
(Anybody that knows of an implementation that currently supports that
please speak up.)
I may be the only person who ever thought that sending a new invite
within an existing dialog had any utility at all, and even I consider it
marginal. Making it work right would probably require other changes that
are not worth the trouble.
> 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.
Paul
> 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
