Vodia PBX

Yes... IMHO it is absolutely okay to edit the settings that are provisioned on the phone. There are so many of them, and it does not make sense to "babysit" them all on the PBX web interface. The domain setting for a PnP phone dialplan covers only the most obvious cases. If you take star codes into consideration, the picture gets really difficult. Apart from that I believe that most customers are okay today with pressing the green button to start the call, just like on the cell phone.

Well they are under (in the domain admin mode) Settings/Domain Settings then at the bottom: Provisioning Parameters/Default PnP dial plan scheme. But editing the template is another way to get the job done.

That is not controlled by the dial plan of the domain, the provisioning of the dial plan on the phone is controlled by the domain setting in the PnP area. There you can select what pattern you want to deploy on the phone.

You mean in the received call list on the phone? Actually we recently talked about this topic, and it seems there is a way to get this done.

Well if you use the analog in, it should do exactly that!

Services are massively moving to the cloud right now, where IP addresses are always routable. So IMHO time will heal the problem of SIP servers behind NAT anyway.

Seems like we updated the Sipgate page at http://wiki.snomone.com/index.php?title=Sipgate. Please check if that helps. E.g. the To-header looks very suspicous to me in the above example.

You have to keep in mind, that a user e.g. is talking to another conference system. Then a single # can be a problem, e.g. you dial into some conference server, say your name and then press # -- your call is on hold. Ops. That's why we wanted to have something more unique. But it is probably a good idea to make that symbol a setting, default is "##". Yes this sequence has something. It is easy to remember and users dont have to listen to the voice prompts. I think the core message is that we need to think in sequences.

Hier ist der "geheime" Link für die aktuellen Versionen: http://wiki.snomone.com und speziell http://wiki.snomone.com/index.php?title=Upgrades_(Release_4.5).

Ja das müßte eigentlich funktionieren. Falsche Version? 4.5.1090 ist die letzte...

Ich würde erst mal "Permissions to monitor" (in der Rufgruppe/hunt group) the account leer lassen, dann darf jeder. In der Rufgruppe muss es klingeln, wenn schon verbunden ist kann man nicht mehr *87 verwenden.

Das ist das "Mailbox Direct Dial Prefix" (siehe http://wiki.snomone.com/index.php?title=Voicemail_Mailbox). Auf dem Deutschen Wiki scheint es die Übersetzung nicht geschafft zu haben...

The star codes in general are settings of the domain. However the behavior on the cell phone are hard coded at this point. Should not be too difficult to make those a setting; however changing the logic is something different. Maybe you can make a proposal what settings we could introduce, and then we can see how much work that would be...

Sorry for the English answer... I guess the problem is that LDAP does not work with the Polycom. The snom ONE LDAP server is not a complete LDAP implementation, it only implements a small subset. If you provide us a PCAP trace, we can see how much work it would be to support the LDAP feature set that Polycom uses.

In the case of an attended transfer codecs might have to be re-negotiated. Usually the PBX does not send Re-INVITE on trunks (interop hassle with the thousand different SIP interpretations out there), this internal hidden flag may tell the PBX to do so and avoid transcoding. Another internal flag that hopefully is never needed. It disables media flow-though the PBX and instead forces always transcoding. This flag is more for debugging, so that we dont have to wait in the lab for re-regstration when restarting the PBX process. Works only on UDP, obviously. Thats obsolete.

Während der Urlaubszeit würde ich die Anrufe auf einen Auto Attendant (automatische Vermittlung) umleiten. Dort kann man dann dem Anrufer einige Möglichkeiten geben, z.B. in Notfällen Handy anrufen etc. Das ganze kann man über ein Service-Flag (Ein-Aus-Schalter) in der Rufgruppe steuern, wo man z.B. die Urlaubstage einstellen kann.

It seems that the Polycoms dont like it when the PBX updates the information in a SIP header (from) and from then on it goes south. We will see how fast we can patch this.

Die Zeit sollte doch durch die Dauer der Stufen in der Rufgruppe zu definieren sein?! Vorher geht die MB auch nicht ran. Die Anzahl der Aufnahmen kann man natürlich hochsetzen. ich würde aber einen Email-Client einrichten und die Nachrichten per Email rausschicken und dann in der Mailbox entweder als gelesen markieren oder gleich löschen. Damit braucht man sich dann nicht mehr mit dem Löschen der Nachrichten herumärgern. Email ist heute nicht mehr teuer, selbst wenn die nachrichten über Jahre hinweg archiviert werden.

Well we added the UHLL support some time ago. It seems that in the hospitality world there are so many different interfaces, we dont want to program them all. But I agree, there should be a simple post paid (or better: check-out) payment model. We are probably not far from it, maybe even a simple HTTP GET interface would do.

It seems the license key is not the problem. Maybe there is something wrong with the call flow for call transfer from Polycom. We are investigating.

There is some information about call pickup on the Wiki (see http://wiki.snomone.com/index.php?title=Transferring_Calls_Codes). Maybe the probem in your case is that you have defined permissions to monitor the account and the one where you want to pickup from has not the right permissions.

Habt Ihr mal versucht in der letzten Stufe 820 einzutragen? 8 für "gehe zu mailbox" und 20 für die Nebenstelle 20. Wenn die Rufgruppe (hunt group) eine Nebenstelle anruft, wird niemals direkt die Mailbox angerufen; das muss man explizit angeben.

Hmm. You might need a license key with the magic word "3pr" in it because you come from a pbxnsip build. Please send me a private message with the license key in it, so that we can take a look if thats the problem.

Seems like the %cmc% screws it up. This is inserted internally when you use $c, and it seems that the renaming of the file later fails. Workaround, if you dont use CMC: Take the $c out. But this is something that we obviously need to check again (also the display in the web interface seems to have a problem: strange characters are not okay).

The CDR URL can take more than one destination. Each destination must be seperated by a space. That means you can send the CDR to the TCP address *and* for example, out by email or to a CSV file. I would use this feature to see where the problem is. If e.g. the CSV file has those records, then you can be pretty sure that there is a problem with the TCP connection.