List Info

Thread: Long delays for DTMF - Seems that 200 OK is "lost"
Long delays for DTMF - Seems that 200 OK is "lost"
user name
 2006-08-22 12:44:15 
Hello,

OK, this is probably not Opal philosophy, but here is how I
got it working.

1 - Analysis : SIPConnection::SendUserInputTone is blocked
on 
    infoTransactions->Wait() 
    because it needs to know if the answer is 200 OK or not,
and there
    is a dead lock with the PDU receiver thread.

2 - Instead of doing a ->Wait(), it is possible to do a
->Start()
    It seems that this will prevent to wait for the answer
PDU, thus 
    preventing the deadlock.

3 - Drawback : if the answer _is not_ 200 OK, we have
already returned to the
    caller and we have no real way to tell him it failed
(Unsupported 
    content-type for example).

As of now, I don't have a better answer to provide, it
seems that this should
be done better, but as far as I'm concerned, it is fine for
now.

Anyone with a better idea is welcome ;)

Regards,
Paul

Paul Rolland, rol(at)as2917.net
ex-AS2917 Network administrator and Peering Coordinator

--

Please no HTML, I'm not a browser - Pas d'HTML, je ne suis
pas un navigateur 
"Some people dream of success... while others wake up
and work hard at it" 

"I worry about my child and the Internet all the time,
even though she's too 
young to have logged on yet. Here's what I worry about. I
worry that 10 or 15 
years from now, she will come to me and say 'Daddy, where
were you when they 
took freedom of the press away from the Internet?'"
--Mike Godwin, Electronic Frontier Foundation 
  

> -----Original Message-----
> From: openh323-adminopenh323.org 
> [mailto:openh323-adminopenh323.org] On Behalf Of
Paul Rolland
> Sent: Tuesday, August 22, 2006 9:29 AM
> To: openh323openh323.org
> Cc: rolas2917.net
> Subject: RE: [OpenH323]Long delays for DTMF - Seems
that 200 
> OK is "lost"
> 
> Hello,
> 
> Wonderful gdb !!!
> It has just told me what's wrong !
> 
> OK, I don't have a clue for the solution, but the
problem : I'm using
> simpleopal, and to send a tone, the SendTone from the
manager does :
> 1 - GetAllConnections
> 1.1 - GetConnectionWithLock
> 
> and then a conn->SendUserInputTone
> 
> Thus, we have acquired a lock in the SendTone function,
and this lock
> is _NOT_ released at the time the 200 OK PDU is
received, 
> thus causing the
> problem.
> 
> Hannes, is this the kind of change you could have
introduced in 2.93 ?
> 
> Is there another way to proceed in the simpleopal
application to avoid
> getting the lock ?
> 
> Regards,
> Paul
> 
> Paul Rolland, rol(at)as2917.net
> ex-AS2917 Network administrator and Peering Coordinator
> 
> --
> 
> Please no HTML, I'm not a browser - Pas d'HTML, je ne
suis 
> pas un navigateur 
> "Some people dream of success... while others
wake up and 
> work hard at it" 
> 
> "I worry about my child and the Internet all the
time, even 
> though she's too 
> young to have logged on yet. Here's what I worry
about. I 
> worry that 10 or 15 
> years from now, she will come to me and say 'Daddy,
where 
> were you when they 
> took freedom of the press away from the
Internet?'"
> --Mike Godwin, Electronic Frontier Foundation 
>   
> 
> > -----Original Message-----
> > From: openh323-adminopenh323.org 
> > [mailto:openh323-adminopenh323.org] On Behalf Of
Paul Rolland
> > Sent: Tuesday, August 22, 2006 8:04 AM
> > To: openh323openh323.org
> > Cc: rolas2917.net
> > Subject: RE: [OpenH323]Long delays for DTMF -
Seems that 200 
> > OK is "lost"
> > 
> > Hello Hannes;
> > 
> > > I'm not sure whether I can help, but I can
at least try to 
> > give some  
> > > clarifications.
> > 
> > Thanks for your time and details !!!
> >  
> > > finished.Wait() blocks until the transaction
is 
> considered to have  
> > > finished. Due to some SIP timer requirements
(check RFC 3261),  
> > > finished.Wait() originally blocked for at
least 5s after 
> > the 200 OK  
> > > was received. This was unacceptable in case
of hangups and  
> > > unregistration, where this sync point was
used as well. 
> I've then  
> > > applied a quick fix, that unblocks the sync
point as soon as the  
> > > transaction is considered complete.
> > 
> > Well, it's not precisely finished.Wait() that
seems to the the real
> > culprit, as digging more into the code seems to
show that 
> I'm stuck in
> > writerSemaphore.Wait(); 
> > inside 
> > PReadWriteMutex::StartWrite (this=0x80a35a8) at 
> > ../common/osutils.cxx:2571
> > when doing a GetSIPConnectionWithLock()
> > This occurs when I receive a 200 OK PDU as a reply
to an INFO I sent
> > to signal DTMF.
> > >From reading the code, it seems that the
locking mechanism 
> > is done to be
> > very local to a scope, so a ReadWrite lock
acquired thru 
> > GetSIPConnectionWithLock is expected to last only
as long as 
> > the returned
> > pointer exists. 
> > As this function in only called in
SIPEndPoint::OnReceivedPDU, I've
> > been PTRACE'ing enter and exit of this function,
to make sure 
> > that they
> > are balanced, and though they definitely are (or
behave as 
> > if), I still
> > have this lock.
> > 
> > > It may be that I've done something wrong
there. At least, since  
> > > you've mentioned
"finished.Wait()", I was instantly alerted.
> > > Make sure that the SIP Transaction is really
added to the  
> > > corresponding transactions list in either the
endpoint or 
> > connection.
> > > In doubt, have a look at sippdu, revision
2.93 of CVS HEAD.
> > 
> > If it was not added, what would be the result ? I
would 
> expect to see
> > GetSIPConnectionWithLock to return a NULL pointer
(or 
> > equivalent) to indicate
> > that no connection has been found, but this
shouldn't create 
> > a lock inside
> > the Get... call. Or is there something unusual I
should expect ?
> > 
> > > Unfortunately, I do not have time to work on
some issues in OPAL  
> > > library - at least not for the next couple of
weeks. I am 
> > not happy  
> > > with the patch I've commited in 2.93 and
have planned to 
> > review the  
> > > code and to implement a better solution.
> > I'll try to find time to analyze more precisely,
and I'll 
> > keep you informed.
> > 
> > I suspect that the addition of the SIP transaction
is also a 
> > ReadWrite locked
> > operation, so I might have a look at this, as it
is possible 
> > that I'm still
> > lock at the point I add the transaction when I
already 
> > receive and process
> > the reply... But, the Wait() should allow the
adding thread 
> > to run, and thus
> > Signal() ... 
> > Damn, really weird :(
> > 
> > Thanks again,
> > Paul
> > 
> >
------------------------------------------------------------
--
> > ----------
> > Check the FAQ before asking! - 
> > http://www.
openh323.org/~openh323/fom.cgi
> > The OpenH323 Project mailing list, using Mailman.
To unsubscribe or
> > change your subscription options, goto
> > htt
p://www.openh323.org/mailman/listinfo/openh323
> > Maintained by Quicknet Technologies, Inc - http://www.quicknet.net
> >
------------------------------------------------------------
--
> > ----------
> > 
> 
>
------------------------------------------------------------
--
> ----------
> Check the FAQ before asking! - 
> http://www.
openh323.org/~openh323/fom.cgi
> The OpenH323 Project mailing list, using Mailman. To
unsubscribe or
> change your subscription options, goto
> htt
p://www.openh323.org/mailman/listinfo/openh323
> Maintained by Quicknet Technologies, Inc - http://www.quicknet.net
>
------------------------------------------------------------
--
> ----------
> 

------------------------------------------------------------
------------
Check the FAQ before asking! - http://www.
openh323.org/~openh323/fom.cgi
The OpenH323 Project mailing list, using Mailman. To
unsubscribe or
change your subscription options, goto
htt
p://www.openh323.org/mailman/listinfo/openh323
Maintained by Quicknet Technologies, Inc - http://www.quicknet.net
------------------------------------------------------------
------------
[1]

about | contact  Other archives ( Real Estate discussion Medical topics )