On 2/21/14 6:38 AM, Brett Tate wrote:
>> All is well but what happens with the Session Timer response?
>
> RFC 4028 basically allows the Session-Timer to be negotiated with every
> INVITE/UPDATE request. The last 2xx response wins.
>
> If UPDATE 2xx sent/received within an INVITE, refreshing/expiring would be
> done based upon the UPDATE 2xx's added/missing Session-Expires. When the
> subsequent INVITE 2xx is sent/received, refreshing/expiring would be done
> based upon the INVITE 2xx's added/missing Session-Expires. If I recall
> correctly, the RFC provides some guidance to reduce the impacts of
> potential race conditions.
I generally agree with Brett.
I think this is a bit fuzzy in the rfc when the UPDATE occurs before the
initial invite transaction completes.
To be safe, I would recommend that B-side do put SE in the UPDATE, and
then make sure that what is in the 200 (INV) is consistent with all that
went before, so that both sides will agree on the expiration time and
refresher regardless of whether taking the result from the UPDATE or the
INVITE.
IMO it is not safe to omit SE from the UPDATE - that might result in no
session timer.
Thanks,
Paul
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
