|
| From: | Julien Chavanton |
| Subject: | RE: [Bayonne-devel] RE: Globalcall stress test |
| Date: | Fri, 19 Aug 2005 09:40:03 -0400 |
|
Hi made some modification and the server
receiving call is working just fine after 150 000 really fast calls. Often I receive an Offered while still in
release state and the small modification are working. However my test script on the answering
server was only doing sleep. Now there is another problem with the
voice dx_ and dt_ function call I think we must modify dt_listen() by gc_listen()
since it is not good to make lower level R2 call while using Globalcall. I will modify this and make some play, and
after conference to test the sc_bus and dx_ function again since currently
there is a problem during theses tests. Julien
From: Julien Chavanton
Note that this modification is really
important since this situation currently result in port being blocked since
“idle” does not support disconnected. From: Julien Chavanton
The only an offered and notify the next
“idle”. Later we shall go further and have a real
support for multiple calls per line but for now this is not required since as
far as I know the Telco does not offer call on hold. Julien From:
address@hidden
[mailto:address@hidden On Behalf Of Julien Chavanton The problem is a bit more complex then expected: There can be more then one simultaneous call on a line
device (For example ISDN call on hold). And when between drop and release we can receive an
offered. So Bayonne Globalcall shall be modified to support
more then one CRN on each line. I have to evaluate the complexity of such
modification. Here is an example of 2 simultaneous CRN on one line
device. dx(12): GCEV_DISCONNECTED
HDL:31 CRN:33616924 dx(12): step 2 exit() dx(12): exit dx(12): script exiting dx(12): HANGUP TRUNK_ENTER_ STATE reset_timer:1090604252
hangup_timer:100 dx(12): hangup dx(12): gc_DropCall(33616924) == SUCCESS dx(12): detach script dx(12): GCEV_DROPCALL
HDL:31 CRN:33616924 dx(12): HANGUP TRUNK_CALL_DISCONNECT:31 CRN:33616924 dx(12): release dx(12): gc_ReleaseCallEx(33616924) == SUCCESS dx(12): GCEV_OFFERED
HDL:31 CRN:33617948 dx(12): GCEV_RELEASECALL
HDL:31 CRN:33616924 dx(12): ENTERING IDLE STATE:31 CRN:-1 dx(12): idle dx(12): GCEV_DISCONNECTED
HDL:31 CRN:33617948 -----Original Message----- Cool, May we have this modif ? Le mercredi 17 Août 2005 21:17, Julien Chavanton a
écrit : > I have made modification to Bayonne Globalcall to
remove CRN > modification from outside driver.cpp (the
Dialogic event handler) > > This way the CRN is always correct. > > > > I am stressing the port as much as I can. > > > > I have good result. > > > > > > > > > > _____ > > From: Julien Chavanton > Sent: August 17, 2005 10:25 AM > To: ' > Subject: > > > > While debugging and stressing Bayonne1 / Globalcall
I have found another > problem that take place under heavy stress > > Here we can see a call clearing and a new call
coming with almost no > delay between them > > > > > > > > The problem is that > of the new call is cleared ! > > > > I think only driver.cpp should be able to clear
CRN since it is the > driver event handler. > > > > I am testing the modification. > > > > Aug 27 08:37:18 localhost > > Aug 27 08:37:18 localhost > > Aug 27 08:37:18 localhost > > Aug 27 08:37:18 localhost > > Aug 27 08:37:18 localhost > > Aug 27 08:37:18 localhost > > Aug 27 08:37:18 localhost > > Aug 27 08:37:18 localhost > > Aug 27 08:37:19 localhost > > Aug 27 08:37:19 localhost > CRN:33604644 > > Aug 27 08:37:19 localhost > > Aug 27 08:37:19 localhost > CRN:-1 > > Aug 27 08:37:19 localhost > > Aug 27 08:37:28 localhost > > Aug 27 08:37:29 localhost > > Aug 27 08:37:29 localhost > reference number has been used > > Aug 27 08:37:29 localhost -- Etoile Dièse _______________________________________________ Bayonne-devel mailing list address@hidden http://lists.gnu.org/mailman/listinfo/bayonne-devel |
| [Prev in Thread] | Current Thread | [Next in Thread] |