Vodia PBX

IMHO the phones look pretty on table, but from a feature perspective the SIP builds are quite limited. Fortunately, you can mix handsets in the same deployment. If you want to do paging, you might also want to look into dedicated paging devices, e.g. snom PA1.

That probably comes from the usage of buttons. *601 is the internal code for connecting calls.

Q1: You can use the prefix (*90xxx) to initiate Intercom from the phone; for receiving intercom calls, you need to present a Call-Info header with auto-answer=0 as-far-as-I-know. The entries can be edited in the ringtones.xml file and in version 5, it seems that this is already included (see below). In version 4, you might have the problem that your license does not allow non-snom user-agents. <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>

It should. Calls are calls, no matter where they originate from and where they end on.

Grundsätzlich sollte es gehen, wenn man da z.B. ein Softphone registrieren kann. Wir können gerne mal die Registrierung optimieren, brauchen dafür aber den Zugang (am besten als private Message; Passwort kann dann anschliessend geändert werden).

Thanks for the updates. Yes, dual stack operation IPv4 and IPv6 can be challenging.

5.1.2. If you want a test build, send us a private message with the OS that you need.

Ouch. Looks like a serialization error. But that one should be easy to fix and will be in the next build.

It might depend on the path it takes. Maybe one provider does it for you, maybe the other does not. Maybe the delay gets so long that the delay gets out of range for echo canceler. Echo cancellation is a tricky topic. A good headset does the echo cancellation right in the headset. There are even microphones that do the digitization right in the microphone, so that there is no line echo at all. Echo is easy to kill if you do it right at the source and then down the path the involved parties don't have to deal with all sorts of tricky digital signal processing issues.

Yea.... we saw that request already when adding the cell phone forking to the hunt group. Unfortunately it is difficult to schedule those invitations during all those times. User 1 might decide to include the cell phone after 10 seconds, user 2 after 15 seconds and so on. Keep in mind that every call also may result in fail-over if the first trunk fails and so on. You can somewhat control the timing with the hunt group stage delay. The desktop phones might start ringing a little earlier than they should; at the end of the day that solution comes with the risk that someone picks up the call that would otherwise not be bothered.

Yes, that should work. If not, just log into the base and try to register them manually.

Did you do any manual changes to the webpages (maybe to fix a problem with the previous versions)? If yes, please undo them--5.1.1 has the fix already included.

The format in version 5 is backward compatible with the previous versions even down to version 3. There are a few pitfalls when upgrading, especially on the trunk side that will require manual steps or at least checks. If you are using SIP service providers, check if the trunks register and you can make inbound and outbound calls. Whatever you do, make sure that you copy the whole PBX directory to a safe place, so that you can start over again if you have to.

You mean SSH or RDP? That depends on the device and operating system. I know that for some snom ONE SoHo devices, the developer thought it would be smart to choose port 8722, but it has been changed back to the default port 22 in the newer devices.

Echo cancellation is the job of the gateway and the handsets. The PBX stays out of this.

Sorry, we are not the biggest CSTA experts... what should be the right response to the ConsultationCall request?

If you put the dongle into the new server it should also work. If it does not work, it could be that there are some USB library problems. It is hard to keep that stuff compatible. We usually offer the same upgrade path for pbxnsip like snom ONE customers. However because pbxnsip was not using activation codes, you need to send a quick email to sales to get that code (include the old license key in that).

We have made some proprietary extensions for CSTA messages, for example to show what type of call an incoming calls is (ACD, hunt, ...). We could do the same thing for the Call-ID. But of course it would be better to have a standard-compliant solution.

Did you click on the edit icon for the domain (in admin mode list domains)? The maximum number of calls per conference bridge cannot be configured separately (AFAIK).

Yes, that feature was already available in version 4.

Well, the license is bound the server would be my first guess unless you are using one of those dongles that were offered with pbxnsip.

Thanks. Hopefully the next build will address that properly.

You don't have to use ulaw. You can also use linear codec (16 bit/sample, mono, 8 kHz). I remember we added that to the PBX--it makes tons of sense especially for streaming.

We cannot recommend that firmware for production use yet.

CSTA is a difficult topic. Actually we have made some more fixes for CSTA in 5.1.2 that help to increase the stability. If you can give us a trace of the CSTA messages, we can take a look and see if we can get this working (private message).