RE: [Bayonne-devel] Re : Slog stops producing traces in syslog/message- got event 89 - TDX_ERROR

[Julien Chavanton]

Right, this does a dx_stopch() but properly since it use Bayonne event to do 
it, thank you. 

I am still testing conference and I can tell the problem I have reported exist, 
my server as an average of 100 simultanious calls.
However I do not know why sometime it is fine and sometimes not.

Can you send me an example of script using conference, I am interested to see 
how we deal with a remote party hangup, because this is where problem is taking 
place (sometimes).

Maybe we can code something in the drivers that will automatically remove 
conferee from the conference if the server receive hangup and the script is in 
conference.

Good week-end,
Julien




-----Original Message-----
From: Etoile Dièse [mailto:address@hidden 
Sent: April 8, 2005 1:27 PM
To: Julien Chavanton; address@hidden
Subject: Re: [Bayonne-devel] Re : Slog stops producing traces in 
syslog/message- got event 89 - TDX_ERROR

Le Fri, 8 Apr 2005 13:11:35 -0400, Julien Chavanton  
<address@hidden> a écrit:

> We may want to do a dx_stopch(), there is no problem doing it even if it  
> is not required.
>
> Julien
>
> -----Original Message-----
> From: address@hidden  
> [mailto:address@hidden  
> On Behalf Of Etoile Dièse
> Sent: March 13, 2005 12:20 PM
> To: address@hidden
> Subject: [Bayonne-devel] Re : Slog stops producing traces in  
> syslog/message- got event 89 - TDX_ERROR
>
> Hi again,
>
> Last news : adding a break when receiving TDX_ERROR
> seems to solve the problem.
> The code we are using is now ignoring TDX_ERROR :
> Here is the diff that can be applied to
> bayonne1.2.14/driver/globalcall/driver.cpp :
>
> diff driver.new.cpp driver.cpp
>
> 767,768d766
> <               case TDX_ERROR:
> <                       break;
> 783a782
>>               case TDX_ERROR:
>
> Cheers,
>


Be careful !!!!
Following the mail you've just mentionned, I posted something else because  
that was not the good solution :

Here is what I posted a few days after :


_____________________________________________________________________________________
Hi,

Following my last mail, it seems that ignoring TDX_ERROR is not
a good idea : When this event occurs after having started to play a file,
the channel get stucked.

It seems better to handle it that way :

case TDX_ERROR:
      event.id = TRUNK_AUDIO_IDLE;
      trunk->putEvent(&event);
      break;


___________________________________________________________________________________________

We are using this piece of code on our production servers.
But I think you're right, we could do a dx_stopch().
We don't, because it seems to work without it (I mean, the next  
play/record/getdigit
is working).




FdR/ED


-- 
Etoile Dièse - www.etoilediese.com