[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [SPAM] - RE: [Bayonne-devel] Bayonne Globalcall TASKFAIL and TRUNK_C
|
From: |
David Sugar |
|
Subject: |
Re: [SPAM] - RE: [Bayonne-devel] Bayonne Globalcall TASKFAIL and TRUNK_CALL_FAILURE - Bayesian Filter detected spam |
|
Date: |
Thu, 19 Jan 2006 13:35:24 -0500 |
|
User-agent: |
Mozilla Thunderbird 1.0.7 (X11/20051011) |
The original point was it may also be in a scripting state, so that it
can handle ^hangup or exit handlers. But this seems to cover the
correct cases. This is essentially what I was suggesting, introducing a
flag like this gc_ResetLineDev to track when the port has been "cleared"
in mid-processing outside of any normal call termination.
Julien Chavanton wrote:
>
>
>When there is a TASKFAIL I always reset the port since it is 99% short
>calls/abandon calls.
>
>
>
>case GCEV_TASKFAIL:
>
> trunk->getName(buffer);
>
> slog(Slog::levelError) << buffer << ": GCEV_TASKFAIL HDL:" <<
> metaevent.linedev << endl;
>
> trunk->UpdateStatus(trunk->id, metaevent.crn, "TASKFAIL");
>
> trunk->gcResetLineDev = 1;
>
> gc_ResetLineDev(linedev, EV_ASYNC);
>
> break;
>
>
>
>
>
>I have a flag (defined in driver.h trunk class) used to keep track of the fact
>that the port is resting.
>
>trunk->gcResetLineDev
>
>
>
>
>
>I reset the flag to 0 only when I receive another call because even if
>GCEV_RESETLINEDEV was received
>
>Bayonne may still be in another state "hangup" or "idle"
>
>
>
>case GCEV_OFFERED:
>
> trunk->gcResetLineDev = 0;
>
>
>
>
>
>Now I check this flag at several places in globalcall/trunk.cpp
>
>
>
>// Initialize in Trunk constructor
>
>DialogicTrunk::DialogicTrunk(int id, devices_t *devif) :
>
>TimerPort(), Trunk(id, 0, devif->span), Thread(0), URLAudio(), AudioService()
>
>{
>
> gcResetLineDev = 0;
>
>. . .
>
>
>
>
>
>// If acceptcall is failing I immediately set the flag because Bayonne may go
>to hangup to fast.
>
>// This is where most of the short call problem take place.
>
>if(gc_AcceptCall(crn, 0, EV_ASYNC) < 0)
>
> {
>
> slog (Slog::levelError) <<"dx("<<id<<"):"<<"gc_AcceptCall("<<crn<<")
> == FAILURE call state:"<<call_state<< endl;
>
> gc_ResetLineDev(linedev, EV_ASYNC);
>
> gcResetLineDev=1;
>
> slog(Slog::levelError) <<"dx("<<id<<"):"<<"gc_ResetLineDev()"<<endl;
>
> postGCError("gc_AcceptCall");
>
> return false;
>
> }
>
>. . .
>
>
>
>// Samething with answer
>
>// This is also where most of the short call problem take place.
>
>if(gc_AnswerCall(crn, 0, EV_ASYNC) < 0)
>
> {
>
> slog(Slog::levelError) << "dx(" << id << "): "
> <<"gc_AnserCall("<<crn<<") == FAILURE"<<endl;
>
> postGCError("gc_AnswerCall");
>
> gcResetLineDev=1;
>
> gc_ResetLineDev(linedev, EV_ASYNC);
>
> slog(Slog::levelDebug) << "dx(" << id << "): "
> <<"gc_ResetLineDev()"<<endl;
>
> return false;
>
> }
>
>. . .
>
>
>
>// Now if there was a taskail Bayonne would not know and will try an hangup
>anyway this is why I check the flag here as well
>
>bool DialogicTrunk::hangupCall(void)
>
>{
>
> int cause;
>
>
>
> if(!Trunk::flags.offhook && !_accepted && !gcResetLineDev)
>
> return false;
>
>. . .
>
>
>
>// Samething for releaseCall Bayonne in "idle" state
>
>void DialogicTrunk::releaseCall(void)
>
>{
>
> _disconnecting = false;
>
> int call_state;
>
>
>
> if(gcResetLineDev){
>
> slog(Slog::levelError) << "dx(" << id << "): " <<"Device reseting
> ignoring gc_ReleaseCallEx"<<endl;
>
> TrunkEvent event;
>
> event.id = TRUNK_CALL_RELEASE;
>
> postEvent(&event);
>
> return;
>
> }
>
>. . .
>
>
>
>// And if someone is doing a port reset
>
>void DialogicTrunk::resetChannel(void)
>
>{
>
> gcResetLineDev = 1;
>
> gc_ResetLineDev(linedev, EV_ASYNC);
>
>
>
> slog(Slog::levelError) << "dx(" << id << "): "
> <<"gc_ResetLineDev()"<<endl;
>
>}
>
>. . .
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>address@hidden globalcall]# grep gcResetLineDev *
>
>driver.cpp: trunk->gcResetLineDev = 1;
>
>driver.cpp: trunk->gcResetLineDev = 0;
>
>driver.h: bool gcResetLineDev;
>
>Binary file globalcall.ivr matches
>
>trunk.cpp: gcResetLineDev = 0;
>
>trunk.cpp: gcResetLineDev=1;
>
>trunk.cpp: gcResetLineDev=1;
>
>trunk.cpp: if(!Trunk::flags.offhook && !_accepted && !gcResetLineDev)
>
>trunk.cpp: if(gcResetLineDev){
>
>trunk.cpp: if(gcResetLineDev){
>
>trunk.cpp: gcResetLineDev = 1;
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>-----Original Message-----
>From: Mladenovic Zoran [mailto:address@hidden
>Sent: January 17, 2006 5:20 AM
>To: Julien Chavanton; David Sugar
>Cc: address@hidden
>Subject: RE: [SPAM] - RE: [Bayonne-devel] Bayonne Globalcall TASKFAIL and
>TRUNK_CALL_FAILURE - Bayesian Filter detected spam
>
>
>
>We are using dm3 DMW1200 E1 cards with external SIU520 for signaling. In order
>to make everything work, driver.cpp need's to be changed to open ss7 device
>(":L_SS7:N_dtiB%dT%d:P_%s:V_%s"). trunk.cpp was also changed, for parsing
>additional messages in IAMa and applying eACM to achieve charge free calls. If
>interested, I can post that changes.
>
>
>
>REL is release and RLC is release complete ISUP message. I'm interested how
>you solve short call properly. Can you send me changes you've made?
>
>
>
>Zoran
>
>
>
>-----Original Message-----
>
>From: Julien Chavanton [mailto:address@hidden
>
>Sent: Saturday, January 14, 2006 2:16 AM
>
>To: Mladenovič Zoran; David Sugar
>
>Cc: address@hidden
>
>Subject: RE: [SPAM] - RE: [Bayonne-devel] Bayonne Globalcall TASKFAIL and
>TRUNK_CALL_FAILURE - Bayesian Filter detected spam
>
>
>
>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
>
>
>
>
>
>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
>
>