Vodia PBX

snom ONE blue supports five domains and they may legally not be used in hosted environments. The other editions only support only one domain. Yes, thirds parties not made by snom. This is a common model and this is because of the support issues (ping-pong with other vendors) when something goes wrong and the subsidized pricing for snom ONE.

AFAIK only Sangoma tried to make a USB to FXO adapter yet. It seems to be very problematic because USB does support a syncronous mode; however this is a non-mainstream mode in the USB driver and therefore difficult to get working. The problem is the driver, not the hardware. Thats why everybody stays with PCI or stand-alone FXO gateways where you have full control over everything (even analog problems like noise).

We added service flags in the dial plan already; but AFAIK there is not released image available for this yet.

Version 4 has the huge advantage that it automatically black list IP addresses that try to hack the system. This is a tremendeous advantage for hosted systems that offer service to all the public Internet. For example, call drops might have happened because the system was under attack at this time and you might not even really know about it. I would set up a test system first with a couple of friendly users. Then you get a better feeling if version 4 is ready for you or not.

It depends on the license type for snom ONE. When using the free edition for example, you can register only two third-party devices.

Right. We have seen cases where a cheap router went belly up with so many connections (just a few weeks ago again). For NAT this is in theory no problem, but the product quality is important here. If you buy a professional router it should be no problem. NAT can have up to 65000 ports.

It seems that the call terminates after the phone puts the call on hold after 540-13=527 seconds and then sends a REFER: REFER sip:147@62.205.34.2:5060;transport=tcp SIP/2.0 Via: SIP/2.0/TCP 192.168.1.23:5062;branch=z9hG4bK675160821 From: "2113110124" <sip:302113110124@62.205.34.2;user=phone>;tag=943082977 To: <sip:00302831028982@62.205.34.19;user=phone>;tag=921271490 Call-ID: [email="804d25e5@pbx"]804d25e5@pbx[/email] CSeq: 30106 REFER Contact: <sip:147@192.168.1.23:5062;transport=TCP> Max-Forwards: 70 User-Agent: Yealink SIP-T20P 9.50.0.50 Refer-To: <sip:123@112467.z1.vpbx.gr> Referred-By: "2113110124" <sip:302113110124@62.205.34.2;user=phone> Event: refer Content-Length: 0 The PBX then starts a blind transfer and disconnects that call. That is how it should be. Did the user really transfer the call?

When registered to the PBX, I would forget about the ability in DECT to talk directly. "So what"! Especially when in the LAN, bandwidth cannot be the issue. Ehh. So you mean the m9 should have an internal dial plan that says if you can this and that extension, go there directly? What about CDR then? And what if call recording was enabled or the call gets put on hold and you should hear the music on hold? Barge in? I would say it is easier to run all the stuff through the PBX... The idea was to use LDAP for this. The address book sounds like a simple topic, but the lack of the "one" standard in the real life makes things complicated. LDAP is good if you don't want to replicate the data all the time; just keep everything in a central place; the PBX is just the fallback in this case and you'll have the same address book on your DECT device that you might also have on your desktop device (useful when you have them both registered to the same extension). One of the interesting points about the address book is that it can store images. The m9 supports the photo caller ID ("poor mans video telephony"), and when extensions have their pictures uploaded you can see who is calling you. But thanks to the smart phone, that model of the centralized address book is becoming obsolete these days. Seems that in the future we have to think about synchronizing address books between the devices . Anyway, thats work in progress. Why not!

Just call the extension with the extension number. For example, if you want to ring extension 40, dial "40". For a PBX "intercom" you would have to dial *9040 and have the permission to do that. Many people believe that they have a 1:1 relationship between base station and handset. This is not true. The base station can be more seen like a switch that converts DECT to Ethernet. The base can maintain a registration for each handset. The beauty of this is that handsets are relatively cheap and if budget is really low (and features like address book integration don't count) you can take other dirt cheap DECT handsets and register them with the base as well. No problem. Different scenarios require different solutions. For example, at home you would register two or more handsets with the same SIP account and they will ring on incoming calls at the same time; this is the typical DECT deployment in many many installations. But in a business where you want to be able to control which exact handset is ringing, you probably better give each of them its own SIP identity.

Well the question is what "User-Agent" header the phone presents. If it is a Yealink OEM, it might be something like "Tiptel", then you have to change the entries below: <?xml version="1.0"?> <ringtones> <tone name="custom1"> <vendor ua="Polycom.*">Custom 1</vendor> <vendor ua="Cisco-.*"><Bellcore-dr4></vendor> <vendor><http://127.0.0.1/Bellcore-dr4></vendor> </tone> <tone name="custom2"> <vendor ua="Polycom.*">Custom 2</vendor> <vendor ua="Cisco-.*"><Bellcore-dr4></vendor> <vendor><http://127.0.0.1/Bellcore-dr4></vendor> </tone> <tone name="custom3"> <vendor ua="Polycom.*">Custom 3</vendor> <vendor ua="Cisco-.*"><Bellcore-dr4></vendor> <vendor><http://127.0.0.1/Bellcore-dr4></vendor> </tone> <tone name="custom4"> <vendor ua="Polycom.*">Custom 4</vendor> <vendor ua="Cisco-.*"><Bellcore-dr4></vendor> <vendor><http://127.0.0.1/Bellcore-dr4></vendor> </tone> <tone name="internal" type="internal"> <vendor ua="Polycom.*">Internal</vendor> <vendor ua="Cisco-.*"><Bellcore-dr2></vendor> <vendor ua="Grandstream HT-.*"></vendor> <vendor><http://127.0.0.1/Bellcore-dr2></vendor> </tone> <tone name="external" type="external"> <vendor ua="Polycom.*">External</vendor> <vendor ua="Cisco-.*"><Bellcore-dr3></vendor> <vendor ua="Grandstream HT-.*"></vendor> <vendor><http://127.0.0.1/Bellcore-dr3></vendor> </tone> <tone name="intercom" type="intercom"> <vendor ua="Polycom.*">Auto Answer</vendor> <vendor ua="Cisco-.*" type="call-info">auto-answer=0</vendor> <vendor ua="optiPoint .*" type="call-info">auto-answer=0</vendor> <vendor ua="snom.*" type="call-info"><{from-uri}>;answer-after=0</vendor> <vendor ua="Linksys.*" type="call-info"><{from-uri}>;answer-after=0</vendor> <vendor ua="Aastra.*" type="call-info"><{from-uri}>;answer-after=0</vendor> <vendor ua="Yealink.*" type="call-info"><{from-uri}>;answer-after=0</vendor> <vendor type="answer-mode">Auto</vendor> </tone> </ringtones>

The word "intercom" is used in different ways. In the snom ONE PBX world it means "call an extension and have it pick up immediately in handsfree mode". In the snom m9 world, it means "call another handset on DECT without bothering the SIP world (but have the handset ring)". The m9 model is that every handset is a different extension. The users don't have to know that it all runs on the same base station. I would keep it this way, if you register everyone on the same extension this is pretty chaotic (also the PBX limits the number of registrations per extension by default to 5), and you cannot call from one handset to another except using the "m9 intercom" feature.

Make sure: That you run the PBX on a routable (public) IP address, and make sure the firewall is not intercepting the traffic That the phones are using plug and play. If you dont want to expose the TFTP port on the server, then use HTTP for provisioning. That should be working fine. The PBX will make sure that the SIP registrations are kept alive and that the media will flow both directions.

The 870 has the snom certificate built-in, which makes the whole plug and play experience a lot better. No need for passwords!

Navigate to the admin/certificates web page import the following certificate as server root CA. Ouch, I tried and it did not take it... Looks like we need to investigate whats going on here. -----BEGIN CERTIFICATE----- MIIDIDCCAomgAwIBAgIENd70zzANBgkqhkiG9w0BAQUFADBOMQswCQYDVQQG EwJV UzEQMA4GA1UEChMHRXF1aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN 1cmUgQ2Vy dGlmaWNhdGUgQXV0aG9yaXR5MB4XDTk4MDgyMjE2NDE1MVoXDT E4MDgyMjE2NDE1 MVowTjELMAkGA1UEBhMCVVMxEDAOBgNVBAoTB0VxdWlmY XgxLTArBgNVBAsTJEVx dWlmYXggU2VjdXJlIENlcnRpZmljYXRlIEF1dGhv cml0eTCBnzANBgkqhkiG9w0B AQEFAAOBjQAwgYkCgYEAwV2xWGcIYu6gmi0 fCG2RFGiYCh7+2gRvE4RiIcPRfM6f BeC4AfBONOziipUEZKzxa1NfBbPLZ4 C/QgKO/t0BCezhABRP/PvwDN1Dulsr4R+A cJkVV5MW8Q+XarfCaCMczE1ZM KxRHjuvK9buY0V7xdlfUNLjUA86iOe/FP3gx7kC AwEAAaOCAQkwggEFMHAG A1UdHwRpMGcwZaBjoGGkXzBdMQswCQYDVQQGEwJVUzEQ MA4GA1UEChMHRXF 1aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlm aWNhdGUgQX V0aG9yaXR5MQ0wCwYDVQQDEwRDUkwxMBoGA1UdEAQTMBGBDzIwMTgw ODIyM TY0MTUxWjALBgNVHQ8EBAMCAQYwHwYDVR0jBBgwFoAUSOZo+SvSspXXR9gjI BBPM5iQn9QwHQYDVR0OBBYEFEjmaPkr0rKV10fYIyAQTzOYkJ/UMAwGA1UdE wQF MAMBAf8wGgYJKoZIhvZ9B0EABA0wCxsFVjMuMGMDAgbAMA0GCSqGSIb3 DQEBBQUA A4GBAFjOKer89961zgK5F7WF0bnj4JXMJTENAKaSbn+2kmOeUJX Rmm/kEd5jhW6Y 7qj/WsjTVbJmcVfewCHrPSqnI0kBBIZCe/zuf6IWUrVnZ9 NA2zsmWLIodz2uFHdh 1voqZiegDfqnc1zqcPGUIWVEX/r87yloqaKHee957 0+sB3c4 -----END CERTIFICATE-----

Yea, in version 3.4 every thread still needs something like 10 MB virtual memory space, so here goes 1 GB of virtual memory space (out of 3). Another common pitfall are the CDR kept in memory, I guess you already made sure you keep only a few days history in memory. Regarding memory leaks, we also did a lot of stuff in version 4. You might want to backup and try upgrading to a 4.2 build (maybe even 64 bit), so that you don't have to restart the system for a long time.

In the latest, we actually changed a few things regarding passwords due to the obvious problems with default passwords. When the PBX takes the default configuration, the default passwords for extensions (also PIN) and domain provisioning are just "*". That means the PBX will generate automatically some random passwords for these extensions (12 alphanumeric or so), so that someone from outside will have a real hard time guessing them. You can still do PnP and the PBX will provision the passwords fine (depending on the MAC trust level and the client certificate that the device presents). The only open door is still the admin password. But somehow you have to log in the first time! If admins don't change that password then I also dont know. I think when you try to save global settings (which also contains the admin password) by default the JavaScript will complain about the empty admin password, so you have the chance to change that as well. We added a warning symbol in the account page that lights up when the account has no password set. But it is not as critical as before, as the PBX does not accept registrations without passwords any more (another change we did a few months ago). The biggest security risk as users that don't like to use good passwords, that remains the core problem.

Good point, we'll put that in.

This is probably because the PBX does not accept the gmail certificate. Either import the certificate or disable the use of TLS for sending emails.

Don't choose trivial passwords! There is a reason that the PBX has a password policy (though it was a marketing decision to disable it by default). Check the following passwords/items: Set the password policy for the domain Set a reasonably safe system admin password Set reasonably safe extensions passwords Set a reasonably safe domain provisioning password Specify an outbound proxy for trunks, and possibly explicitly specify the addresses for inbound traffic.

There is a POSIX call that was obviously supported on an older version of the OS and the support was not available later in OS 10 (as far as I can tell). Seems to be a know problem in the Mac world, so it was relatively easy to get a workaround and put it in. We compiled on a Darwin 9 system, usually it is good to stay a little bit behind to make sure the executables are backward compatible, but in this case it was the other way around.

Well, to me that looks like they have no session border controller so it is the customers responsibility to come up with a routable IP address! Hint: Check the stock price of ACME packet, then you know that there is a industry need for SBC, even if some service providers hate to spend money for this. The problem with STUN is that it does not work all the time, especially with high-class stateful firewalls that don't like it when someone tries to "dig a hole" in the NAT. The result is that it works 95 % of the time, and it is extremly support intensive and expensive to try to fix the remainnig 5 %. The early versions of the PBX supported STUN; but we drowned in support explaining each and everyone what their problem with their specific router/router firmware was and that was just a nightmare. So we dropped STUN and instead added support for outbound (RFC5626). Most service providers that we know and that provide business class service use a session border controller today that solves the problems with customers operating their PBX behind a NAT. For example try out broadvoice, callcentric.com, they use a SBC and it works without problems.

No we just need to make a build that avoid that POSIX function when compiled for Apple... Should be happening today.

Not using the SIP IP Replacement List is a good thing. Did you set the outbound proxy in the trunk? I guess so. Maybe you need to tell the ASA now that it really can trust the PBX and there is no need to filter the traffic...

Instead of recording all calls for an extension, you can as well send the recording "live" to a SIP URI. The PBX will use the "auto-answer" feature in the INVITE, or you can just set the phone to auto answer. Then you can monitor one specific extension.

There is a feature called "hairpinning" in routers which means that the device is available through the public address. Maybe that feature need to be enabled. We had installations where it came down to something simple like the default gateway (thats on IP routing level) was wrong and thats why the PBX could not send replies back the right way. IP routing can be tricky!