|
| From: | Gilmore, Gerry |
| Subject: | RE: [Bayonne-devel] Global Call outbound call problem resolution |
| Date: | Thu, 9 Dec 2004 07:32:53 -0800 |
|
Julien, Could you confirm that you are getting the
OPENEX event *after* the
UNBLOCKED? In all of my testing, I don’t think that I’ve ever seen
that. You may also want to test using gcdiag, as
that’s what I’ve mainly used for my testing. 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: Julien Chavanton
[mailto:address@hidden 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] |