Vodia PBX

So we did build 3.1.1.3110 for all operating systems today and made them available from the pbxnsip software download page (http://pbxnsip.com/software). Although there are still a few open points, this should be the best version ever. Release notes can be found on the Wiki on http://wiki.pbxnsip.com/index.php/Release_Notes_3.1, and as you can see we did fix a lot of problems and also added some interesting new features. The main point of 3.1.1 is that tel tel:-alias has been replaced with a telephone number. That makes it easier to represent that number in different environments, international or carrier-dependent and it also makes telephone number matches more safe. Also we added a new trunk identification mechanism possible that is very useful for multiple-domain environments. We made it possible to use the Cisco 7961 phone series with the pbxnsip in multiple domain environments, and even use features like park and pickup. And we found a ugly memory leak that could surface when Polycom phones are automatically provisioned with TCP transport layer. Thanks for all those who were helping out testing the different builds in all kinds of environments!

Also keep in mind that the dial plan on the PBX has nothing to do with the question when the number is complete. You you can safely use the pattern "xxxxxxx" (7 digits) for all 7-digits, and then the replacement can just be 212* (if 212 is your area code). Then later in the dial plan, if you don't insist on the length, you can use the pattern "1*" to match anything starting with 1, and replace it with the matched behind the 1 (you need no replacement for that). So you dial plan could look like this: Prio: 110; Pattern: 011*; Replacement: 011* Prio: 120; Pattern: xxxxxxx; Replacement: 212* Prio: 130; Pattern: xxxxxxxxxx; Replacement: * Prio: 140; Pattern: 1*; Replacement: *

In SIP the destination is in the first line (the Request-URI, see http://wiki.pbxnsip.com/index.php/Request-URI). That means the PBX is searching for the user "egix". If you want to use the "To"-header, then you can use the following pattern in the setting "Send call to extension": !(.*)!\1!t!

The PBX is a B2BUA. That means that different Call-ID may have different From-header. Within a call, the From is not allowed to changed (unless the connected UA indicates it supports from-change, see http://www.ietf.org/rfc/rfc4916.txt). What the PBX puts into the other leg of a call is a complex topic. "It depends". Trunks have their own rules, and the address book plays a major role for inbound calls.

For some reason the timestamp seems to be empty, as the from and to-fields. That is indeed strange. Any insight on what kind of call can cause this? Maybe click to dial?

There was a problem with RFC2047 headers (see http://tools.ietf.org/html/rfc2047). Will hopefully be fixed in the next version.

That is just another reason not to use prefixes like 9. IMHO people should just enter the number that they want to dial.

Ouch. Also on the CS410/CS425 you can make backup's of the file system. If you have a SSH client just log on the system (see http://wiki.pbxnsip.com/index.php/Installi...P-PBX_Appliance), in the end it is just a regular Debian computer. Last resort is to send an email to support with the MAC address and ask for a new license key.

Hmm. Can you upgrade the phone to 3.1.1 (see http://wiki.pbxnsip.com/index.php/Polycom on how to do that)? We have a 550 here and there everything seems to be working fine; however we are using 3.1.1.

Can you turn SIP packet logging on? You should see a packet with the header "INVITE sip:xxx SIP/2.0" (see http://wiki.pbxnsip.com/index.php/Log_Setup on how to do that). Probably the SIP provider rejects the call.

What phone are you using? What firmware version? At first glance sounds like a royal bug on the phone. Is there NAT involved? If that is so is there a "smart" router that screws the calls up?

Unicast is not a good idea with 90 users. You can use the multicast mode which sends the RTP to a IP address/port without sending out INVITE packets. If that IP address is a multicast address (starting with 224.x.x.x), interested devices can play it back. snom phones do that and if you use Plug and Play then they are automatically set up for the first multicast paging group in their domain.

The CS410 is not a router... It is just a computer with a couple of IP addresses that runs an application called "PBX"!

The name "localhost" is like a wildcard. It matches any name. That makes it easier to use the PBX in a environment where there is only one domain. Once you have more than one domain, you must use exactly the name of the domain in your user agent.

Well the TCP is for inbound TCP traffic. When the PBX opens an outbound TCP connection (PBX being a TCP client) then the OS will assign the IP address; and the PBX has no control over it. AFAIK you cannot bind a TCP client socket to a specific address. IMHO client authentication based on IP address is not the right way to solve this problem...

Is that a regular call coming in? Or is it a intercom call? The PBX cannot put an ongoing call on a phone on hold, only the phone can do that. There was an issue with a Linksys phone some time ago; Linksys argued this was a feature, because the intercom might be an life-or-death call. Not sure if they changed their opinion in the meantime.

Yea, at the moment that is the intended behavior. If you want to get a callback on your cell phone, consider using the callback feature (see http://wiki.pbxnsip.com/index.php/Calling_Card).

On system level they are hiding under the logging tab. There you can also turn and and off if the domains all use the same settings.

I think we have a interesting new device that the PBX can talk to: The FritzBox now support SIP trunking, see http://wiki.pbxnsip.com/index.php/AVM. This is a device that can talk to ISDN, primary in Germany.

I tested that with version 3.1.1.3107 and there is seems to be fixed.

Well, that is not a good sign. These calls are probably really in the internal database. This can happen when there is some SIP problem (handshake problem), but those calls should clear up after some time (8 hours or shorter).

The latest & greatest can be found at http://pbxnsip.com/protect/pbxctrl-debian4.0-3.1.1.3107. If you want to force a ANI outbound, set the trunk Remote Party/Privacy Indication to "No Indication".

The big question is how they want the CDR. For simple CDR I could imagine introducing a domain-based setting that overrides the global setting. We'll soon have CSV CDR written to the file system; the location may include the domain name. That might be possibility to solve the problem. If you are running a SQL server then we might also be able to feed the CDR into a table. We could also introduce a domain-based setting here. And of course, you can send emails with CDR per day. That is there already for some time.

No, at the moment this is hardcoded to two seconds. Maybe this is too long. What would be better? One second?

In 3.0 is was still buggy. In 3.1 it depends on the selected audio language. If the selection is "en" (US-English) then it should be correct in USA.