Vodia PBX

I think the easiest is to locate the pbx.xml file and change the port there. Also, consider changing the https port (443) as well.

Whow, I believe that is very interesting stuff!

I just looked at their documentation (never had the device). I believe it should be easy to get this working. Probably you just have to use a gateway trunk to the device. Do you have one? Maybe if you can PM the access information to the gateway and the PBX we can try it remote.

Automatic provisioning or manual? Automatic would not allow Action URL...

I don't see why not as long as it talks SIP and you make sure that the QoS is okay! (The latter being the hard part, especially if the provider does not play nice)

There should be no space between the "action:" and the "bye". Maybe that is the problem?

I guess you need to send it to mail: http://linux.die.net/man/1/mail. You can either use a pipe (|) or first redirect the result into a file and then send it with mail. Though I am not a Linux guru

That sounds like you have to put the 666666 into the replacement part of the dial plan?

Hmm. If the web interfaces mentions REFER, there must be a way to get this working. Then at least the blind transfer should be easy.

Yes, that's the problem. The handset tells the PBX that some key "16" has been pressed. But the PBX does not know what to do with that... (sorry for the 200 Okay, which essentially means "got it"). If the handset is able to send REFER then you have to use that mode...

UDP is evil. Imagine the "web" or email would have been built on UDP. UDP requires message repetition, there are many extremly buggy NAT implementations out there when it comes to UDP (fragmentation, ops). If you would ask the inventors of SIP if they would propose UDP transport layer again they would say "shoot me" (maybe not in an official statement). The PBX allocates one thread per TCP/TLS connection. The good news is that today that is no problem for an operating system. Check out web and email servers if you want to know how stable that can be.

Well use can use the event "E" (audio end) to switch to another account. Sorry, no drag and drop. Just regular expressions......

Did you take a look at the IVR node? At first glance, it should be able to do what you want.

Those settings seem to make sense... Do you see a REFER going out to the PBX? The PBX does not perform the job of collecting the digits; this must be done by the SIP endpoint (making it also possible to edit it before sending it). Then from the PBX perspective the way of collecting the transfer information should not matter--this is a implementation detail of the endpoint user interface.

Then the PBX has to assume the request can come from any address. This makes it more difficult to match incoming traffic to the trunk.

The outbound proxy also defines the inbound proxy... Maybe we should change the name to something like "proxy address".

This is indeed not a simple question. We found that many people love the speed and productivity of key systems. A CO-line is something everyone understands and everyone knows the police office movie where the officer shouts "hey Joe, XXX on line 3". Then he just needs to push button 3 and the call transfer worked. While this scenarion is fast & productive, there are a couple of problems here. First of all the "core" (interop) SIP simply does not support this. Blame the IETF, but they believe this is a unrealistic scenario! So far, AFAIK only snom works with the "shared line appearance" mode. But the other problem is, that for large organizations, you might have a lot of CO-lines (like 24 or more) and it is getting messy calling "hey Joe, XXX on line 324!". That is when people invented the attended transfer. Instead of shouting through offices (which BTW requires visibility), they just call the other person and then perform the transfer. That does not require any kind of parking, just holding the call. IMHO that is as productive as the police office application, but has the benefits that you don't need the term of a CO-line any more, you can actually have a lot of them, and it is even SIP compliant. We must also note here that CO-lines are something very primitive and physical (versus virtual). The number of cases where you really have to park a call is quite limited then and most companies quickly forget what parking was all about anyway. I believe that most users are very little religious about the way transfers are being done. In the end, it is about getting the job done. I remember there was a huge discussion in SIP about "overlap dialling" and that customers would never accept that they have to push the dial button. Today we know that this is nonsense. Everyone who has a cell phone understands that you have to press the "okay" key in order to start the call and it even has the benefit that you have someing like a delete/backward button (just in case that you entered the wrong digit!!). After some initial bitching about not being 100 % backward compatible users understand that they actually witness technological progress, it makes their life easier and finally happily accept it (later they might complain how stupid it was in the old times). I believe the same thing slowly also happens to the way people transfer calls. A proper explanation how it works helps a lot, if done proactively and in the beginning. I don't even remember the last time I parked a call (vs just holding it). Except for testing purposes, of course.

Is the softphone on a routable IP address (no NAT)? Maybe the router is just no good for VoIP. For example, we had a case where the router only had 32 NAT entries and was dropping assiciations randomly (depending on the traffic). https://www.pbxnsipsupport.com/index.php?_m...kbarticleid=491 also contains some things that you can check. Having a softphone behind NAT is similar to having a PBX running behind NAT.

Maybe there is a feature kicking in that asks the user to change the password every month (no kidding). Not sure where this setting is hidden on the web interface of the phone, but I think there was one. Anyway, pressing the cancel button should solve that problem for time being.

They do that on the screen?

The best way to deal with this is still to use an external (stateless) proxy or gateway that receives all traffic, no matter if it later will terminate in the PSTN or on the same server. That is a "idiot proof" way of dealing with the problem. The loopback is a hack that tries to get installations going where something external is not an option. Loopback still has issues with the ANI presentation.

If you want to map CO lines to buttons on the phone you need a phone that supports that. We have developed a special protocol that does that. Currently only snom phones support that. You can configure that through the web interface and the PnP of the PBX.

Well, the "Windows Firewall" runs locally on the computer that is running Windows and it tends to block incoming or outgoing traffic. This should help getting trojan horses and other stuff under control ("Trust me, I am a soft phone. Please let me open the connection to the public Internet with a secret protocol and let me have access to your file system"). Microsoft Windows usually generates a pop-up that should warn the user when a program wants to open ports. I think because most users always just click okay Microsoft changed the strategy (even if the warning says "a program called 'StealAllYourData' tries to open the connection to the Internet. Do you agree with this?"). Funny story. I believe you would look for RTP going into both directions. AFAIK the PCAP trace is already "behind" the Windows firewall, which means you see what is really going on on the cable.

Are you doing automatic provisioning? Check the files in the generated directory. You should see what "TOS" is being provisioned to the phones.

You mean because customers might use a ACD or hunt group on their only DID number? It starts to make sense to me.