Vodia PBX

Hmmmm... When the hunt group goes from one stage to another there is actually no reason to believe that there was a missed call at all. I think this is something that we should change on the hunt group. However when the caller hangs up while the phones are still ringing, those phones will still see a missed call, which is IMHO not a perfect behavior, but reasonable. In the ACD we don't have the same problem as the agents keep on ringing.

Well, the RFC DNS idea was that the clients always look up the DNS records. The problem is that the overall uptime now depends on the stability of the SIP server AND of the DNS server. We also had numerous discussions on this forum why the SIP trunks go down from time to time when service providers choose TTL of 60 seconds for their entries... Anyway, I depends on the vendor. Our strategy is to use DNS for the provisioning, but then use IP for the outbound proxy. This way, if the service provider really has to move the service from one server to another, a re-provisioning of the phone will be sufficient--and we don't have to worry about DNS problems with the handsets.

The phone is not aware about hunt groups or any groups. When several phones are ringing and one of them picks up, the PBX tell the phone "call completed somewhere else" in the reason header for the cancel. But when the whole group has missed that call it is all or nothing--all phones will show a missed call. Unfortunately, the only way to properly implement the missed call requires a logic totally outside of the SIP call. In the UC Client we are using an extended message waiting indication for that, but this is not according to any standard and will not work with snom phones or any other phone type.

How long does this take? Maybe the PBX blacklists the phones for some time because there are a lot of SUBSCRIBE coming in at the same time (unauthenticated)?

Yea we had reports that the 8.7 firmware could lead to endless reboot loops. IMHO there is no real reason to move to 8.7 for the 3xx series; you might be better off with 8.4.32.

Both is possible. IMHO the PBX needs to have the correct time set up; otherwise you will hear funny announcements e.g. when you want to listen to your voicemail. And having the phone getting the time from the PBX has the advantage that they otherwise don't have to talk to any outside address any more (if you provision the firmware from the PBX). The SoHo is a broad term when it comes how it was configured. The mini should have the NTP client set up properly, so that the system has the right time.

We are changing a few things in version 5, but it too early to talk about that.

Anyway, if there are media problems it does make sense to get a PCAP trace from what's going on. I agree scratching the head and trying all kinds of things out is very time consuming. We are running 710 here with 8.7.3.15 with satisfying results (no one way audio or something), and there are lots of 3xx on 8.4.32 also without major problems.

You should see in the LOG that the OPTIONS request from the service provider are answered with 200 Ok.

Well if you use CURL you could emulate the user to log in and upload the address book. That does not win the beauty price, but would solve the problem at hand. Down the road, we probably have to come up with something more elegant.

Yes that can be a reason. According to IETF it is okay if the RTP stream comes from a different location than where it is being sent to. Although it is very rate and extremly NAT unfriendly; but in theory it can happen.

Looks like the problem is that the service provider sends OPTIONS to refresh the binding. The PBX does not answer those requests by default. However there is a way to enable them by editing the pbx.xml file and set out_of_dialog_options to true. Version 5.0.3 will contain something that does this automatically.

The + sign should actually not get to the phone, except maybe in the display-name where it causes no harm. Maybe you can instead use the 0044xxx form to represent the global phone number. Unfortunately I am not the biggest Vega expert, but I know it can be done.

Hmm you could put that into the tftp folder and have the phones poll every few hours for new configuration data. I believe that would be the easiest solution.

We have made a blog post on blog.snomone.com about how to upgrade the license on the SoHo and mini to version 5. Hopefully that will resolve some of the issues that we had over the past weeks with these devices. Because not all of those devices hav an activation code, we are using the MAC address as the "token" for the device. Also we added another bundle specifically for the ARM-based devices, so that very small offices can now also use features like Fax2Email.

As long as you did not change your configuration, it should be possible for you to downgrade to version 4.5. For this, you need to use the "upgrade" URL (ending in .xml) and put that into the software upgrade field in the PBX. As usual, it is a good idea to backup your working directory of the PBX to avoid unpleasant surprises if anything goes into a direction that you did not anticipate.

I agree. Maybe someone can set up a email service in the net where it does the transcoding from WAV to MP3...

Ahhh.... Okay if you are using a Vega then you should be able to present the number so that the PBX 100 % understands the number right. Ideally, the numbers start with a + and then the country code. There is no point in keeping the numbers short; a few bytes more in a KB packet don't make any difference. Once that the PBX knows the complete number, other things like address book become easy or easier.

I can only guess. Maybe you can ask on the snom Forum if there are any plans.

I am afraid the Vision with 64 MB memory, ARM processor and Ethernet is not capable of doing that.

It is used for the formatting of numbers. The breaking risk is relatively now. The question was if your service provider made any statement on how he presents numbers. If you are using a PSTN gateway, then you need to change the setup of your gateway, so that the numbers are represented in a better way.

In either case they have to play back WAV files. http://developer.android.com/guide/appendix/media-formats.html has a overview what codecs are supported; seems like the WAV support was added only in 4.1, and only uncompressed. There is a option in pbx.xml that tell the PBX not to compress the attachments, not sure if that would be a solution.

Hmm, this is a phone specific question. I would look at http://wiki.snom.com/Features/Dial_Plan/Regular_Expressions for some examples.

When does that happen during the call? Pretty much at the beginning or can it also happen later? Are there multiple phones ringing when that happens? What OS are you on?

The point is: Don't use DNS as outbound proxy. Use DNS only for provisioning the phones, so that it points to the PBX IP address. Then the PBX should figure out what IP address to present to the phone which is being provisioned. If you set up the phones manually, try to use IP addresses; at least to see if that solves the problem or we have a more fundamental problem with the routing.