OpenZAP parse error [-3012] [Q931E_INVALID_CRV]
After a time I receive the following error when a call comes in on our OpenZap span 2: parse error [-3012] [Q931E_INVALID_CRV] Here's the log 2009-01-14 13:14:11 [DEBUG] ozmod_isdn.c:320 zap_isdn_931_34() Yay I got an event! Type:[4d] Size:[103] CRV: 23 (0x17, CTX: Originator) 2009-01-14 13:14:11 [DEBUG] ozmod_isdn.c:352 zap_isdn_931_34() zchan 0 (-1:-1) source isdn_data->channels_remote_crv[0x17] 2009-01-14 13:14:11 [CRIT] ozmod_isdn.c:446 zap_isdn_931_34() Received Release with no matching channel 0 2009-01-14 13:14:11 [DEBUG] ozmod_isdn.c:781 zap_isdn_921_23() 931 parse error [-3012] [Q931E_INVALID_CRV] 2009-01-14 13:14:15 [DEBUG] ozmod_isdn.c:777 zap_isdn_921_23() READ 5 -------------------------------------------------------------------------------- When freeswitch is restarted or mod_openzap is reloaded, the error is gone away. Any idea what this can be? Best regards Peter
Some more info: Now I cannot get any incoming call through OpenZAP. "oz dump 1" and "oz dump 2" show that all channels are DOWN. After reload of mod_openzap everythings works again. I receive the following messages for each incoming call: 2009-01-14 19:07:29 [DEBUG] ozmod_isdn.c:777 zap_isdn_921_23() READ 12 -------------------------------------------------------------------------------- [08 02 00 19 4d 08 05 82 e6 33 30 33] 2009-01-14 19:07:29 [DEBUG] ozmod_isdn.c:320 zap_isdn_931_34() Yay I got an event! Type:[4d] Size:[110] CRV: 25 (0x19, CTX: Originator) 2009-01-14 19:07:29 [DEBUG] ozmod_isdn.c:352 zap_isdn_931_34() zchan 75ea20 (1:1) source isdn_data->channels_remote_crv[0x19] 2009-01-14 19:07:29 [DEBUG] mod_openzap.c:1418 on_clear_channel_signal() got clear channel sig [STOP] 2009-01-14 19:07:29 [DEBUG] ozmod_isdn.c:440 zap_isdn_931_34() Received Release in state DOWN, requested hangup for channel 1:0 2009-01-14 19:07:29 [DEBUG] ozmod_isdn.c:1529 q931_rx_32() WRITE 9 -------------------------------------------------------------------------------- [08 02 80 19 5a 08 02 82 e6] 2009-01-14 19:07:29 [DEBUG] ozmod_isdn.c:781 zap_isdn_921_23() 931 parse error [1] [Q931E_NO_ERROR] Peter P GMX schrieb:
After a time I receive the following error when a call comes in on our OpenZap span 2: parse error [-3012] [Q931E_INVALID_CRV]
Here's the log 2009-01-14 13:14:11 [DEBUG] ozmod_isdn.c:320 zap_isdn_931_34() Yay I got an event! Type:[4d] Size:[103] CRV: 23 (0x17, CTX: Originator) 2009-01-14 13:14:11 [DEBUG] ozmod_isdn.c:352 zap_isdn_931_34() zchan 0 (-1:-1) source isdn_data->channels_remote_crv[0x17] 2009-01-14 13:14:11 [CRIT] ozmod_isdn.c:446 zap_isdn_931_34() Received Release with no matching channel 0 2009-01-14 13:14:11 [DEBUG] ozmod_isdn.c:781 zap_isdn_921_23() 931 parse error [-3012] [Q931E_INVALID_CRV] 2009-01-14 13:14:15 [DEBUG] ozmod_isdn.c:777 zap_isdn_921_23() READ 5 --------------------------------------------------------------------------------
When freeswitch is restarted or mod_openzap is reloaded, the error is gone away.
Any idea what this can be?
Best regards Peter
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
I believe these are all symptoms of something that Stefan is working on: better Q931 timers. It's been on the todo list for some time but we've had absolutely NOBODY willing to pony up serious $$ to support OpenZAP development which means it is progressing at the speed of developers' free time. -MC On Wed, Jan 14, 2009 at 9:44 AM, Peter P GMX <Prometheus001@gmx.net> wrote:
After a time I receive the following error when a call comes in on our OpenZap span 2: parse error [-3012] [Q931E_INVALID_CRV]
Here's the log 2009-01-14 13:14:11 [DEBUG] ozmod_isdn.c:320 zap_isdn_931_34() Yay I got an event! Type:[4d] Size:[103] CRV: 23 (0x17, CTX: Originator) 2009-01-14 13:14:11 [DEBUG] ozmod_isdn.c:352 zap_isdn_931_34() zchan 0 (-1:-1) source isdn_data->channels_remote_crv[0x17] 2009-01-14 13:14:11 [CRIT] ozmod_isdn.c:446 zap_isdn_931_34() Received Release with no matching channel 0 2009-01-14 13:14:11 [DEBUG] ozmod_isdn.c:781 zap_isdn_921_23() 931 parse error [-3012] [Q931E_INVALID_CRV] 2009-01-14 13:14:15 [DEBUG] ozmod_isdn.c:777 zap_isdn_921_23() READ 5 --------------------------------------------------------------------------------
When freeswitch is restarted or mod_openzap is reloaded, the error is gone away.
Any idea what this can be?
Best regards Peter
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Hello Michael, how much $$ are we talking about? I need this issue to be solved quickly and it's worth to spend some money. I've read the following post: http://www.mail-archive.com/freeswitch-users@lists.freeswitch.org/msg05792.h... and have the same symptom with "after hundreds of calls I start to get b channels that are stuck in states like "TERMINATING" or "HANGUP"" Best regards Peter Michael Collins schrieb:
I believe these are all symptoms of something that Stefan is working on: better Q931 timers. It's been on the todo list for some time but we've had absolutely NOBODY willing to pony up serious $$ to support OpenZAP development which means it is progressing at the speed of developers' free time.
-MC
On Wed, Jan 14, 2009 at 9:44 AM, Peter P GMX <Prometheus001@gmx.net> wrote:
After a time I receive the following error when a call comes in on our OpenZap span 2: parse error [-3012] [Q931E_INVALID_CRV]
Here's the log 2009-01-14 13:14:11 [DEBUG] ozmod_isdn.c:320 zap_isdn_931_34() Yay I got an event! Type:[4d] Size:[103] CRV: 23 (0x17, CTX: Originator) 2009-01-14 13:14:11 [DEBUG] ozmod_isdn.c:352 zap_isdn_931_34() zchan 0 (-1:-1) source isdn_data->channels_remote_crv[0x17] 2009-01-14 13:14:11 [CRIT] ozmod_isdn.c:446 zap_isdn_931_34() Received Release with no matching channel 0 2009-01-14 13:14:11 [DEBUG] ozmod_isdn.c:781 zap_isdn_921_23() 931 parse error [-3012] [Q931E_INVALID_CRV] 2009-01-14 13:14:15 [DEBUG] ozmod_isdn.c:777 zap_isdn_921_23() READ 5 --------------------------------------------------------------------------------
When freeswitch is restarted or mod_openzap is reloaded, the error is gone away.
Any idea what this can be?
Best regards Peter
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Michael, it must not be the case here, but I had the same error, when incomming calles used a wrong numbering plan resp not the one, FS expected. Just a hint. regards Helmut Am 15.01.2009 09:20, schrieb Peter P GMX:
Hello Michael,
how much $$ are we talking about? I need this issue to be solved quickly and it's worth to spend some money.
I've read the following post:
http://www.mail-archive.com/freeswitch-users@lists.freeswitch.org/msg05792.h... and have the same symptom with "after hundreds of calls I start to get b channels that are stuck in states like "TERMINATING" or "HANGUP""
Best regards Peter
Michael Collins schrieb:
I believe these are all symptoms of something that Stefan is working on: better Q931 timers. It's been on the todo list for some time but we've had absolutely NOBODY willing to pony up serious $$ to support OpenZAP development which means it is progressing at the speed of developers' free time.
-MC -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32)
iEYEARECAAYFAklvFEkACgkQ4tZeNddg3dxitgCeIgNS+qUwYQ0ypc1KyXjRO3OV OFwAn1TeaNP466OWErmqEFr9H9p2Wam5 =2NfD -----END PGP SIGNATURE-----
Helmut, can you give me a hint, how you worked around this? Best regards Peter Helmut Kuper schrieb:
Hi Michael,
it must not be the case here, but I had the same error, when incomming calles used a wrong numbering plan resp not the one, FS expected.
Just a hint.
regards Helmut
Am 15.01.2009 09:20, schrieb Peter P GMX:
Hello Michael,
how much $$ are we talking about? I need this issue to be solved quickly and it's worth to spend some money.
I've read the following post:
http://www.mail-archive.com/freeswitch-users@lists.freeswitch.org/msg05792.h...
and have the same symptom with "after hundreds of calls I start to get b channels that are stuck in states like "TERMINATING" or "HANGUP""
Best regards Peter
Michael Collins schrieb:
I believe these are all symptoms of something that Stefan is working on: better Q931 timers. It's been on the todo list for some time but we've had absolutely NOBODY willing to pony up serious $$ to support OpenZAP development which means it is progressing at the speed of developers' free time.
-MC
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Peter, it was simply a change in our TDM Voice Switch. It used a different numbering plan and we changed it to "national" to get it work with FS and openzap in Q921/Q931 mode. What I still search is a way to configure the numberplan in FS. To make it clear: In my case it didn't work from the second FS starts up. So this differs from your problem. To get an idea what's going on on the TDM link I used a TDM D-Channel monitoring device and traced the d-channel messages exchanged between FS and TDM. That should make it easier to see what's wrong when the problems occur. But you can also increase FS debug level to debug and trace the Q921 and Q931 messages in FS console via fs_cli during runtime. You have to set this in openzap.conf.xml: <param name="q921loglevel" value="debug"/> <param name="q931loglevel" value="debug"/> Unfortunately FS doesn't decode the whole Q931 messages, but it shows a hex representation of the message, so you can manually decode it with this documents: Q.931: http://www.itu.int/rec/T-REC-Q.931-199805-I/en Q.921: http://www.itu.int/rec/T-REC-Q.921-199709-I/en I think for numberingplan issues you only have to track the Q.931 messages. The last idea I have to get some light into your problem and to avoid manually decoding, try to convert FS's q931 hexdump into wiresharks pcap format. Wireshark should be able to decode it :) http://wiki.wireshark.org/Q.931 Maybe it's a good idea to implement a wireshark export for those messages in FS. This will make debugging easy and cheap. Hope it helps a bit. regards helmut Am 15.01.2009 12:06, schrieb Peter P GMX:
Helmut,
can you give me a hint, how you worked around this?
Best regards Peter
Helmut Kuper schrieb:
Hi Michael,
it must not be the case here, but I had the same error, when incomming calles used a wrong numbering plan resp not the one, FS expected.
Just a hint.
regards Helmut
Am 15.01.2009 09:20, schrieb Peter P GMX:
Hello Michael, how much $$ are we talking about? I need this issue to be solved quickly and it's worth to spend some money. I've read the following post: http://www.mail-archive.com/freeswitch-users@lists.freeswitch.org/msg05792.h... and have the same symptom with "after hundreds of calls I start to get b channels that are stuck in states like "TERMINATING" or "HANGUP"" Best regards Peter Michael Collins schrieb:
I believe these are all symptoms of something that Stefan is working on: better Q931 timers. It's been on the todo list for some time but we've had absolutely NOBODY willing to pony up serious $$ to support OpenZAP development which means it is progressing at the speed of developers' free time.
-MC
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAklvLHMACgkQ4tZeNddg3dxF0ACgpMqGf8hu1iSKbOG7nG2o1HZN qdEAoIpTY3Bgwv9wzhV7lq7IKtvDxO5/ =lDVf -----END PGP SIGNATURE-----
Thanks Helmut, I cross-checked with our provider. They use national numbering plan for our lines. So this didn't solve our problem. I also ensured that the local language is DE and ZAP timing is dedicated to span 1. I changed the configs to debug mode for OpenZAP, so I hopefully will get some more info on the next failure. Best regards Peter Helmut Kuper schrieb:
Hi Peter,
it was simply a change in our TDM Voice Switch. It used a different numbering plan and we changed it to "national" to get it work with FS and openzap in Q921/Q931 mode.
What I still search is a way to configure the numberplan in FS.
To make it clear: In my case it didn't work from the second FS starts up. So this differs from your problem.
To get an idea what's going on on the TDM link I used a TDM D-Channel monitoring device and traced the d-channel messages exchanged between FS and TDM. That should make it easier to see what's wrong when the problems occur. But you can also increase FS debug level to debug and trace the Q921 and Q931 messages in FS console via fs_cli during runtime. You have to set this in openzap.conf.xml:
<param name="q921loglevel" value="debug"/> <param name="q931loglevel" value="debug"/>
Unfortunately FS doesn't decode the whole Q931 messages, but it shows a hex representation of the message, so you can manually decode it with this documents:
Q.931: http://www.itu.int/rec/T-REC-Q.931-199805-I/en Q.921: http://www.itu.int/rec/T-REC-Q.921-199709-I/en
I think for numberingplan issues you only have to track the Q.931 messages.
The last idea I have to get some light into your problem and to avoid manually decoding, try to convert FS's q931 hexdump into wiresharks pcap format. Wireshark should be able to decode it :) http://wiki.wireshark.org/Q.931
Maybe it's a good idea to implement a wireshark export for those messages in FS. This will make debugging easy and cheap.
Hope it helps a bit.
regards helmut
Am 15.01.2009 12:06, schrieb Peter P GMX:
Helmut,
can you give me a hint, how you worked around this?
Best regards Peter
Helmut Kuper schrieb:
Hi Michael,
it must not be the case here, but I had the same error, when incomming calles used a wrong numbering plan resp not the one, FS expected.
Just a hint.
regards Helmut
Am 15.01.2009 09:20, schrieb Peter P GMX:
Hello Michael, how much $$ are we talking about? I need this issue to be solved quickly and it's worth to spend some money. I've read the following post:
http://www.mail-archive.com/freeswitch-users@lists.freeswitch.org/msg05792.h...
and have the same symptom with "after hundreds of calls I start to get b channels that are stuck in states like "TERMINATING" or "HANGUP"" Best regards Peter Michael Collins schrieb:
I believe these are all symptoms of something that Stefan is working on: better Q931 timers. It's been on the todo list for some time but we've had absolutely NOBODY willing to pony up serious $$ to support OpenZAP development which means it is progressing at the speed of developers' free time.
-MC
Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
I did some more tests. When I sequentially setup calls (only one simultaneous call at a time), it works for hundreds of calls. As soon as I setup 2 calls in parallel ist fails aber a number of calls. Please find another debug ouput (now with Q.921 debug also). The log starts with the latest hangup of a successfull call. After this one I receive a "2009-01-15 20:26:46 [CRIT] ozmod_isdn.c:446 zap_isdn_931_34() Received Release with no matching channel 0" and later "2009-01-15 20:26:46 [DEBUG] ozmod_isdn.c:781 zap_isdn_921_23() 931 parse error [-3012] [Q931E_INVALID_CRV]" Is there anyone to fix it? May I donate some money for fixing that? Best regards Peter Debug: 2009-01-15 20:26:44 [DEBUG] Span:0 Q.921() Sending frame ----------------- Q.921 Packet [Outgoing] --------------- SAPI: 0, TEI: 0, C/R: Command (0) Type: S Frame, SV: RR (Receive Ready) P/F: 0, N(R): 81 [V(A): 80, V(R): 81, V(S): 80] Q.921 state: "Multiple Frame Mode Established" (7) [flags: ----] ---------------------------------------------- 2009-01-15 20:26:44 [DEBUG] ozmod_isdn.c:813 state_advance() 2:3 STATE [TERMINATING] 2009-01-15 20:26:44 [DEBUG] ozmod_isdn.c:1121 state_advance() Terminating: Direction Inbound 2009-01-15 20:26:44 [DEBUG] mod_openzap.c:1418 on_clear_channel_signal() got clear channel sig [STOP] 2009-01-15 20:26:44 [NOTICE] mod_openzap.c:1437 on_clear_channel_signal() Hangup OpenZAP/2:3/21658519 [CS_EXECUTE] [NORMAL_CLEARING] 2009-01-15 20:26:44 [DEBUG] switch_channel.c:1513 switch_channel_perform_hangup() Send signal OpenZAP/2:3/21658519 [KILL] 2009-01-15 20:26:44 [DEBUG] switch_core_session.c:807 switch_core_session_signal_state_change() Send signal OpenZAP/2:3/21658519 [BREAK] 2009-01-15 20:26:44 [DEBUG] Span:0 Q.931() Receiving message from Layer4 (size: 184, type: 77) 2009-01-15 20:26:44 [DEBUG] Span:0 Q.931() Sending message to Q.921 (size: 184) 2009-01-15 20:26:44 [DEBUG] Span:0 Q.931() Creating Q.931 Message Header: ProtDisc 8 (0x8), CRV 126 (0x7e), CRVflag: 1 (0x1), MesType: 77 (0x4d) 2009-01-15 20:26:44 [DEBUG] ozmod_isdn.c:1529 q931_rx_32() WRITE 5 -------------------------------------------------------------------------------- [08 02 80 7e 4d] 2009-01-15 20:26:44 [DEBUG] Span:0 Q.921() Got frame from Q.931, type: 4, tei: 0, size: 9 2009-01-15 20:26:44 [DEBUG] Span:0 Q.921() Enqueueing I frame for TEI 0 [0] 2009-01-15 20:26:44 [DEBUG] Span:0 Q.921() Sending frame ----------------- Q.921 Packet [Outgoing] --------------- SAPI: 0, TEI: 0, C/R: Command (0) Type: I Frame P/F: 0, N(S): 80, N(R): 81 [V(A): 80, V(R): 81, V(S): 80] Q.921 state: "Multiple Frame Mode Established" (7) [flags: ----] ---------------------------------------------- 2009-01-15 20:26:44 [DEBUG] Span:0 Q.921() T200 (timeout: 1000 msecs) started for TEI 0 2009-01-15 20:26:44 [DEBUG] Span:0 Q.921() T203 stopped for TEI 0 2009-01-15 20:26:44 [DEBUG] Span:0 Q.931() Q931Rx43 return code: 1 2009-01-15 20:26:44 [DEBUG] mod_event_socket.c:1922 listener_run() Session complete, waiting for children 2009-01-15 20:26:44 [DEBUG] mod_event_socket.c:1946 listener_run() Connection Closed 2009-01-15 20:26:44 [DEBUG] switch_ivr_play_say.c:1222 switch_ivr_play_file() done playing file 2009-01-15 20:26:44 [DEBUG] switch_core_state_machine.c:454 switch_core_session_run() (OpenZAP/2:3/21658519) State EXECUTE going to sleep 2009-01-15 20:26:44 [DEBUG] switch_core_state_machine.c:379 switch_core_session_run() (OpenZAP/2:3/21658519) Running State Change CS_HANGUP 2009-01-15 20:26:44 [DEBUG] switch_core_state_machine.c:410 switch_core_session_run() (OpenZAP/2:3/21658519) State HANGUP 2009-01-15 20:26:44 [DEBUG] mod_openzap.c:472 channel_on_hangup() OpenZAP/2:3/21658519 CHANNEL HANGUP 2009-01-15 20:26:44 [DEBUG] switch_core_state_machine.c:46 switch_core_standard_on_hangup() OpenZAP/2:3/21658519 Standard HANGUP, cause: NORMAL_CLEARING 2009-01-15 20:26:44 [DEBUG] switch_core_state_machine.c:410 switch_core_session_run() (OpenZAP/2:3/21658519) State HANGUP going to sleep 2009-01-15 20:26:44 [DEBUG] switch_core_session.c:939 switch_core_session_thread() Session 251 (OpenZAP/2:3/21658519) Locked, Waiting on external entities 2009-01-15 20:26:44 [NOTICE] switch_core_session.c:957 switch_core_session_thread() Session 251 (OpenZAP/2:3/21658519) Ended 2009-01-15 20:26:44 [NOTICE] switch_core_session.c:959 switch_core_session_thread() Close Channel OpenZAP/2:3/21658519 [CS_HANGUP] 2009-01-15 20:26:44 [DEBUG] Span:0 Q.921() New packet received (4 bytes) ----------------- Q.921 Packet [Incoming] --------------- SAPI: 0, TEI: 0, C/R: Response (0) Type: S Frame, SV: RR (Receive Ready) P/F: 0, N(R): 81 [V(A): 80, V(R): 81, V(S): 81] Q.921 state: "Multiple Frame Mode Established" (7) [flags: ----] ---------------------------------------------- 2009-01-15 20:26:44 [DEBUG] Span:0 Q.921() T200 stopped for TEI 0 2009-01-15 20:26:44 [DEBUG] Span:0 Q.921() T203 (timeout: 10000 msecs) restarted for TEI 0 2009-01-15 20:26:44 [DEBUG] Span:0 Q.921() New packet received (9 bytes) ----------------- Q.921 Packet [Incoming] --------------- SAPI: 0, TEI: 0, C/R: Command (1) Type: I Frame P/F: 0, N(S): 81, N(R): 81 [V(A): 81, V(R): 81, V(S): 81] Q.921 state: "Multiple Frame Mode Established" (7) [flags: ----] ---------------------------------------------- 2009-01-15 20:26:44 [DEBUG] ozmod_isdn.c:777 zap_isdn_921_23() READ 5 -------------------------------------------------------------------------------- [08 02 00 7e 5a] 2009-01-15 20:26:44 [DEBUG] Span:0 Q.931() Received message from Q.921 (ind 4, tei 0, size 9) MesType: 90, CRVFlag 0 (Originator), CRV 126 (Dialect: 0) 2009-01-15 20:26:44 [DEBUG] Span:0 Q.931() Sending message to Layer4 (size: 103) 2009-01-15 20:26:44 [DEBUG] ozmod_isdn.c:320 zap_isdn_931_34() Yay I got an event! Type:[5a] Size:[103] CRV: 126 (0x7e, CTX: Originator) 2009-01-15 20:26:44 [DEBUG] ozmod_isdn.c:352 zap_isdn_931_34() zchan e0020270 (2:3) source isdn_data->channels_remote_crv[0x7e] 2009-01-15 20:26:44 [DEBUG] ozmod_isdn.c:418 zap_isdn_931_34() Changing state on 2:3 from TERMINATING to DOWN 2009-01-15 20:26:44 [DEBUG] Span:0 Q.921() Sending frame ----------------- Q.921 Packet [Outgoing] --------------- SAPI: 0, TEI: 0, C/R: Response (1) Type: S Frame, SV: RR (Receive Ready) P/F: 0, N(R): 82 [V(A): 81, V(R): 82, V(S): 81] Q.921 state: "Multiple Frame Mode Established" (7) [flags: ----] ---------------------------------------------- 2009-01-15 20:26:44 [DEBUG] Span:0 Q.921() T200 stopped for TEI 0 2009-01-15 20:26:44 [DEBUG] Span:0 Q.921() T203 (timeout: 10000 msecs) restarted for TEI 0 2009-01-15 20:26:44 [DEBUG] Span:0 Q.921() Sending frame ----------------- Q.921 Packet [Outgoing] --------------- SAPI: 0, TEI: 0, C/R: Command (0) Type: S Frame, SV: RR (Receive Ready) P/F: 0, N(R): 82 [V(A): 81, V(R): 82, V(S): 81] Q.921 state: "Multiple Frame Mode Established" (7) [flags: ----] ---------------------------------------------- 2009-01-15 20:26:44 [DEBUG] ozmod_isdn.c:813 state_advance() 2:3 STATE [DOWN] 2009-01-15 20:26:44 [DEBUG] zap_io.c:1125 zap_channel_done() channel done 2:3 2009-01-15 20:26:46 [DEBUG] Span:0 Q.921() New packet received (16 bytes) ----------------- Q.921 Packet [Incoming] --------------- SAPI: 0, TEI: 0, C/R: Command (1) Type: I Frame P/F: 0, N(S): 82, N(R): 81 [V(A): 81, V(R): 82, V(S): 81] Q.921 state: "Multiple Frame Mode Established" (7) [flags: ----] ---------------------------------------------- 2009-01-15 20:26:46 [DEBUG] ozmod_isdn.c:777 zap_isdn_921_23() READ 12 -------------------------------------------------------------------------------- [08 02 00 7d 4d 08 05 82 e6 33 30 33] 2009-01-15 20:26:46 [DEBUG] Span:0 Q.931() Received message from Q.921 (ind 4, tei 0, size 16) MesType: 77, CRVFlag 0 (Originator), CRV 125 (Dialect: 0) 2009-01-15 20:26:46 [DEBUG] Span:0 Q.931() Sending message to Layer4 (size: 110) 2009-01-15 20:26:46 [DEBUG] ozmod_isdn.c:320 zap_isdn_931_34() Yay I got an event! Type:[4d] Size:[110] CRV: 125 (0x7d, CTX: Originator) 2009-01-15 20:26:46 [DEBUG] ozmod_isdn.c:352 zap_isdn_931_34() zchan 0 (-1:-1) source isdn_data->channels_remote_crv[0x7d] 2009-01-15 20:26:46 [CRIT] ozmod_isdn.c:446 zap_isdn_931_34() Received Release with no matching channel 0 2009-01-15 20:26:46 [DEBUG] Span:0 Q.931() Sending message to Q.921 (size: 110) 2009-01-15 20:26:46 [DEBUG] Span:0 Q.931() Creating Q.931 Message Header: ProtDisc 8 (0x8), CRV 125 (0x7d), CRVflag: 1 (0x1), MesType: 90 (0x5a) 2009-01-15 20:26:46 [DEBUG] ozmod_isdn.c:781 zap_isdn_921_23() 931 parse error [-3012] [Q931E_INVALID_CRV] 2009-01-15 20:26:46 [DEBUG] Span:0 Q.921() Sending frame ----------------- Q.921 Packet [Outgoing] --------------- SAPI: 0, TEI: 0, C/R: Response (1) Type: S Frame, SV: RR (Receive Ready) P/F: 0, N(R): 83 [V(A): 81, V(R): 83, V(S): 81] Q.921 state: "Multiple Frame Mode Established" (7) [flags: ----] ---------------------------------------------- 2009-01-15 20:26:46 [DEBUG] Span:0 Q.921() T200 stopped for TEI 0 2009-01-15 20:26:46 [DEBUG] Span:0 Q.921() T203 (timeout: 10000 msecs) restarted for TEI 0 2009-01-15 20:26:46 [DEBUG] Span:0 Q.921() Sending frame ----------------- Q.921 Packet [Outgoing] --------------- SAPI: 0, TEI: 0, C/R: Command (0) Type: S Frame, SV: RR (Receive Ready) P/F: 0, N(R): 83 [V(A): 81, V(R): 83, V(S): 81] Q.921 state: "Multiple Frame Mode Established" (7) [flags: ----] ---------------------------------------------- Peter P GMX schrieb:
Thanks Helmut,
I cross-checked with our provider. They use national numbering plan for our lines. So this didn't solve our problem. I also ensured that the local language is DE and ZAP timing is dedicated to span 1.
I changed the configs to debug mode for OpenZAP, so I hopefully will get some more info on the next failure.
Best regards Peter
Helmut Kuper schrieb:
Hi Peter,
it was simply a change in our TDM Voice Switch. It used a different numbering plan and we changed it to "national" to get it work with FS and openzap in Q921/Q931 mode.
What I still search is a way to configure the numberplan in FS.
To make it clear: In my case it didn't work from the second FS starts up. So this differs from your problem.
To get an idea what's going on on the TDM link I used a TDM D-Channel monitoring device and traced the d-channel messages exchanged between FS and TDM. That should make it easier to see what's wrong when the problems occur. But you can also increase FS debug level to debug and trace the Q921 and Q931 messages in FS console via fs_cli during runtime. You have to set this in openzap.conf.xml:
<param name="q921loglevel" value="debug"/> <param name="q931loglevel" value="debug"/>
Unfortunately FS doesn't decode the whole Q931 messages, but it shows a hex representation of the message, so you can manually decode it with this documents:
Q.931: http://www.itu.int/rec/T-REC-Q.931-199805-I/en Q.921: http://www.itu.int/rec/T-REC-Q.921-199709-I/en
I think for numberingplan issues you only have to track the Q.931 messages.
The last idea I have to get some light into your problem and to avoid manually decoding, try to convert FS's q931 hexdump into wiresharks pcap format. Wireshark should be able to decode it :) http://wiki.wireshark.org/Q.931
Maybe it's a good idea to implement a wireshark export for those messages in FS. This will make debugging easy and cheap.
Hope it helps a bit.
regards helmut
Am 15.01.2009 12:06, schrieb Peter P GMX:
Helmut,
can you give me a hint, how you worked around this?
Best regards Peter
Helmut Kuper schrieb:
Hi Michael,
it must not be the case here, but I had the same error, when incomming calles used a wrong numbering plan resp not the one, FS expected.
Just a hint.
regards Helmut
Am 15.01.2009 09:20, schrieb Peter P GMX:
Hello Michael, how much $$ are we talking about? I need this issue to be solved
quickly
and it's worth to spend some money. I've read the following post:
http://www.mail-archive.com/freeswitch-users@lists.freeswitch.org/msg05792.h...
and have the same symptom with "after hundreds of calls I start to
get b
channels that are stuck in states like "TERMINATING" or "HANGUP"" Best regards Peter Michael Collins schrieb:
> I believe these are all symptoms of something that Stefan is working > on: better Q931 timers. It's been on the todo list for some time but > we've had absolutely NOBODY willing to pony up serious $$ to support > OpenZAP development which means it is progressing at the speed of > developers' free time. > > -MC >
Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Peter, I believe we are in a bit of a holding pattern right now with OpenZAP PRI stuff. We have a super user, Stefan, who is working on some Q931 timers and such but he is working on it in spare time and there's no hard date. If you know someone with serious PRI and C programming skillz who can assist then we'd definitely be willing to have some help. "Patches welcome" as it were. :) Thanks, MC On Thu, Jan 15, 2009 at 12:12 PM, Peter P GMX <Prometheus001@gmx.net> wrote:
I did some more tests. When I sequentially setup calls (only one simultaneous call at a time), it works for hundreds of calls. As soon as I setup 2 calls in parallel ist fails aber a number of calls.
Please find another debug ouput (now with Q.921 debug also). The log starts with the latest hangup of a successfull call. After this one I receive a "2009-01-15 20:26:46 [CRIT] ozmod_isdn.c:446 zap_isdn_931_34() Received Release with no matching channel 0" and later "2009-01-15 20:26:46 [DEBUG] ozmod_isdn.c:781 zap_isdn_921_23() 931 parse error [-3012] [Q931E_INVALID_CRV]"
Is there anyone to fix it? May I donate some money for fixing that?
Best regards Peter
Debug: 2009-01-15 20:26:44 [DEBUG] Span:0 Q.921() Sending frame ----------------- Q.921 Packet [Outgoing] --------------- SAPI: 0, TEI: 0, C/R: Command (0)
Type: S Frame, SV: RR (Receive Ready) P/F: 0, N(R): 81 [V(A): 80, V(R): 81, V(S): 80]
Q.921 state: "Multiple Frame Mode Established" (7) [flags: ----] ----------------------------------------------
2009-01-15 20:26:44 [DEBUG] ozmod_isdn.c:813 state_advance() 2:3 STATE [TERMINATING] 2009-01-15 20:26:44 [DEBUG] ozmod_isdn.c:1121 state_advance() Terminating: Direction Inbound 2009-01-15 20:26:44 [DEBUG] mod_openzap.c:1418 on_clear_channel_signal() got clear channel sig [STOP] 2009-01-15 20:26:44 [NOTICE] mod_openzap.c:1437 on_clear_channel_signal() Hangup OpenZAP/2:3/21658519 [CS_EXECUTE] [NORMAL_CLEARING] 2009-01-15 20:26:44 [DEBUG] switch_channel.c:1513 switch_channel_perform_hangup() Send signal OpenZAP/2:3/21658519 [KILL] 2009-01-15 20:26:44 [DEBUG] switch_core_session.c:807 switch_core_session_signal_state_change() Send signal OpenZAP/2:3/21658519 [BREAK] 2009-01-15 20:26:44 [DEBUG] Span:0 Q.931() Receiving message from Layer4 (size: 184, type: 77) 2009-01-15 20:26:44 [DEBUG] Span:0 Q.931() Sending message to Q.921 (size: 184) 2009-01-15 20:26:44 [DEBUG] Span:0 Q.931() Creating Q.931 Message Header: ProtDisc 8 (0x8), CRV 126 (0x7e), CRVflag: 1 (0x1), MesType: 77 (0x4d) 2009-01-15 20:26:44 [DEBUG] ozmod_isdn.c:1529 q931_rx_32() WRITE 5 -------------------------------------------------------------------------------- [08 02 80 7e 4d]
2009-01-15 20:26:44 [DEBUG] Span:0 Q.921() Got frame from Q.931, type: 4, tei: 0, size: 9 2009-01-15 20:26:44 [DEBUG] Span:0 Q.921() Enqueueing I frame for TEI 0 [0] 2009-01-15 20:26:44 [DEBUG] Span:0 Q.921() Sending frame ----------------- Q.921 Packet [Outgoing] --------------- SAPI: 0, TEI: 0, C/R: Command (0)
Type: I Frame P/F: 0, N(S): 80, N(R): 81 [V(A): 80, V(R): 81, V(S): 80]
Q.921 state: "Multiple Frame Mode Established" (7) [flags: ----] ----------------------------------------------
2009-01-15 20:26:44 [DEBUG] Span:0 Q.921() T200 (timeout: 1000 msecs) started for TEI 0 2009-01-15 20:26:44 [DEBUG] Span:0 Q.921() T203 stopped for TEI 0 2009-01-15 20:26:44 [DEBUG] Span:0 Q.931() Q931Rx43 return code: 1 2009-01-15 20:26:44 [DEBUG] mod_event_socket.c:1922 listener_run() Session complete, waiting for children 2009-01-15 20:26:44 [DEBUG] mod_event_socket.c:1946 listener_run() Connection Closed 2009-01-15 20:26:44 [DEBUG] switch_ivr_play_say.c:1222 switch_ivr_play_file() done playing file 2009-01-15 20:26:44 [DEBUG] switch_core_state_machine.c:454 switch_core_session_run() (OpenZAP/2:3/21658519) State EXECUTE going to sleep 2009-01-15 20:26:44 [DEBUG] switch_core_state_machine.c:379 switch_core_session_run() (OpenZAP/2:3/21658519) Running State Change CS_HANGUP 2009-01-15 20:26:44 [DEBUG] switch_core_state_machine.c:410 switch_core_session_run() (OpenZAP/2:3/21658519) State HANGUP 2009-01-15 20:26:44 [DEBUG] mod_openzap.c:472 channel_on_hangup() OpenZAP/2:3/21658519 CHANNEL HANGUP 2009-01-15 20:26:44 [DEBUG] switch_core_state_machine.c:46 switch_core_standard_on_hangup() OpenZAP/2:3/21658519 Standard HANGUP, cause: NORMAL_CLEARING 2009-01-15 20:26:44 [DEBUG] switch_core_state_machine.c:410 switch_core_session_run() (OpenZAP/2:3/21658519) State HANGUP going to sleep 2009-01-15 20:26:44 [DEBUG] switch_core_session.c:939 switch_core_session_thread() Session 251 (OpenZAP/2:3/21658519) Locked, Waiting on external entities 2009-01-15 20:26:44 [NOTICE] switch_core_session.c:957 switch_core_session_thread() Session 251 (OpenZAP/2:3/21658519) Ended 2009-01-15 20:26:44 [NOTICE] switch_core_session.c:959 switch_core_session_thread() Close Channel OpenZAP/2:3/21658519 [CS_HANGUP] 2009-01-15 20:26:44 [DEBUG] Span:0 Q.921() New packet received (4 bytes) ----------------- Q.921 Packet [Incoming] --------------- SAPI: 0, TEI: 0, C/R: Response (0)
Type: S Frame, SV: RR (Receive Ready) P/F: 0, N(R): 81 [V(A): 80, V(R): 81, V(S): 81]
Q.921 state: "Multiple Frame Mode Established" (7) [flags: ----] ----------------------------------------------
2009-01-15 20:26:44 [DEBUG] Span:0 Q.921() T200 stopped for TEI 0 2009-01-15 20:26:44 [DEBUG] Span:0 Q.921() T203 (timeout: 10000 msecs) restarted for TEI 0 2009-01-15 20:26:44 [DEBUG] Span:0 Q.921() New packet received (9 bytes) ----------------- Q.921 Packet [Incoming] --------------- SAPI: 0, TEI: 0, C/R: Command (1)
Type: I Frame P/F: 0, N(S): 81, N(R): 81 [V(A): 81, V(R): 81, V(S): 81]
Q.921 state: "Multiple Frame Mode Established" (7) [flags: ----] ----------------------------------------------
2009-01-15 20:26:44 [DEBUG] ozmod_isdn.c:777 zap_isdn_921_23() READ 5 -------------------------------------------------------------------------------- [08 02 00 7e 5a]
2009-01-15 20:26:44 [DEBUG] Span:0 Q.931() Received message from Q.921 (ind 4, tei 0, size 9) MesType: 90, CRVFlag 0 (Originator), CRV 126 (Dialect: 0) 2009-01-15 20:26:44 [DEBUG] Span:0 Q.931() Sending message to Layer4 (size: 103) 2009-01-15 20:26:44 [DEBUG] ozmod_isdn.c:320 zap_isdn_931_34() Yay I got an event! Type:[5a] Size:[103] CRV: 126 (0x7e, CTX: Originator) 2009-01-15 20:26:44 [DEBUG] ozmod_isdn.c:352 zap_isdn_931_34() zchan e0020270 (2:3) source isdn_data->channels_remote_crv[0x7e] 2009-01-15 20:26:44 [DEBUG] ozmod_isdn.c:418 zap_isdn_931_34() Changing state on 2:3 from TERMINATING to DOWN 2009-01-15 20:26:44 [DEBUG] Span:0 Q.921() Sending frame ----------------- Q.921 Packet [Outgoing] --------------- SAPI: 0, TEI: 0, C/R: Response (1)
Type: S Frame, SV: RR (Receive Ready) P/F: 0, N(R): 82 [V(A): 81, V(R): 82, V(S): 81]
Q.921 state: "Multiple Frame Mode Established" (7) [flags: ----] ----------------------------------------------
2009-01-15 20:26:44 [DEBUG] Span:0 Q.921() T200 stopped for TEI 0 2009-01-15 20:26:44 [DEBUG] Span:0 Q.921() T203 (timeout: 10000 msecs) restarted for TEI 0 2009-01-15 20:26:44 [DEBUG] Span:0 Q.921() Sending frame ----------------- Q.921 Packet [Outgoing] --------------- SAPI: 0, TEI: 0, C/R: Command (0)
Type: S Frame, SV: RR (Receive Ready) P/F: 0, N(R): 82 [V(A): 81, V(R): 82, V(S): 81]
Q.921 state: "Multiple Frame Mode Established" (7) [flags: ----] ----------------------------------------------
2009-01-15 20:26:44 [DEBUG] ozmod_isdn.c:813 state_advance() 2:3 STATE [DOWN] 2009-01-15 20:26:44 [DEBUG] zap_io.c:1125 zap_channel_done() channel done 2:3 2009-01-15 20:26:46 [DEBUG] Span:0 Q.921() New packet received (16 bytes) ----------------- Q.921 Packet [Incoming] --------------- SAPI: 0, TEI: 0, C/R: Command (1)
Type: I Frame P/F: 0, N(S): 82, N(R): 81 [V(A): 81, V(R): 82, V(S): 81]
Q.921 state: "Multiple Frame Mode Established" (7) [flags: ----] ----------------------------------------------
2009-01-15 20:26:46 [DEBUG] ozmod_isdn.c:777 zap_isdn_921_23() READ 12 -------------------------------------------------------------------------------- [08 02 00 7d 4d 08 05 82 e6 33 30 33]
2009-01-15 20:26:46 [DEBUG] Span:0 Q.931() Received message from Q.921 (ind 4, tei 0, size 16) MesType: 77, CRVFlag 0 (Originator), CRV 125 (Dialect: 0) 2009-01-15 20:26:46 [DEBUG] Span:0 Q.931() Sending message to Layer4 (size: 110) 2009-01-15 20:26:46 [DEBUG] ozmod_isdn.c:320 zap_isdn_931_34() Yay I got an event! Type:[4d] Size:[110] CRV: 125 (0x7d, CTX: Originator) 2009-01-15 20:26:46 [DEBUG] ozmod_isdn.c:352 zap_isdn_931_34() zchan 0 (-1:-1) source isdn_data->channels_remote_crv[0x7d] 2009-01-15 20:26:46 [CRIT] ozmod_isdn.c:446 zap_isdn_931_34() Received Release with no matching channel 0 2009-01-15 20:26:46 [DEBUG] Span:0 Q.931() Sending message to Q.921 (size: 110) 2009-01-15 20:26:46 [DEBUG] Span:0 Q.931() Creating Q.931 Message Header: ProtDisc 8 (0x8), CRV 125 (0x7d), CRVflag: 1 (0x1), MesType: 90 (0x5a) 2009-01-15 20:26:46 [DEBUG] ozmod_isdn.c:781 zap_isdn_921_23() 931 parse error [-3012] [Q931E_INVALID_CRV] 2009-01-15 20:26:46 [DEBUG] Span:0 Q.921() Sending frame ----------------- Q.921 Packet [Outgoing] --------------- SAPI: 0, TEI: 0, C/R: Response (1)
Type: S Frame, SV: RR (Receive Ready) P/F: 0, N(R): 83 [V(A): 81, V(R): 83, V(S): 81]
Q.921 state: "Multiple Frame Mode Established" (7) [flags: ----] ----------------------------------------------
2009-01-15 20:26:46 [DEBUG] Span:0 Q.921() T200 stopped for TEI 0 2009-01-15 20:26:46 [DEBUG] Span:0 Q.921() T203 (timeout: 10000 msecs) restarted for TEI 0 2009-01-15 20:26:46 [DEBUG] Span:0 Q.921() Sending frame ----------------- Q.921 Packet [Outgoing] --------------- SAPI: 0, TEI: 0, C/R: Command (0)
Type: S Frame, SV: RR (Receive Ready) P/F: 0, N(R): 83 [V(A): 81, V(R): 83, V(S): 81]
Q.921 state: "Multiple Frame Mode Established" (7) [flags: ----] ----------------------------------------------
Peter P GMX schrieb:
Thanks Helmut,
I cross-checked with our provider. They use national numbering plan for our lines. So this didn't solve our problem. I also ensured that the local language is DE and ZAP timing is dedicated to span 1.
I changed the configs to debug mode for OpenZAP, so I hopefully will get some more info on the next failure.
Best regards Peter
Helmut Kuper schrieb:
Hi Peter,
it was simply a change in our TDM Voice Switch. It used a different numbering plan and we changed it to "national" to get it work with FS and openzap in Q921/Q931 mode.
What I still search is a way to configure the numberplan in FS.
To make it clear: In my case it didn't work from the second FS starts up. So this differs from your problem.
To get an idea what's going on on the TDM link I used a TDM D-Channel monitoring device and traced the d-channel messages exchanged between FS and TDM. That should make it easier to see what's wrong when the problems occur. But you can also increase FS debug level to debug and trace the Q921 and Q931 messages in FS console via fs_cli during runtime. You have to set this in openzap.conf.xml:
<param name="q921loglevel" value="debug"/> <param name="q931loglevel" value="debug"/>
Unfortunately FS doesn't decode the whole Q931 messages, but it shows a hex representation of the message, so you can manually decode it with this documents:
Q.931: http://www.itu.int/rec/T-REC-Q.931-199805-I/en Q.921: http://www.itu.int/rec/T-REC-Q.921-199709-I/en
I think for numberingplan issues you only have to track the Q.931 messages.
The last idea I have to get some light into your problem and to avoid manually decoding, try to convert FS's q931 hexdump into wiresharks pcap format. Wireshark should be able to decode it :) http://wiki.wireshark.org/Q.931
Maybe it's a good idea to implement a wireshark export for those messages in FS. This will make debugging easy and cheap.
Hope it helps a bit.
regards helmut
Am 15.01.2009 12:06, schrieb Peter P GMX:
Helmut,
can you give me a hint, how you worked around this?
Best regards Peter
Helmut Kuper schrieb:
Hi Michael,
it must not be the case here, but I had the same error, when incomming calles used a wrong numbering plan resp not the one, FS expected.
Just a hint.
regards Helmut
Am 15.01.2009 09:20, schrieb Peter P GMX:
Hello Michael, how much $$ are we talking about? I need this issue to be solved
quickly
and it's worth to spend some money. I've read the following post:
http://www.mail-archive.com/freeswitch-users@lists.freeswitch.org/msg05792.h...
and have the same symptom with "after hundreds of calls I start to
get b
channels that are stuck in states like "TERMINATING" or "HANGUP"" Best regards Peter Michael Collins schrieb:
>> I believe these are all symptoms of something that Stefan is working >> on: better Q931 timers. It's been on the todo list for some time but >> we've had absolutely NOBODY willing to pony up serious $$ to support >> OpenZAP development which means it is progressing at the speed of >> developers' free time. >> >> -MC >>
Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Hello Michael, thanks for your response. We have now decided (although this is not the best solution) to put an Asterisk in front of FS who handles the Zap stuff and passes it via SIP to freeswitch. That way we got a stable zap configuration and the benefits of freeswitch, although our IVR application is now respoinding a bit slowly. I also do not have any developer with these skills in sight for fixing these issues. Anyway I hope that we will overcome these zap problems soon so that we can cme back to a pure FS installation. Best regards Peter Michael Collins schrieb:
Peter,
I believe we are in a bit of a holding pattern right now with OpenZAP PRI stuff. We have a super user, Stefan, who is working on some Q931 timers and such but he is working on it in spare time and there's no hard date. If you know someone with serious PRI and C programming skillz who can assist then we'd definitely be willing to have some help. "Patches welcome" as it were. :)
Thanks, MC
On Thu, Jan 15, 2009 at 12:12 PM, Peter P GMX <Prometheus001@gmx.net> wrote:
I did some more tests. When I sequentially setup calls (only one simultaneous call at a time), it works for hundreds of calls. As soon as I setup 2 calls in parallel ist fails aber a number of calls.
Please find another debug ouput (now with Q.921 debug also). The log starts with the latest hangup of a successfull call. After this one I receive a "2009-01-15 20:26:46 [CRIT] ozmod_isdn.c:446 zap_isdn_931_34() Received Release with no matching channel 0" and later "2009-01-15 20:26:46 [DEBUG] ozmod_isdn.c:781 zap_isdn_921_23() 931 parse error [-3012] [Q931E_INVALID_CRV]"
Is there anyone to fix it? May I donate some money for fixing that?
Best regards Peter
Debug: 2009-01-15 20:26:44 [DEBUG] Span:0 Q.921() Sending frame ----------------- Q.921 Packet [Outgoing] --------------- SAPI: 0, TEI: 0, C/R: Command (0)
Type: S Frame, SV: RR (Receive Ready) P/F: 0, N(R): 81 [V(A): 80, V(R): 81, V(S): 80]
Q.921 state: "Multiple Frame Mode Established" (7) [flags: ----] ----------------------------------------------
2009-01-15 20:26:44 [DEBUG] ozmod_isdn.c:813 state_advance() 2:3 STATE [TERMINATING] 2009-01-15 20:26:44 [DEBUG] ozmod_isdn.c:1121 state_advance() Terminating: Direction Inbound 2009-01-15 20:26:44 [DEBUG] mod_openzap.c:1418 on_clear_channel_signal() got clear channel sig [STOP] 2009-01-15 20:26:44 [NOTICE] mod_openzap.c:1437 on_clear_channel_signal() Hangup OpenZAP/2:3/21658519 [CS_EXECUTE] [NORMAL_CLEARING] 2009-01-15 20:26:44 [DEBUG] switch_channel.c:1513 switch_channel_perform_hangup() Send signal OpenZAP/2:3/21658519 [KILL] 2009-01-15 20:26:44 [DEBUG] switch_core_session.c:807 switch_core_session_signal_state_change() Send signal OpenZAP/2:3/21658519 [BREAK] 2009-01-15 20:26:44 [DEBUG] Span:0 Q.931() Receiving message from Layer4 (size: 184, type: 77) 2009-01-15 20:26:44 [DEBUG] Span:0 Q.931() Sending message to Q.921 (size: 184) 2009-01-15 20:26:44 [DEBUG] Span:0 Q.931() Creating Q.931 Message Header: ProtDisc 8 (0x8), CRV 126 (0x7e), CRVflag: 1 (0x1), MesType: 77 (0x4d) 2009-01-15 20:26:44 [DEBUG] ozmod_isdn.c:1529 q931_rx_32() WRITE 5 -------------------------------------------------------------------------------- [08 02 80 7e 4d]
2009-01-15 20:26:44 [DEBUG] Span:0 Q.921() Got frame from Q.931, type: 4, tei: 0, size: 9 2009-01-15 20:26:44 [DEBUG] Span:0 Q.921() Enqueueing I frame for TEI 0 [0] 2009-01-15 20:26:44 [DEBUG] Span:0 Q.921() Sending frame ----------------- Q.921 Packet [Outgoing] --------------- SAPI: 0, TEI: 0, C/R: Command (0)
Type: I Frame P/F: 0, N(S): 80, N(R): 81 [V(A): 80, V(R): 81, V(S): 80]
Q.921 state: "Multiple Frame Mode Established" (7) [flags: ----] ----------------------------------------------
2009-01-15 20:26:44 [DEBUG] Span:0 Q.921() T200 (timeout: 1000 msecs) started for TEI 0 2009-01-15 20:26:44 [DEBUG] Span:0 Q.921() T203 stopped for TEI 0 2009-01-15 20:26:44 [DEBUG] Span:0 Q.931() Q931Rx43 return code: 1 2009-01-15 20:26:44 [DEBUG] mod_event_socket.c:1922 listener_run() Session complete, waiting for children 2009-01-15 20:26:44 [DEBUG] mod_event_socket.c:1946 listener_run() Connection Closed 2009-01-15 20:26:44 [DEBUG] switch_ivr_play_say.c:1222 switch_ivr_play_file() done playing file 2009-01-15 20:26:44 [DEBUG] switch_core_state_machine.c:454 switch_core_session_run() (OpenZAP/2:3/21658519) State EXECUTE going to sleep 2009-01-15 20:26:44 [DEBUG] switch_core_state_machine.c:379 switch_core_session_run() (OpenZAP/2:3/21658519) Running State Change CS_HANGUP 2009-01-15 20:26:44 [DEBUG] switch_core_state_machine.c:410 switch_core_session_run() (OpenZAP/2:3/21658519) State HANGUP 2009-01-15 20:26:44 [DEBUG] mod_openzap.c:472 channel_on_hangup() OpenZAP/2:3/21658519 CHANNEL HANGUP 2009-01-15 20:26:44 [DEBUG] switch_core_state_machine.c:46 switch_core_standard_on_hangup() OpenZAP/2:3/21658519 Standard HANGUP, cause: NORMAL_CLEARING 2009-01-15 20:26:44 [DEBUG] switch_core_state_machine.c:410 switch_core_session_run() (OpenZAP/2:3/21658519) State HANGUP going to sleep 2009-01-15 20:26:44 [DEBUG] switch_core_session.c:939 switch_core_session_thread() Session 251 (OpenZAP/2:3/21658519) Locked, Waiting on external entities 2009-01-15 20:26:44 [NOTICE] switch_core_session.c:957 switch_core_session_thread() Session 251 (OpenZAP/2:3/21658519) Ended 2009-01-15 20:26:44 [NOTICE] switch_core_session.c:959 switch_core_session_thread() Close Channel OpenZAP/2:3/21658519 [CS_HANGUP] 2009-01-15 20:26:44 [DEBUG] Span:0 Q.921() New packet received (4 bytes) ----------------- Q.921 Packet [Incoming] --------------- SAPI: 0, TEI: 0, C/R: Response (0)
Type: S Frame, SV: RR (Receive Ready) P/F: 0, N(R): 81 [V(A): 80, V(R): 81, V(S): 81]
Q.921 state: "Multiple Frame Mode Established" (7) [flags: ----] ----------------------------------------------
2009-01-15 20:26:44 [DEBUG] Span:0 Q.921() T200 stopped for TEI 0 2009-01-15 20:26:44 [DEBUG] Span:0 Q.921() T203 (timeout: 10000 msecs) restarted for TEI 0 2009-01-15 20:26:44 [DEBUG] Span:0 Q.921() New packet received (9 bytes) ----------------- Q.921 Packet [Incoming] --------------- SAPI: 0, TEI: 0, C/R: Command (1)
Type: I Frame P/F: 0, N(S): 81, N(R): 81 [V(A): 81, V(R): 81, V(S): 81]
Q.921 state: "Multiple Frame Mode Established" (7) [flags: ----] ----------------------------------------------
2009-01-15 20:26:44 [DEBUG] ozmod_isdn.c:777 zap_isdn_921_23() READ 5 -------------------------------------------------------------------------------- [08 02 00 7e 5a]
2009-01-15 20:26:44 [DEBUG] Span:0 Q.931() Received message from Q.921 (ind 4, tei 0, size 9) MesType: 90, CRVFlag 0 (Originator), CRV 126 (Dialect: 0) 2009-01-15 20:26:44 [DEBUG] Span:0 Q.931() Sending message to Layer4 (size: 103) 2009-01-15 20:26:44 [DEBUG] ozmod_isdn.c:320 zap_isdn_931_34() Yay I got an event! Type:[5a] Size:[103] CRV: 126 (0x7e, CTX: Originator) 2009-01-15 20:26:44 [DEBUG] ozmod_isdn.c:352 zap_isdn_931_34() zchan e0020270 (2:3) source isdn_data->channels_remote_crv[0x7e] 2009-01-15 20:26:44 [DEBUG] ozmod_isdn.c:418 zap_isdn_931_34() Changing state on 2:3 from TERMINATING to DOWN 2009-01-15 20:26:44 [DEBUG] Span:0 Q.921() Sending frame ----------------- Q.921 Packet [Outgoing] --------------- SAPI: 0, TEI: 0, C/R: Response (1)
Type: S Frame, SV: RR (Receive Ready) P/F: 0, N(R): 82 [V(A): 81, V(R): 82, V(S): 81]
Q.921 state: "Multiple Frame Mode Established" (7) [flags: ----] ----------------------------------------------
2009-01-15 20:26:44 [DEBUG] Span:0 Q.921() T200 stopped for TEI 0 2009-01-15 20:26:44 [DEBUG] Span:0 Q.921() T203 (timeout: 10000 msecs) restarted for TEI 0 2009-01-15 20:26:44 [DEBUG] Span:0 Q.921() Sending frame ----------------- Q.921 Packet [Outgoing] --------------- SAPI: 0, TEI: 0, C/R: Command (0)
Type: S Frame, SV: RR (Receive Ready) P/F: 0, N(R): 82 [V(A): 81, V(R): 82, V(S): 81]
Q.921 state: "Multiple Frame Mode Established" (7) [flags: ----] ----------------------------------------------
2009-01-15 20:26:44 [DEBUG] ozmod_isdn.c:813 state_advance() 2:3 STATE [DOWN] 2009-01-15 20:26:44 [DEBUG] zap_io.c:1125 zap_channel_done() channel done 2:3 2009-01-15 20:26:46 [DEBUG] Span:0 Q.921() New packet received (16 bytes) ----------------- Q.921 Packet [Incoming] --------------- SAPI: 0, TEI: 0, C/R: Command (1)
Type: I Frame P/F: 0, N(S): 82, N(R): 81 [V(A): 81, V(R): 82, V(S): 81]
Q.921 state: "Multiple Frame Mode Established" (7) [flags: ----] ----------------------------------------------
2009-01-15 20:26:46 [DEBUG] ozmod_isdn.c:777 zap_isdn_921_23() READ 12 -------------------------------------------------------------------------------- [08 02 00 7d 4d 08 05 82 e6 33 30 33]
2009-01-15 20:26:46 [DEBUG] Span:0 Q.931() Received message from Q.921 (ind 4, tei 0, size 16) MesType: 77, CRVFlag 0 (Originator), CRV 125 (Dialect: 0) 2009-01-15 20:26:46 [DEBUG] Span:0 Q.931() Sending message to Layer4 (size: 110) 2009-01-15 20:26:46 [DEBUG] ozmod_isdn.c:320 zap_isdn_931_34() Yay I got an event! Type:[4d] Size:[110] CRV: 125 (0x7d, CTX: Originator) 2009-01-15 20:26:46 [DEBUG] ozmod_isdn.c:352 zap_isdn_931_34() zchan 0 (-1:-1) source isdn_data->channels_remote_crv[0x7d] 2009-01-15 20:26:46 [CRIT] ozmod_isdn.c:446 zap_isdn_931_34() Received Release with no matching channel 0 2009-01-15 20:26:46 [DEBUG] Span:0 Q.931() Sending message to Q.921 (size: 110) 2009-01-15 20:26:46 [DEBUG] Span:0 Q.931() Creating Q.931 Message Header: ProtDisc 8 (0x8), CRV 125 (0x7d), CRVflag: 1 (0x1), MesType: 90 (0x5a) 2009-01-15 20:26:46 [DEBUG] ozmod_isdn.c:781 zap_isdn_921_23() 931 parse error [-3012] [Q931E_INVALID_CRV] 2009-01-15 20:26:46 [DEBUG] Span:0 Q.921() Sending frame ----------------- Q.921 Packet [Outgoing] --------------- SAPI: 0, TEI: 0, C/R: Response (1)
Type: S Frame, SV: RR (Receive Ready) P/F: 0, N(R): 83 [V(A): 81, V(R): 83, V(S): 81]
Q.921 state: "Multiple Frame Mode Established" (7) [flags: ----] ----------------------------------------------
2009-01-15 20:26:46 [DEBUG] Span:0 Q.921() T200 stopped for TEI 0 2009-01-15 20:26:46 [DEBUG] Span:0 Q.921() T203 (timeout: 10000 msecs) restarted for TEI 0 2009-01-15 20:26:46 [DEBUG] Span:0 Q.921() Sending frame ----------------- Q.921 Packet [Outgoing] --------------- SAPI: 0, TEI: 0, C/R: Command (0)
Type: S Frame, SV: RR (Receive Ready) P/F: 0, N(R): 83 [V(A): 81, V(R): 83, V(S): 81]
Q.921 state: "Multiple Frame Mode Established" (7) [flags: ----] ----------------------------------------------
Peter P GMX schrieb:
Thanks Helmut,
I cross-checked with our provider. They use national numbering plan for our lines. So this didn't solve our problem. I also ensured that the local language is DE and ZAP timing is dedicated to span 1.
I changed the configs to debug mode for OpenZAP, so I hopefully will get some more info on the next failure.
Best regards Peter
Helmut Kuper schrieb:
Hi Peter,
it was simply a change in our TDM Voice Switch. It used a different numbering plan and we changed it to "national" to get it work with FS and openzap in Q921/Q931 mode.
What I still search is a way to configure the numberplan in FS.
To make it clear: In my case it didn't work from the second FS starts up. So this differs from your problem.
To get an idea what's going on on the TDM link I used a TDM D-Channel monitoring device and traced the d-channel messages exchanged between FS and TDM. That should make it easier to see what's wrong when the problems occur. But you can also increase FS debug level to debug and trace the Q921 and Q931 messages in FS console via fs_cli during runtime. You have to set this in openzap.conf.xml:
<param name="q921loglevel" value="debug"/> <param name="q931loglevel" value="debug"/>
Unfortunately FS doesn't decode the whole Q931 messages, but it shows a hex representation of the message, so you can manually decode it with this documents:
Q.931: http://www.itu.int/rec/T-REC-Q.931-199805-I/en Q.921: http://www.itu.int/rec/T-REC-Q.921-199709-I/en
I think for numberingplan issues you only have to track the Q.931 messages.
The last idea I have to get some light into your problem and to avoid manually decoding, try to convert FS's q931 hexdump into wiresharks pcap format. Wireshark should be able to decode it :) http://wiki.wireshark.org/Q.931
Maybe it's a good idea to implement a wireshark export for those messages in FS. This will make debugging easy and cheap.
Hope it helps a bit.
regards helmut
Am 15.01.2009 12:06, schrieb Peter P GMX:
Helmut,
can you give me a hint, how you worked around this?
Best regards Peter
Helmut Kuper schrieb:
Hi Michael,
it must not be the case here, but I had the same error, when incomming calles used a wrong numbering plan resp not the one, FS expected.
Just a hint.
regards Helmut
Am 15.01.2009 09:20, schrieb Peter P GMX:
> Hello Michael, > how much $$ are we talking about? I need this issue to be solved > > quickly
> and it's worth to spend some money. > I've read the following post: > > http://www.mail-archive.com/freeswitch-users@lists.freeswitch.org/msg05792.h...
> and have the same symptom with "after hundreds of calls I start to > > get b
> channels that are stuck in states like "TERMINATING" or "HANGUP"" > Best regards > Peter > Michael Collins schrieb: > > >>> I believe these are all symptoms of something that Stefan is working >>> on: better Q931 timers. It's been on the todo list for some time but >>> we've had absolutely NOBODY willing to pony up serious $$ to support >>> OpenZAP development which means it is progressing at the speed of >>> developers' free time. >>> >>> -MC >>> >>>
Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Your company could always sponsor some of the time and effort to improve OpenZAP to meet your needs. Its also a good way to give back to the project. /b On Jan 19, 2009, at 1:09 PM, Peter P GMX wrote:
I also do not have any developer with these skills in sight for fixing these issues. Anyway I hope that we will overcome these zap problems soon so that we can cme back to a pure FS installation.
Best regards Peter
On Mon, Jan 19, 2009 at 11:16 AM, Brian West <brian@freeswitch.org> wrote:
Your company could always sponsor some of the time and effort to improve OpenZAP to meet your needs. Its also a good way to give back to the project.
In this case you'd want to contact the FreeSWITCH team directly at consulting@freeswitch.org so that you could talk specifics. -MC
/b
On Jan 19, 2009, at 1:09 PM, Peter P GMX wrote:
I also do not have any developer with these skills in sight for fixing these issues. Anyway I hope that we will overcome these zap problems soon so that we can cme back to a pure FS installation.
Best regards Peter
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
participants (4)
-
Brian West
-
Helmut Kuper
-
Michael Collins
-
Peter P GMX