Hi Carsten,
It looks like the challenge is generated by the config line 721 - could
you post somewhere what is in there (or your whole config)?
5(31487) DEBUG: auth [api.c:218]: check_response: Authorization is OK
[...]
5(31487) ERROR: *** cfgtrace: c=[//etc/kamailio/kamailio.cfg] l=721
a=27 n=auth_challenge
On 01/29/2013 05:25 PM, Carsten Maass wrote:
Hello Andrew,
thanks for coming back to me.
On 29.01.2013 13:40, Andrew Pogrebennyk wrote:
I see no problem with an ACK in the trace. The
t38modem ACK's the
407, sends the new INVITE with authorization but it's not accepted
by kamailio. I'm not sure if t38modem can even perform the
authorization. Maybe you need to accept the calls from it without
authorization. But if it can and you have configured the password in
there, you should check that the subscriber 979 exist in kamailio
domain 10.1.1.148 and the passwords do match.
In the afterthought a siptrace might not have been the best way to show
the problem, as it could have legitimate reasons to reject the
Authentication.
Yes, the user exist in Kamailio:
# kamctl ul show --brief
Domain:: location table=512 records=2 max_slot=1
AOR:: 979(a)10.1.100.148
AOR:: berofixtrunk(a)10.1.100.148
and they are successfully registered:
# kamctl monitor
Server:: kamailio (3.3.3 (x86_64/linux))
Build:: mi_core.c compiled on 11:15:34 Dec 20 2012 with gcc 4.4.4
Flags:: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, TLS_HOOKS,
USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP,
PKG_MALLOC, F_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE,
USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
GIT:: 412053
Now:: Tue Jan 29 16:26:22 2013
Up since:: Tue Jan 29 07:27:36 2013
Up time:: 32326 [sec]
Transaction Statistics:
tmx:UAS_transactions = 1
tmx:UAC_transactions = 0
tmx:inuse_transactions = 0
Stateless Server Statistics:
sl:sent_replies = 791
sl:sent_err_replies = 0
sl:received_ACKs = 0
UsrLoc Stats:
usrloc:location-contacts = 2
usrloc:location-expires = 0
usrloc:location-users = 2
usrloc:registered_users = 2
On the t38modem side there is only one password, the same with which
t38modem successfully registers at Kamailio.
Here is an exerpt from the t38modem.log:
2013/01/29 16:39:15.973 Pool:0xc1b0d700 SIP Sending PDU
INVITE sip: 030987654321@10.1.1.148:5123 (1167 bytes) to:
rem=udp$10.1.1.148:5123,local=u
dp$10.1.1.148:6050,if=10.1.1.148%eth0
2013/01/29 16:39:15.973 Pool:0xc1b0d700 OpalUDP Setting
interface to 10.1.1.148%eth0
2013/01/29 16:39:15.975 Opal Liste...0xc1c52700 OpalUDP Binding to
interface: 10.1.1.148:6050
2013/01/29 16:39:15.975 Opal Liste...0xc1c52700 SIP PDU 407 Proxy
Authentication Required received:
rem=udp$10.1.1.148:5123,local=udp$10.1.1.148:6050,
if=10.1.1.148%eth0
2013/01/29 16:39:15.975 Opal Liste...0xc1c52700 Opal Transport clean
up on termination
2013/01/29 16:39:15.975 Pool:0xc1b0d700 SIP Adding
authentication information for user "979" at realm "10.1.1.148"
2013/01/29 16:39:15.976 Pool:0xc1b0d700 SIP Sending PDU ACK
sip: 030987654321@10.1.1.148:5123 (682 bytes) to:
rem=udp$10.1.1.148:5123,local=udp$1
0.1.100.148:6050,if=10.1.1.148%eth0
2013/01/29 16:39:15.976 Pool:0xc1b0d700 OpalUDP Setting
interface to 10.1.1.148%eth0
2013/01/29 16:39:15.976 Pool:0xc1b0d700 SIP INVITE
transaction id=z9hG4bK7892f2b4-9768-e211-98e4-005056bd002b completed.
2013/01/29 16:39:15.976 Pool:0xc1b0d700 SIP Received Proxy
Authentication Required response
2013/01/29 16:39:15.976 Pool:0xc1b0d700 SIP Found auth info
for realm "10.1.1.148", user "979"
2013/01/29 16:39:15.976 Pool:0xc1b0d700 SIP Authentication
already performed using current credentials, not trying again.
2013/01/29 16:39:15.976 Pool:0xc1b0d700 OpalCon SetPhase from
SetUpPhase to ReleasingPhase for
Call[d4a716ee69]-EP<sip>[5c51f0b4-9768-e211-98e4-005056b
d002b]
2013/01/29 16:39:15.976 Pool:0xc1b0d700 OpalCon Releasing
Call[d4a716ee69]-EP<sip>[5c51f0b4-9768-e211-98e4-005056bd002b]
2013/01/29 16:39:15.976 Pool:0xc1b0d700 OpalCon Call end reason
for Call[d4a716ee69]-EP<sip>[5c51f0b4-9768-e211-98e4-005056bd002b] set
to EndedByQ931Ca
use
T38modem gets a 407, sends out the Authorization request, gets back a
407 and doesn't try again, because the same credentials were already sent.
The debug output of Kamailio can be found at
http://pastebin.com/7r1V5JyE
At line 158 it looks like it succeeds the authentication, but in line
169 it sends out another Proxy-Authenticate request.
The error in line 167 points to this code in kamailio.conf:
# authenticate requests
if (!auth_check("$fd", "subscriber", "1"))
{
auth_challenge("$fd", "0");
exit;
}
Could this be the culprit? How can I avoid it?
Thanks and greetings,
Carsten.