-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello community, to keep you informed about this. I got an early copy of the new openzap ISDN stack. I did some changes to get it running with my uplink provider. Most were dedicated to my uplink provider (AVAYA PBX, e.g. needed IEs in CALL_PROC, missed CON ACK, debug messages, ...) and a few were more general (like auto recover after a long term E1 link disconnect, not handled PROGRESS messages in cetrain call states, addind Timerhandlinf or call tear down) Since last friday I use it my prod environment (E1, Q931-TE, enBlock-Dialing). I have currently no problems. Timers work as expected and seems to keep the stack clean, although not all timers are implemented, yet ... So far Stefan and Tony did a very good job so far. Here is a snippet from my log showing the handling of my old originate problem of a missed RELEASE message from uplink after sending a DISCONNECT by the NEW stack: 2009-07-20 11:05:40.208698 [DEBUG] ozmod_isdn.c:1999 WRITE 9 - -------------------------------------------------------------------------------- [08 02 80 1e 45 08 02 81 90] 2009-07-20 11:05:40.208698 [NOTICE] Span:1 Starting timer 6 (timeout: 30000 ms) for call 30 [0x1e] 2009-07-20 11:05:40.208698 [DEBUG] Span:1 Call going from state 8 -> 11 2009-07-20 11:05:40.208698 [DEBUG] Span:1 Q931Rx43 return code: 0 [Waiting for RELEASE] 2009-07-20 11:06:10.279950 [NOTICE] Span:1 Stopping timer 6 for call 30 [0x1e] 2009-07-20 11:06:10.279950 [NOTICE] Span:1 Timer T305 timed out for call 30 2009-07-20 11:06:10.279950 [DEBUG] Span:1 Receiving message from Layer4 (size: 109, type: 77 [0x4d], CRV: 30, CRVFlag: 0) 2009-07-20 11:06:10.279950 [NOTICE] Span:1 Handling message from Layer4 in call state: 11 2009-07-20 11:06:10.279950 [DEBUG] Span:1 Processing RELEASE message from Local for CRV: 30 (0x1e) 2009-07-20 11:06:10.279950 [DEBUG] Span:1 Sending message to Q.921 (size: 109) 2009-07-20 11:06:10.279950 [DEBUG] Span:1 Creating Q.931 Message Header: ProtDisc 8 (0x8), CRV 30 (0x1e), CRVflag: 1 (0x1), MesType: 77 (0x4d) 2009-07-20 11:06:10.279950 [DEBUG] Span:1 XXX Adding IE 0x8 2009-07-20 11:06:10.279950 [DEBUG] Span:1 XXX Adding IE 0x28 2009-07-20 11:06:10.279950 [DEBUG] Span:1 XXX Adding IE 0x34 2009-07-20 11:06:10.279950 [DEBUG] Span:1 XXX Adding IE 0x1c 2009-07-20 11:06:10.279950 [NOTICE] Span:1 Unable to get reference for IE 28 (0x1c) 2009-07-20 11:06:10.279950 [DEBUG] Span:1 XXX Adding IE 0xd 2009-07-20 11:06:10.279950 [NOTICE] Span:1 Unable to get reference for IE 13 (0xd) 2009-07-20 11:06:10.279950 [DEBUG] ozmod_isdn.c:1999 WRITE 9 - -------------------------------------------------------------------------------- [08 02 80 1e 4d 08 02 81 e6] 2009-07-20 11:06:10.279950 [NOTICE] Span:1 Starting timer 9 (timeout: 4000 ms) for call 30 [0x1e] 2009-07-20 11:06:10.279950 [DEBUG] Span:1 Call going from state 11 -> 19 2009-07-20 11:06:10.279950 [DEBUG] Span:1 Q931Rx43 return code: 0 2009-07-20 11:06:10.419951 [DEBUG] ozmod_isdn.c:1181 READ 9 - -------------------------------------------------------------------------------- [08 02 00 1e 5a 08 02 81 d1] 2009-07-20 11:06:10.419951 [DEBUG] Span:1 Call is in state 19 [Release request] 2009-07-20 11:06:10.419951 [DEBUG] Span:1 Received message from Q.921 (ind 4, tei 0, size 13) MesType: 90, CRVFlag 0 (Originator), CRV 30 (Dialect: Q.931 TE) 2009-07-20 11:06:10.419951 [DEBUG] Span:1 Processing RELEASE COMPLETE message from Remote for CRV: 30 (0x1e) 2009-07-20 11:06:10.419951 [NOTICE] Span:1 Stopping timer 9 for call 30 [0x1e] 2009-07-20 11:06:10.419951 [DEBUG] Span:1 Sending message to Layer4 (size: 110) 2009-07-20 11:06:10.419951 [DEBUG] ozmod_isdn.c:696 Yay I got an event! Type:[5a] Size:[110] CRV: 30 (0x1e, CTX: Originator) 2009-07-20 11:06:10.419951 [DEBUG] ozmod_isdn.c:728 zchan 8124e08 (1:25) source isdn_data->channels_remote_crv[0x1e] 2009-07-20 11:06:10.419951 [DEBUG] ozmod_isdn.c:799 Received Release Complete message for channel 0 2009-07-20 11:06:10.419951 [DEBUG] ozmod_isdn.c:804 Changing state on 1:25 from HANGUP to DOWN :D A known bug is the handling of incomming calls aiming for non registered, but known targets. Currently caller isn't informed about that and so its call stays open. Will try to fix that. regards Helmut -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) iD8DBQFKZDx94tZeNddg3dwRApjxAJ4tynu+xrzM3uMWlAhgnp2fdjmi0wCfZvgU 1wxVCgyskanESU0UxHQ4Ars= =4xqu -----END PGP SIGNATURE-----