Re: [Bayonne-devel] Bayonne Globalcall TASKFAIL and TRUNK_CALL_FAILURE

[David Sugar]

Hmm...one thing I think we should do is add a "cleared" flag to the
Dialogic trunk structure. This would be used to indicate that the
current call had been "cleared" (channel reset after a failure, for
example), but that the driver (bayonne state) is not yet "idle". This
could happen if we reset a channel and issue a hangup signal event to
the script engine to handle call exiting scripts, for example.

Hence, in the example you give, instead of issuing TRUNK_CALL_FAILURE in
response to the TASKFAIL, I think we should instead raise the cleared
flag, and post a TRUNK_STOP_DISCONNECT. The hangup state handler, when
it is later called, would check the cleared flag, and skip hangup if the
channel is already "cleared". The idle state would reset the cleared
flag on entry. If a new call is presented in postEvent while the current
call is still clearing, then it should send back a call reject. This I
think is also related to the simultaneous CRN issue.

What do you think of this idea?

Julien Chavanton wrote:

> I have made a few modification to globalcall drivers to handle
> TASKFAIL more efficiently
>
> I always reset the port when there is a TASKFAIL because anyway when
> there is a TASKFAIL the call is lost and most of the time the TASKFAIL
> is caused by short call
>
> Or abandon calls.
>
> This is producing positive results.
>
> The only difficulty was to keep bayonne state sync with Globalcall
> state because RESETLINEDEV is not the normal state transition.
>
> -------------------------------------------------------------
>
> I keep an eye on Bayonne 2 evolution; it would be interesting for me
> to help with the Globalcall Drivers in Bayonne 2.
>
> Something positive about Globalcall is that Intel is moving to HMP
> host media processing “Voip library optimized for Xeon CPU”.
>
> And this may be the best performance Voip solution available due to
> the integration in the Xeon CPU internal instructions.
>
> If they succeed Globalcall should be almost compatible with HMP, and
> bayonne could be HMP enabled without to much work.
>
> However HMP is commercial I think it is 10$ a port and it may be too
> much for a software solution.
>
> Julien
>
> ------------------------------------------------------------------------
>
> *From:*
> address@hidden
> [mailto:address@hidden
> *On Behalf Of *Julien Chavanton
> *Sent:* December 19, 2005 10:09 AM
> *To:* address@hidden
> *Cc:* address@hidden
> *Subject:* [Bayonne-devel] Bayonne Globalcall TASKFAIL and
> TRUNK_CALL_FAILURE
>
> Hi David,
>
> I am looking to modify TRUNK_CALL_FAILURE in bayonne globalcall since
> this is currently handled as a disconnection.
>
> It was not that bad but most of the time this is not enough.
>
> And we loose port, only when there is a TASKFAIL that is really caused
> by the Dialogic drivers.
>
> The main source of TASKFAIL is abandon calls and short calls the
> Dialogic drivers are not capable of handling this automatically and
> this result in TASKFAIL
>
> The only problem I think is that the script may be left attached and
> the next call will fail to attach.
>
> Here is what I have in mind:
>
> globalcall/driver.cpp
>
> case GCEV_TASKFAIL
>
> event.id = TRUNK_CALL_FAILURE;
>
> trunk->postEvent(&event);
>
> gc_ResetLineDev(linedev, EV_ASYNC);
>
> break;
>
> globalcall/trunk.cpp
>
> case TRUNK_CALL_FAILURE:
>
> // We need to prepare Bayonne for recovery of next call
>
> Trunk::detach();
>
> if(join)
>
> Part();
>
> if(tgi.pid)
>
> ::kill(tgi.pid, SIGHUP);
>
> if(thread)
>
> thread->stop();
>
> Trunk::flags.dsp = DSP_MODE_INACTIVE;
>
> More information about TASKFAIL if any interest:
>
> How to Handle GCEV_TASKFAIL Events (However I have made some test and
> I am not sure about this article complete accuracy)
>
> http://resource.intel.com/telecom/support/tnotes/tnbyos/2000/tn061.htm
>
> You can find information about abandon calls here:
>
> http://resource.intel.com/telecom/support/releases/winnt/SR511FP1/onldoc/htmlfiles/gcprgdw/gc-sta15.htm
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Bayonne-devel mailing list
>address@hidden
>http://lists.gnu.org/mailman/listinfo/bayonne-devel
>  
>

dyfet.vcf
Description: Vcard