[asterisk-dev] AstriDevCon Follow Up - Asterisk and Kamailio - smoother integration

[Matthew Jordan]

On Wed, Mar 11, 2015 at 6:26 PM, Daniel-Constantin Mierla
<miconda at gmail.com> wrote:
>
>
> On 11/03/15 22:11, Matthew Jordan wrote:
>> On Wed, Mar 11, 2015 at 3:31 PM, Olle E. Johansson <oej at edvina.net> wrote:
>>>>> So far most of authorization between Kamailio and Asterisk relies on IP
>>>>> addresses, but those need to be provisioned one by one in both sides. The
>>>>> new module is practically adding a custom header with a hash over parts of
>>>>> the message or other environment attributes (eg., IP address) and a shared
>>>>> secret. The www-digest with username and password has the overhead of an
>>>>> extra round of signaling messages, but also the constraint on CSeq increment
>>>>> after the challenge. Also, the MD5 is rather week hashing these days.
>>>>>
>>> Why can't this be done in the dialplan?. This is exactly why I implemented the MD5
>>> dialplan stuff in Asterisk years ago. We need something else than MD5 today,
>>> but still - both Asterisk and Kamailio can handle it without modules or extra coding...
>>>
>>> The IETF is working on OAUTH authentication for SIP - which is the solution
>>> we really want to look into - not copy weak auth from the API world... :-)
>
> Continuing the thread, but answering to Olle's remarks -- yes, many
> things can be done via config, as I noted it is mainly about the
> management of the shared secret rather than the computing of the
> hashing. I consider it important to be able to work verifying against
> many keys at the same time, but using one (the most recent) for adding
> the header.
>
> Then I didn't want a complex scripting around it, with db queries and
> managing the result in the config, putting extra complexity there. The
> idea was to make it as scalable and elastic as possible. Also, C coding
> is the easiest I can do ;-) and again, I wanted to come up with some
> real stuff, not just theoretical discussion. Being something good or
> bad, is now opened for discussions.
>
> One problem with IETF is that takes ages for new good specs and the 'API
> guys' will be further ahead with new auth mechanisms by that time. Not
> to say that many things from IETF come out without any practical
> background, being based on pure theoretical concepts from some
> specs-writting-machine-guys.
>
> While I am all for standardization and open specifications, I think that
> some concepts can be tested before pushing to a formalization. And open
> source should be the perfect ground for such ideas, if found useful
> and/or practical, someone can take the lead on standardization process.
> In other words, I want open source to be more involve in standardizing
> practical things, rather than implementing specs from others --
> definitely will be more feasible specs out of such process.
>

If we put aside the notion of authentication for a second, I think it
is worth exploring the concept of 'identity' - that is, how does an
Asterisk instance know who the Kamailio instance that just sent a
request is, and how should it treat it.

Currently, the most used (and probably the only way) is to use
Asterisk RealTime, and - before the new Kamailio instance sends a
request to an instance in the cluster - add an endpoint for that
instance in the database. When a request is received from the new
Kamailio node, an Asterisk instance will query the database, match the
endpoint using one of the existing mechanisms (From user, IP
address/hostname, etc.), and then perform authentication using the
proposed mechanism.

There are downsides to this approach:
(1) All Asterisk nodes have to either use the same database, or else
the new Kamailio endpoint has to be replicated across multiple
databases. Either way, the databases become the limiting factor in
scaling.
(2) Ostensibly, if the goal is to have a new node "inform" the cluster
of its existence, then requiring a database update for nodes in the
cluster to occur defeats much of the "discovery" message.

Is there a better, or different way? In an ideal world, how should a
new Asterisk instance be informed of the existence of a new Kamailio
instance?

A few rough ideas:

* Map instances of Kamailio to a single endpoint definition. This
works fine for inbound requests, but has limitations on how Asterisk
can place outbound requests to specific instances, as it must send all
outbound INVITE requests using specific SIP URIs in the dialplan.
* Allow something external to both systems (possibly whatever decided
to bring up a new Kamailio instance in the first place) to push the
configuration of the PJSIP endpoint into Asterisk. This could be
exposed through ARI.
* Use an existing platform, such as Corosync, to provide the
"discoverability" of nodes and map that (somehow) to PJSIP endpoints.

There may be other ideas - I'd be very curious what others think is
the best way to handle this particular scenario, as it gets rather
tricky quickly.

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org