On 06/06/13 16:35, Daniel-Constantin Mierla wrote:
Hello,
On 6/6/13 11:05 AM, Daniel Pocock wrote:
I was just looking over:
http://kb.asipto.com/asterisk:realtime:kamailio-3.3.x-asterisk-10.7.0-astdb
A couple of things I noticed:
- Kamailio is using a column sippasswd which is not hashed. Asterisk
doesn't use that column at all. Is there any reason this can't be done with the H(A1) and H(A1b) columns? The INSERT example shows a non-encrypted password.
you can store hashed value there. In Kamailio is just a matter of config parameter/function parameter to say the loaded value is either plain text or ha1.
Great - are there any interoperability issues with the realm name when using hashes? I presume that as long as the same challenge realm name is configured in Asterisk and Kamailio and when making the hashes it is all OK?
I also posted a query on the asterisk-users list about support for ha1b - would you know if that is something that still comes up in practice? It is in the Kamailio schema, but I have not encountered a device behaving that way in practice.
- Is it all considered valid for Kamailio 4 and Asterisk 11? (maybe a
disclaimer could be added at the top)
There is another one for K4.0 and A11:
http://kb.asipto.com/asterisk:realtime:kamailio-4.0.x-asterisk-11.3.0-astdb
Not many changes and apparently there are newer updates in asterisk database structure on latest RC of 11.3.x.
Great - Google searches for "Asterisk Kamailio" or even "Asterisk 11 Kamailio 4" still return the old page, so maybe it is still useful to link the pages
- The Asterisk columns `md5secret' and `secret' are left empty so that
Asterisk won't challenge. I believe there are other ways of doing this: for example, telling Kamailio to be the registrar and forcing Asterisk to use outbound proxy mode. I managed to make this work against repro - Asterisk no longer receives any REGISTER messages, but all INVITEs go through Asterisk, so the double-challenge problem only arises for INVITEs. Maybe Asterisk can be told that Kamailio's source IP:port is `trusted' and doesn't need to be challenged - is anybody aware of such an option in Asterisk?
There are various ways of doing it, this particular one tried to be at least intrusive as possible in asterisk, not to require changing a deployed asterisk configuration.
For a new deployment, other approach is more recommended, using kamailio as outbound proxy.
As you can imagine, I've played with a few variations of this against repro
I've noticed that it isn't so straightforward, here are some issues (Asterisk faults, not proxy issues):
- Asterisk doesn't automatically use it's bind IP:port for outgoing connections to the proxy - so proxy ACLs are tricky to set up if the Asterisk host has multiple IPs
- if Asterisk tries to connect to a TLS proxy, and the proxy has optional client cert verification enabled, Asterisk tries to send it's cert. There seems to be no way to disable Asterisk sending a cert in this scenario, but the proxy doesn't like the way the client cert is submitted and so it seems impossible to connect to such a proxy.
This was observed with Asterisk 11.4