|
From: | Julien Chavanton |
Subject: | RE: [Bayonne-devel] Global Call outbound call problem resolution |
Date: | Thu, 9 Dec 2004 10:26:49 -0500 |
Thank you, But when shall we issue the first
gc_waitcall() after gc_openex() then ? I see the GCEV_OPENEX event always comes
in after GCEV_UNBLOCKED, this is why I was thinking it was the proper place to
issue the gc_waitcall() Julien From: Gilmore, Gerry
[mailto:address@hidden Julien, I would encourage you (and/or Mark) to
remove the gc_WaitCall() from the GCEV_OPENEX event. The GCEV_OPENEX event
should really just be there to let you know that the open was successful. The
only thing that should kick off the gc_WaitCall() is, again, the
GCEV_RESETLINEDEV event. Gerry There are 10 kinds of people in the world,
those who understand binary and those who don't. Gerry Gilmore Field Applications Engineer Intel Corporation From:
address@hidden
[mailto:address@hidden On Behalf Of Julien Chavanton I have nice test result! 150 000 calls in 12 hours, my test server
call himself using the FIFO and a dual T1 board. So I have 150 000 outbound calls and 150
000 inbound calls and still all port are fine. Globalcall implementation drivers seem
good. However there is still something annoying
with Globalcall, I see lots of GCEV_RESETLINEDEV after GCEV_DROCALL This is caused by hangup
TRUNK_TIMER_EXPIRED I will look at this more closely. But this do not create serious problem
although it may stress the Dialogic drivers. I would like to thanks Mark for the great
work is as made, it is really hard to find something wrong in this program ;-) Julien The change I have made to trunk.cpp 1- bool DialogicTrunk::waitCall(void) { //
if(gc_WaitCall(linedev, NULL, NULL, -1, EV_ASYNC) == 0)
slog(Slog::levelDebug) << "No waitCall" << endl;
return true; // else //
return false; } The change I have made to drivers.cpp 1- I did change gc_OpenEx() to async mode
since there is no need to use it in sync and it is better to use only async
when possible. 2- I added GCEV_OPENEX and
GCEV_OPENEX_FAIL to the event handler 3- I added a gc_WaitCall() to
GCEV_RESETLINEDEV. case
GCEV_OPENEX:
trunk->getName(buffer);
slog(Slog::levelDebug) << buffer << ": GCEV_OPENEX HDL:"
<< metaevent.linedev << endl;
gc_WaitCall(linedev, NULL, NULL, 0, EV_ASYNC);
break; case
GCEV_OPENEX_FAIL:
trunk->getName(buffer);
slog(Slog::levelDebug) << buffer << ": GCEV_OPENEX_FAIL
HDL:" << metaevent.linedev << endl;
break;
case GCEV_RESETLINEDEV:
trunk->getName(buffer);
slog(Slog::levelDebug) << buffer << ": GCEV_RESETLINEDEV
HDL:" << metaevent.linedev << endl;
gc_WaitCall(linedev, NULL, NULL, 0, EV_ASYNC);
trunk->crn = -1;
event.id = TRUNK_CALL_RESTART;
event.parm.ok = true;
trunk->postEvent(&event);
break; From: Julien Chavanton
Sorry this was wrong: Bayonne/Globalcall Drivers use
gc_openex() When using gc_openex() we do not need to issue gc_waitcall() But still I did found the problem it does take place when we
call gc_waitcall() several time without necessity This could have made no problem but it looks like it is
wasting a CRN every time. I have to find the proper modification because we still need
to invoque gc_waitcall() after a gc_resetlinedev() I will make intensive testing and post the result. Julien From:
address@hidden [mailto:address@hidden
On Behalf Of Julien Chavanton Following the recommendation of Mark Lipscombe I now revert
to Dialogic Drivers. And finally good news, I have found the problem with
outbound call with Globalcall 1 – Bayonne/Globalcall Drivers use gc_openex() When
using gc_openex() we do not need to issue gc_waitcall() 2 – Bayonne/Globalcall was also make gc_waitcall()
every calls this is not the normal behavior. I have commented gc_waitcall() from trunk.cpp Before I will now revert to globalcall since this was the only
known bug and dialogic drivers are not realy fine. Julien |
[Prev in Thread] | Current Thread | [Next in Thread] |