Vodia PBX

You need to set the "Log Watch List (IP)" to the IP address(es) that you want to see, and the log level in the "Log Watch List", choose something below 7 so that you can keep the other SIP messages out of the log by going to a log level lower than 7.

Just create a trunk which is only used for outbound direction and don't set the outbound proxy. Then in the replacement part of the dial plan you can put the URI as you wish. The PBX will follow the RFC3263 rules for routing the request.

I saw these virtual keys, nice idea but only half there. From the PBX perspective, it should not matter if the keys are virtual or not; the phone should display the labels and not start giving it its own names. The support of ActionURL is only sporadic, another problem especially for the provisioning of the soft keys atthe bottom of the display (redirection!!!).

I have to defend callcentric here... How can they tell if it is one-way audio or a conference call with a caller muted? You might want to check if a software upgrade of the phone fixes that problem. It is the job of the phone to send SID packets when on mute. Or there might be an option that does send silent packets with the selected codec, kind of waste of bandwidth but a solution.

I guess you want that so that the customer can not copy & paste the key so easily? I guess we would have to make that a feature of the key itself; not a big thing but it will be difficult to do that with the keys which are out there.

You must send the CDR out as email. Right now you do this by using the scheme "mailto" in the global setting "soap_cdr_adr" (well, right now; we obviously need to change either the name or add a new setting); for example "mailto:matt@test.com". Then the PBX will include an attachment with the MIME type "application/vq-rtcpxr". This will look like this (see http://tools.ietf.org/html/draft-ietf-sipp...rtcp-summary-06): VQSessionReport: CallTerm LocalMetrics: TimeStamps:START=2010-01-07T13:28:58Z STOP=2010-01-07T13:29:51Z CallID:0078-0B66-2DD33E69-0@D141DFC50C7AA2248 FromID:"00972781202229" <sip:00972781202229@domain.com;user=phone>;tag=007A-11C4-2CCCD3F2 ToID:<sip:423@domain.com>;tag=5c6f4cceba LocalAddr:IP=192.168.0.233 PORT=55882 SSRC=0xcf528dde RemoteAddr:IP=192.168.0.248 PORT=17264 SSRC=0x1e9f6401 x-UserAgent:pbxnsip-PBX/4.0.1.3409 x-SIPterm:SDC=OK SDR=AN PacketLoss:NLR=0.0 JDR=0.0 BurstGapLoss:BLD=0.0 BD=0 GLD=0.0 GD=52123 GMIN=16 Delay:RTD=16 ESD=0

Well, the other simple thing could be that it is illegal to use the demo key in operational environments (in those countries that respect intellectual property)...

That must be a joke from of the sales guys. Probably they think there are people operating the PBX with a 3-minute call limitation.

Okay, point taken. While we are on it, maybe we should address this in a more complete way, the current solution is not really satisfactory. I think that many people would like to do a lot more customization. Adding a parameter for everything is unrealistic. But maybe we can do the same thing that we already did for the emails--have a default and allow the admin to override that default in the web browser. The problem with this would be that those files can get very long (e.g. Polycom easily hits the 200 KB range). Maybe a matter on minor inconvenience? Any other ideas?

In a recent discussion, some folks complained that the name "domain" is inapropriate and should be changed to "PBX". Originally, the name "domain" came from DNS, because that is the way SIP works (like email). If you want to address a specific user cluster, you have to use a domain name in the request URI, similar to what you put behind the @ in the email address or what you use when you enter a resource name in the web browser. Renaming the "domain" to "PBX" would cause a major disruption because the name "PBX" is actually already taken and we would have to go through the web interface, the documentation and yes also through this forum and rename every occurance of "PBX" into "system" (or whatever we will choose as new name). IMHO this would cause such a huge chaos that it would take years to get this name straight again. My vote goes for "no".

Well if the system has only one domain, then the PBX should automatically append the domain name (if there is no @ in the name). The name "localhost" does not matter.

I agree... But I do believe in this feature and that it contributes to the system sanity. Maybe we should put bigger warning signs on the admin landing page (emails are being sent out already, but that is obviously not enough). We already made a timeout on the blacklisting so that eventually after one hour the system allows the next attempt (by default).

Well, we had park orbits as explicit type in the first versions. Honestly, I don't remember why we took them out (I think it was because of hte idea that a user wants to park a call and then pick it up on another station and every extension should be able to do that or so; okay not very convincing). Right now you can select that the mailbox should behave like a park orbit, which should get you close to the pure park orbit functionality. Another workaround would be to park calls in ACD with no agents. It should give you the same functionality that just playing music with no other functionality.

Thanks, the description is very useful! We are working on 3.5 with some smaller improvements, including a 870 PnP. Those who would like to get a 3.5 image, send a PM or email to support@pbxnsip.com.

It would be interesting to see if there is any performance difference. Feature wise, cell phone forking for the groups, trunk CDR (including quality metrics), automatic blacklisting and maybe IPv6 interop (phase 2) should be the big topics.

Yes, tcpdump is also fine. BTW from command line, you can also use tshark, that's the command-line version of Wireshark.

The latest Windows snapshot can be found here: http://www.pbxnsip.com/protect/pbxctrl-4.0.1.3408.exe Note: Please do not use this version in a production environment. We changed a couple of things that have not been tested well. For example, this build uses the SSE instruction set and uses otherwise optimized code. The Windows builds were slower than Linux build and we suspect this was because of the compiler options what we were using. So it would be great if you can help us giving feedback on the stability of this version, bt be careful with production systems.

Hi Bill, first of all the whole PnP topic is easy if you just want to use it the way it is (that is where the name comes from)... Once you want to change it things get messy. My recommendation is to use the PBX as tftp server in cases where you want to do your own setup. Then you can just drop the files that you need into the tftp directory. What you have to drop there depends on the phone type; but there is plenty of documentation available for each phone type. You can also mix the "run as tftp server" mode with the plain pnp type--some phone can use the plain pnp mode and other phones can pull their config from the tftp directory. For example, ifyou want to have a special setup for the receptionist, you can put the special files into the tftp directory and leave the others with the standard provisioning. The files in the "generated" directory may help you getting the files that you need to put into the tftp directory. Think of them as templates that you can copy and edit with a text editor.

If you have specified telephone number alias names, then you can also log in with that number (no domain required).

Well, what we definitevely do in version 4 is QoS reporting (that is one ofthe reasons why version 4 takes a little bit longer ). So far we just push the reports out together with the CDR. But you are right, it is a good idea to define rules after which the PBX takes a trunk down. For example, if the packet drop rate gets higher than lets say 10 %, the PBX would mark the trunk as bad for the next hour. The alternative is that we disconnect the call when a admin-definable threshold has been reached. That might help to keep other calls which are on the same internet connection in good shape. Of course a report must be sent in such a case to the admin. Needless to say, this is all not beautiful. Better make sure that the QoS is fine. BTW found a good book on this topic: "Deploying IP and MPLS QoS for Multiservice Networks: Theory & Practice (The Morgan Kaufmann Series in Networking)", John William Evans, Clarence Filsfils. I did not read it (yet), but the ToC looks promising.

7 minute means 128 kbit/s times 7 * 60 seconds = 6.7 MB. That is okay. The first time the PBX might have a little hickup (jitter), but the subsequent calls to the MoH file will be smooth because the PBX keeps it in memory.

No, we added handling of MIME to the pbxnsip PBX!

The problem is that it takes several ms before the OS is able to move the thread context from one core to another. For most applications this is no problem. But for the PBX, this introduces additional jitter. We had cases where this made it difficult to understand the conversation.

Additionally, looking at the trace my first guess would be that the phone has problems with a full SDP answer (more than once codec). Can you quickly try to lock the codec or offer only one codec, e.g. G.711? We have seem other cases where the phone had a problem with G.729 where it just completely lost audio after some time. Maybe there are still some gremlins in the audio subsystem of the phone. And do you have another phone for comparison? Maybe this is a network related issue.

Yea obviously the pbxnsip web site is hosted by yahoo. Welcome to the cloud! We are not too good at operating web services...