I didn't have much luck getting it working at all through the web interface, but I was able to get it registering with an iax.conf similar to the configuration I used with 1.2. Sadly it still uses the server assigned refresh rate, and Tesco are still sending a value of 0. So I'm still going to have to run my own customized version (though this time, I'll release a diff file so others can patch theirs - sorry about not getting around to it before). As it appears that I have a bit of time left between now and when 1.4 hits Debian (and then down to Ubuntu), I'm going to look into something a bit less hackish - namely a configuration value for iax.conf (something like forcerefresh=value).
I've been looking at the latest internet draft of IAX2, to see if it can shed light on if a value of 0 is at all valid, and if a client must always accept the servers value. There are 2 sections that appear relevant - 6.1 (especially 6.1.4 - REGACK) and 8.6.18 (REFRESH). It appears that the refresh value is optional and when not present it defaults to 60, but no mention is made if 0 is a valid value. It also looks like the refresh value in a REGACK is there for informational value than anything else - from the draft
When sent with a DPREP or REGACK, it is informational and tells a remote peer when the local peer will no longer consider the event valid.So, it looks like I can alter Asterisk's behaviour without having to worry about breaking the protocol - whether I use the hack I did last time or the "forcerefresh" option.
On a side note, the web interface really started to screw up tonight - it would log in and then immediately jump to a broken version of the setup wizard. I eventually gave up and started over with a fresh copy of the VM. I also found out that when starting with a fresh VM, run the update before you do anything else - something I did last night but didn't tonight. If you don't update, it doesn't seem to work (as in, the login page never loads).
No comments:
Post a Comment