[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: |
Sun, 15 Jan 2006 10:00:20 -0500 |
User-agent: |
Mozilla Thunderbird 1.0.7 (X11/20051011) |
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
>
>