Vodia PBX

Option zero is to apply the latest software. I guess that has been done already. Well, one option is to move the setup to a PC-based solution. Just save the config and restore it on the other system. This is a short-term measure to make sure the customer is happy. If you have a PSTN gateway that you can use, and the call quality is still bad, well then there is a problem with the line. Of course the second step is to ask why the quality is bad with the CS410. What does the CPU load say on the web interface? Is there a QoS-problem in the setup (shared data/voice internet connection)? The CS410 has tcpdump locally on the system, this way you can get a PCAP trace to see what is going on. We had a case where a web browser was constantly requesting web pages from the CS410 in a DoS style. After moving the port away from port 80/443 the traffic was much less and the box was working fine again.

Hmm. Good use case. At the moment I have no good answer... Looks we have to add a setting that lists the preferred pickup accounts.

Well, what we need at a certian point is a transformation rule for the trunk. Because different service providers have different ways of presenting a phone number we might need a setting for that. For example, one provider would like to see <sip:+19787562777@...>, the next one <sip:19787562777@...>, and the next one <sip:9787562777@...>, and the next one <sip:0019787562777@...>. Internally we decided to use only the + form, as this is the only global common denominator.

Well that would be tough (to the extend of being impossible)...

What about just turning the DECT phone on and off? Like a hardcore DND?

Ehhh... Scratching my head a little bit. At least I think we can conclude this thing is not very intuitive.

I remember testing this some time ago and then it was okay. See if you get calls during the week! There was a problem with the interpretation when the PBX should do the call. From a users perspective, both ways of looking at it are reasonable.

The web site says "Designed only to be deployed with the Linksys SPA9000". Not sure how serious this is. Maybe it is only supporting Skinny. But if it works like the other SPA gateways it should be pretty straightforward. On the PBX side, you just need to set up a gateway trunk. In FXO, you don't have the chance to do too much with caller-ID anyway, so the trunk setting default should be fine already.

If you have a local PSTN gateway, you would use something like "<sip:12121234567@ip-of-the-gateway;user=phone>".

Of course the PBX does not care if it is POTS, cell phone or just a SIP URI (actually, there is no way of finding out). The point behind the cell phone inclusion in an extension is that the caller actually has no chance to find out that the call was redirected. The PBX user should be able to hide where he actually is. That is different from the redirection after timeout, when the PBX makes an annoucement ("please stand by while redirecting") and then actually plays the ringback tone of the POTS line (which may include comfort noise in the beginning). The biggest problem is the propagation of the caller-ID. It is a reality that most ITSP are today not able to differentiate between display-ID and network-ID, and then those redirected calls always seem to come from inside the PBX. Playing an annoucement could be a "poor mans" original caller-ID - and it would also solve the problem that cell phones tend to redirect calls to mailboxes.

Well, only the dialplan part... As VoIP becomes more mainstream and people have cell phones, hitting the "call" button on a SIP phone also becomes more popular these days.

Yea, the TSP is using plain SIP, unencrypted and using UDP. If you have a SIP-aware firewall between the PBX and the PC, trouble is pre-programmed...

"Broken" means the PBX disconnects the call? Do you see that the PBX sends a BYE? Is there NAT between the PC that runs the TSP and the PBX?

One simple workaround would be to use a manual registration (see http://wiki.pbxnsip.com/index.php/Manual_Registration, and http://wiki.pbxnsip.com/index.php/Extension#Registrations). Then the speech server does not have to register with the PBX, but you can treat the server like a registered SIP device. The "outbound proxy" is also the "inbound proxy" - at least the the sake of finding out where the call came from. The message "Could not identify user" means that the use was not found in the domain. Is 7000 an extension or account? Maybe you should create 7000 and add a manual registration pointing to the speech server. Demo license makes no difference. Also important is that you check "accept redirect" in the trunk to the speech server. The speech server is nothing else that the SIP engine of the Exchange UM. http://wiki.pbxnsip.com/index.php/Microsoft_Exchange should contain a good checklist on how to configure the speech server as well.

Oh ok, SMTP (thought it would be SIP) - if you do IP-Address based authentication, then you don't need username/password.

Hmm, what is the use case here? Is it only for the cell phone? There we still have the topic that we want the user to confirm the call because of the cell phone mailbox problem. It would also mean that the first few seconds of the conversation are cut off? Or do you want to mix it with the audio of the other side?

Report the MAC to snom. Maybe there is something specific with that MAC address.

I guess you checked http://wiki.pbxnsip.com/index.php/Microsoft_Exchange?

You should really use PnP, at least for the initial config. The address book requires that you calculate a hash over the username and the password, and that is really difficult if you want to do it one your own.

What phone model?

I would factory reset the phones and then if it still not works power-cycle the switches. Also, make sure there is no VLAN involved here and the netmask is set correctly in the DHCP server.

Are you using buttons or dialog-state? I tried this here with buttons and it seemes okay to me. Try hitting the save button on the button profile again. If you change (or create) an account that you list there after hitting the save button, references might be broken (we'll fix that problem in 3.1 as it really can drive people nuts).

Hmm. Hmm. Hmm. But you do see "Set scheduling priority to ..." on log level 5 after a start? That should tell the OS that RTP is more important than anything else. I remember there were some patches in the kernel with the scheduler. Maybe they had the side effect that the RR scheduling does not work properly any more. We have to check.

I would use: Pattern: x11, no replacement. That should already do the work.

:nailbiting: Maybe this week.