[reSIProcate] Session destroyed while in OnTerminated(..)

Kovar, William (Bill) bkovar at avaya.com
Thu Jan 18 15:42:59 CST 2007


see below..
 
Bill Kovar

  _____  

	From: Scott Godin [mailto:slgodin at icescape.com] 
	Sent: Thursday, January 18, 2007 4:26 PM
	To: Kovar, William (Bill)
	Cc: resiprocate-devel at list.sipfoundry.org
	Subject: RE: [reSIProcate] Session destroyed while in
OnTerminated(..)
	
	

	Bill,

	 

	It the threading model was valid, 
	[Kovar, William (Bill)] I AM assuming that my threading model is
invalid, i.e. calling session->end() from an App thread is BAD!!, and
I'm trying to best understand how to fix it. My question below still
stands. Will DumCommand fix the timing problem?

	 then Dum should not be able to process the 200 response while
you are in your onTerminated callback.  The process loop should be
blocked. [Kovar, William (Bill)]  Right!! But it's not given my
scenario.

	How do you ensure that messages such as BYE and their responses
are routed to the same dum thread that created the dialog  by using the
message filter rules?[Kovar, William (Bill)]  Since I only run a small
number of UAs ( 1 B2B for almost all my devices, and separate UAs for
special devices) I register their URI in a UserList similar to
resip::MessageFilterRule::SchemeList and then added code in
MessageFilterRule to handle the new type of List. Since the
MessageFilterRule is at the Stack level, I continually add new URIs when
needed and the TU layer routes the msg to the correct DUM.

	 

	Scott

	 

	From: Kovar, William (Bill) [mailto:bkovar at avaya.com] 
	Sent: Thursday, January 18, 2007 4:09 PM
	To: Scott Godin; resiprocate-devel at list.sipfoundry.org
	Subject: RE: [reSIProcate] Session destroyed while in
OnTerminated(..)

	 

	Scott,

	 

	You may have mis-understood me. I have an app thread that
controls/monitors one of N UAs, each running on their own DumThread but
sharing a single StackThread. Use of a single Stack thread across
multiple Dums is accomplished by adding user based switching in
MessageFilterRule. Works quite nicely for phone numbers, actually!!

	 

	In no situation does one Dum thread (UA) ever make a call on
another Dum thread. I don't do that kind of thread hopping.

	 

	What I am doing, which I believe is solvable with DumCommand, is
this: At the App thread, when I decide which UA to control, I directly
call session->end() from the App thread causing the problem I described,
namely, if OnTerminated() runs too long, the 200 OK response to the BYE
blows away the session/Dialog/etc.

	 

	So my question is: Will the use of DumCommand in this instance,
from my App thread, directed at a specific Dum thread, fix the sequence
problem??

	 

	Bill Kovar

	bkovar at avaya.com

	Avaya, Inc.

	(732) 852-2609

	 

		 

  _____  

		From: Scott Godin [mailto:slgodin at icescape.com] 
		Sent: Thursday, January 18, 2007 3:56 PM
		To: Kovar, William (Bill);
resiprocate-devel at list.sipfoundry.org
		Subject: RE: [reSIProcate] Session destroyed while in
OnTerminated(..)

		It is not legal to have multiple dum threads.  All calls
to dum->process and the dum api's must be run from the same thread, or
must be protected.

		 

		http://www.resiprocate.org/DUM_Threading

		 

		 

		From: Kovar, William (Bill) [mailto:bkovar at avaya.com] 
		Sent: Thursday, January 18, 2007 3:20 PM
		To: Scott Godin; resiprocate-devel at list.sipfoundry.org
		Subject: RE: [reSIProcate] Session destroyed while in
OnTerminated(..)

		 

		I run 2 dums, 1 SipStack in my B2B, each using DumThread
(2) and the same StackThread(1).

		 

		So my calling session->end() from outside of the Dum
thread is causing this sequencing problem??

		 

		And posting the session->end() using DumCommand will get
around this sequencing problem??

		 

		Bill Kovar

		bkovar at avaya.com

		Avaya, Inc.

		(732) 852-2609

		 

			 

  _____  

			From: Scott Godin [mailto:slgodin at icescape.com] 
			Sent: Thursday, January 18, 2007 2:17 PM
			To: Kovar, William (Bill);
resiprocate-devel at list.sipfoundry.org
			Subject: RE: [reSIProcate] Session destroyed
while in OnTerminated(..)

			It seems that you may have multiple dum threads
running.  Dum should only be running in one thread.  With dum running in
one thread - nothing else in dum happens until you return from the
onTerminated callback.

			 

			The 15ms delay you are seeing is likely due to
some problem in your process loop.

			 

			Scott

			 

			From:
resiprocate-devel-bounces at list.resiprocate.org
[mailto:resiprocate-devel-bounces at list.resiprocate.org] On Behalf Of
Kovar, William (Bill)
			Sent: Wednesday, January 17, 2007 6:08 PM
			To: resiprocate-devel at list.sipfoundry.org
			Subject: [reSIProcate] Session destroyed while
in OnTerminated(..)

			 

			All,

			 

			I'm sure this is not new information but I am
wondering what, if anything could/will be done to the following problem
regarding OnTerminated() callback.

			 

			When one sends an BYE with
InviteSessionHandle->end() the following happens:

			1. The BYE msg is built and put on the Fifo
ready to be sent on the wire

			2. the session is transitioned to
IsTerminating()

			3. The onTerminated() callback is fired.

			 

			If system load causes a slowdown, it quite easy
to be manipulating the session in OnTerminated() and the AppDialog,
AppdialogSet and InviteSession all get destroyed before exiting the
callback. This happens when the BYE gets a 200 OK answer and the session
is torn down.

			 

			It seems that there is a window of ~15ms before
the BYE msg is sent out. What's controlling this time?

			 

			Any suggestions how to get around this issue or
if the session will be kept around longer than the receipt of the 200 OK
on the BYE. Any forseeable changes to DUM?

			 

			Bill Kovar

			bkovar at avaya.com

			Avaya, Inc.

			(732) 852-2609

			 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20070118/5e225e82/attachment.htm>


More information about the resiprocate-devel mailing list