Re: [Freeswitch-users] OpenZAP parse error [-3012] [Q931E_INVALID_CRV]

2009-01-19 Thread Michael Collins
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 prometheus...@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]
 

Re: [Freeswitch-users] OpenZAP parse error [-3012] [Q931E_INVALID_CRV]

2009-01-19 Thread Peter P GMX
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 prometheus...@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 

Re: [Freeswitch-users] OpenZAP parse error [-3012] [Q931E_INVALID_CRV]

2009-01-19 Thread Brian West
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


___
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


Re: [Freeswitch-users] OpenZAP parse error [-3012] [Q931E_INVALID_CRV]

2009-01-19 Thread Michael Collins
On Mon, Jan 19, 2009 at 11:16 AM, Brian West br...@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
consult...@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


___
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


Re: [Freeswitch-users] OpenZAP parse error [-3012] [Q931E_INVALID_CRV]

2009-01-15 Thread 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.html
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 prometheus...@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

   

___
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


Re: [Freeswitch-users] OpenZAP parse error [-3012] [Q931E_INVALID_CRV]

2009-01-15 Thread Helmut Kuper
-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.html
 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-

___
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


Re: [Freeswitch-users] OpenZAP parse error [-3012] [Q931E_INVALID_CRV]

2009-01-15 Thread 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.html
  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


Re: [Freeswitch-users] OpenZAP parse error [-3012] [Q931E_INVALID_CRV]

2009-01-15 Thread Helmut Kuper
-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.html
 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-

___
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


Re: [Freeswitch-users] OpenZAP parse error [-3012] [Q931E_INVALID_CRV]

2009-01-15 Thread Peter P GMX
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.html
  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


Re: [Freeswitch-users] OpenZAP parse error [-3012] [Q931E_INVALID_CRV]

2009-01-15 Thread Peter P GMX
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: 1 msecs)
restarted for TEI 0
2009-01-15 

[Freeswitch-users] OpenZAP parse error [-3012] [Q931E_INVALID_CRV]

2009-01-14 Thread Peter P GMX
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


Re: [Freeswitch-users] OpenZAP parse error [-3012] [Q931E_INVALID_CRV]

2009-01-14 Thread Peter P GMX
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

   

___
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


Re: [Freeswitch-users] OpenZAP parse error [-3012] [Q931E_INVALID_CRV]

2009-01-14 Thread Michael Collins
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 prometheus...@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