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
