An UPDATE is an UPDATE. The effect is strictly a function of its
content. And as already mentioned, every UPDATE either refreshes the
session timer, or disables it, regardless of what else it does.
I suppose you might consider that an UPDATE that does nothing else must
have been intended only to manipulate the session timer. But that is
mere speculation. There is no way to know (nor *need* to know) why the
UPDATE was sent.
Best to think of session timer as simply a reminder that you should do
some additional signaling before it expires.
For instance, if you have a session timer running, and then before it
expires you have need to do a reINVITE/UPDATE for some *other* reason
(e.g. hold), then that signaling will reset/cancel the session timer. If
you have occasion to do that often enough you may never have to
explicitly refresh your session timer.
Thanks,
Paul
On 11/7/2010 11:02 PM, Priya Arya wrote:
> Hi,
>
> I have one query regarding the Session Refresh UPDATE.
>
> - Just by looking at PDU of UPDATE in a session, can it be idenitified that
> if this UPDATE is for session refresh or for updating the SDP parameters in
> the session.
>
> Actually RFC 4028 recommends the following :
> " It is RECOMMENDED that the UPDATE request not contain an offer
> [4<http://tools.ietf.org/html/rfc4028#ref-4>], but a re-INVITE SHOULD contain
> one, even if the details of the session have not changed."
>
> But if UPDATE is received from UAS containing SDP in it, then can the session
> version number in the "o-line" be used to identify if this UPDATE is for
> updating the SDP parameters only.
>
> Thanks in advance.
>
> Regards
> Priya Arya
>
> ________________________________
> "DISCLAIMER: This message is proprietary to Aricent and is intended solely
> for the use of the individual to whom it is addressed. It may contain
> privileged or confidential information and should not be circulated or used
> for any purpose other than for what it is intended. If you have received this
> message in error, please notify the originator immediately. If you are not
> the intended recipient, you are notified that you are strictly prohibited
> from using, copying, altering, or disclosing the contents of this message.
> Aricent accepts no responsibility for loss or damage arising from the use of
> the information transmitted by this email including damage from virus."
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
