Hello,
o Bert Fraterman [09/21/09 13:52]:
Sorry for the half message, I’ve hit the send button too early, full
message is below:
*From:* [email protected]
[mailto:[email protected]] *On Behalf Of *Bert Fraterman
*Sent:* maandag 21 september 2009 13:41
*To:* [email protected]
*Subject:* [Sems] Problem with early session destruction
Hello,
I have developed a SEMS application in C++, but I had problems with too
early destroyed sessions:
First, the BYE is send, and my sessions wait for some event, which is
launched by a separate thread. After this event is launched, the session
is stopped with the setStopped() method call.
Sometimes, the session was destroyed before I called the setStopped()
method, which made me delve into the SEMS code.
are you sure the session was really destroyed, i.e. it was deleted?
If you look at AmSessionContainer::clean_sessions, you will see that the
sessions that are still running (!is_stopped()) are not deleted, only
those where setStopped() has been called. in the debug log you should
see something like 'Session xyz is still running' periodically.
I believe this code is responsible for this behavior (SEMS 1.1.0):
void AmSession::run()
{
try {
try {
onStart();
while (!sess_stopped.get() ||
(dlg.getStatus() == AmSipDialog::/Disconnecting/)// ||
// (dlg.getUACTransPending())
){
It seems to me that the main loop waits for the session to reach the
stopped status or the status ‘Disconnecting’. I can’t see the logic in
this, since in most cases, the loop will wait for the setStopped()
method call and be destroyed after that, but in very few cases (when the
while-check is made, the call is in disconnecting status) the call is
also destroyed.
So once I send a BYE, the session *might* be destroyed, but I have no
guarantee. This makes it impossible to wait for an (non SEMS) event
after sending a BYE, since the session might soon be destroyed.
I’m not sure why this code is structured like this, I think it would be
better if SEMS behaved in one of following two modes:
- Destroy the session only once the setStopped() method was called.
the idea was to make it easy for the application developer. If the SIP
dialog is in disconnecting state, for example due to BYE from RTP
timeout, the session would still be destroyed after a while, even if the
application developer did not think about all possible cases.
- Destroy the session if the setStopped() method was called or
when the dialog has the disconnecting or disconnected status.
good idea, but in the beginning, before e.g. an INVITE is sent out, the
session's dialog is in the Disconnected state as well.
This way there is more consistent behavior in the destruction of sessions.
Is the code in AmSession intended this way? The comments suggest it is
incomplete, could this be fixed?
if you want to further get and process events after 'main even
processing loop' has finished, you can use the onBeforeDestroy function:
void MySession::onBeforeDestroy() {
try {
while (!sess_stopped.get()) {
waitForEvent();
processEvents();
} catch(const AmSession::Exception& e){
ERROR("%i %s\n",e.code,e.reason.c_str());
}
}
hth
Stefan
Kind regards,
Bert Fraterman
http://www.winitucom.com/stationary/emailfooter_logo.jpg
Tolnasingel 1
2411 PV Bodegraven
Mobiel
Email
Website
http://www.frontisklanten.nl/winitu/emailfooter_spacer.jpg
+31(0)6-30102385
[email protected] <mailto:[email protected]>
www.winitucom.com/ <http://www.winitucom.com/>
This message (including any attachments) is confidential and may be
privileged. If you have received it by mistake please notify the sender
by return e-mail and delete this message from your system. Any
unauthorised use or dissemination of this message in whole or in part is
strictly prohibited. Please note that e-mails are susceptible to change.
Winitu Communications B.V. shall not be liable for the improper or
incomplete transmission of the information contained in this
communication nor for any delay in its receipt or damage to your system.
Winitu Communications B.V. does not guarantee that the integrity of this
communication has been maintained nor that this communication is free of
viruses, interceptions or interference.
------------------------------------------------------------------------
_______________________________________________
Sems mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/sems
--
Stefan Sayer
VoIP Services
[email protected]
www.iptego.com
IPTEGO GmbH
Wittenbergplatz 1
10789 Berlin
Germany
Amtsgericht Charlottenburg, HRB 101010
Geschaeftsfuehrer: Alexander Hoffmann
_______________________________________________
Sems mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/sems
