[asterisk-dev] Run extension script on SIP peer registration

[Kirill 'Big K' Katsnelson]

Olle E. Johansson wrote:
> I am afraid of all the apps that expect a call to be running or about  
> to be setup.

Yes, might be lots of unintended consequences here. Good point.

> In voicemail we have hooks to external shell scripts, which is a  
> better a more flexible solution.

I am not even loading voicemail. I'll see what I can do there. Thanks 
for a pointer.

> You propably want a hook for when we loose contact as well. I think it  
> would be better to hook into the qualify subsystem for these kind of  
> events.

May be. In my application, I do not particularly care about devices 
being reachable/unreachable (that is handled by the queue).

Maybe I should explain what I am trying to do in more detail. I am using 
autocreatepeer=yes in sip.conf. New peers should be added to queues (a 
peer knows what queue it should be added to; how it passes that 
knowledge to Asterisk is open). I also want to remove ones that 
unregister, because they might never come back, because of external 
configuration change.

My current solution is:
1. Format peer name specially, so that it contains queue name inside a 
well-formed user name. (e.g., `dyn-myqueue-foo123', where `dyn-' is a 
common prefix and `myqueue' is the queue the device enrolls into).
2. Run a perl script on AMI, monitor register and unregister and issue 
QueueAdd and QueueRemove as required.

Every device enrolls into exactly one queue, and security is not an 
issue. Everything happens on a LAN, and I have lots of control over 
devices, as they are software applications based on PJSIP so pretty much 
open to be hacked.

Client sustains registration if it loses it, but it would be much more 
complex, it currently seems to me, to maintain also queue membership 
from the client side. A client needs either to dial a special call to 
enroll (and what if registration disappears? when to re-enroll?) or talk 
to Asterisk via AMI (many, many devices. when to re-enroll?). Also, the 
configuration we use is redundancy with fail-over using LinuxHA, and 
that quite adds to the complexity.

Is there any better approach to this type of a problem? The 
configuration seems pretty uncommon, I reckon.

  -kkm