John,
My understanding.
I guess it is sort of implied in the signalling that turns the
feature off - having come from the UA that UA on receipt of the 200 OK
with no Session Expires will turn it off then, it wont wait until the next
session refresh because there won't be one - neither end point retains an
expectation to send | receive one.
Now, I might jump the gun on Brett here ;-) if say the UAC did
this signalling (no Session Expires header = turning off the feature) it
should be possible for the UAS in the 200 OK or in subsequent signalling
to turn the feature back on potentially with itself as the refresher.
(Require with timer, SessionExpires >90 with a refresher of UAS .... ).
Wayne Davies
"John Smith" <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
14/11/2004 06:06 PM
To: [EMAIL PROTECTED]
cc:
Subject: [Sip-implementors] Response without a Session-Expires
header
Hi,
I have a question about the Session-Timer draft:
A quotation, taken from draft-ietf-sip-session-timer-15 section 7.2 says:
"...the session timer can be 'turned-off' mid dialog by receiving a
response
without a Session-Expires header."
This description regards only the side, which received the response, but
not
to the sending endpoint.
Referring response sender side in this scenario, should it turn off the SE
mechanism or should it wait until the upcoming session timer expiration
and
then refresh/disconnect the call?
Best Regards,
JS.
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.com/
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
******************************************************************************
- NOTICE FROM DIMENSION DATA AUSTRALIA
This message is confidential, and may contain proprietary or legally privileged
information. If you have received this email in error, please notify the
sender and delete it immediately.
Internet communications are not secure. You should scan this message and any
attachments for viruses. Under no circumstances do we accept liability for any
loss or damage which may result from your receipt of this message or any
attachments.
******************************************************************************
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
