Vodia PBX

Well, in theory SIP offers a method called REFER that would do the same thing on a SIP trunk. The reality is that practically no SIP trunk provider supports this today. My impression is that it has just too many security and payment issues so it scares the trunking providers off.

There is a setting "Keepalive Time" in the trunk. If you set that to 120 seconds, the PBX will ignore the time sent from the switch and reregister after the value that you set there. What the trunk is proposing as keep-alive time can always be overwritten by the switch. Some switches send one hour and keep the connection alive by sending keep-alive packets. That mechanism is not very stable - many firewalls do not treat traffic coming from the outside as keep-alive traffic.

I would solve this problem either with an IVR node that just plays the moh.wav file in an endless mode or use the agent group without agents.

In the admin settings for the PBX, there are four settings: "Minimum Registration Time", "Maximum Registration Time", "UDP NAT Refresh", "TCP/TLS NAT Refresh" (see also http://wiki.pbxnsip.com/index.php/Overall_...gs#Performance). You can lower the Maximum Registration Time, IMHO it is no problem to choose duration of one minute. The CPU load generated by a few hundered extensions refreshing their registration every minute is no problem.

It would be easier to POST them using HTTP.

That should work. Do you see a INFO packet during the call with an attachment that contains the changed caller-ID information? Do you have the SIP packets that are being exchanged between the PBX and phone that should display the changed ID?

So far we can say: With the 2.1.5 release, the problem begins when one of the BLF extensions is active, on DND or has any other reasons to be "on". Then the initial packet contains a dialog state list that cannot be parsed correctly by the phone and then the BLF state display goes south. For us, it was neccessary to use the version 2.2.2 of the Polycom phone. 2.2.0 had the strange problem that after the first call or the first address book usage, the list was getting crazy. The workaround we did was to ignore the state of the account (in a 2.1.6 build). That has the disadvantage that when the device starst up and there is a call active on the extension, the phone will not show that. When the call stops and the extension has a new call, then everything will be okay again.

Yes, that is the easiest for inbound calls. You can also use multiple patterns in the "Extension" field of the trunk. The PBX will pick the first one that exists, this makes sense if you use patterns to extract certain parts from the INVITE. Dial plans are for outbound traffic only. There might be a tricky way to use the dial plans also for inbound calls, but it was not designed for that...

Practically all installations just assign a DID to a FAX. Then there is no need for a fax detection. But it would be interesting to see if we also get the FAX detection working in the auto attendant. The PBX has a fax CNG tone detection (1100 Hz) - if the PBX detects a FAX tone, it sends the DTMF 'F' to the application. You can use this for example in the auto attendant as a direct destination. But you must perform inband detection in this case, because the FAX tone is usually not part of the RFC 2833.

No, there is no difference between Windows and Linux: generated: This directory is generated by the PBX during the PnP process, it contains the files generated for specific MAC addresses. html: This directory is optional and may override the built-in html web pages spool: This is used for spooling emails. The directory is created when the first email goes out tftp: This directory must be created manually if you want to put files for the provisioning process there (e.g. firmware)

Well, the PBX already has TLS (which is compatible with SSL3.0). Maybe it is time to "upgrade" the email client to TLS. If it helps to reduce the number of SPAM, we will be happy to help.

You mean you want that the PBX plays music on hold as soon as you call a specific number on the PBX? Like a IVR node?

Hmm. We had a very strange case recently where the MTU was set to a short value which caused a lot of strange effects... It took a lot of time to find that problem, but in the end it was good to see why the "mystery" was not a mystery. Maybe it also makes sense to find out what is different on that specific server and once we find it out put it on the check list.

Okay, 2.1.6 will jump directly to the dial by name mode when the "Input that triggers name search" is set to "start". Okay, has been changed...

Check out the discussion about outbound (http://www3.tools.ietf.org/html/draft-ietf-sip-outbound-11). That is practically what everybody is doing today. This is a defacto must, because otherwise you don't get TLS working behind NAT. Well, the problem is if you indicate RTP/SAVP then the other side will reject it if it does not support SRTP. Using RTP/AVP means "tentative" SRTP. The PBX does the same thing.

Well, there are other limitations like the number of sockets that you can have open. And the absolute maximum number of calls in 2.1 are 256 calls (2-legged). All other structures are pretty much dynamic. But that all does not explain choppy audio. The CPU load meter is what we should pay attention to. Maybe the blue line at 75 % is still too optimistic and we should lower it to like 50 %.

No, 2.1.5 is no difference regarding the performance. My opinion is that hardware has become so cheap today that it is not worth having customers complaining about dropouts. So I would definitevely power up another server. The new domain backup feature comes in handy. It should be relatively simple to move a few domains off to a new server!

Do NOT use STUN. Do NOT use STUN. Do NOT use STUN. Do NOT use STUN. Do NOT use STUN. Do NOT use STUN.

Oh you mean, a number so that you get directly to the dial by name? Interesting thought... I think at the moment there is always some DTMF interaction neccessary.

Currently only MakeCall and ClearCall... Only HTTP/HTTPS. Not much, but a start.

Looks like a log from the Polycom phone to me?

Well, in that case you would match the first 11 digits: Pattern: ([0-9]{11})[0-9]*@.* Replacement: (left empty) Or if you want to match the front part as well: Pattern: (1800[0-9]{7})[0-9]*@.* Replacement: (left empty)

The difference is that the register registers while the gateway does not. That means that only the register trunk can have an account name, which is used for authentication purposes.

Well, the other thing is maybe the domain name in the from header. I can understand that they would not like "localhost", maybe you should rename the primary domain alias to something that they expect...

That is not even a RFC-compliant packet. Not even talking about RFC3581 (http://www.ietf.org/rfc/rfc3581.txt, August 2003), which is not set to the actual port. The content-length is not set.