<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Good to see the discussion had more people and wider approach on
different levels, covering pure agnostic signaling up to specific
application constraints.<br>
<br>
While being somehow silent, I worked to make a concrete step
forward, developing a new module for kamailio named auth_xkeys --
for those interested, some details here:<br>
<br>
* <a class="moz-txt-link-freetext" href="http://kamailio.org/docs/modules/devel/modules/auth_xkeys.html">http://kamailio.org/docs/modules/devel/modules/auth_xkeys.html</a><br>
<br>
Specifically, the issue I wanted to solve with this one is the
elasticity of authentication/trust relations between the nodes of a
VoIP platform.<br>
<br>
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.<br>
<br>
Imagine I have a cloud of 200 asterisk/kamailio application servers
and I want to add another Kamailio edge proxy/load balancer in
Singapore to collect the traffic from the area based on DNS. Will
require an update to 200 nodes for adding a new trusted IP. With a
shared secret to build the auth key, that is transparent. Think
about that you need to orchestrate the number of application servers
and edge proxy dynamically to be able to cope with special
situations (DDoS attacks, unexpected emergencies for lot of people
(earthquake, etc...) or days of the year with lot of traffic
(christmas, new year)).<br>
<br>
What I implemented with auth_xkeys is not something new, it is used
a lot by the API web services (e.g., github) and I think it is good
for SIP networks as well. It is more about secret keys management.<br>
<br>
What Asterisk devs think about it? Does it sound useful to get a
similar mechanism in Asterisk? I can provide more tech details if
needed, just ask.<br>
<br>
Now some remarks on different points discussed by others here before:<br>
<br>
- to confirm: dispatcher can take the algorithm and destination set
id from variables, those values can be taken from anywhere (db, via
some api, etc)<br>
- DNS is good for discovery, but propagation is unreliable over the
public networks<br>
- using an embedded language to create all the attributes needed for
the context of the call is ok as long as it doesn't do any other
network communication. There is already a sip packet sent between
the nodes. If the sender has to do some network transmission to
prepare the receiver, it adds another set of troubles: delays,
connection failures, incomplete transmissions, etc. - it is not
helping much with scalability. In other words, ideally I am looking
for something like: you got the INVITE request from a trusted proxy,
all needed for routing should be inside it + some config templates.<br>
<br>
Daniel<br>
<br>
<div class="moz-cite-prefix">On 24/02/15 17:58, Matthew Jordan
wrote:<br>
</div>
<blockquote
cite="mid:CAN2PU+4RprKau-6G-JRJq+9wtqr85Mpfa9_rMUTLTqoQZCD0nw@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, Feb 23, 2015 at 2:07 PM, Olle
E. Johansson <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:oej@edvina.net" target="_blank">oej@edvina.net</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div style="word-wrap:break-word"><br>
<div>
<div>
<div class="h5">
<div>On 23 Feb 2015, at 20:10, Matthew Jordan <<a
moz-do-not-send="true"
href="mailto:mjordan@digium.com"
target="_blank">mjordan@digium.com</a>>
wrote:</div>
<br>
<blockquote type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, Feb 23,
2015 at 11:16 AM, James Cloos <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:cloos@jhcloos.com"
target="_blank">cloos@jhcloos.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">>>>>>
"MJ" == Matthew Jordan <<a
moz-do-not-send="true"
href="mailto:mjordan@digium.com"
target="_blank">mjordan@digium.com</a>>
writes:<br>
<br>
MJ> What I'm trying to reason out is:
given a set of routing constraints -<br>
MJ> which includes not only load
balancing but also "application" level
routing<br>
MJ> decisions - what's the
appropriate place for that information
to live?<br>
MJ> Particularly when you want your
entire system - not just Asterisk - to
be<br>
MJ> scalable?<br>
<br>
You need to use something to keep track
of whether each box is reachable<br>
and what each is doing. There a lots of
ways of doing that, including<br>
custom network applications, shared
networkable databases, shared nfs,<br>
et alia.<br>
<br>
Then each node needs a bit of logic to
use that data to determine what<br>
to do with any given event.<br>
<br>
As one example, if a sip server gets an
invite which directs on to an<br>
existing conference, it needs to know
which asterisk is handling that<br>
conference, so that it can send the
invite there.<br>
<br>
A shared database is required, but
whether it is a custom application, a<br>
networkable db or a local db stored on a
networked file systems is<br>
something anyone writing the code needs
to choose.<br clear="all">
</blockquote>
</div>
<br>
</div>
<div class="gmail_extra">Completely agree.<br>
<br>
</div>
<div class="gmail_extra">What I'm driving
towards - albeit in something of a
roundabout fashion - are two notions:<br>
</div>
<div class="gmail_extra">(1) Hard coding logic
in application configuration does not lend
itself well to scalability. Kamailio lessens
the pain in certain ways - you're typically
going to have fewer proxies than application
servers (although, I suppose that depends on
what you are doing). Also, as Olle pointed
out, you can replicate information out using
an htable. Or use a database. To some extent
though, this is not much different than
using func_odbc with Asterisk (a concept
many people miss often.) At the same time,
requiring direct access to a database from
my routing engine/media application server
does not lend itself well to expressive
logic. While I've managed to push the data
out of the application, I haven't
necessarily done the same with the business
rules.<br>
<br>
</div>
<div class="gmail_extra">If you approach the
problem purely from a "how horizontally
scalable can I make this," then ideally most
of your business logic would lie outside of
the routing engine (Kamailio) or the media
application server (Asterisk). That may mean
a web microservice architecture that exposes
REST APIs for the real-time component to
consume. That may mean something else. As
Daniel noted, the more REST APIs you hit
using a cURL module (or what have you), the
slower things get in Kamailio. The same is
true for Asterisk. What I'm trying to fish
for is where that dividing line should occur
- that is, what properly belongs to Kamailio
(routing decisions) and what properly
belongs to something else.<br>
<br>
</div>
<div class="gmail_extra">(2) Domain specific
languages require domain specific knowledge.
This is not necessarily a bad thing. At the
same time, it's far easier to parallelize
the problem of application development if
you can split tasks into well defined
domains that make use of tools that have a
wider base of knowledge. If, for example,
the logic of "who is in a conference on
which server" can be answered by a REST API
written in Python, or JavaScript, or
something else - and does not even live on
the Kamailio server - then not only does the
job of the Kamailio integrator become
easier, it is also becomes easier to find
multiple people to help write the services
that it integrates with.<br>
</div>
</div>
</blockquote>
<br>
</div>
</div>
Kamailio really doesn't need to know as long as
Asterisk knows... You are trying to solve something
that is not really a problem, Matt. I have tried this
path before with conferences and ended up with
something too complex. Went back to</div>
<div>forking, if a server responded with 200 OK I added
a temporary state in an autoexpire hashtable so I
remembered for next call which did not need to fork.
Simple. Fast. No distributed states.</div>
<div><br>
</div>
<div>The real key to scalability is keeping it simple
and keeping states local. As soon as you start trying
to synch or distribute states it gets very complex and
you loose a lot of scalability. Asterisk is filled
with all kinds of states, keep it there as much as
possible and be smart with your signalling. You want
to be able to restart Kamailio anytime without loosing
states and without disrupting any single call. As soon
as you start adding call states, server states and
conference server states you loose a lot of that and
end up with replication in databases and other complex
schemes.</div>
<div><br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Really, distributing the state in Asterisk is not much
of a problem in this scenario. Sure, if the application in
question is ConfBridge, or Queue, or some other dialplan
application, then the difficulty of sharing that state
across clustered Asterisk instances is non-trivial.
However, in a system where the application state lives off
of the Asterisk boxes - that is, where ARI is used to
control the Asterisk instances and an external process (or
set of processes - everyone must scale!) manages the
application state - then the question of how the
application state distributed is solved.<br>
<br>
</div>
<div>That is: I'm not really questioning where the
application state lives. I'm questioning how routing
decisions - which may be impacted by that application
state - should be made. It sounds like the answer is
"don't worry, and just use Kamailio's built-in routing
mechansims." Which is an acceptable answer - there's ways
to work with that answer in a clustered Asterisk
environment.<br>
</div>
<div><br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div style="word-wrap:break-word">
<div>Forking doesn't cost much, really. Using SIP makes
life simple. The network flow is already established.</div>
<div><br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Forking to all Asterisk servers is certainly a
solution. I could also 302 the INVITE request or send a
REFER request to the initiator to move the session to
another Asterisk server if the one it lands on isn't the
one that is "correct" based on some application state.
Handling that at the application level is relatively
straight forward; my line of questioning was really to
make sure that there isn't some mechanism in Kamailio that
would be more appropriate.<br>
</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div style="word-wrap:break-word">
<div>If you are looking for restful interfaces, Kamailio
has an embedded HTTP server you can use for quite a
lot compared with the Asterisk one. The HTTP requests
are as configurable and routable as the SIP
requests... Quite cool.</div>
<div><br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>You do know we built all of ARI on the internal
Asterisk HTTP server, right? :-)<br>
<br>
</div>
<div>Of course, the request callbacks aren't exposed to the
dialplan - but then again, that's not really a concept
that the Asterisk dialplan syntax would handle well. <br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div style="word-wrap:break-word">
<div>There are a few applications that require more
states, like trying to build a PBX in Kamailio. - but
why try that when Asterisk has all the functionality
you need? :-)</div>
<div><br>
</div>
<div>Keep the states where they belong. </div>
<div><br>
</div>
<div>Now for load balancing, we could add a module to
Asterisk that sends simple SIP messages with an
attachment that describes current call load and maybe
a few global variables that I configure.
application/asteriskstate - simple json structure that
we can parse in Kamailio and use for load balancing on
call and cpu load. This could be a subscribe/notify
event package that Kamailio feeds into the DMQ
cluster.</div>
<div><br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Since this would be consumable in Kamailio, a spec on
the event package would be handy.<br>
<br>
</div>
<div>I noticed that there are some RFCs for this already.
Most are informational, although RFC 7200 looks to take
things to quite a logical extreme. Any thoughts on these?<br>
<br>
</div>
<div>* RFC 5390: Requirements for Management of Overload in
the Session Initiation Protocol - <a
moz-do-not-send="true"
href="https://tools.ietf.org/html/rfc5390">https://tools.ietf.org/html/rfc5390</a><br>
</div>
<div>* RFC 6357: Design Considerations for Session
Initiation Protocol (SIP) Overload Control - <a
moz-do-not-send="true"
href="https://tools.ietf.org/html/rfc6357">https://tools.ietf.org/html/rfc6357</a><br>
</div>
<div>* RFC 7200: A Session Initiation Protocol (SIP)
Load-Control Event Package - <a moz-do-not-send="true"
href="https://tools.ietf.org/html/rfc7200">https://tools.ietf.org/html/rfc7200</a><br>
<br>
<br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div style="word-wrap:break-word">
<div>Another thing would be to have events triggered on
startup of asterisk and shutdown - maybe something as
simple as a REGISTER. These could be used to enable
and disable one Asterisk server in a dispatcher set.</div>
<span class=""><font color="#888888">
<div><br>
</div>
</font></span><br clear="all">
</div>
</blockquote>
</div>
<br>
</div>
<div class="gmail_extra">I would imagine that in any clustered
scenario, you would want Asterisk to REGISTER to Kamailio to
notify it of its existence. If a SUBSCRIBE/NOTIFY scheme were
used to inform Kamailio of the loaded status of the Asterisk
instances, Kamailio could then SUBSCRIBE to Asterisk and start
receiving subsequent NOTIFY requests.<br>
</div>
<div class="gmail_extra"><br>
-- <br>
<div class="gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<div>Matthew Jordan<br>
</div>
<div>Digium, Inc. | Director of Technology<br>
</div>
<div>445 Jan Davis Drive NW - Huntsville, AL 35806 -
USA</div>
<div>Check us out at: <a moz-do-not-send="true"
href="http://digium.com" target="_blank">http://digium.com</a>
& <a moz-do-not-send="true"
href="http://asterisk.org" target="_blank">http://asterisk.org</a></div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Daniel-Constantin Mierla
<a class="moz-txt-link-freetext" href="http://twitter.com/#!/miconda">http://twitter.com/#!/miconda</a> - <a class="moz-txt-link-freetext" href="http://www.linkedin.com/in/miconda">http://www.linkedin.com/in/miconda</a>
Kamailio World Conference, May 27-29, 2015
Berlin, Germany - <a class="moz-txt-link-freetext" href="http://www.kamailioworld.com">http://www.kamailioworld.com</a></pre>
</body>
</html>