I generally agree with Jeroen. Couple more points inline.
Paul
Jeroen van Bemmel wrote:
> inline
>
> Regards,
> Jeroen
>
> ----- Original Message ----- From: "Markus Hofmann" <[EMAIL PROTECTED]>
> To: "Paul Kyzivat" <[EMAIL PROTECTED]>
> Cc: <[email protected]>
> Sent: Friday, October 06, 2006 11:30 AM
> Subject: Re: [Sip-implementors] BYE request overlapped on re-INVITE
>
>
>> Paul Kyzivat wrote:
>>
>> Hi Paul,
>>
>>> -- OR, this could be treated as a new invite within an existing dialog,
>>> and so be treated as a new call. (This is not a recommended behavior and
>>> clearly has a bad result here.)
>>
>> exactly that the point. Where should the UAS know that the Re-INVITE
>> retransmission belongs to an old dialog? The whole information is
>> destroyed after the BYE was answered with 200 OK.
>
> The BYE ServerTransaction lingers for 64*T1 seconds (for UDP), i.e.
> Timer J. A properly implemented SIP stack would keep the dialog state
> around for at least that long, in order to avoid this situation
The interactions between transactions, dialog usages, and dialogs are
subtle and not well defined. (That is why we end up talking about them.)
The reinvite is keyed to the same *dialog* by the callid & to/from tags,
but in the case of invite (unlike subscribe) there is no keying to a
dialog usage. THere can never be more than one invite dialog usage per
dialog. It has never been clarified whether that means there can only be
one invite dialog usage per dialog *ever*, or *concurrently*.
Specifically, whether it is possible to end one invite dialog usage in a
dialog, and then begin another one.
This is an example of a problem that arises if you allow a second one to
begin after a first one ends. Give the lack of popularity for multiple
dialog usages in general, I think we can safely declare that there
should be at most one *ever*, or that it is invalid to initiate an
invite dialog usage in an existing dialog. That would prevent the
problem above.
*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.
>> Another point is what is the goal to produce retransmission after
>> sending out after a BYE. What the UAC expects? Is it still necessary to
>> send out Re-INVITEs when the own call is gone?
>>
>> In my opinion the BYE should be give to the transaction layer until the
>> INVITE transaction was finished.
I think the above was probably intended to say "BYE should *not* be
given...".
> The transaction layer treats each transaction independently of others.
> Associations between transactions are made in the dialog layer, that
> would be the place to implement this. It already has to ensure that no
> new INVITE is sent while another one is pending; BYE can be added to
> that logic
You can certainly do this if you wish. But 3261 doesn't require it, so
you had better be prepared for somebody doing it the other way.
I think this is well enough defined that it doesn't require a change to
3261 to mandate this behavior.
Paul
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
