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: [EMAIL PROTECTED] on behalf of Mladenovič Zoran > Sent: Wed 1/11/2006 04:22 PM > To: David Sugar > Cc: [email protected] > 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David > Sugar > Sent: Wednesday, January 11, 2006 7:24 PM > To: Mladenovič Zoran > Cc: [email protected] > 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: [EMAIL PROTECTED] > >[mailto:[EMAIL PROTECTED] > ><mailto:[EMAIL PROTECTED]> ] On > >Behalf Of David Sugar > >Sent: Friday, December 30, 2005 7:04 PM > >To: Julien Chavanton > >Cc: [email protected] > >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:* > >>[EMAIL PROTECTED] > >>[mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> . > >>org] > >>*On Behalf Of *Julien Chavanton > >>*Sent:* December 19, 2005 10:09 AM > >>*To:* [email protected] > >>*Cc:* [EMAIL PROTECTED] > >>*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 > >>[email protected] > >>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 > >[email protected] > >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 > [email protected] > http://lists.gnu.org/mailman/listinfo/bayonne-devel > > > > >------------------------------------------------------------------------ > >_______________________________________________ >Bayonne-devel mailing list >[email protected] >http://lists.gnu.org/mailman/listinfo/bayonne-devel > >
_______________________________________________ Bayonne-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bayonne-devel
