IMO the appropriate way to treat session timer is that it simply
establishes a deadline for a session refresh and a responsibility for
doing it.
If no reinvite or update has been initiated when the deadline is
reached, then the designated UA is to initiate one. If there is need to
send a reinvite or update prior to the deadline, it still serves as a
refresh, and renegotiates a new deadline and responsibility.
If the deadline is reached, the UA can send whatever sort of
invite/update it wishes. This may change the session or not. If there
was no other reason for sending this, then presumably there is no need
to request a change.
The decision whether to reuse the old sdp or create new must be made on
every reinvite or update, not just those used for session timer. (And if
an UPDATE is being sent, if the intent is not to change the sdp, then it
is better to send no offer than to send the prior offer.)
If you want to just verify the session, whether for session timer or
not, and you don't wish to change the sdp, then the best option is to
use UPDATE with no sdp, since that guarantees there will be no o/a.
Thanks,
Paul
Brett Tate wrote:
>> Of course the refresher should always be prepared
>> to receive a new SDP. What I was trying to establish
>> is what can the UAC and UAS do to re-use a previous
>> SDP (as RFC 4028 suggests) when the roles of the
>> offer/answer dialog have been reversed since the
>> last exchange.
>
> RFC 4028 does not authorize violation of RFC 3264. This means that the
> UAC and/or UAS may need to supply adjusted offer or answer SDP for RFC
> 3264 compliance reasons during a refresh.
>
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
