Vodia PBX

Intercom is two-way audio, compared to paging which is one-way audio. Because of that, you can intercom only with one extension registered. Otherwise the PBX will wait until one of the extensions has picked up. If the PBX would intercom with several extensions at the same time, it would require a conference, which is very challenging (at least) when everybody is in handsfree mode.

Can you tell us what the trick was? Then others may find this here on the forum and don't have to go through a similar experience...

snom ONE does not need the FMTP line, but it needs a a-line like a=rtpmap:101 telephone-event/8000. The FMTP line provides additional information about a codec (parameters). The one above looks like a telephone-event parameter (DTMF), and it says send everything from 0-9, #, *, A, B, C, D and also hook-flash (according to RFC2833). But anyway this is the right corner. If it is sending the fmtp line, it actually must also send the a=rtpmap:101 line.

You have to be careful with roaming. It is not a handover. Essentially roaming means that the same handset can register with different bases. If the bases ranges overlap, you get a kind of random behavior where the handset logs in. Useful cases are when you have different warehouses that are far away from each other and employees should be able to keep their handset with them. If you are looking for a handover solution, you need to invest in a handover solutions. They have a different price tag for a reason.

Well the SDP in the response says "okay, you can send me aLaw and uLaw"; but nothing about telephone-event (which is RFC2833 a.k.a. RFC4733 out of band). Maybe there is a setting on the gateway that needs to be turned on to offer the DTMF codec as well?

If you know the extension number and the dialplan number already, you can just use the DBSet method. For example, you can find the numbers by looking at the XML files in the file system. This is not very elegant, but gets the job done until the more elegant REST methods are available.

Newer versions of the PBX already support AES (TLS_RSA_WITH_AES_128_CBC_SHA and TLS_RSA_WITH_AES_256_CBC_SHA). Not sure when the support exactly started; but in 5.1.0 it is included.

In the SIP world, the UUID would serve perfectly as device identifier. Unfortunately only few devices support this in the registration (snom does). If we would use the UUID as the device identifier and the extension@domain as the default, we could get this working properly for snom devices; other devices might have the limitation to one registration per extension then.

Well it is not so easy yet. You could try to do this with DBGet and DBSet (see http://kiwi.pbxnsip.com/index.php/Access_to_the_Database). We are adding more and more REST methods, but this one is not available yet.

Well if you can change it in the network it would be the best solution. If that's not possible, make it shorter in the PBX admin settings (admin/general/system/performance TCP/TLS NAT Refresh).

MetaSwitch is used in a lot of installations. That's not the problem. I am sure when you measure the packets on the PBX server (e.g. Wireshark) you will see that the packets leave with 20 ms delay. 100 ms packet delay is a problem. It should be 20 ms, or maybe 30 ms (with 10 ms jitter). What could be is that if you have limited bandwidth, the SIP packets which can be easily 1 KB clog up the upstream. E.g. if you have 3 KB of upstream burst packets can occupy the line for 100 ms if you have 250 kBit/s. If you have hunt groups that send more calls out, e.g. forking to 3 hunt group members, then you end up with 100 ms even if you have 1 MBit/s upstream. The solution is usually to introduce some kind of QoS, e.g. by giving RTP traffic a higher priority. There are routers available that do that for you; actually many modern router have settings where you can give UDP traffic from the PBX source address higher priority than e.g. TCP traffic.

If the phone behind a firewall or in the LAN? It looks to me like the TCP connection is not stable. You might have to make the intervals shorter.

Not sure if routing DISCOVER packets should be considered "critical". Also the fact that the phone is registered is not critical IMHO. OTOH the "notice" that the socket timed out would be critical. I would suggest that the log levels in the phone should be reviewed...

Schätzungsweise wird "pbx.company.com" Vodafone nicht reichen... Am besten wäre es, ein funktionierendes INVITE Paket zu haben wo man sieht wie der SIP Server es gerne hätte (z.B. von einem Telefon). Dann kann man die SIP Header so einstellen, dass es auch von der PBX aus funktioniert.

Well, this is a difficult topic. First of all, 50 USD seems to be the price for a good soft phone (market price). Don't expect to get something better for a lower price. We addressed the problem with the UCClient that runs on Windows. However, the revenue a vendor like Vodia can make from that application is honestly quiet limited. The volume is just very low. Windows might be still the #1 platform for PC and laptops; however if you are following the news around Microsoft and the IT industry, there are a lot of things changing right now. Using the web browser might look clunky today; however keep in mind that web browsers run practically anywhere; the software written for the web browser has a far better reach than a "hard coded" application for Windows. And recent developments like websocket and WebRTC show that web-based technology is a good investment into the future.

If you are using trunks only for outbound traffic, try to set them as outbound only in the trunk setting. At least this way you can make sure that they are not messing up inbound traffic. If all trunks register (for inbound traffic) at the same time, you might just confuse the service provider with overlapping registrations. Also you have to keep in mind, that in the SIP world a trunk does not mean a physical connection with a cable. At the end of the dialing process, a SIP INVITE packet leaves the PBX, no matter what trunk the PBX has selected during the routing of the call. If all trunks are configured the same way, then the packets will also look the same. If you just want to change the caller-ID that you would like to present, you can also achieve that with the ANI field in the extension which is placing the call. This issue has nothing to do with Windows or license or even version 4 or version 5.

Bria will give you essentially only the talk functionality.

Asterisk dial plans are completely different than snom ONE dial plan. In snom ONE, the dial plan is really just about finding the right trunk to terminate an outbound call. There is no programming language involved, just patterns. Check out http://wiki.snomone.com/index.php?title=Dial_Plan_Samples for some examples.

Well, Bria is an answer. It is supported on a lot of platforms. If you only want to make outbound calls, you can as well just use Chrome. Just log in as a user on the PBX, and then you can use the WebRTC feature of the browser to make calls. We don't support receiving calls yet, but that's a question of time. But you can see the presence of the other extensions, see if you have VM and even see and schedule conferences.

I would try dialing 003583315259, especially if you have set the country code in the domain to Finland. The + might be confusing when processing the dial plan. Also check the log how the PBX processes the request.

As for the volume, looks like you need to use something like --volume 10. Seems there was a bug in older versions of VLC, https://trac.videolan.org/vlc/ticket/3913 says it is fixed now.

Probably the problem is then on the trunk side. The SIP headers probably need to be tweaked. What service provider are you using? Try to use "No indication" on the drop down box for the caller-ID presentation, that pretty much behaves like a soft phone.

Do other phones work? Are the m9 extensions using the standard dial plan of the domain?

We probably need an option that stops logging star codes at all. E.g. when a user programs a redirection should not show up in the CDR.

Did take a look into this. Lets say there are two phones registered for sip:123@domain.com and a call comes in. Then one of the phones is supposed to pick up the call. If they both have the same CallID, how can the PBX tell which call leg should be connected?! deviceID will be the same for both legs . If this is supposed to work, we need to change the meaning of deviceID to something related to the registration, not the extension.