Vodia PBX

Hmm 61xx looks like there is no country code set? Anyway. If there is nothing in the web client log on the Vodia side, it ist first of all a problem on the PBX. As for the license there should be "CRM support" in the reg_status.htm page. If that is there, there must be something in the web client log - make sure you set the log level to 9. After a call there must be something, even the attempt to resolve the DNS address must leave some traces in the log.

It only saves if you have entered the address data in the first tab. That is not ideal, but try if you get the customer data into stripe this way. We'll make the updating of the address and credit card data easier to use later.

For Australia and actually for every country this is the human readable format as it is e.g. being fed into the dial plan. If you have the country code set, it would use something like 0234567 for +61234567. You should see this when you get the first CDR in HubSpot - the point is to stick with the format and not change it along the way. In order to see if anything is being sent out just enable the logging of the web client - you can then see the traffic from and to HubSpot. If there is nothing well then there must be some fundamental problem, e.g. the license does not permit it.

Did you go into the domain and set the credit card for the customer? In test mode, you can use VISA card 424242424242.

Die Roboterstimme ist noch nicht so gut dass man sie überall einsetzen kann. Daher würde ich erst mal die vorhandenen Dateien einspielen, so dass nur bei neuen/fehlenden Dateien die WAV automatisch generiert werden. Aber es ist nur eine Frage der Zeit wann dann alles synthetisiert wird...

Aufzeichnungen: WAV sollte heute bei den allermeisten Browsern funktionieren (https://caniuse.com/#search=wav audio format). Wir haben auch versucht die WAV-Datei in MP3 umzuwandeln, es klingt aber wesentlich schlechter und deswegen belassen wir es lieber bei WAV. Bei Email sieht es anders aus, da ist offenbar immer noch Steinzeit angesagt und dort können wir das WAV in MP3 umwandeln lassen. Bei der Mailbox-Sprache kommt es darauf an, wer anruft. Wenn der Benutzer anruft, bekommt der "seine" Sprache. Aber wenn jemand anders anruft, wird die Domänen-Sprache (oder genauer: Die Sprache des Anrufs) gewählt. Wenn z.B. jemand im Auto-Attendant seine Sprache auswählt, wäre es komisch wenn dann auf einmal die Sprache des angerufenen Benutzers gewählt würde. aa_offer_cellphone.wav whow da scheint was durchgerutscht zu sein. Das war wohl eine Datei die nicht in der Original-Aufnahme dabei war; wenn jetzt was fehlt springt der Roboter ein (klingt auch besser). Bitte die Datei in audio_de löschen und es nochmal probieren, die PBX sollte dann die Datei automatisch nachladen. Vielen Dank für den Versuch IOP über die Webseite zu kaufen. Online-Shops sind offenbar nicht unsere Kernkompetenz... Wir sind dabei Partner an Bord zu holen die das für uns übernehmen. Da scheint Chrome vorher etwas toleranter gewesen zu sein was das ausfüllen von Forms angeht, das sollte jetzt aber auch wieder gehen. Ja "Camp On" da waren die Defaults im webinterface falsch. Global war es gar nicht im Webinterface...

Yea the original message thread was about Freshbooks. Stripe should work, though we still have things like taxes on the open issues list.

One thing is to make sure that you have no spaces in the wrong place (beginning end) or tabs or other "invisible" characters. This is a common source for a lot of confusion. Maybe just open a ticket and attach the IVR node XML file there (the file is in the ivrnodes folder).

Is this a SPIP601 (support ended 03/31/2013)? There might be a reason why those phones were so cheap. You might want to purchase a robot punching those things into the keyboard!

We were finally able to test this - it seems to work here both if we enter the 10-digit CMC code and also after the timeout... Are you on the latest 62.1?

We have re-integrated the Freshbooks V2 API into the latest 62.1 version. Or are you using the V1 API?

These are the multi tenant client settings, they are essentially a front end to the stripe settings for this client. The auto refill setting is used for prepaid termination cost (like a calling card), so that the client keeps a certain amount for calls in the account.

The line hpr: {if clip true}id{fi clip true} tell the trunk to use the header Privacy: id when CLIP is on - do you see that header when making a call in the INVITE?

Okay the address book checks will be in the next version. A quick search for the TrueCNAM API did not come up with anything. Also the question is what the best feedback mechanism is - we have a code for blacklisting the last number that we could use; we would also have to add a code for whitelisting a number.

Well... customer is always right! You can try to open a ticket with Cisco to do it the same way, but it might be easier to sell him some more snom phones instead.

I would not change the template for something like this. We have set this up in a way that works, and there is usually no reason to change it unless you want to experiment. Maybe you can try to explain what you actually want to achieve. BTW the new Yealink template includes a "general" parameter where you can add content to the template without having to change the template itself. This has the advantage that if there is a new PBX version available you will not miss those updates.

Shared lines is a concept that is difficult to achieve with SIP. There was recently a RFC published about it (RFC 7463, it was actually in 2015); however we are not aware that Cisco or any other vendor actually implemented that. The reason why this is difficult in SIP is simply because there are no shared lines, actually no lines at all in SIP and SIP works entirely different than proprietary PBX systems. Most users are fine using park orbits (non-exclusive hold), it solves their problem.

Hmm what pattern are you using? This is really strange.

The Yealink ignore those settings when there is a outbound proxy set. We always use outbound proxy. BTW there is a new template available in the 62.1 version.

What is being sent on the trunk in the initial INVITE? Blocking caller-ID is usually done by sending the Privacy header. What trunk provider are you using?

The easiest way to get this done is to use a park orbit.

Does the DTMF navigation in the mailbox work fine? Then we can exclude problems with the DTMF.

That sounds like a problem with DTMF detection. E.g. does DTMF work when you call into a mailbox? If yes, what pattern are you using in the IVR node?

In principle it would make sense to feed that information back to the SPAM score provider - they will need to update the database on this. Right now the PBX completely relies on that scoring, no matter what is in the address book. It might make sense to look the address book up as well (which is just a quick internal operation), I don't see a reason why a local address book listing should have a lower priority that the lookup from an external score provider.

We have Flowroute on the drop-down list when you create the trunk - hopefully that should work out of the box. You can open tickets at vodia.zendesk.com, which makes sense if you want to share passwords (temporarily) with us. Passwords are recently a pain, because the browser is very aggressive in filling out forms. Make sure to enter the password again in the trunk settings, just to make sure that the autofill has not overwritten the password that you have previously entered. We are addressing this issue in the next versions.