Vodia PBX

CSTA just runs on the HTTP ports, e.g. 80 and 443 (if you want TLS).

That actually looks pretty good. You can verify what has been sent in the "generated" directory in the working directory of the PBX. There you can also see what extension has been provisioned. You should also take a look on the web server of the phone. To me it does not look like a problem with the provisioning, there might be something after that (firewall stuff for example).

Most providers send something like sip:anonymous@ip-adr. Then it is clear that the caller-ID is unknown.

As stated in the other post, PM us and then you can get a build with a fix.

We have something working in the lab already. Firmware upgrade on the phones will probably not help as the 8.4.31 has just been released and I would not expect another one for the next couple of months. We can give you a build of the 4.2 branch with a fix, if it is urgent to make the customer happy (private message pbx_support for that).

As long as it does not have to be escaped in XML (& < > ' ") it should be fine!

So why does the phone not include the rport parameter? Maybe it was turned off (http://wiki.snom.com/Settings/enable_rport_rfc3581). As a result, the PBX sends the response back to the port that was advertized by the phone (according to the RFC). Generally, I would suggest to factory-reset the phones and then use plug and play for the phones (including the upgrade to 8.4.18). You can try this with one phone and then if it solves the problems then you can include the other phones as well.

Well, here is the problem: There is no username in the SIP URI of the From header. So the phone falls back to display the IP address. IMHO not beautiful, but what else should it do...

Are they just off by one hour or are they completely off? In the first case that would be a problem with the nitty gritty details of the daylight savings. In the latter case, muts be a problem telling the phones where the NTP server is and then also reaching it. Also make sure that the NTP server has the right time...

Unfortunately, G.729 is not a free codec and snom has to pay per concurrent call. AFAIK there is no license model available that allows paying per extension or even per system.

If you want to use broadband, the most important topic for you will be "quality of service". Voice packets are more critical than for example, email packets. If someone sends out and email with a 20 MB attachment (upstream traffic) or downloads some huge files from the Internet (downstream traffic), you want to make sure that the voice does not get interrupted by this ("Ey!!! Can you stop downloading MP3-files, I am having an important phone conversation here!!!"). While that might be acceptable in free home services, it is not when it comes to business-critical applications. Some people forget this and create a lot of frustration with customers.

We tried it out. The PBX does send the INFO message, however the phones don't respect it. Only with the old snom-proprietary method it works, the RFC-method does not work. Now that both the PBX and the phones comes from one company, obviously someone needs to throw a coin and make a decision who fixes it...

You need to see something in the log. Did you also turn the SIP logging on (for the SIP packets)? If you dont see anything, the packet source either was blacklisted (admin/settings/access) or did not make it at all to the PBX. If you are behind a firewall ("NAT"), then that is a big topic and the answer is not so easy. You must see something in the log. Do you see ICMP packets in the wireshark? Maybe the port is for whatever reason not open.

Is this an environment where the PBX has multiple IP addresses? There is no REGISTER message in the snomONE scenario. What is the output of "route print"? There is definitively something wrong in the network setup. Even the RTP statistics coming from the phone show that there is a dramatic packet loss. Also what is the outbound proxy of the phone that sends the "use proxy"? Did you plug and play it with the PBX? Or did you at least factory reset it before registering it to the PBX? This is is a pretty much classical setup and should work without problems pretty much!

I would start bumping up the log level to 9 and take a look at the logs in the web interface. The PBX tells you then step by step what it does to find the right extension and if the country code was in the right format. Because this is not a live system obviously you won't get flooded in log messages.

Looks like you have to set the "Send call to extension" of the trunk (if you want to send all ten numbers to the same account, USA-auto-attandent-style) or use the alias names for the extensions. For example, set the alias names to "41 028809511" (space between the account number 21 and the alias). Also consider setting the country code so that the PBX can translate the numbers into a global format for easier matching. More info here: http://wiki.snomone.com/index.php?title=Inbounds_Calls

Okay, why dont you try this (in the dial plan): Trunk: your trunk Pattern: Whatever your number/pattern is Replacement: sip:hello.there@domain.com;parameter1=value1;and=so.on

Yea this is somewhere on the to-do list. I think the important part is the default (built-in) greeting, as it will be very difficult for an end-user to program such things. Maybe the user should just record the name, and then the voicemail will do the rest.

Which part. Are you able to call in and hit the mailbox? Are you able to call out from this extension (using a registered SIP device) to the number that you are using in the redirection? Divide and conquer...

1. Make sure that you can call the extension that you want to redirect. It will be enough if you get to the mailbox, leave a message for example. 2. Setup a new trunk. Set the outbound proxy of the trunk where you want the outbound traffic to go. Set the trunk to "outbound" mode (no inbound) 3. Redirect the extension (for example by using redirect all) to the number that you want to dial. This might be a real number or just a bogus number that you use in the dial plan later. 4. Then in the dial plan make an entry for the number where you want to redirect the number. Select the trunk that you have created in step #1 and set the SIP URI in the replacement that you want to show in the outgoing INVITE request. 5. Give it a try.

You need a trunk for this, that's clear. You can do this: Make this trunk an outbound trunk only, and leave the outbound proxy empty (unless you will redirect the call always to the same location). Redirect the call to a number that you will process in the dial plan (you can also create a new dial plan just for that extension if you like). Then in the dial plan for the extension that you are using, use the replacement pattern to write the URI. This will be passed on to the trunk that you selected, and voila! that should do what you want.

If you are calling from from well-known numbers (e.g. cell phones) you can very easily make outbound calls. Just put the cell phone number into the extension, and then when the PBX detects the caller-ID it knows that an extension using is calling in. Then it will offer this caller a special menu to place outbound calls. You can also use the "calling card" account type to make outbound calling possible. Then users have to enter their PIN code to authenticate before they can make outbound calls.

Well, this is a PBX... Private Branch Exchange... Calls coming from trunks are going to extensions in one way or another. You can do some tricks essentially with the redirection features of an extension, you there must be an extension in the game--or in other words there needs to be some one who pays the bill for the outbound call. If you really just want the routing functionality, you are probably better off with a SIP proxy.

It might just depend on the firmware version. In the "meantime" there was a RFC available for the update or the caller ID, which caused some major confusion (RFC4916). The PBX uses this RFC, but some phone firmware versions are lagging behind.

We already have a code change that will fix this issue, it is in the pipeline also for the 4.2 branch.