There has been some internal discussion at the company I work for about
1. Asterisk forking. I am in the process of testing an asterisk forking patch. It is alpha at best. I have added to the struct sip_peer called maxregistrations (int) which will track the maximum allowed sip registrations to the particular sip peer to allow forking. maxregistrations >= 1 obviously.
Is there any interest in helping me test this patch ?
2. Problem:
- when Asterisk can no longer qualify an extension, it marks the
extension as "UNREACHABLE"
- it leaves the extension "registered" though
- this results in the behaviour of being able to call out, but no calls
come in
The fix,
There is a function called sip_poke_noanswer that handles thefact that a sip peer did not answer a qualify poke. The easiest way to remove the registration is to expire_register
Use static int expire_register( const void * data ). Prior to calling expire_register, the code checks if nat is set to anything but no and insecure= are set because generally, insecure= is set for trunks with providers for incoming calls.
Comments?
Qualify set higher
The problem with setting qualify higher is the expiration of nat bindings on some of our devices. So this is an easier resolution. Where possible, I find it easier to handle things in the pbx than in the end user devices because not all devices we support the same features. Rather than having to come up with specialized configurations for device specific problems, its easier to leave the logic in a centralised place.
I know everyone won't agree with my methodology on this but seems to have worked well so far.
kick NAT in the ass
kick NAT in the ass entirely, use a SIP proxy. If you are doing NAT that tells me you're running the phones and the PC's on the same network. The single, best, thing you could do for yourself is to run your phones in a seperate VLAN apart from the PCs (despite using the same ethernet cable). In order to do this in MTE a gateway must exist for this second VLAN. If you are going through the trouble of a 2nd gateway, you might as well put a sip proxy on it and dhcp server so that
1) nat issues vanish due to the sip proxy routing between two networks untranslated
2) seperate gateway to facilitate a voice vlan (much better QoS)
3) dhcp server with advanced features such as time server, time offset, tftp/ftp server for configs etc.
Currently we do use nat,
Currently we do use nat, however, we do use multiple vlans and packet tagging to ensure that the voice packets get the highest priority. Also, as a company the policy has been set out to never use the passthrough port on the cisco phones. This might seem severe but has worked out well for us.
The problem does not arise with customers who have a cpe that can run sip proxy on their end. However, for resi and smaller customers, the cost of having a cpe that can run a sip proxy does not work out.
The reason for discussing the above logic was to handle this at the pbx so that we don't have to add another moving part to customer installs and have a single solution for all.
do you still get this when you set the qualify time to a very high value?