11 Jun
2013
11 Jun
'13
11:10 a.m.
On 10/06/13 09:32, Daniel-Constantin Mierla wrote:
I first hit this issue with Asterisk 1.8 I think - ever since then, I've
been doing the same workaround with transport=tcp (I found some UDP
packets would be too big)
Hello,
On 6/7/13 11:33 AM, Daniel Pocock wrote:
Oddly enough, I almost forgot to mention Lumicall is using the ha1b column.
In Lumicall, it is explicitly configured in the phone settings:
authentication username = +41xxxxx(a)sip5060.net
and it sends that whole value to the SIP proxy in the auth header
To be clear, this was an administrative decision and not a
device-specific issue.
- instead of having a ha1b column (which is a hassle for sharing the
database with Asterisk or other systems that don't know ha1b), maybe it
is also useful to have an auth_user column or to have a flag in the
domains table to indicate that the user@domain convention is used for a
particular domain?
- in other cases, do people expect this for administrative reasons or
solely to support devices that are internally hard-wired to this behavior?
On 06/06/13 16:35, Daniel-Constantin Mierla
wrote:
Yes, same realm along same username and password results in same hash.
Hello,
On 6/6/13 11:05 AM, Daniel Pocock wrote:
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 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. 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.
There are few devices, not remembering any at this moment that use
user value in authentication header as being username@domain.
ha1 = MD5(username:realm:password)
ha1b = MD5(username@domain:realm:password)
I hope I remembered correctly the order, by you get the idea. - 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
I haven't played with Asterisk over tls, I used kamailio to bridge tls
to udp and then send to asterisk.