Happy
-
Posts
97 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Posts posted by Happy
-
-
Still the log starts with the ACK but not the INVITE:
[0] 2011/01/03 08:44:58: SIP Rx udp:192.168.1.2:5060:
ACK sip:patton@192.168.1.15:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 192.168.1.2:5060;branch=z9hG4bKc5be534e8ef8eee06
Max-Forwards: 70
From: <sip:anonymous@192.168.1.2:5060>;tag=d9a4a13a83
To: <sip:01158****@192.168.1.15:5060>;tag=c211bdee78
Call-ID: dd8a0982e3e2df15
CSeq: 1065 ACK
User-Agent: Patton SN4552 2BIS EUI 00A0BA053BE6 R5.2 2009-07-09 SIP M5T SIP Stack/4.0.26.26
Content-Length: 0
Then the PBX receives the BYE:
[0] 2011/01/03 08:45:44: SIP Rx udp:192.168.1.2:5060:
BYE sip:patton@192.168.1.15:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 192.168.1.2:5060;branch=z9hG4bK283d7c36279b55e3d
Max-Forwards: 70
From: <sip:anonymous@192.168.1.2:5060>;tag=d9a4a13a83
To: <sip:01158****@192.168.1.15:5060>;tag=c211bdee78
Call-ID: dd8a0982e3e2df15
CSeq: 1066 BYE
User-Agent: Patton SN4552 2BIS EUI 00A0BA053BE6 R5.2 2009-07-09 SIP M5T SIP Stack/4.0.26.26
Content-Length: 0
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 ?
-
Just make the log history longer (or write the log into a file), so that you can see the initial INVITE that has the same Call-ID as the BYE from the gateway. Then we can see all messages that are exchanged between the gateway and the PBX.
The whole thing in attachment
-
http://pbxnsip.com/protect/beta/win32/pbxctrl-4.2.0.3970.exe should take care of this issue.
Must still be a bug somewhere in the code.
Dial plan still locks up after a day or so.
-
what I can see is that the gateway sent a BYE to the PBX
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.
but it could be the problem that for whatever reason the gateway wants the call to disconnect.
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 ...
I cannot see the other messages in this call
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 ...
-
Does the hangup occur from a analog line? Do you see a BYE hitting the PBX?
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.
-
Does the hangup occur from a analog line? Do you see a BYE hitting the PBX?
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.
-
What OS and version (pbxnsip or snom ONE) are you using? we have a version that takes care of the issue.
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.
-
There must be a bug somewhere so that the CO line does not get cleared. Obviously then it never gets cleared again. We also have to investigate in the code; however if it should happen again, it will be a lot faster to fix it...
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.
-
I try to contact the patton support now
If you still have configuration problems with the patton 4554, I could upload my config file to you. Firmware version 5.2.
-
Can I just put the CO lines back ? Is it better to first set the index.txt file to 1 in the colines directory ?
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 !
-
Before removing the CO lines, I would delete the country code setting (under the domain) and try it. While country code setting is useful, it may create issues like this sometimes. In the USA, we set the country code on the domain so that user can either dial 10 digit or 11 digits.
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.
-
Spent some quality time on it...
This must definitevely have to do with CO-lines. Can you check in the directory colines if there are any entries and if yet, if there is one file that contains a paramter "user"? If that is so, please remove that user, restart the system and see if that did a change. Actually a restart should clear the CO line anyway.
That "user" means that this user has seized the line and outbound calls must stick with it. It must be something in this area.
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
-
If you want to use a country code but dont want to use the area code, you can use "-" as the area code.
'-' 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.
On log level 9 you should see something like "Dialplan: Evaluating so-and-so against so-and-so" (Log IVR events).
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 ??
-
Well, this one should work! There is something fishy here. Maybe some "invisible" characters here like a space?
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
-
for me i thought it was no going to show...then several minutes later it started to! ;-(
appears very slow.
WAC needs work from my experience. will be incredible when features work.
ps- i see i made a suggestion on this:
http://snomone.ideascale.com/a/dtd/WAC---Web-Attendent-console-should-be-completed/91174-11275
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
-
Well, this one should work! There is something fishy here. Maybe some "invisible" characters here like a space?
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
-
Well, this one should work! There is something fishy here. Maybe some "invisible" characters here like a space?
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 !
-
There is also canonical format for ROW. International numbers (outside of 0032) are represented in 00xxxx format, national numbers in the format 0xxxx. If you set the domain code, you also get numbrs without 0 prefix for local calls. This number is put into the dial plan.
You can see what is fed into the dial plan on log level 9. That is very useful to debug problems like the one that we have here.
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
-
Are you using country codes? If that is the case keep in mind that numbers are always represented in "canonical" format (e.g. NANPA). In plain words, in the USA all numbers will be ten digits. If you dont want it, clear the country code then the dial plan will see what the user has entered.
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.
-
That was from the license server. We have corrected it on the new versions.
I upgraded to the version 4.2.0.3966 (Win32). So that should be fixed. Thanks for checking it out.
Detecting early hangup
in Hunt Group Setup
Posted
In addendum log-file, I did log to a file directly, so nothing will be purged.