Happy

In addendum log-file, I did log to a file directly, so nothing will be purged.

I can't pick up the INVITE. Log settings : general logging sip events at log level 0/ log all sip events. Is it something in the log settings ?

The whole thing in attachment Log Ivr Empty Call Full.txt

Must still be a bug somewhere in the code. Dial plan still locks up after a day or so.

All incoming calls come from a Patton Gateway BRI. Seems correct to me that the Gateway sends a BYE to the PBX when someone hang up the line. This needs some explanation, it looks logic to me that pbxnsip ends the call after a BYE from the gateway for whatever reason there might be. But it isn't happening ... Can I provide you with a better logfile to get a better understanding of what is going on. What log settings do you suggest ? It would be a great relief to get this thing fixed ...

I'm adding a logfile to this post. The anonymus call came from a cellphone. Connection was terminated while the Ivr-Message was still playing. Call got through anyway. I took the (empty) call on extension Bureel. Log IVR Empty Call.txt

Hangup occurs from any line, analog, isdn or cellphone. Don't know about the BYE. I have to log a test for that. I'll check it out.

OS : WinXp Pbxnsip version 4.2.0.3966 (Win32) It would be nice to have that version.

Situation: Ivr directly answering the phone, if user is pressing <1> or just remains on the line, HG connects call to extensions or to external line. Ivr Dtmf List : !1!95! !E!95! ![^1]!-! Problem: When user hangs up the phone while the Ivr is playing, very often the 'empty' call is put through, as well to the extensions as to external line. Is there a way to avoid this behaviour, because is is very annoying to get the empty calls. We don't want to change the dtmf list so that user is only connected when he makes the right choice.

Indeed there must be a bug : same problem occurs again every now and then. Until now, a simple restart of the service clears the co-lines.

If you still have configuration problems with the patton 4554, I could upload my config file to you. Firmware version 5.2.

Just created the same co-lines on the trunks, everything works fine. Many thanks for the support, would never have found this one without your input !

Removing the country code did not solve the problem. However .. removing all CO lines did ! Now next question : can I just put the CO lines back ? Is it better to first set the index.txt file to 1 in the colines directory ? Marc.

I' m using 6 CO-lines, 2 on the Belgacom trunk and 4 on the Weepee trunk. These entries are in the \colines directory. Every xml-file contains a #text field referring to one of the trunks. No user info there. I did a restart, things remain the same. Log info exactly as before. If you think that Co lines are the culpit, I could of course remove them all and see what I'm getting. Does that make any sense to do ? Best Regards, Marc

'-' is not accepted in the area code field, has to be a number. But anyway, problem is the same wether I use the country code or not. This is a small portion of the log file, first with just the number, next one with a 1 before the tel.number. Looks to me the dialplan skips all options and doesn't find a match, though it definitely should match ! ----------Log ------------- [8] Call from an user 19 [8] To is <sip:0495******@pbx.praktijk.be;user=phone>, user 0, domain 1 [8] From user 19 [8] Call state for call object 703: idle [9] Dialplan: Evaluating !^0([0-9]*)@.*!sip:0\1@\r;user=phone!i against 0495******@pbx.praktijk.be [5] Dialplan "Algemeen Kiesplan": Match 0495******@pbx.praktijk.be to <sip:0495******@ssw0.brussels.weepee.org;user=phone> on trunk WeePee [8] Call state for call object 703: alerting ******************* [8] Call from an user 19 [8] To is <sip:10495******@pbx.praktijk.be;user=phone>, user 0, domain 1 [8] From user 19 [8] Call state for call object 704: idle [9] Dialplan: Evaluating !^0([0-9]*)@.*!sip:0\1@\r;user=phone!i against 10495******@pbx.praktijk.be [9] Last message repeated 2 times [9] Dialplan: Evaluating !^1([0-9]*)@.*!sip:\1@\r;user=phone!i against 10495******@pbx.praktijk.be [9] Dialplan: Evaluating !^2([0-9]*)@.*!sip:\1@\r;user=phone!i against 10495******@pbx.praktijk.be [9] Dialplan: Evaluating !^329909([0-9]*)@.*!sip:329909\1@\r;user=phone!i against 10495******@pbx.praktijk.be ------------End Log ---------

There are several interesting facts in your answer : 1. <<your answer 'You can try to use the area code "-" to suppress this message. Then the PBX will convert it into something like +3220495****** (for Belgium). Then in the dial plan you would have to match 00322* instead of 2*'>> Means that pbxnsip is doing the number comversion (according to country code and area code) BEFORE the number reaches the dial plan. That is of cause very inconvenient and quite unpractical to work with. Because all Belgian numbers start with 0, I can use prefixes like 1 or 2 to go to a specific trunk. But if the 1 and 2 get mixed up in a general format before they reach the dial plan, the starting 0 is filtered out and I can't distinguish between the prefix 1 and a normal number starting with 01. That means I'll have to use something like a star code #111# to send numbers to a specific trunk. Is it possible to give this code after the number also ? 2. I followed the wiki instructions to get a sip trace, but I did not manage to see the actual conversion of the number before it reaches the dialplan. Maybe I'm missing something here. In addendum the complete sip trace like I managed to make it. Are my log settings incomplete ? 3. When does the trunk number modifications (rewrite general number) take place : they should at least be after the dial plan conversions ?? Log Ipness.txt

Checked out some more and made a sip-log of the problem : -----Log Partim ------- [7] 2010/12/10 12:50:25: Cannot convert number 20495****** into global format [7] 2010/12/10 12:50:25: Last message repeated 4 times [7] 2010/12/10 12:50:25: SIP Tx tls:192.168.1.22:2344: SIP/2.0 100 Trying Via: SIP/2.0/TLS 192.168.1.22:2344;branch=z9hG4bK-x5f790s0efyx;rport=2344 From: "Bureel" <sip:12@pbx.praktijk.be>;tag=tada1u8hqo To: <sip:20495******@pbx.praktijk.be;user=phone>;tag=b209a129e7 Call-ID: 3c26a7c1696f-75gxn6gfe3d9 CSeq: 1 INVITE Content-Length: 0 ----------------------- Dial Plan : Pattern = 2* | Replacement = * | Trunk = Ipness ----------------------- So the number 20495****** should be going to trunk Ipness AND be stripped to 0495******. Looks to me even the trunk is not found ?? Number - unstripped - is handled to ??? Marc

Indeed, it is a matter of patience. Stays however slow, also when something changes to the state of the extensions. Outlook import is not working for me either. So not very usefull at the time, but a very promising tool when it ever comes to maturity.

Hi, Pbxnsip Latest version / Pac logged on extension 12 (simultanious with Snom 320 phone) Watch following accounts (on extension 12) gives a list of several extensions to watch. The extension screen of the PAC though is empty ... Am I missing something here ?? Best regards, Marc

I ran some tests, but did not come to a solution anyway : 1. Created new expression in dialplan (4* replaced by *, and the standard trunk : works fine 2. Same dialplan expression, with the trunks that were not working : a 'not found : number'. 3. Deleted one of the trunks and build it up again : just a 'not found' on the display, no comfort noise. One of the trunks that are not working is a patton gateway, the other one is a Ipness Sip account. The 2 accounts working are Weepee Sip accounts. I did check the subdirectories trunks, dial_plan and dial_plan_entry. There were no abnormalities. Well I'm stuck here. Hope support comes up with some ideas. Marc

Strange thing is : when I go back to verion 3, just by changing the pbxctl.exe file, the dialplan works again. What do you suggest me to do, the dialplan just seems to skip the right trunk. Reinstall some things here ? Or look into the trunks or dialplan directory for anomalies ? Any suggestions highly appreciated !

I have a dial plan where the numbers starting with 1 and 2 go to a specific trunk : type pattern 1* // replacement *. It looks like these 2 are not well handled by the dial plan, the respective trunks seem not to be found (see the log below). This was not the case in version 3, I don't see why, but you probably do. ----Log file--- [8] 2010/11/25 20:39:59: Could not find a trunk (4 trunks) [6] 2010/11/25 20:39:59: Received bindRequest for user pbx.praktijk.be\12 [6] 2010/11/25 20:40:03: Received searchRequest, cn= [8] 2010/11/25 20:40:04: Could not find a trunk (4 trunks) [7] 2010/11/25 20:40:04: Set packet length to 20 [6] 2010/11/25 20:40:04: Sending RTP for 3c29221ee5dc-azxfh9mboreo to 192.168.1.22:59164, codec not set yet [8] 2010/11/25 20:40:04: Call from an user 12 [8] 2010/11/25 20:40:04: To is <sip:10495123456@pbx.praktijk.be;user=phone>, user 0, domain 1 [8] 2010/11/25 20:40:04: From user 12 [8] 2010/11/25 20:40:04: Call state for call object 148: idle [7] 2010/11/25 20:40:04: set_codecs: for 3c29221ee5dc-azxfh9mboreo codecs "", codec_preference count 6 [9] 2010/11/25 20:40:04: Dialplan: Evaluating !^0([0-9]*)@.*!sip:0\1@\r;user=phone!i against 10495123456@pbx.praktijk.be [9] 2010/11/25 20:40:04: Last message repeated 2 times [9] 2010/11/25 20:40:04: Dialplan: Evaluating !^1([0-9]*)@.*!sip:\1@\r;user=phone!i against 10495123456@pbx.praktijk.be [9] 2010/11/25 20:40:04: Dialplan: Evaluating !^2([0-9]*)@.*!sip:\1@\r;user=phone!i against 10495123456@pbx.praktijk.be [9] 2010/11/25 20:40:04: Dialplan: Evaluating !^329909([0-9]*)@.*!sip:329909\1@\r;user=phone!i against 10495123456@pbx.praktijk.be [7] 2010/11/25 20:40:04: Set packet length to 20

I'm using country code 32. According to the docs, that should exclude the NANPA and make me use a 'rest of the world' notation with 00 as prefix for international calls. Is there a way in the log-settings to see what number is actually sent to the trunk ? Without the country code, my default trunk won't work correctly either.

Since I upgraded from Pbxnsip version 3 to version 4, it is impossible to force an outgoing call to a specific trunk. When I call out using the default trunk, things go well. But when I call out choosing a specific trunk with a prefix, I'm getting a NOT FOUND : DIALEDNUMBER. Since the same dialplan worked fine for me on version 3, I have no idea where to look for to solve this issue. Hope someone stumbled upon this problem also. Marc.

I upgraded to the version 4.2.0.3966 (Win32). So that should be fixed. Thanks for checking it out.