Vodia PBX

It searched for the occurance of "j" anywhere in the text. Maybe you get too many results, and the real Johnsons are already too far down in the list. J* does not work, there is no pattern matching here. Just case-insensitive text search...

It would not help. If these devices share the same Call-ID there will be a lot of confusion anyway. If a device chooses a non-random Call-ID, even appending the local IP address will not really help and just make the confusion bigger. If another client has the same IP address pool (typically 192.168.0.x), then the probability of a conflict is lower, but not zero and it just makes it even harder to find the problem. The PBX writes log messages and even sends out emails when such IP address conflict (they look like changes) occur. This thread shows the gravity of that message.

That message just says that for an incoming INVITE, it could not match it to a trunk; but it will probably come from an extension so that is perfectly okay.

You can just put it into the tftp folder and then you can use the PnP parameters for the snom firmware. Just put the filename in there and it should provision the local firmware in the tftp directory.

Right now conference.txt looks like this: SUBJECT:{lng subject1}{ssi variable name}{lng subject2} SUMMARY:{lng summary1}{ssi variable name}{lng summary2} DESCRIPTION:{lng description1}{ssi variable pin}{lng description2}{ssi variable room}{lng description3} LOCATION:{lng location1}{ssi variable number}{lng location2} You can just copy this into the file html/conference.txt and edit it as you like. However, keep the headers and keep the line breaks so that the PBX can extract the right information.

Could be a simple phone problem. It should try again after getting challenged. Try http://dms.snom.com, username "beta", password "beta".

Was missing; we'll add it soon.

No, we just wanted to avoid displaying potentially 100000 entries on one web page. You need to narrow your search, then it will display those entries in chunks of the first 10/20/50 results. Paging does not really help because the PBX then needs to keep the result set internally.

Now you know why they are so successful! They did their marketing homework. IT decision makers can be like children. Sound is very important, especially in the lower frequencies (when the decision makers get old). Maybe try to open the box! Check if you find the speaker!!!

AFAIK the Grandstream ATA support it.

Okay, seems like we cannot blame the ITSP this time. We are currently investigating if there is a difference between the Windows and Linux abstraction for locking. Seems that Windows works better, and we need to have the same behavior in Linux as well. Let us know if you want to be the ginuea pig and try it out on the MAC.

Did anybody ever try Pacemaker and Corosync? Seems this is a newer project that heatbeat.

Well right now the only way to do this is to use the MAC address in the file. You can use the files from the "generated" directory as template and copy them into the tftp directory. But you probably have to rename them so that the MAC is included. Check out the root file (snom_300.xml), there you can give the snom_300_custom.xml file a special name (e.g. snom_300_extension_123.xml) and leave the other names as they are, they will still be automatically generated.

Did you see https://www.pbxnsipsupport.com/index.php?_m...kbarticleid=329? Maybe we should put more examples there. The good news is that the simple patterns seem to cover most of the regular cases. The number of tickets that are related to the dial plan really went down compared to the time when pbxnsip has only extended regular expression patterns in the dial plan!

Well, this is a standard Linux distribution. You can run dhcpd there like on any other Linux distribution. We even compiled the toolchain natively on the system. No cross compilation! That was very cool. You feel like home if you know Debian. The gotcha is it is an embedded system. When the memory is full, that's it. Also I think we had the wrong file system in the beginning (jffs2), it went completely belly up and we had to move on to the next device. Fortunately, they don't break the bank! The form factor is also debatable. Make sure the cleaning personnel does not mistake it as an abandoned power brick and plugs it out in the morning. We are a little bit afraid people might think that "affordable" hardware means that the software running there is cheap trash. Most people feel more comfortable with 19" racks that make a lot of noise. So maybe we should get an empty 19" box, put one of these devices inside plus a speaker that produces the noise patterns and sell it for 3000 bucks. I want to see their face when they open the 19" up!

The problem with talking to the SQL servers of the world is that they all have their little dirty login mechanisms, way of stating the SQL statements etc. I thought it would be an ASCII-based protocol such as SMTP or POP3; but seems that was a mistake. You have to implement the whole history of mySQL versions with all their little changes in the protocol. So we are back to SOAP and Email.

I guess you mean "1xx" to "sip:\*1\1@\r;user=phone;line=2"

Why don't you use a ACD for this? Hunt groups are pretty simple and so is their feature set.

Well... Maybe the service provider has a small "window"... It is not so unusualy that SIP trunks go down for some time. Logging shows the inconvenient truth! I doubt that it depends on Mac or Windows.

That is nonsense. Right now (version 3) you can have only ringback.wav; you can load your own ringback file in the file system, but then all other ringback will also sound like that. In version 4 we are adding the possibility to have ringback WAV files per account, which includes the hunt group. No extra license cost for this.

Well, yes and no... The way the subscription is handled was changed; and it might have not been such an obvious problem before. The problem was that the phone subscribe for a list of dialog events, and the PBX now answers with "sorry no, but try again in one hour". The phones try again after three seconds (maxbe a unit problem, s vs. ms). We had other installations where this problem was fixed in version 3.5. In this version we answer, "okay" but send a empty list. That slows down the traffic significantly. BTW it should be very easy to see in the traces (or Wireshark) if there is a subscription storm. We should look at a Wireshark tracve anyway to see what is going on there.

Well, there is a lot of buggy RFC4733 implementation out there, that's for sure. Packet loss should not cause any double-digit detection there, out of band is very robust against packet loss. Usually the problem comes from "DTMF transcoding". Especially when using TDM lines, someone has to translate inband into out of band that usually leaves a small detection ap on the edges where there is still inband DTMF. ---------IIIIIOOOOOOOOOOOOOOOOOOOOOOOOOOOIIII------------------- (try to read it aloud) The whole thing is a tricky topic. I remember we had a discussion years before and the conclusion was that the conversion from inband to out of band should be avoided whenever possible. I think that was the point when we added inband detection to the PBX.

Definitevely. Oh, please use lower-case x, I think upper-case is not recognized (we'll fix that later). In the replacement where ypu put the user=phone, you can also put a parameter called "line" (e.g. line=2). This will tell the gateway which line to use.

Maybe they are reading this forum...

Arghh.. Well, I think the SIP INFO pass-through is supported... If you phone sends it it might actally get through. The "transcoding" from media DTMF to signalling DTMF is not supported.