Sani,
I don't think this is legal. But it also shouldn't be necessary. An UPDATE without SDP
is a good way to update the session timer if that is all you need to do. But if you
are sending an UPDATE for some reason you should take the opportunity to use it to
refresh the session timer as well.
I posted a similar question about this some time ago but using reINVITE. There was a
response from Brett Tate, but no other discussion that I recall. As I read the spec, I
believe that an UPDATE or reINVITE that doesn't mention the session timer actually
causes the session timer to be cancelled, leaving the session without a timer. But the
language is sufficiently obscure that it would be good to get a clarification. Brett
agreed wrt reINVITE. I have attached the older messages.
Paul
> Sani Tripathy wrote:
>
> My question is : Is it possible to send Update without any offer when a re-invite or
>Update having an offer is pending?
>
> According to Session-Timer -- draft-ietf-sip-session-timer-09.txt, Update is
>recommended to be used as the refresher request instead of a re-invite. It is
>recommended that Update used for refresh should not have SDP.
>
> Update draft suggests that
> "if the UPDATE is being sent after the completion of the initial INVITE
>transaction,
> it cannot be sent if the caller has generated or received offers in a re-INVITE
>or
> UPDATE which have not been answered. "
> This is justified when Update is used only for offer-answer purpose, but can be
>overridden while being used for session timer.
>
> Thanks,
> Sani
>
>
>
>
--- Begin Message ---
I was having a side conversion with Sani on this, and one point came up as unclear:
Suppose a session expiration value has been negotiated. Then, before it expires, a
reINVITE is sent without any Session-Expires header. Then what is the session timing
state?
I *think* this must have the effect of disabling the session timer (equivalently,
setting the session expires value to infinity.) But the point was hazy enough to want
to
get clarification.
Paul
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
--- End Message ---
--- Begin Message ---
> I was having a side conversion with Sani on this, and one
> point came up as unclear:
>
> Suppose a session expiration value has been negotiated. Then,
> before it expires, a reINVITE is sent without any
> Session-Expires header. Then what is the session timing
> state?
>
> I *think* this must have the effect of disabling the session
> timer (equivalently, setting the session expires value to
> infinity.) But the point was hazy enough to want to
> get clarification.
Yes, it indicates a potential disabling. However
the 2xx is what truly would indicate a disabling.
Section 3:
"All session refresh requests are processed
identically to the initial session refresh
request, so that the 2xx response to a session
refresh request carries the new time at which
the session will expire."
Section 7.2:
"If the 2xx response did not contain a
Session-Expires header field, there
is no session expiration. In this case, no
refreshes need to be sent. A 2xx without a
Session-Expires can come for both initial
and mid-dialog session fresh requests."
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
--- End Message ---
