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

[Mladenovič Zoran]

Cool...I have some "filthy" services running on top of 20050116 release 
(odbc...) and with couple of 100k calls per day this is not so rare event. 
Beside that it is rock stable.

Zoran

-----Original Message-----
From: address@hidden [mailto:address@hidden On Behalf Of David Sugar
Sent: Wednesday, January 11, 2006 7:24 PM
To: Mladenovič Zoran
Cc: address@hidden
Subject: Re: [Bayonne-devel] Bayonne Globalcall TASKFAIL and TRUNK_CALL_FAILURE

I suspect this issue is related to what I am thinking of with handling of call 
state in gc, especially for short calls, vs how the Bayonne state machine ends 
up processing them and what Bayonne believes the call state is.  I may jump all 
the way back to 1.2.11, and roll forward some changes selectivily as well as 
some of my own ideas about having a call cleared flag for this.

Mladenovič Zoran wrote:

>Would this help to solve my problem?
>
>I have mid-range installation with 2 IVR's, 16 E-1, ss7. When there is short 
>call, or sometimes, when call is abandoned, links are blocked because of that.
>Extract from ss7 trace:
>
>08:33 23.657    <-- [12] IAM in cs_READY, i=0, 
>p:010601000702600109010a020100040803901551910000f20a060313131861790801000b0603101416572413020361280603
>        10141657241d038090a33102005a390431d03fc03f08849383460140110100
>08:33 23.657  <==   [12] MT_OFFERED_IND    in cs_OFFERED, size=172
>08:33 23.657    <-- [12] REL in cs_OFFERED, i=0, p:0c1202839f00
>08:33 23.657  <==   [12] MT_DISCONNECT_IND in cs_DISCONNECTED, size=25
>08:33 23.657    --> [12] REL in cs_DISCONNECTED, p:0c00
>08:33 35.135    <-- [12] REL in cs_DISCONNECTED, i=0, p:0c1202859f00
>08:33 35.136  WARNING: [12] Circuit::ProcessMsg() REL in 
>cs_DISCONNECTED, still waiting for application DropCall
>
>As seen above Bayonne is still sending REL message instead of RLC. SS7 guard 
>timer expires and port is blocked. 
>
>Zoran Mladenovic
>
>-----Original Message-----
>From: address@hidden 
>[mailto:address@hidden 
><mailto:address@hidden> ] On 
>Behalf Of David Sugar
>Sent: Friday, December 30, 2005 7:04 PM
>To: Julien Chavanton
>Cc: address@hidden
>Subject: Re: [Bayonne-devel] Bayonne Globalcall TASKFAIL and 
>TRUNK_CALL_FAILURE
>
>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 <mailto:address@hidden> .
>>org]
>>*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 
>><http://resource.intel.com/telecom/support/tnotes/tnbyos/2000/tn061.ht
>>m>
>>
>>You can find information about abandon calls here:
>>
>>http://resource.intel.com/telecom/support/releases/winnt/SR511FP1/onld 
>><http://resource.intel.com/telecom/support/releases/winnt/SR511FP1/onl
>>d>
>>oc/htmlfiles/gcprgdw/gc-sta15.htm
>>
>>----------------------------------------------------------------------
>>-
>>-
>>
>>_______________________________________________
>>Bayonne-devel mailing list
>>address@hidden
>>http://lists.gnu.org/mailman/listinfo/bayonne-devel 
>><http://lists.gnu.org/mailman/listinfo/bayonne-devel>
>>
>>
>>    
>>
> 
> 
>SAMO NASLOVNIKU! / ONLY FOR THE INTENDED RECIPIENT!
> 
>To elektronsko sporočilo in pripete datoteke lahko vsebujejo informacije 
>zaupne narave in/ali informacije, ki so varovane s pravom in so namenjene samo 
>posamezniku ali družbi, na katero so naslovljene. Kakršnakoli neavtorizirana 
>uporaba  informacij, prejetih v tem elektronskem sporočilu in pripetih 
>datotekah, je prepovedana. 
>Če elektronsko sporočilo in pripete datoteke niso bile namenjene prejemniku 
>sporočila, ali če je bilo zaradi napake v naslovniku ali pri prenosu sporočilo 
>poslano drugam, prosimo, da o tem obvestite pošiljatelja, prejeto elektronsko 
>sporočilo in pripete datoteke pa brez kakršnekoli predhodne uporabe zbrišite. 
>Mobitel, d. d., in z njim povezane ali od njega odvisne družbe niso odgovorne 
>za elektronsko sporočilo in pripete datoteke, če je to spremenjeno, ponarejeno 
>ali preoblikovano s strani tretje osebe. Elektronsko sporočilo in pripete 
>datoteke so bile pregledane z antivirusno programsko opremo.
>
>
>This e-mail and its attachments may contain confidential and/or privileged 
>information and are intended solely for the use of the individual or entity to 
>whom they are addressed. Any unauthorized use of information received in this 
>email and its attachments is forbidden. If you are not the intended recipient, 
>or an addressing or transmission error has misdirected this e-mail, please 
>notify the sender by replying to this e-mail and delete it without any prior 
>use. Neither Mobitel, d.d. nor any of its subsidiaries or affiliates shall be 
>liable for the e-mail and its attachments if altered, changed or falsified by 
>third parties. This e-mail and its attachments have been scanned by Anti-Virus 
>Software.
>_______________________________________________
>Bayonne-devel mailing list
>address@hidden
>http://lists.gnu.org/mailman/listinfo/bayonne-devel
>  
>
 
 
SAMO NASLOVNIKU! / ONLY FOR THE INTENDED RECIPIENT!
 
To elektronsko sporočilo in pripete datoteke lahko vsebujejo informacije zaupne 
narave in/ali informacije, ki so varovane s pravom in so namenjene samo 
posamezniku ali družbi, na katero so naslovljene. Kakršnakoli neavtorizirana 
uporaba  informacij, prejetih v tem elektronskem sporočilu in pripetih 
datotekah, je prepovedana. 
Če elektronsko sporočilo in pripete datoteke niso bile namenjene prejemniku 
sporočila, ali če je bilo zaradi napake v naslovniku ali pri prenosu sporočilo 
poslano drugam, prosimo, da o tem obvestite pošiljatelja, prejeto elektronsko 
sporočilo in pripete datoteke pa brez kakršnekoli predhodne uporabe zbrišite. 
Mobitel, d. d., in z njim povezane ali od njega odvisne družbe niso odgovorne 
za elektronsko sporočilo in pripete datoteke, če je to spremenjeno, ponarejeno 
ali preoblikovano s strani tretje osebe. Elektronsko sporočilo in pripete 
datoteke so bile pregledane z antivirusno programsko opremo.


This e-mail and its attachments may contain confidential and/or privileged 
information and are intended solely for the use of the individual or entity to 
whom they are addressed. Any unauthorized use of information received in this 
email and its attachments is forbidden. If you are not the intended recipient, 
or an addressing or transmission error has misdirected this e-mail, please 
notify the sender by replying to this e-mail and delete it without any prior 
use. Neither Mobitel, d.d. nor any of its subsidiaries or affiliates shall be 
liable for the e-mail and its attachments if altered, changed or falsified by 
third parties. This e-mail and its attachments have been scanned by Anti-Virus 
Software.