Vodia PBX

This is a general SIP problem. Are you using snom? There is a RFC for this, but most devices don't support it. snom has some bugs in this area, abut at least in principle it is supported.

Can you get a WAV file and attach it here? It could be the rollover counter of the SRTP. First guess.

Check out http://www.911enable.com/. They have the documentation on how it works.

Yea, it is amazing that web-based admin can scare professionals off. They prefer remote desktop when they can have HTTP. Version 4 has a new web interface, designed by a web designer (not a C++ programmer ). Maybe that will help to present the buttons in a way that is easier to digest.

My advice: Keep in mind this is a small embedded system. So: be careful with large hunt groups, transcoding, recording. In other words, use G.711 and keep groups small. FXO is always a tricky part. Depending on carrier, caller-ID and hangup this will require some fiddling... Well, and this is Linux. If you need to do anything advanced, get Putty ready. And if you plan to run it on public IP, don't forget to change the default password also on the Linux. We are using it every day.

Nope. I guess this will be pretty boring as version 3 does not fully support video yet. You first have to establish a audio connection before you can include video.

Well, you should think the way the PBX processes the request. If you want to ring the receiptionist during office hours, you would probably "hunt" her first (pretty small hunt group), and if the night mode is active send the call to the auto attendant (on holidays) or to another hunt group which rings the whole office. What most customers do is that the hunt group for the receiptionist also rings other people in the office after some time. This covers the cases when the receiptionist is temporarily unavailable (everybody needs a break).

This is available, but only in a pretty unstable version 4...

If you want to have a special greeting for the holidays, you should set up a service flag for the holidays and specify 00:00-24:00 for Monday-Sunday and list the holidays. That means "we are open anytime, except the holidays". For example, this might be the service flag "123". The other service flag has the usualy 09:00A-5:00P settings for Monday-Friday. Lets call it "124". Then put that service flag first, so that on any time during the holidays the caller will hear the holiday greeting. Then put the other regular service flag begind this flag, Service Flag Account="123 124" and set the redirection accordingly, Night Service Number="130 131" (130 for the holiday and 131 for regular days night mode).

I guess you turned the loopback detection off already (admin settings). Does the PBX received the request from the proxy as well? You can see that in the "Rx" in the log. If the request also comes from the proxy, then it should work... Loops are a dangerous stuff. It can very quickly consume a lot of resources. That is why the PBX has a special settings for that. If you have some leisure, check out "Max-Breadth" in RFC 5393.

We did put that into the template. FYI it is only for the handsfree mode. You can check if it made it into the config file by checking out the file in the "generated" directory.

Multiple domains are just a problem with Cisco. You cannot use a domain name! You cannot use a domain name! You cannot use a domain name! I don't know what Cisco was thinking, but that is the way it is. Set up multiple domains, and set up multiple IP addresses, name each domain after the IP address. We are hoping Cisco comes out with a firmware that supports DNS names in domains. Every crappy phone that I know supports this from day 1. It would be good for their reputation as a technology company.

You probably have set it up for 3-digit dialing (this is a domain setting in the PnP setting area). You may dial numbers by starting with 1. For example, you you want to dial (978) 746-2777 then you would enter 19787462777. If you don't want to have this behavior, you can change the PnP setting to "user must press enter". Then the user may use the phone like like he uses a cell phone. Enter the number, edit the number, and when done start the call with the green button.

T.38 has been invented for a reason. The reason is that SIP trunking very easily looses packets. If you loose one packet when receiving a FAX, the rest of the page might become completely black (or white, if you are lucky). The CS410 does not change anything regarding echo compensation or silence suppression. Once the two calls are connected the PBX happily passes the audio packets from one side to another and that's it (unless you are performing transcoding). If the provider performs echo compensation on a FAX this might be an issue. Well, that is a major bug that they should really fix. Right, unfortunately in the SIP world Grandstream is not the only vendor with problems implementing UPDATE correctly... Check the pbx.xml file to see what the current value is. The only thing that I can think of is transcoding. But if you are using G.711 on both sides, the signal should not be changed at all. The PBX also does not perform VAD, and does not advertize this. Well, FAX is a problem in the VoIP world, this is not only a Teliax problem. T.38 does solve the problem of packet loss and it makes FAX possible over the regular Internet. T.38 sounds like a solution that they should support, but the interoperability in T.38 is lously. And there is not even a way to encrypt T.38 packets like RTP and SRTP. T.38 does not even use RTP.

Probably the usage of the snom 360 sidecar will also expose this problem (see the other topic from today). There must be something wrong with the DND indication.

IMHO the whole CO-line emulation is a little bit historic. Today they are virtual anyway, and in SIP there is not really any CO-line. In large PBX systems, there is also no CO-line monitoring (think about companies that may have 120 lines). The only point I see in CO-lines is a easy way of parking and picking up calls. Someone shouting in the office "Joe, Fred is on line 3"... An attended transfer would also do. That does not sound like a feature to me... I believe I have to dust off one of these sidecars.

It could be that the phone only sees the notification for the LED. It should be easy to see if that is the problem. Check from the phone's web interface if it receives a INVITE message. If not, then the phone somehow is not included in the list of devices that should ring. From there on we can dig deeper.

We have such a HT in an office, and it works with T.38 (though we have to reboot it from time to time in order to keep receiving FAX). The CS410 PSTN gateway does not support T.38; therefore you must use G.711 for the FAX. If the FAX is in the office (same LAN) that should be okay. I remember there are a couple of settings for the HT regarding FAX. Maybe double check and make sure it does not use T.38.

What was the trick? Something that others also might stumble into? You can "drill deeper" by entering the next search digit. Then the PBX will refine the search. Don't push the digits too fast, you always have first to wait for the next XML page to show up before your can request the next one.

For CS410, there are special files available, just next to the ZIP files in the software download section.

Of course the PBX can only display what it gets. AudioCodes gateways are pretty flexible, there must be a way to make the AC send the correct DID number. But I am not the AC expert. In the end the PBX just uses the information in the From- and To-header to display where the call comes from and where it goes to (the Request-URI is used for the routing, not for displaying). My suggestion is to keep an eye on the From/To header and try to change the AC setup. Yea, this should make no difference. This is more for outbound calls. The CO lines do not influence the display of the caller-ID.

No. We had that in the beginning, but most customers were complaining they don't want to hear it. People are so impatient today!

Those numbers that should be invisible (also for the dial by name) must be listed in the setting "Accounts that cannot be called". And also, you can tell the PBX how many digits it should collect before starting to search ("Start Search"). The PBX should be searching in both first and last name. IMHO the whole first name, last name topic is debatable. It would be better to have just the name (just one string). There are so many middle names, McXXX and Prof., Dr. and von zu.

When inbound calls don't stick to the CO lines as they should that smells like a problem with the identification of a registered trunk. There are some service providers that ignore SIP URI parameters (which is definitevely not RFC-compliant), and then then PBX has problems matching incoming calls to the right trunk. Check if there is a "line" parameter on incoming calls. And also the PBX talks a lot about the trunk matching in the log file if the log level is high enough!

That looks okay... Try turning the logging on and see how the PBX processes the dial plan when the user dials a number. Maybe wrong assignment of the dial plan to the user or maybe the wrong trunk in the dial plan.