Vodia PBX

I do see the feature benefits. But well, thats where it ends with the shared line emulation in VoIP... You cannot imagine what it would mean to get that working in SIP! Unfortunately, things are a lot more complex than in the analog world, where you could really solve this with some copper cable.

We though about this some time ago and even talked to Sangoma how this could be achieved. The answer was that it would be very difficult to get that experience working. The way it is with the PSTN gateway trunking, there is not standardized way to go offhook. The only workaround would be to dial a "ghost" number and then essentially have the call connected and do the dialling with DTMF. No back key then! And for digital lines line E1 the dialling process will work differently anyway. So the bottom line for us was: This is not a analog line system, so lets not try to emulate every feture exactly like an analog system. The good news is that additional features like the back key are available with the way it works now.

Well, there is another workaround... in ACD A after ringing for 60 seconds, escalate to ACD B; then in B after ringing for 60 seconds, escalate to ACD A. And so on. If there are not too many people in the line, it is reasonlable.

Absolutely. Having phones ring for several minutes cannot be the answer. My suggestion is to use another ACD as "escalation" ACD, and there I would include cell phone numbers or at least additional agents. You can set the event when the call should be redirected/escalated from the web interface.

Hmm. Did you select "remember the agent" in the ACD? This is how non-anonymous numbers can advance in the queue. On the snom phone side. 8.4.32 is out (at least as serious beta), but I dont think that can be the problem here.

Yes that should be okay. Maybe the phones get "nervous" after ringing for too long... although it would be really strange if that happens only for anonymous calls.

Sounds like a problem with the packet ordering on the incoming side. When the PBX encodes that with the GSM codec, it usually generates such strange sounds. Solutions: a) Upgrade to the latest 4 release (which as a fix for this) or switch to uncompressed voice recordings which makes the effect less obvious.

Well, from what I see it look like you have the wrong password. The service provider responds with a challenge, then the PBX answers and the servie provider challenges again. This is typically the case then password is not correct or you have chosen the wrong account.

Having phones ringing for a longer time is a problem especially if you have the call on the trunk side not connected yet. Many carriers allow ringing only for 60 seconds. Maybe there is a problem in this area.

Well, you probably experience the "NAT" problem in VoIP. There has been a lot written about this, and you might also check out these links: http://kiwi.pbxnsip.com/index.php/Office_with_private_and_public_IP_addresses, http://kiwi.pbxnsip.com/index.php/One-way_Audio. But in short, you have the following options: Get a routable IP address. In an ideal world, you just grab a IPv6 address and your service provider does support IPv6; but in the world we are living in lets be realistic and just get a IPv4 address, add the IP address to your server with the right routing, and you have a rock-solid setup. Change your service provider. Many service providers use a session border controller to help you making your life easier and the system more stable. Pretend that the PBX has a public IP address, but without having it. That can be very stable, but it is usually very tricky to set this up and you must be a master in configuring your firewall. Many service providers recomment to use a STUN server. This is reasonably okay for softphones, but IMHO for a mission critical PBX with requirements for the uptime unacceptable. Because you dont know what your firewall is doing with STUN traffic when there is a lot of traffic, we have found this method extremly support intensive (and frustrating) and finally took it out from the PBX.

We have some of these features here and there. For example, when the PBX disconnects a call because of one-way audio, it does send a email with the SIP trace attached. But for regular call clearing, there is no special report being send.

That is quiet normal. By the time when SIP was specified, the engineers were optimistic that by the day that SIP would be used by anyone, everyone would have IPv6 and there would be no need to refresh bindings so quickly. In the meantime, we have to live with such dirty workaround like refreshing every so-and-so seconds.

Very loud white noise is usually SRTP that is decypted the wrong way. I would gibe 8.4.32 a try, could be that something got fixed there.

To me it looks like the To header is really empty. Which is of course not okay. What should be there? Are you sure you entered a valid email address as the destination? Also there is a typo in "comapny.com.com", I guess this is not the issue here...

As we found recently, there is a special behavior in Bria that it registered two contacts at the same time (one with the expiry 0 and the other one with the real expiry value) if Bria detects that is IP address/port has changed. If you start Bria up the first time, it should have only one contact and everything should be fine. Apart from that, you should turn STUN off on Bria, because snom ONE has a session border controller functionality already built in and the soft phone does not have to find out what its public IP address is. And snom ONE has a built-in discrimination of third party (where the user-agent string is not snom), please feel free to let the snom marketing know that this is not a good idea .

well, rebooting the PBX is not really the solution; it would be better to know what the problem is. From experience, DNS could be a problem; you can try to set the outbound proxy as a IP address and see if that narrows the problem down.

Are you using the name "localhost" in the PBX as alias name? If not, do you have more than one domain? If you dont use the magic name "localhost", you must be clean with the setting of the domain name in the phone and possibly (if you dont have set the DNS names up right) the outbound proxy.

There were a couple of discussions on the forum about this already, you may use the search-engine-of-your-choice to find some tips. http://wiki.snomone.com/index.php?title=CSTA_api also has some important information. The CSTA specification is publically available.

There is a old article about this topic here: http://kiwi.pbxnsip.com/index.php/Office_with_private_and_public_IP_addresses. Essentially it says, you can have multiple IP addresses even mixed IPv4 and IPv6 on the PBX, no problem there, as long as the operating system routing table is set up properly (especially for UDP). If you did not do anything to the ports, and just bind them to any IP address, the move should be smooth and I would not suspect this is a problem with the IP subsystem. Probaby on the other server, there is another server blocking ports 80, 443, 5060, 5061 or 389 (LDAP). You can use netstat to see what is going on on the server. Also you can run the PBX manually with the option --no-daemon and --log 9 to see what happens when it starts up.

Version 3 is already a couple of years old... I would really suggest you try to update to version 4, first in a safe test-system (not operational). The CDR structures have changed since version 3, but for a reason and it is not likely we'll change it so soon again. So if you have to make changes for version 4, it should be a good investment.

What is very efficient is to give the extensions alias names with the DID. For example "41 9781234567" could say "extension 41 has also the alias name 9781234567", and then when the call comes it, the PBX would try to find the account in the account alias list. That works pretty effient (internal DB lookup), and you can scale that easily to mor ethan 900 numbers. There is also a way to bulk-import accounts through teh CSV import feature, so that you essentially have to come up with a CSV file for you extensions and import that.

There should also be a way to use a new firmware. 8.4.22 is not the latest AFAIK, http://wiki.snom.com/Firmware/V8/Release_Notes/Change_Log_V8 lists the things that have been fixed in the meantime. If 8.4.31 still has the same problem (sorry I dont have a 820 here for checking), you need to open a trouble ticket for the phone and ask them to provide a fix.

The URL method is a simple way to get the click-to-dial functionality done. However, if you want to do serious integration, a look a CSTA is a good idea. There you have much more control about the device, and you also have the chance to see incoming calls.

There is a snom App coming out for Windows that could make your life easier there. PM pbx_support for a link.

This is definitevely a problem with the SRTP MAC decoding which seems to be wrong. The phone actually should never play out anything if the MAC (like a cheksum of the SRTP packet) is not okay. The problem is obviously that the rollover counter increments (happens every 22 minutes @ 20 ms packets), and the phone gets out of sync. I believe in e.g. snom 821 or m9 it should be fine, but the 820 has a relatively old SRTP implementation that obviously need some extra TLV. If you have a 821 around, this is definitevely worth a try.