Vodia PBX

Great! BTW RFC 2833 has been replaced now by RFC 4733. But it is essentially the same.

Do you have the chance to upgrade? http://pbxnsip.com/protect/pbxctrl-3.1.1.3095.exe is the latest & greatest, it still has a ugly transfer bug so don't use it for operation, but maybe you can try to see if that fixes the license counting problem (make a backup of your working directory, so you can move back any time).

Ehh - we are currently wresting with a ugly problem in the transfer area. You better wait a day until that is finished. When it may be time to generate a set of new builds!

Well, you can lock the phone, just like you lock your cell phone.

Well he can go to his own mailbox, push 5 for recording a message and then move it into his own mailbox. Less than ten key strokes ...

Try turning off polarity reverse detection. That is causing such effects. I guess technically the call is never connected, so the phone disconnects the call.

How many buttons does he want to push?

You can drop the attached file into the html folder. Don't forget to remove it when finally upgrading to 3.1.1 (or later). snom_300_fkeys.xml

Whow thats strange. Do you have too many domains? Trunks? Having the 3-minute key is nice, but when you start using a real license key it sometimes comes asa bad surprise that there are already too many resources for a regular license key. Do you see anything like this in the log? "License suspended: There are too many domains"

Clear the country code and it will be shut off. That whole global number topic was a bigger cleanup round than we thought, but we are seeing light at the end of the tunnel now.

Is your DSL router doing DNS? There are many DSL routers that are not able to deal with non-DNS A requests (SRV, NAPTR, AAAA). In general, if you have to get a new IP address then I would really really recommend trying another router. There is just so much buggy stuff in the low-end router market that you can burn a lot of time pinpointing the problem just to find out that the NAT implementation was just a little bit toooo pragmatic.

Yea, the Mac installation is a little bit screwed up. We need to focus on a new Mac installer.

:blush: We are just not big experts on Mac installations... In a perfect world, the Mac installation would just run on a shell script; but we are not sure if that is an option.

Yes, in the beginning we also offered STUN support for clients behind NAT. There was a hope five years ago that STUN would solve the problem overcoming the routing problems with SIP. But we just drowned in support explaining customers what the difference between full-cone NAT and symmetrical NAT is and asking customers to try new routers. That's it! STUN is not the solution. Today it looks like SBC will will win the race and IPv6, that's the "inconvenient truth", will be the only way to have true peer-to-peer SIP media. Also outbound looks promising (see http://tools.ietf.org/html/draft-ietf-sip-outbound), this will solve a lot more problems that the 2003 STUN did. Of course, we put everthing into the pbxnsip PBX already . I don't believe that a free, home-compiled SIP proxy and some good marketing is enough to build the ITSP money printing machine. The truth is that a lot more is required and carriers do have to spend money for SIP equipment. Time will tell, and customers are making their vote on good and bad service. Also, a big question mark is QoS. Some say that a solid carrier need to have control over it, otherwise voice hickups when emails are being uploaded are only a question of time. At times when 100 MBit/s are available for a few bucks, there is no easy answer for this. I would try setting that to 30.

What you can try is to set the "Keepalive Time" explicitly to something like 30 seconds and see if that makes a difference. 600 seconds is too long for NAT unless sipgate sends some keep-alive traffic. But not all firewalls treat keep-alive traffic from the outside as valid keep-alive, maybe you are the lucky one with such a firewall.

Check if the PBX runs in the expected directory. See the status screen of the PBX.

Looks bad... If there is absolutely nothing coming back then maybe your firewall blocks the traffic? Even if sipgate does not offer SBC service (which is neccessary to run the PBX behind all kinds of NAT unless you have a routable IPv4 or IPv6 address, see http://en.wikipedia.org/wiki/Session_Border_Controller), their edge proxy should respond with something.

The TOS is not so serious and is fixed in newer versions. The WAV problem may be because of upper/lowercase problems? Check if there is anything uppercase in the file system. And check if the PBX process has the permissions to read.

What kind of transfer is this? I guess attended transfer? The blind transfer should work and IMHO is a good workaround (because the agent group will always take care of the call). The attended transfer is very tricky as we have to transfer the media state as well. We already had problems with conference and regular calls (which should be solved), and we now need to look into agent groups as well.

There is a setting in the domain called "Offer Camp On". Turn it off and the prompt will disappear.

The PBX is at this point just a presence agent that receives the presence information from a user-agent and then notifies it to subscribed parties. It does not look at the presence document itself. A UA that wants to publish its presence state must use PUBLISH and the event must be set to "presence". Pretty SIMPLE!

Always make a backup before removing something...

Well, that log did not reveal what the problem was... It would be good to see the SIP packets. See http://wiki.pbxnsip.com/index.php/Log_Setup on how to turn that on.

And what does it say now?

That looks strange. Too many @ symbols... And it is not a valid SIP URI.