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

[Kirill 'Big K' Katsnelson]

Is my understanding correct that currently there is no way to get any
reaction to a SIP peer registration, e. g. add the newly registered peer
into a queue, other than through an external AMI process?

If I am not missing something and this is correct, do you think that
invoking an extension script on such events would be too hacky an
approach to the problem? (practically, with ast_pbx_outgoing_*() in the
name of a Local channel). Seems to me very flexible: one can use
applications, call AGI, whatever. But I should say I am very
inexperienced in Asterisk internals to make a good architectural
decision here. Any downside in that approach? Any better solution you
would think of?

-kkm

[Olle E. Johansson]

Post by Kirill 'Big K' Katsnelson
Is my understanding correct that currently there is no way to get any
reaction to a SIP peer registration, e. g. add the newly registered peer
into a queue, other than through an external AMI process?

No. We have no concept of running dialplan without a call, or related
to a previous call ("h" extension).

Post by Kirill 'Big K' Katsnelson
If I am not missing something and this is correct, do you think that
invoking an extension script on such events would be too hacky an
approach to the problem? (practically, with ast_pbx_outgoing_*() in the
name of a Local channel). Seems to me very flexible: one can use
applications, call AGI, whatever. But I should say I am very
inexperienced in Asterisk internals to make a good architectural
decision here. Any downside in that approach? Any better solution you
would think of?

I am afraid of all the apps that expect a call to be running or about
to be setup.

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

However, it will be hard for you since we're running this at every
registration, regardless if it's a first registration or a re-
registration.

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.

/O

[Kirill 'Big K' Katsnelson]

Post by Olle E. Johansson
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.

Post by Olle E. Johansson
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.

Post by Olle E. Johansson
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

[Russell Bryant]

Post by Olle E. Johansson
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.

This is a very good suggestion. If someone wanted to pursue adding
asynchronous hooks into qualify status (or anything else) within the
Asterisk C code, it wouldn't be too hard to add.

I would suggest finding where we generate manager events for qualify
status today and generating an ast_event there. This part is probably
something we could merge. (See event.h, and search for instances of
ast_event_queue for examples of code that generates events).

Then, create a new module to subscribe to those events and act on them.
We have API calls that make it very easy to originate a call to start
dialplan execution (ast_pbx_outgoing_exten()). The Channel part of the
"call" could just be Local/extensionThatJustAnswersAndWaitsForever. The
extension would be where you handle your response to the event.
Alternatively, instead of originating a "call", you could run a shell
script, just execute the queue add/remove member applications directly,
etc etc etc...