Vodia PBX

The "Use Proxy" method comes from the phone it seems, and AFAIK there is a setting on the phone that restricts inbound traffic to come from the "proxy" (AKA PBX). You can try to change the setting on the phone if it then accepts the traffic from that address.

I would say 95 % yes.The problem is not so much the average bandwidth, it is the peak. For example, if you have to send 1 KB every minute, that's usually not a problem. However when you are in a call and you have a bandwidth of lets say 128 KBit/s, then that packet blocks the traffic for 8000/128000 = 62.5 ms. You will hear this, the jitter buffer on the other side will get a lot more pessimistic and you'll have a voice delay of probably 60-70 ms just because of this. Well, if the provider supports "outbound" (RFC5626), then everything should be working beautifully. However, I am not aware about any provider that supports this great solution to NAT yet. Anyway, looking at this problem: # host -t NAPTR dn01-03.fs.broadvox.net dn01-03.fs.broadvox.net has NAPTR record 70 50 "s" "SIP+D2T" "" _sip._tcp.dn01-03.fs.broadvox.net. dn01-03.fs.broadvox.net has NAPTR record 50 50 "s" "SIPS+D2T" "" _sips._tcp.dn01-03.fs.broadvox.net. dn01-03.fs.broadvox.net has NAPTR record 60 50 "s" "SIP+D2U" "" _sip._udp.dn01-03.fs.broadvox.net. Whow! We have a provider that supports UDP, TCP and even TLS! TCP is the preferred method here, so the PBX continues looking up the TCP record ajnd finally comes up with an IP address. However, it does not look like they support outbound, and I guess if you want TCP working you need to run your PBX on a routable ("public") IP address. I would say for now the only way for you to get this working is to fall back to good old UDP. You can do that by using "sip:dfw01-03.fs.broadvox.net:5060" or "sip:nyc01-03.fs.broadvox.net" as outbound proxy of the trunk, whatever is closer (Dallas or New York I guess).

Yea, we probably have to read the resolv.conf file practically every time we nede the DNS server again. The workaround for now could be to delay the startup of the PBX, maybe with a sleep in the startup script.

Right, for inbound calls you can use this link: http://wiki.snomone.com/index.php?title=Inbounds_Calls For outbound calls it is essentially on how you service provider or PSTN gateway wants it represented: http://wiki.snomone.com/index.php?title=Outbound_Calls

Well that feature was put in so that Joe Doe user cannot log into the web interface of the phone and screw things up (and then call you)... Anyway, you should have set a password after the installation; however if you have file system access there is a trick you can get that password: cd into the worknig directory of the PBX then into the domains dir. Look at the XML file, it contains teh password for the provisioning. Same for extensions. But there you can click on "send welcome message" in the PBX web interface to send the user an email with the password. Default passwords are not a solution, as they are not a secret (thanks to the-search-engine-of-your-choice). Thats why the PBX creates pretty random passwords during the first boot up.

Hmm... The PBX reads the resolv.conf during the start up. Maybe it is not there when that happens? Can you check anyhow if the DHCP client is slower than the PBX startup? Maybe give it a quick shot with a static IP configuration where the /etc/resolv.con is written 100 % before the PBX starts up?

AFAIK yes. You should see in the trunk section the rates table, and in the settings for the extension the prepaid balance. When the balance goes to zero, the PBX will cut off the call (give a warning one minute before that happens).

Inbound and outbound are different topics. For inbound, the "alias" is the way to go. For outbound the "ANI" is the important setting. In both cases, you also need to adjust the trunk settings to deal with the operator's (or PSTN gateway) style of dealing with these items.

First of all, what is in your /etc/resolv.conf? That is where the PBX is reading the DNS configuration from. Looks like it has problems reading this file. If it cannot read the DNS servers, it starts to use some well-known addresses, including the one that you see above. If you want to disable IPv6, you can use the option "--ipv6 false" in the script that starts up the PBX.

Yea thats a known issue. Probably something in the AJAX part where it fetches the page from the server, it is on the to-do list.

If you want to make changes to all phones, I would just edit the template from the web interface (admin/web/templates). You can edit the snom_3xx_phone.xml, that is probably the easiest way to get things done.

That sounds like the (phone) address book has that number stored. Does it make a difference if you power-cycle the phone (to make sure that there is nothing left in the RAM)? You can also try to factory reset the phone, then PnP it (which should in theory happen automatically) and see if the problem goes away.

If you want to do that you need to change the configuration templates. They are available through the web interface (admin/web/templates). Then you can use whatever is available as settings locally on the phone.

The snom phones use CSTA for this, this is called "as-feature-event". If he is using PnP and uses the redirection menu of the phone, it should happen all automatic. Disadvantage: He needs to enter the cell phone number over and over again. The same CSTA is also used for DND, which is not the solution here because DND will also inhibit the forking to the cell phone. Maybe you should tell him that he can already have the cell phone forking today where the forking to the cell phone is delayed by a few seconds, which should have practically the same effect as the redirection and where he does not have to enter anything on the phone before going home.

I would generally use the email reporting for call legs to find out what is going on. In order to do that put something like "mailto:ndemou@abc.com" into the CDR URL in the admin settings (make sure that the system is generally able to send out emails). Then you will receive emails for every call leg made on the system. The email will have an attachment which shows you a lot of information about the call, including the reason why the call got disconnected (SIPterm). The SDR will tell you if the PBX initiated the call disconnect or the other party. Also you should pay attention to the other email warnings the system sends out. For example, if the system actively disconects a call because of one-way audio, it would send you as the admin a email warning (admin/email/messages in the web interface of the pbx). That would make it a lot easier for you to find out why calls get disconnected.

Whow, that should not happen. The phone should not increase the counter when it sees the Reason header in the CANCEL request. If you can, check if that header is present; the easiest is to log into the web interface of the phone and check the SIP trace. Maybe you can paste the CANCEL request here with the firmware version of the phone and then we can see where the problem is.

No problem.

The PBX supports only "pull" where the phone has to fetch the files during the provisioning steps. Is this topic only phone related? In that case you can try the forum at forum.snom.com.

We are have no problem making head builds available, something worth presenting would be a matter of weeks. It is actually not clear if we come out with a kind of "Service Pack 2" image (4.3) for the 4 release of the PBX. There it might be included, but I would say that will be something for summer.

Well, pbxnsip supported it and it was working great. I dont see a reason why it should not be available for snom ONE. Though I dont know the download location...

Well honestly, we are not masterminds when it comes to operating forums... (focus on the VoIP stuff). It is not secret we are using Invision Power, maybe they also have some bugs in their software . I know that other users are able to attach files as long as they are not too long. Otherwise, send an email to support@pbxnsip.com, this email still works and maybe also point out which other email addresses faulted.

Yea the usage of / and space is confusing. When you create an account, the slash means that it should create alias. When editing the account, a space means that it should use alias, and a slash would have the meaning that it is part of the name.

We it is in "head", but head is not in a shape that we can release. Porting it back to version 4.2 always carries the risk of bringing in instability, and that is what we want to avoid there as much as possible.

In the CDR definitevely not. The CDR only contains the information if the call got connected or not. The only way I can think of would be to log to the file (or named pipe) as well and then search for messages with the same Call-ID and dig the information out from there.

CSTA is not for the light hearted... There is a reason why professional call center solutions easily go into the six figures. There is plenty of documentation available on this, though.