Vodia PBX

Regarding billing, RFC3325 explains that there is a difference between hiding the number and telling the provider who to bill. We do support RFC3325, so that should be possible. There is another (IMHO more elegant way) of telling the provider who to bill, I believe it was specified in the scope of IMS. This is called the "ICID", which is essentially a token that the PBX will present when it uses the trunk. This token can be assigned by the provider and it makes 100 % clear who is sending the call. Unfortunately, this method did not make it to most of the providers, it is a shame. Passing *69 upstream to the provider might have the side-effect that it blocks the caller-ID for all users from the PBX that are sharing the trunk. In other words, you neighbor might accidentially turn it on just after you turned it off and you are making a phone call now.

I dont get the part where you say you cant to call from one trunk to another trunk. From the description above, it seems that a simple alias does the job.

The other thing that you can do very easily is to temporarily change the time zone to something like Chicago without DST. Dirty workaround, but it should fix the problem immediately without reboot of the PBX.

Before you do that, take a look at the XML in the file system. The point is if the other emails work for the same extension, weneed to know what is the matter with the flags for the other emails. Or maybe that extension does something like hotdesking. It is in the extension XML.

Well, that's your problem now: "Received incoming call without trunk information and user has not been found". That means you must have a trunk that accepts traffic from 127.0.0.1 (or ::1 in IPv6). In V4, you can explicitly put the 127.0.0.1 into the trunk now (at the bottom, "Explicitly list addresses for inbound traffic").

Well the question is if it works for other phones, e.g. Cisco or snom. Maybe this problem affects only Polycom (potential offset problem)

This is in timezones.xml: <zone name="EDT"> <description>Eastern Time Zone</description> <gmt_offset>-18000</gmt_offset> <dst_offset>3600</dst_offset> <dst_start_day_of_week>1</dst_start_day_of_week> <dst_start_month>3</dst_start_month> <dst_start_time>02:00</dst_start_time> <dst_start_week_of_month>2</dst_start_week_of_month> <dst_stop_day_of_week>1</dst_stop_day_of_week> <dst_stop_month>11</dst_stop_month> <dst_stop_time>02:00</dst_stop_time> <dst_stop_week_of_month>1</dst_stop_week_of_month> </zone> Not sure if that reflects the 14th?

What time server are you using? Dirty workaround could be to set the time locally on that time server. Are other phones doing okay with the same server?

Oh so you see the other emails in the log but not this one? Maybe just try hitting the save button for the extension; maybe there was some old data from previous versions. Can you find the XML in the extensions directory? Maybe there is something wrong in that table entry.

Well that is a short question that reqires a long answer... The bottom line is that the LB just dispatches the SIP and HTTP traffic to the right PBX by looking at a table that contains all users of the cluster. The PBX continues to perform the SBC jobs, so the LB does not actually take load off the PBX, it just balances it. If you are able to tell your users what their outbound proxy is, then there is no need for a LB. It is only interesting if you have a large userbase that essentially just get a DID with a mailbox, then the LB makes a lot of sense.

If it gets other emails we can rule out that the email address or server address is wrong. Did you check the SPAM folder? What could be different here is the content-type or even stuff like line breaks. Do you have some extrem long lines in the email? If the emails are not encoded with base64 there could be a problem with the line breaks. If you can get a Wireshark when the email is being sent out it should be pretty easy to see if the email was actually sent out to the server.

Right now the PBX is writing only very important messages to the syslog like admin logging in (using the standard syslog functions). I guess you could redirect those messages though some OS-level functions to an external server. Though I guess this is not what you are looking for. And this does not work in Windows. Looks right now you have to use the file-based method.

Well, my first comment is that the number of physical hardware NIC is not really so much the point. You can, for example, add another IP address to the same NIC (just make sure it is not in the same subnet). If you are using a service provider with a SBC (like callcentric) then you don't even need a public IP address. They take care about it; though I am sure they would not complain about it--if it is setup the right way. I am definitevely a big fan of routable IP addresses; IMHO they are a must-have if you have remote users that register from home. When it comes to firewall protection, I still wonder what that exactly is. The only thing that comes to my mind is TCP/SYN flooding protection; hower a recently updated OS should also do the job on this one. If you check with netstat that only relevant ports are open to the public, the risk not having a firewall in fron of the PBX seems absolutely okay to me. Whenever I hear "firewall" I ask if they are SIP-aware and then my first recommendation is to turn it off (usually that solve a lot of issues right away). Though I am not the big experts on firewalls; to me this is kind of pill. Maybe someone can enlighten me.

You can see it in the 4th graph in the status screen (now on a seperate page). And we also send the data in the SOAP messages.

In V4, the PBX will send two CDR emails. One for the extension leg, the other one for the trunk leg. Both of them may include RTCP-XR information, for the local call and for the remote call. The PBX does not calculate a "total" QoS score for both legs, it sticks to it's nature as a B2BUA.

No, you can only control the core for RTP. Everything else is "automatic". IMHO that makes a lot of sense.

The question if a star code matches or not is non-trivial. If the PBX would allow exceptions, it would make it very difficult and random to find out why a star code was not forwarded to a trunk. Because of that, the PBX treats eerything starting with * as a star code. There is a very simple workaround if you want to pass a * to the carrier, just use another prefix instead of * (e.g. 99).

That setting controls the affinity for the RTP thread only. All other threads can now run on different cores. But because of the internal database locking, the biggest effect is essentially in the TLS processing. And under heavy load, the RTP thread will run on a different core than everything else.

Looks like we need fix the manual

Probably something like 8.2.26; but we are still testing. If you want to try the latest, go to http://dms.snom.com, username beta, password the same.

Okay, sorry I wasnt very clear... Of course you can use the symbol * in a pattern. In a simplyfied pattern, it has a special meaning. That means when you use the *, you won't match the * that someone dialled on the phone. But the main point is that the PBX does not pass numbers to the dialplan if they start with a "*". The star at the beginning of the dialled number tell the PBX that this is a special code on the PBX that needs to be processed locally.

Well, whatever. If there is RTCP available from the carrier, the PBX will do its best to report about the QoS. BTW it is RTCP-XR that gives you the real details about the QoS.

The pattern can never start with *. * is always handled internally by the PBX. You can have a pattern like 9969.

I see two points here: 1. Why do you run the PBX on a private IP address? I guess the firewall supports a transparent mode when the packets are forwarded without changing the IP address (no NAT, just router mode). That is the best solution, as the PBX runs as if it would be on a routable ("public") address. 2. Most service providers today use a session border controller to deal with devices that cannot present a (useful) routable address. I know that callcentric does this; for callcentric you have to do nothing, it will "just work". Well, at least if the firewall is not SIP-aware and screws it all up...

V4 did not add much on the feature side of the PBX... However now you should be able to attend-transfer someone into the conference room, including entering the PIN.