Vodia PBX

Seems like sipgate does not support P-Asserted-Identity (RFC3325). Choose another mode, probably Remote-Party-ID or "No hide". Gradwell probably has the same problem. It is shocking how difficult for providers it is to understand the meaning of the From-header, especially for redirected calls.

Well, which other trunk does the PBX match? Check the above rules, why this trunk would get a higher precedence in the trunk matching than the Linksys trunk. Maybe the other trunk has no outbound proxy specified. And of course make sure that you have no unneccessary trunks and make sure that you dont use IP addresses to identify extensions (in the registration setting for the extension).

The 821 have built-in certificates, the provisioning should be even easier. Did you try just entering the IP address of the PBX in the setting URL of the phone? BTW you can do this also after a reboot by holding the # during the boot process (you dont have to wait until the whol phone has booted up).

Hmm. The Cisco ASA have SIP awareness, though I don't recall they would be instable (either work or don't but nothing in the middle). Any chance to use SNMP to monitor the PBX lets say every 10 seconds? See http://forum.pbxnsip.com/index.php?/forum/29-snmp/ on how to use SNMP with the PBX... The other idea would be to set up a port mirroring for the port that goes to the CS410 and run a wireshark there, so that you can see if the incoming INVITE really makes it to the device or not. This would help locating where the problem is.

Does the SheevaPlug run on Windows Embedded 7???

Okay, it works like this: The PBX looks at all trunks with the following algorithm: 1. If the trunk is disabled or only outbound, this trunk is not considered. 2. Then it sets the following flags: - "Matches IP": If the trunk has associated address this is set to true when the source IP address of the SIP INVITE matched one of the addresses in the associated addresses. If there are no associated addresses set, then it will use the outbound proxy addresses instead. Those addresses are all possible destinations that occur when resolving the outbound proxy address, especially including the DNS SRV candidates. - "Matches Adr": Same like "matches IP", but the comparison includes the port number as well. - "Matches the Domain" if the domain of the trunk matches the host name of the Request-URI or the domain name is "localhost". - "Matches the User": If the trunk account name is set and matches the Request-URI user part and the host of the Request-URI is not a DNS name (IP Address). - "Matches the From": If the trunk account and registrar are both set and match the From-header. - "Matches a DID": If the user name of the Request-URI matches a DID in the domain of the trunk (comparision made based on the globalized number in + format according to the country code of the trunk domain). 3. Then it classified the quality of the match: If it matches the IP and matches the From then the PBX will remember this candidate for "IP address and from match". If it matches the IP and matches the User then the PBX will remember this candidate for "IP address and user match". If it matches the IP and matches the DID then the PBX will remember this candidate for "IP address and DID match". If it matches the Address and matches the Domain then the PBX will remember this candidate for "IP address/port and domain match". If it matches the IP and matches the Domain then the PBX will remember this candidate for "IP address and domain match". If it matches the Address then the PBX will remember this candidate for "IP address/port match". If it matches the IP then the PBX will remember this candidate for "IP address match". If it matches the Domain then the PBX will remember this candidate for "domain name match". 4. After processing all trunks, it will return the result in the following precedence: - IP address and DID match - IP address and from match - IP address and user match - IP address/port and domain match - IP address and domain match - IP address/port match - IP address match - domain name match I know this description needs to be "digested", but that's the way it works folks. The bottom line is to find the "best match" (kind of least energy if you want) which is stated in 4.

AFAIK it can also run Windows CE. It would be interesting if someone got it working on Windows CE. I know we compiled the PBX also for Windows CE (though i386), but I guess it should be no big deal to compile it for ARM.

Ah, okay now got it. No unfortunately, right now you can move only a whole domain. Workaround would be to copy the domain (save and restore it), then delete all accounts except the extension; well then you have singled out that extension and can see what recordings it is using and then create it in the target domain (there is no merging of domains at this point). Very ugly, I know. If it is a valid use case, we might have to make this a feature.

If it is not in the PBX, you can also check the options on the phone (there are a lot). In this case allow two lines for the extension and leave it to the handset to reject a call or not.

No. The CS410 was already discontinued before snom was a topic. There is a tremendous range of devices that support all kinds of protocols, pricing levels and so on so we leave it to the VAR to pick what is best for the client.

Check this out: http://www.pbxnsipsupport.com/index.php?_m=knowledgebase&_a=viewarticle&kbarticleid=576 Your problem might be that Linux is cAsE-sensitive, and snomONE is not snomone.

I guess you are using NAT and you have a firewall... There are firewalls that want to help but hardly do so, just complicate things. Do you have any information about the firewall that you are using? Set the "Keepalive Time" to something like 20 seconds and see if that makes a change.

If you want to use "+", you need to escape it (e.g. "\+"). Extended regular expression... Also keep in mind that the PBX will run the presented number through the country code normalization process, and then it will return it with the + in the beginning. But the +1xxx seems to be in the right format.

Ethernet switch will be okay. I would also say with 50 % probably this has to do with the virtualization setup and 40 % something with the Windows setup inside the VM. 10 % "something else"

Yea, actually we fixed a problem in the failover area and that would explain the changed behavior. But it should be "right" now.

Well if you dont really need the failover then definitevely turn it off. The definition for a failover timeout is that the PBX received a code >= 180 within the specified time. Then the PBX acts as if it has received a 408 Request Timeout error code. If the trunk sends an error code before that, then it depends on the error code what will happen. The critical case here is 486 Busy, because technically that means that the user is busy (not the network) and failover will not change that. But the way the 486 code is used in the real life is different, that is why the error code is a little bit special in the dropdown list.

Does it work fine if you take the failover out completely?

Check if your trunk has something set in the failover section and turn it off. Maybe it is programmed to failover after 5 seconds, and a couple of days ago that was fine (because the provider was answering quick) and now the response takes a little bit longer.

You can also use G.726, this is 32 kbit/s and almost sounds like G.711. Or you can use GSM, which is 13.2 kbit/s and well sounds like your cell phone.

I remember there was a case with a USB driver that would drive the server mad. You never know! It would really be an option to try either a fresh Windows or something else like Linux.

I would turn that off; otherwise your carrier can use your PBX for making outbound calls to expensive destinations. But I dont this this is your problem. That's the setting I was talking about. Some providers send you traffic from IP addresses that are not the registrar. Do you have other trunks? Make sure that they have either the outbound proxy set or the AssociatedAddresses. Then for the incoming trunk you should see that the PBX matches it to the right trunk.

There must be a bug somewhere so that the CO line does not get cleared. Obviously then it never gets cleared again. We also have to investigate in the code; however if it should happen again, it will be a lot faster to fix it...

Spent some quality time on it... This must definitevely have to do with CO-lines. Can you check in the directory colines if there are any entries and if yet, if there is one file that contains a paramter "user"? If that is so, please remove that user, restart the system and see if that did a change. Actually a restart should clear the CO line anyway. That "user" means that this user has seized the line and outbound calls must stick with it. It must be something in this area.

It was considered "a bug" that the PBX does not stick to the seized line...

Here is a old checklist that you can use: http://kiwi.pbxnsip.com/index.php/Troubleshooting_SIP_Trunk_Problems#Poor_Audio_Quality and also http://kiwi.pbxnsip.com/index.php/One-way_Audio. For example we had a tricky case where a (stupid) IP address conflict was causing such problems. But it could also be a router that temporarily runs out of CPU resources and introduces a lot of jitter and complete temporary loss of media. We also had such cases. IMHO it is with installing a analytical tool like Wireshark and try to catch a call where the call quality is not okay. Then you can nail the problem at least from the PBX perspective. Also, the MOS score graph and the email CDR (which include QoS measurement attachments) can give you some indication where the problem might be. But I find it easier in such cases to use Wireshark to find the problem.