Vodia PBX

Try to put it into the trunk setting, for example 4151234567 (or course use the DID assigned by Broadvoice). Then give it a shot. If it does not work, set the domain in the trunk to broadvoice.com or the IP address of the registrar. Hopefully then it will work.

Whow, not it suddenly works for me: $ host -t SRV _sip._tcp.netsmart.ca _sip._tcp.netsmart.ca has SRV record 10 10 5060 ocs.netsmart.ca. Maybe it took a while until the DNS rippled through the system!

Hehe. We were thinking about playing back the VM recording message like you know it from your voicemail machine at home. Probably in an office environment (cubicles!) not very suitable if everyone can listen in. Anyway, it might really be relatively easy to add a star code that barges into the call. You would have to dial a star code in the end, but it would solve the problem. It might be even easier to use this from the PAC/WAC. Then even drag and drop would be an option.

I am not so sure about that... If you want to have OCS ring both the desktop phone and communicator, you need a OCS-compliant desktop phone; the pbxnsip PBX can not solve this problem for you. OCS is the PBX in this case. pbxnsip works more like a PSTN gateway.

Two or three or more NIC are no problem. In today's setup, you will have more and more real and virtual NIC, like for VPN tunnels, IPv6, WLAN and so on. I would definitevely recommend to have the IP setup on the OS network level right. When you send a UDP packet (say, a DNS query) you should see the right IP source address in the packet. All those tricky setups with some port forwarding rules, non-routable addresses or even those instable STUN refreshing modes are all not very maintainable, there is always something going wrong and you spend hours or even days troubleshooting it. In the end a lot more expensive than getting a proper network setup right away.

Yea, the pbxnsip buttons don't support Action URLs (yet). That's why we have to go into manual mode... The platform does not matter. Maybe check out http://www.pbxnsip.com/docs/pbxnsip_adminguide_v4.pdf, there is something about the usage of the tftp directory.

Data? The VM includes the (local) file system, which also includes the data. Nevertheless, it would be possible to also have rsync move everything into a safe place from time to time.

Is this the echo from the beep after the greeting?

Seems this will require a software update. We could reproduce the problem and are working on a fix.

snom 300 automatic provisioning the buttons 3-6 is a tricky topic. The easiest solution is probably to put MAC-dependent configuration files inthe the tftp-directory to bypass the automatic generation for the configuration for the phones in question. You can use the files in the generated directory as templates for this and just edit/rename them.

Just tried that here... on the latest and greatest is works as it should. What you can try is to use the mailbox prefix if you want to make sure that the call really goes to mailbox (so use 820 instead of 20 as the final stage). Maybe that makes a difference.

When I try to resolve the address manually I get the same: $ host -t NAPTR netsmart.ca $ host -t SRV _sips._tcp.netsmart.ca Host _sips._tcp.netsmart.ca not found: 3(NXDOMAIN) $ host -t SRV _sip._tcp.netsmart.ca Host _sip._tcp.netsmart.ca not found: 3(NXDOMAIN) $ host -t SRV _sip._udp.netsmart.ca Host _sip._udp.netsmart.ca not found: 3(NXDOMAIN) $ host -t AAAA netsmart.ca $ host -t A netsmart.ca netsmart.ca has address 66.135.59.238 netsmart.ca mail is handled by 10 mail.netsmart.ca.

Well I guess that address is not known with the provider (very understandable). Try to use the ANI field and the domain name in the trunk settings to put your username there.

I can tell you that I was totally against virtual machines for the PBX. I had a lot of concerns against jitter, performance, CPU resource reservations and so on. Until I saw a failover taking place. Suddenly it became clear to me what this can do. Especially because we have a relatively small system! Forget about all those complicated scenarions where you try to store the relevant state information all the time in case you have to failover. Much to complicated and you never get there! Just fail the whole process over and thats it. The best part: It works--today. No programming required, no adding compliated DB interfaces bla bla. It just works. You can failover keeping callers in the ACD and all calls stay up, and all registrations stay up as well, even if they are TCP/TLS-based. Try to do this with a database. VM are not rocket science any more and they are not expensive either. AFAIK you get them for free from Microsoft and maybe also from VMware (not sure what exactly you need for failover).

Thats actually the way it is handled internally anyway. Maybe when we clean up the park orbits we'll also intro the account type "CO-line" and then have it's own config page where you can set the parameters for the CO-line (currently only the trunk).

You have to use the "button" mode for the (virtual) button then.

You can import a CSV list that set the relevant settings in the accounts.

So is it "481 Call/Transaction does not exist"? Can you attach the SIP INVITE and the response code here so we can see what messages are going back and forth between the PBX and broadvox?

I think the biggest innovation is that it runs nicely in a small Windows virtual machine that can failover quickly. It is a software component that can co-exist with a lot of other stuff running on the same hardware. The other innovation is that it was designed to run for some time without the need to reboot (usually the need to reboot comes from the Windows updates ). P.S. Vacation?

Not yet, and I think this will be very complex (if possible at all)... For example if you seize the line, on which trunk the line should be seized?!

Can you open a new topic for that? I think it does not fit in this discussion thread. Thanks...

Is there anything in the DNS that expires after one day? Maybe a problem with DNS then. If you can, try to change the DNS TTL to another value and check if that changes the frequency of the problem. DNS seems like a very well established protocol, but there are still cases where the router refused to relay certain messages and UDP fragmentation (DNS is using UDP after all) is causing issues.

No problem with that WDSL, yea this will probably help. Something for the to-do list. You mean the RESTful services coming from Sun? That could also be a possiblity, though not trivial. The problem is that there is no real-time suitable library available for the PBX, if we are e.g. using libmysql we are poisoning the memory management (no garbage collector for C...) and then after a couple of days you have to reboot the system all the time. And the PBX will still have to cache everything, using the database every time will slow down the processing dramatically.

You can dial and you can hang up again. Thats pretty much it. It is good for outbound dialling, for example from the Outlook address book. I heared TAPI is dead, at least in Redmond. CSTA is the new thing.

Certificate-based authentication is next. Then you can just import the public key into the account and the PBX will trust it and skip the authentication.