Vodia PBX

What version? Should be solved in 3.1.2.

You need to turn the logging on ("Log SIP events" and "Log trunk events"). The SIP messages are good, but we need to understand what the PBX makes out of it. Set the log level to 8, then you will see additional messages that tell you why the PBX cannot find the destination of the call. In the log you see what user name the PBX is looking for and what trunk was identified. Maybe you did not specify the outbound proxy of the trunk or the extension does not exist. With the right logging, such an issue can be resolved quickly.

I don't understand... The From header that I see is From: "W: Office 1" <sip:9784256666@companya.mydomain.com;user=phone>;tag=648644319, with nice quotes around the "W: Office 1". Maybe they can just take a look at this forum post. If the quotes are missing when it reaches their system, maybe there is a SIP-aware firewall in the middle that takes the quotes out?

There are only 9 listings to limit the amound of data being transferred. It was programmed this way, there must be a limit somewhere. There are customers who have 45000 address book entries, and you don't want to load them all into the phone when pressing a button. Maybe should increase that a little. I believe Cisco can display up to 32 entries, that is probably a better limit.

We are trying to move topics away from the "General Setup" into the forum where it fits best. I am nore sure if the forum software allows such a checkmark, but it might be a good idea to mark the topic. "Close" the topic is probably not a good idea as then it becomes invisible [need to verify that]. But we can use a post icon, or maybe we just change the title and append something like [solved]. Apart from that, we believe that the search engines do a good job making the forum searchable.

Try upgrading to 3.1.2.3120. That might contain a fix.

Try "!7036986000!810! !7036985000!800!". "!7036986000!810! 800" is a little bit more elegant, as everything else but 7036986000 would land on the 800 account. If you have more DID you can extend the pattern like this: "!7036986000!810! !7036986001!811! !7036986002!812! 800"

Nonono. You cannot search for "S" only. You can only search for [PQRS] (on of these characters). Then when you have the XML result on the screen then you can narrow down the search for the next character. It is hard to explain. Maybe we need a video...

Whow that is a very long delay. When you make a phone call echo will be very obvious and it will be difficult to have a natural conversation. Just a side note...

On the DTMF topic, we fixed a bug in the codec negotiation. Essentially the bug was that the PBX was offering the codec number of the foreign device, not it's own codec number. For example, when the PSTN gateway offers 96 for DTMF, the PBX would answer also with 96. However internally it uses 101. In the fix, it now answers with 101 (which is correct). The problem because obvious for outbound calls when the PBX has to generate a SDP offer. When the PBX offers 101 and the other side answers with 96, then the PBX has to send codec 96, and receive codec 101.

We tried, and I learned a lot Dutch! The phone shows all menus and also the web interface in Dutch. The XML content contains no visible langauge-dependent content (at least I did not see anything), IMHO the behavior is okay.

The adhoc recordings are essentially mailbox messages. We assume that the number is "low", as much as the mailbox can store. A simple way of solving that problem is to modify the path for the recording (record_location, see http://wiki.pbxnsip.com/index.php/Recording). If you include the name ($u) in the directory path, all recordings for that agent group will land in that directory.

Just updated http://wiki.pbxnsip.com/index.php/One-way_...AT_and_Firewall.

I would suggest to use the web interface only to generate templates. See http://wiki.pbxnsip.com/index.php/Saving_a...e_Configuration at the top.

Eh you mean RHEL4? That might take a day or two......

Well the problem is when the user decides to change the username you cannot generate a new hash. If we are using the hash method we have to request users to re-enter their passwords.

Did you try "If the caller already waited longer than (s) ... redirect to the destination:"?

Maybe for the sake of finding if that is the problem try "always".

I think we fixed the problem already... Will be included in the next release. If you want a preview, let me know what OS you prefer.

That is a kind of Linksys classical problem. The default dial plan of the phone makes it hard to dial star codes on the PBX. See http://wiki.pbxnsip.com/index.php/Linksys for some dial plan examples.

What is your setting "Generate passwords" (admin/settings/ports)? Maybe the PBX would not generate the passwords for the device?

Ehh. Looks like a bug to me. Workaround could be to use the form "<accountname@domainname.org>; <accountname2@domainname.org>".

Very good. Maybe you increase the log level and look for messages like "Trunk xxx sends call to xxx" (log level 5)? Then we can see what the PBX tries to do with the INVITE.

Maybe you have to turn "strict RTP" routing on. I believe that test tools don't have to be very NAT-friendly, so the PBX gets one-way audio.

Well, at least Broadsoft is using SIP, and I guess with Asterisk they are also using SIP so I would say it works. But only the real device will tell how much exactly works.