Vodia PBX

Yea, the PBX does not wait until the user enters more digits. It is generally a good idea to make sure that all extensions have the same length (at least if they are numbers). Otherwise there are a lot of challenging problems when users try to punch in an extension number. The idea is to make better use of the # sign to terminate input. But that is not such a small change, it is in so many places...

The email from 341 does not neccessarily have to come from an extension. If there is a number configured on the PSTN gateway, the PBX would take that number. Check the date stamp, maybe those emails were sitting in the spool directory for a long time and suddenly they are set free. Restarting the server will not help. Check the spool directory if there is some nonsense. Maybe the PBX has the permission to write into the spool directory, but has no right to delete there? That would definitevely explain a lot of bogus emails...

We are looking into the possbility to send all recordings out by email. There were some technical concerns, but after receiving a 15 MB email today (unrelated topic) it seems that email attachment size plays no role today any more. And the nice thing is that once the email has left the PBX, it is not a PBX problem any more plus there are so many ways out there to sort emails into the right folders, that we don't have to worry about it.

Seems like "Voip Phone 1.0" has a small problem with the registration. The phone coming from the IP address "10.255.109.71" never reregisters, the phone coming from 10.255.109.195 has the same problem. Maybe this is because the re-registration interval is shorter than 32 seconds. Just an idea; it should be easy to fix that in the Voip phone software.

Also as outbound proxy? If the IP config of the host changing during operations?

It is part of the address book. The contact type describes how the PBX should handle incoming calls.

Overall, it should work fine. There were a few minor hickups that have been addressed in 3.0 (e.g. TCP keep-alive, no buddy-lists was confusing the display).

You can use the setting "Watch the presence of the following extensions" in the extension to provision the extension that you want to watch with presence.

The folder name must be audio_en (all lowercase) and it must be readable. You might have to restart the service so that the system gets the files.

Hmm, yea that ANI field might have no meaning in the calling-card... At least in the way you are using it (SOAP might look different). Did you try to make an anonymous call? There is a flag for that.

That smells like the problem. Could it be that DNS is instable and then the outbound proxy of the trunk is not clear? I guess you get the above log message only when it fails, but not when it works okay?

Ehh - you are right. Will be fixed in 3.0.0.2978.

Hmm. Does that mean you also have a problem with attended transfer when there are two different registrations? Hard to believe. Maybe there is a flag that controls this behavior on the phone?

Nice movie! We have seen a problem with the buddy list subscriptions. In the latest & greatest the PBX answeres with 4xx code when the phone wants to subscribe for it, that seems to solve the problem with strange icons on the 2.2.2 version. If you can, give version pbxctrl-3.0.0.2976 a try (http://www.pbxnsip.com/protect/pbxctrl-3.0.0.2976.exe, only Windows).

Whow. I believe that is not very intuitive. Also for attended transfers. What phone type is it? Okay, that sounds like a short-term workaround.

I think the black-list would be appropriate? That would work for calls into an extension. For calls to other accounts, you could think about using a IVR node and do from-based routing.

Maybe you can capture two SIP packets: The INVITE that hits the phone, and the INVITE from the phone that contains the star code. I think if we see those packets we can say if that is the problem or not.

From pbxnsip perspective I see no reason to move to this version. 7.1.33 is fine.

At first glance that does not sound like a TAPI problem to me. Can you check if click to dial behaves correctly? Maybe something "stupid" like a missing dial plan entry for that route or some stange characters that cannot be dialled.

Check the spool directory. But an upgrade to 2.1.11 will fix that problem as well.

Maybe no misunderstanding... The problem is that when the phone starts a call, it needs to use an identity. Chances are, that when the call comes in to extension 400, but the outbound identity on that phone happens to be the other one, - then the PBX says "well that extension does not have an active call" (*85400 means park my calls on orbit 400, not park calls of [the foreign] extension 400).

Yes, I seems we have some trouble with the hunt groups and TLS. What you can try to do is use TCP or UDP instead (the latest versions have a setting for that in admin/PnP Params, so that you can provision this automatically). We need to find out why it is so slow, I cannot believe it is the encryption.

IMHO it makes sense in most cases, but we can make it possible to turn this off. But we can add a global setting that suppresses this... The new setting will have the name "multiple_hot_destking" (default is false) and it will be included in 3.0.0.2976.

Hmm, why are all packets trunkated to 54 bytes? Anyway. Must be a tcpdump "feature". In this trace the delay should be around 1 second, right? Does that happen only if you call a hunt group (= a lot of SIP traffic) or also if you call one extension directly?

Okay, so we need to take a look into *70 again... But this will be in 3.0.