[asterisk-dev] Asterisk and external SIP subscribtions

[Olle E. Johansson]

On 19 Mar 2014, at 15:20, Paul Belanger <paul.belanger at polybeacon.com> wrote:

> On Wed, Mar 19, 2014 at 9:56 AM, Olle E. Johansson <oej at edvina.net> wrote:
>> 
>> On 19 Mar 2014, at 14:50, Paul Belanger <paul.belanger at polybeacon.com> wrote:
>> 
>>> Greetings,
>>> 
>>> I wanted to ask if there is any sort of design document / work started
>>> on having Asterisk 13 be able to subscribe to external SIP messages
>>> for the purpose of presence (device state).
>>> 
>>> More and more we are trying to come up with a good way to have
>>> Asterisk be aware of SIP subscriber presence from our proxy (kamailio)
>>> and propagate that information into Asterisk. Today we are using
>>> custom device state and some AMI / console scripts to do this, but its
>>> a pain to maintain / deploy.
>>> 
>>> So, what we (our company) was planning on doing was funding some
>>> developer to go out and build us something on top of pjproject to
>>> handle this.  Some sort of res_pjsip_foo module to handle presence
>>> from Kamailio.  The question comes up which RFC is should be, but at
>>> this point in time, that's a discussion point.
>> I have an old design and some code for chan_sip, but the design should
>> be working for chan_pjsip as well. Google for project pinana.
>> I presented it at a astridevcon years ago.
>> The important thing is to have a generic design so we can publish
>> states of non-sip extensions too.
>> 
>>> 
>>> Talking to matt, I think we want to use the res_pjsip_pubsub.c module,
>>> but need to confirm. And the reason for having this email. So, is
>>> anybody interested in helping us build it?  Both from a design apsect,
>>> so we can get it into Asterisk and / or help find a developer to do
>>> the work / funding?
>>> 
>>> I see said module having some config file that will allow you to
>>> specific your source, and the domains you which to subscribe too.
>>> Then, when asterisk starts, it sets up the subscriptions and then
>>> listens for the publish and stores them as local (internal) device
>>> states.  I don't really care about adding publish support at this
>>> point in time, simply because everything SIP related is outside
>>> asterisk.
>>> 
>>> EG:
>>> 
>>> [example.org]
>>> server = 192.168.1.1
>>> users = *
>>> 
>>> So, thoughts?  Interested in helping? Want to also fund this venture?
>> Start with reviewing my design.
>> 
> So the MVP for my concept is pretty simple, subscribe to external
> source and update asterisk device states.
Or extension states? Which one do you want to propagate? Which
one should users subscribing to a state in the kamailio server get?
Remember that extension states != device state!

> The reason for this, like
> everybody, is I have multiple asterisk boxes behind a proxy. So, if I
> dial the same SIP subscriber from two different boxes, I want asterisk
> to know the states.
Right. And to be able to move phones to the proxy so that all blinking
lamps notifications are happening there, not on Asterisk.
> 
> I think this fits well with the res_pjsip_foo module design, but I
> might be wrong.
If not, then we have to have a serious talk with Mr Colp. I expect
it to be ready for it. 
> 
> And I want this to be simple, I don't want to depend on XMPP servers,
> res_corsync, python scripts, etc.  That's why I asked if anybody else
Yes! There's value in this.

- We can have call queues on one server getting states from others.
- We can offload the NOTIFY handling.
- We can scale, scale, scale.

While working on Pinana we realized that th XMPP stuff was not
handling device/extension states correctly - I worked with the
developer of the XMPP state distribution in my design and we
realized that he had missed the distinction.

We need to be able to publish device states for aggregation into
extension states, but also publish extension states for blinking
lamps. IE, a hint would be based on a device state subscription.

The device state event states could be simple JSON attachments,
preferably with a host name, the channel name and the device name.

/O