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