Re: [SPAM] - RE: [Bayonne-devel] Bayonne Globalcall TASKFAIL and TRUNK_CALL_FAILURE - Bayesian Filter detected spam

[David Sugar]

If we are still missing changes, I would like to see if we can get all
changes merged together, and then cleaned up a bit.

Julien Chavanton wrote:

>This is interresting,
> 
>You are using globalcall with SS7, can you let us know what drivers version 
>and board you are using.
>I do not know bout REL or RLC 
> 
>I know the fix I use are working with Globalcall/Isdn.
>1.000.000 calls and 99% asr with all the Ports/DS0 still running.
>Performance is good even if I am still running redhat 7.3 (I should make 
>dialogic work on redhat9 at least since the threading as been improved).
> 
>If this is a real problem for you I could verify the CVS version I am still 
>using a modified bayonne-1.2.13-OWI.tar.gz
>(Because there was to much quick customization requirement for us, I did not 
>follow the Bayonne structure enough whe implementing change.)
> 
>However I could verify the CVS version to see if the 2 problems I have 
>indentified are fixed.
>1 - Short calls and abandon calls handling.
>2 - Multiple CRN's support 
> 
>I would recommend activating globalcall event logging it is always good to 
>know "Bayonne state" and "Globalcall state" when a problem take place.
>Globalcall can behave abnormaly when there is shortcall and abandon calls but 
>with proper handling no problem.
>What I did was to use syslog-ng over the network to keep full logging while 
>running lots of traffic.
> 
> 
>Julien
> 
> 
>
>       -----Original Message----- 
>       From: address@hidden on behalf of Mladenovič Zoran 
>       Sent: Wed 1/11/2006 04:22 PM 
>       To: David Sugar 
>       Cc: address@hidden 
>       Subject: [SPAM] - RE: [Bayonne-devel] Bayonne Globalcall TASKFAIL and 
> TRUNK_CALL_FAILURE - Bayesian Filter detected spam
>       
>       
>
>       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.
>       
>       
>       _______________________________________________
>       Bayonne-devel mailing list
>       address@hidden
>       http://lists.gnu.org/mailman/listinfo/bayonne-devel
>       
>
>  
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Bayonne-devel mailing list
>address@hidden
>http://lists.gnu.org/mailman/listinfo/bayonne-devel
>  
>