Vodia PBX

There is also a star code for putting calls on hold and parked calls into a conference.

You mean the web browser-based phone? Sure just make a call from the user portal...

Ouch... Yea those leftovers are a dangerous source for those kind of problems. Thanks for the update.

Well, we are using some super-stripped-down version of SIP. However the main problem with a 3rd party WebRTC-based phone will be that WebRTC requires the media session is set up using ICE, with testing out candidates and using DTLS.

Interesting... I don't think it will be difficult to get this going, especially because we are already massively using websocket for HTTP (and also the soft phone in the browser, using WebRTC). But we can't do this just out of curiosity. The question is if any product requires this or there is any demand for that?

Hmm. I would still try to have the PBX do the job. We (Vodia) spent a lot of time with the PnP files to make it as smooth as possible. In order to limit the damage, maybe you can block HTTP access on the firewall, so that only a certain phone can access the PnP side of the PBX (just an idea). Also, you could still try to get PCAP for the REGISTER packets unless they are using TLS. For example in the packet below the REGISTER contains the MAC in the sip-instance: REGISTER sip:snom-test-xxx.local SIP/2.0 Via: SIP/2.0/UDP 192.168.203.42:44100;branch=z9hG4bK-d8t7hih3alex;rport From: "1020" <sip:1020@snom-test-xxx.local>;tag=x5ntva7ffl To: "1020" <sip:1020@snom-test-xxx.local> Call-ID: 46000000b5b6-x4pyz178xx4n CSeq: 11375 REGISTER Max-Forwards: 70 Contact: <sip:1020@192.168.203.42:44100;line=bkcucywg>;reg-id=1;q=1.0;+sip.instance="<urn:uuid:6c0e6ff2-8c51-4fae-84e0-00041370004A>";audio;mobility="fixed";duplex="full";description="snom720";actor="principal";events="dialog";methods="INVITE,ACK,CANCEL,BYE,REFER,OPTIONS,NOTIFY,SUBSCRIBE,PRACK,MESSAGE,INFO" User-Agent: snom720/8.7.3.25.5 Allow-Events: dialog X-Real-IP: 192.168.203.42 Supported: path, gruu WWW-Contact: <https://192.168.203.42:443> Expires: 3600 Content-Length: 0 If you can still provision the phones with the running V3, you should also consider changing the template so that it "reveals" its identity if you cannot see anything in the REGISTER packet.

Well if there are thousands of phones it makes sense to spend a lot of time on a as-automatic-as-possible approach. If we are talking about 5 phones, you can as well call them up and ask them to turn the phone around and tell you what they see there. Also, I forgot what was the point again to know what MAC addresses are being used? I assume that would be for an upgrade of the PBX. You want to avoid the risk that the upgrade does not work as expected?

Actually if you upgrade the PBX will automatically use MAC in the files. I would make a backup of the working directory and give it a quick shot (potentially using a 30-day demo license). You can then still restore the backup and move back. In theory that should work, as many customers went that path. Chances are it will also work for you.

Well you would not see the MAC layer of the packet in the PCAP; but you could e.g. search for HTTP provisioning requests or MAC hints in the REGISTER packet. PCAP would be still easier than distilling that from the various logs of the PBX. But another approach could be more useful, to have the PBX provision the URL to use the {mac} parameter in it; then the phone would do this on its own. On idea is to modify the som_3xx_fw template, so that you download a dummy file there that will contain the MAC address for the user; then you'll have that in logs and can match extensions to MAC addresses.

The problem is not the 32 or 64 bit; it is the move from one server to another. Unless you are using a hosting license, the customer-premise license is bound to the server which obviously is not the same any more. You can reset it from the license portal (vodia.com), and then re-activate the license on the new server.

I like Goldwave (http://www.goldwave.com/). For what you need here definitively more than sufficient.

Well, I think you will have to go through the list and do this more or less manually. A upgrade would not help much unfortunately. If the number is really large it could make sense to have a PCAP for the registration and try to "fish" MAC addresses out. If they are in the LAN, they would be visible on the PCAP.

Hmm. What version? 4? We have given up on user@domain some time ago because it was not easy to handle and instead always try to use the MAC. If this is a snom phone, you might see the MAC in the REGISTER message in one of the headers.

DECT: Not yet. But we assume that the new models behave similar to the other DECT devices. The expansion module should not matter. This is just an extension of the phones number of keys.

Well, I am not even sure what happened to Greek. But we could spend the time to import the V3 Greek language file, that should bring us closer. Then we can do the rest from the web interface with the translations editor.

We had cases where the 715 phones came with a crooked firmware that needed to be manually updated first before it could be used. I was not aware that such problems also exist with the 710 phones; but maybe that is the problem here as well. It it all does not help, open a trouble ticket, give us access to the system and the phone and we'll take a look from here.

Well we cannot say anything about the non-Vodia-PBX... As for the Vodia-PBX there are two ways you can do this: (1) If you set up a gateway trunk, you can specify the other server IP address, in the outbound proxy and if you like, also in the explicitly list for the list of associated IP addresses for this trunk. (2) If you use an extension, inbound calls will be challenged with the extensions password, which means that the trunk of the other PBX needs to have that same username and password (which is usually no problem).

5.2.4 is definitively able to provision the 710s. Maybe that phone was centrally redirected to another source? I assume that www.server.com is your PBX address... The it should show up there. I assume you already tried a factory reset of the 710. I know such cases can be a time killer; the logs on the phone don't really help. If you have already Wireshark on the PBX I would run it and filter for the phones IP address. That usually helps to see what is going on.

This is what we provision in 5.2.4: snom300: 8.7.3.25.5 snom320: 8.7.3.25.5 snom360: 8.7.3.25.5 snom370: 8.7.3.25.5 snom820: 8.7.3.25.5 snom821: 8.7.3.25.5 snom870: 8.7.3.25.5 snom710: 8.7.3.25.5 snom715: 8.7.5.8.2 snom720: 8.7.3.25.5 snom760: 8.7.3.25.5 snomMP: 8.7.3.25.5 snomPA1: 8.7.3.25.5 For the models that can run 8.4.35 is it probably okay to keep them on that version. The newer models require newer firmware, but from the PBX point of view you are not gaining much running the newer firmware.

Did you turn the writing of the config files off?! Then you should see something in the log unless the log level is too low. Or the phone is not hitting the server at all.

There is a document about this topic on http://www.vodia.com/documentation/trunk_branches that might help you.

Hmm. I would take a look into the "generated" folder, there you can see what has been sent to the phone and if it makes sense. Are you sure that you don't have anything in the webpages folder or in the html folder that could interfere with the provisioning?

Yes that's possible. Actually many users do that. But you should use a username and a password; especially if you are on public IP that's very important. The extension also has a field where you can put the IP address from which the extension registers. The alternative would be to use the trunk-to-trunk routing, which was designed for linking offices. In that case you would use a trunk for inbound calls, which can work without username and password; but then will be based on the IP address.

Of course you should make a backup. The way the PBX works makes it simple, just ZIP or TAR or rsync or Dropbox/box/SkyDrive your working directory. Having another method that works more or less through HTTP of the program itself is not necessary and creates more problems than it solves. For example, if you have a web backup, how do you restore it.

You should not. Everything that the PBX needs is in the file system; sending the file system through the PBX web interface is not helping making it a more stable system. Even for embedded devices, making remote (and even automatized) backups is not that hard any more.