I may be out of my league on this one, since I have not had this
problem yet.
However, in your case, the client is the initiator, so the client is
the one responsible for re-initializing the session key, in other
words, re-establishing the a new session or renewing the current one,
although I don't know if the later is expected. The exception is
thrown to the server when sending back notifications, not the client,
which would be the one responsible for renewing the session he
started.
The documentation states:
"Gets or sets the time span after which the initiator renews the
key for the security session"
So, its in fact the initiator the one responsible for renewing the
session.
Having said this, and although I'm not familiar with your scenario,
I'd assume that the server would wait for a message by the client
(periodically) before continue to send notifications. In fact, 15
hours later the client might not even be there anymore. On the other
hand, if you could renew a session key programatically, it would allow
the server to send a certain notification to make the client perform
the renewal (or re-open the channel) and therefore wakeup/renew the
session key, although this one seems a bit far-fetched, since it was
the client that initiated the conversation and its the client who will
eventually end it.
I know its not a complete answer
, but it was an interesting enough
scenario.
Let me know your thoughts or updates ...
regards,
Tiago Halm