Vodia PBX

There is a guide at https://service.snom.com/display/wiki/DECT+-+1.+Multicell+Deployment+Guide that shows the steps for Multicell. It will be hard to do the whole setup through the provisioning (signal strength etc). It makes sense to provision the primary cell, and then have the slave cell receive the config e.g. through multicast.

There is something keeping the PBX from picking up that call. Possible reasons are permissions (is that extension allowed to pick up the call), the call is already gone (should be easy to reproduce), that extension cannot pick up calls (e.g. because it is a hotel room extension), or one of the extensions is actually ringing, but from a group. In the latter case there is a flag that tells the PBX weather such calls should be picked up, the default is not. If the star code is not handled, the PBX continues finding a way to terminate the call. Its debatable—probably its better to send the call to a IVR that tells the caller that the action failed. We'll address that in on of the next versions but here it is more cosmetic.

488 points at a problem with the codec and/or SRTP. As a first step, I would switch to TCP to make sure it is not a SRTP problem. Did you change anything with codecs?! As for the headsets they are from the PBX point of view just another DECT endpoint. You have already seen the parameter 1 trick to tell the base station what IPUI to use for what extension (actually you can also do this "manually" with the pairing process through the web interface of the M700). We did not test this here—but I would not expect any difference with another snom DECT handset.

There is a video on the subject

So this is in the LAN? Did you use the "LAN devices" menu to discover the M700? This works only if the MAC was not assigned to an extension yet. Also the M700 needs to be factory reset (the default username password). The provisioning link is correct, it should fetch the configuration if you have set the MAC address and started the provisioning window on the PBX side.

The trunk headers are not so important in this case. Did you try the address book? Maybe it already solves the problem for you. You can use CSV to import a list—there is no need to enter each partner manually.

In the PBX, paging accounts can be in unicast or multicast mode. The latter one would be a "Multicast Paging Group". Entering 224.1.1.2:4000 there is a good choice. You can provision the button also from the PBX without having to touch the phone—the PBX would then set up the VPK button automatically. Just select the paging account for the button and hit the save button. As for the echo, that is a good point. There must be a setting that tells the phone that it should not play back its own RTP stream. IMHO it would be reasonable that this is "on" by default. Unfortunately Grandstreams many models all have different provisioning profiles which make it hard to take care about each and every model. Other vendors keep the name of the settings across large amount of devices.

If everything is in the LAN, all you have to do is to put the multicast paging group on the button of a phone and provision the PA1 and the phone. Then when you press the button it will be sent from the phone to the multicast group and make the PA1 play it back. The PBX will be unaware about it—no CDR and also no call recording.

One important question is if this happens within the same LAN. If the answer is yes, then multicast can be a good option (unless call recordings is required). In that case, you can just provision the PA1 be part of the paging group and have the phones permission to page that group. Then the PBX will take care about provision everything to work peer to peer. If your desktop phone does not support sending multicast RTP or you want to use the feature e.g. from a PSTN or Microsoft Teams account, then the PBX can still generate multicast. This would require that the PBX and the PA1 are in the same LAN. If neither a phone that can generate the multicast RTP nor the PBX is in the LAN, then we are talking about sending the RTP over unicast SIP. This is easy if there is just one PA1. If there are many PA1, it becomes more and more difficult to have them all play back the page as the load on the system goes up, which is especially a burden if you are on hosted PBX with limited bandwidth into the LAN. In that case there is an option in the PA1 to relay the unicast RTP into multicast RTP. However the PBX does not support provisioning that kind if scenario and this would have to be set up manually.

Wir arbeiten an einer Lösung die auch mit der Deutschen Telekom (und sicher auch noch anderen Anbietern) sauber funktioniert. Das wird noch ein paar Tage dauern.

Try to scan the QR code with something else (e.g. Lens). Does the content make sense, especially the address of the PBX? Would the cell phone be able to reach the address?

You should open ports 443 (HTTP TLS) and if you want to use LetsEncrypt certificates, you must also open port 80 (cannot be another port). For UDP, you need to make sure that the PBX UDP ports (by default 49152-65535) are also forwarded to the PBX.

"http:" is not an action—this would be configured on the ActionURL page...

We need the domain name somewhere otherwise it would not work in a multi domain environment. Though I agree this should be done on HTTP level (hostname). Anyway we are looking into this.

Yes—certificates work only with DNS addresses. snom does this for a long time. This is in /reg_pnp_settings.htm setting "Use domain name instead of IP address".

Beim Thema SRTP schien es etwas hin- und herzugehen. Zwischendurch ging es nur wenn man SRTP explizit ausgeschaltet hatte. Jetzt scheint es so zu sein, dass SRTP/SDES doch wieder geht (vermutlich gab es zu viele Geräte die es so machen so dass DTLS in der Praxis zu viele Probleme bereitet hat). Wir haben die Vorlage wieder entsprechend angepaßt. Thema Codec ist auch schwierig. Das liegt weniger an der Telekom, sondern daran dass die das SDP weiter reichen an die andere Stelle, die dann teilweise mit nicht G.711 ins Schlingern kommen. Daher ist G.711 sozusagen der kleinste gemeinsamer Nenner mit dem es am wenigsten Ärger gibt. Wenn G.722 nicht nativ auf den Endgeräten unterstützt wird klingt es schlechter als G.711. Bezüglich Zuordnung eingehender Anrufe sollte IMHO praktisch immer ein Präfix verwendet werden. Dann braucht man keine Telefonnummern anlegen, sondern nur dafür sorgen dass die Nummer hinter dem Präfix einer Nebenstelle (kann auch eine Gruppe sein) entspricht.

The app uses web socket—so there will be no UDP. Depending on how you are logged in, the PBX will generate a HTTP or HTTPS URL for you.

Practically everything today uses SNI—because practically all web traffic is on multi-home web servers. There are unfortunately still some SIP phones out there that did not have SNI turned on. In a nutshell, there is no way to use them with TLS in a secure (validate certificate) way if there are more than one tenant on the hosted PBX. The only way to get this working is to certificate validation off.

We also have a OpenWRT build, see the "OpenWRT (MIPS)" target in http://portal.vodia.com/downloads/pbx/version-65.0.xml for example it runs on https://openwrt.org/toh/hwdata/zbt/zbt_wg3526_16m

Why using such an old version? We are now at 65.0.

We have a template for the 1620—might be much easier to use the template than going through all the settings and o this yourself. You only have to set the provisioning server to the address of the PBX, add the MAC address and start the provisioning process.

Usually you need to use https—though e.g. in Safari you can tell the browser than http is fine (mostly for testing). However there should be some kind of warning if https is not allowing WebRTC to start.

We had already a similar problem problem when it came to the question what outbound ANI to use for an outbound call. The rule was to use the one from the last ACD the user logged into. It makes sense to not only associate the ANI with the ACD, but also assign the call the ACD. We'll do that in the next version 65.0.5. Maybe we can make that even graphically visible in the soft phone.

Looks like this is an area that needs to be revisited. Especially the possibility to send out weekly and monthly emails should be very useful in many environments.

The dial plan pattern normally does not use the +-form. It uses the form in which a human would read the number—for NANPA this is just the 10-digit number and for international numbers, its 011xxx. (2-9) is not a valid pattern. Do you mean [0-9]? BTW if the pattern (priority number 30) matches the plan will stop there. That means you don't need to make that exception in the line 40. You can probably just use * for "everything else". Or you could use the pattern [2-9]xxxxxxxxx.