29 Jan
2013
29 Jan
'13
6:41 a.m.
Hi all,
I am trying to set up a fax gateway in the following way:
PSTN-GW (10.1.1.150) <--> Kamailio (10.1.1.148:5123) <--> t38modem
(10.1.1.148:6050) <--> Hylafax
PSTN-GW is a standalone Berofix appliance and Kamailio 3.3.3, t38modem
1.2 and Hylafax 6.0.3 running on the same host under Redhat EL6.
I used the default kamailio.cfg and just adjusted the PSTN route pattern
to "if(!($rU=~"^(\+|00|0)[1-9][0-9]{3,20}$"))", to route all calls
starting with 0 to the PSTN-GW.
Both PSTN-GW and t38modem Successfully register to Kamailio but when I
try to send out a fax from t38modem, Kamailio doesn't ACK the
Proxy-Authorization request and t38modem terminates the call:
<siptrace>
05:49:11.158157 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto
UDP (17), length 986)
10.1.1.148.6050 > 10.1.1.148.5123: UDP, length 958
E.....@.@.Y.
.d.
.d.........INVITE sip:030987654321@10.1.1.148:5123 SIP/2.0
Route: <sip:10.1.1.148:5123;lr>
Date: Tue, 29 Jan 2013 04:49:11 GMT
CSeq: 1 INVITE
Via: SIP/2.0/UDP
10.1.1.148:6050;branch=z9hG4bK020144e4-3c68-e211-98e4-005056bd002b;rport
User-Agent: T38Modem/1.2.0
From: "root"
<sip:030123456789@10.1.1.148:5123>;tag=169d43e4-3c68-e211-98e4-005056bd002b
Call-ID: 16a243e4-3c68-e211-98e4-005056bd002b(a)myhost.mydomain.local
Organization: Vyacheslav Frolov
To: <sip:030987654321@10.1.1.148:5123>
Contact: <sip:030123456789@10.1.1.148:6050>
Allow:
INVITE,ACK,OPTIONS,BYE,CANCEL,SUBSCRIBE,NOTIFY,REFER,MESSAGE,INFO,PING
Content-Type: application/sdp
Content-Length: 262
Max-Forwards: 70
v=0
o=- 1359434951 1 IN IP4 10.1.1.148
s=Opal SIP Session
c=IN IP4 10.1.1.148
t=0 0
m=audio 5008 RTP/AVP 8 101 100
a=sendrecv
a=rtpmap:8 PCMA/8000/1
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16,32,36
a=rtpmap:100 NSE/8000
a=fmtp:100 192-193
05:49:11.158927 IP (tos 0x10, ttl 64, id 28825, offset 0, flags [none],
proto UDP (17), length 584)
10.1.1.148.5123 > 10.1.1.148.6050: UDP, length 556
E..Hp...@.*.
.d.
.d......4.oSIP/2.0 407 Proxy Authentication Required
CSeq: 1 INVITE
Via: SIP/2.0/UDP
10.1.1.148:6050;branch=z9hG4bK020144e4-3c68-e211-98e4-005056bd002b;rport=6050
From: "root"
<sip:030123456789@10.1.1.148:5123>;tag=169d43e4-3c68-e211-98e4-005056bd002b
Call-ID: 16a243e4-3c68-e211-98e4-005056bd002b(a)myhost.mydomain.local
To:
<sip:030987654321@10.1.1.148:5123>;tag=75c88a497c1ef184e8ac0d2e60c130e4.0580
Proxy-Authenticate: Digest realm="10.1.1.148",
nonce="UQdV81EHVMeoOdE8gs8P4V1EFJAb79/W"
Server: kamailio (3.3.3 (x86_64/linux))
Content-Length: 0
05:49:11.160273 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto
UDP (17), length 501)
10.1.1.148.6050 > 10.1.1.148.5123: UDP, length 473
E.....@.@.[.
.d.
.d.........ACK sip:030987654321@10.1.1.148:5123 SIP/2.0
Route: <sip:10.1.1.148:5123;lr>
CSeq: 1 ACK
Via: SIP/2.0/UDP
10.1.1.148:6050;branch=z9hG4bK020144e4-3c68-e211-98e4-005056bd002b;rport
From: "root"
<sip:030123456789@10.1.1.148:5123>;tag=169d43e4-3c68-e211-98e4-005056bd002b
Call-ID: 16a243e4-3c68-e211-98e4-005056bd002b(a)myhost.mydomain.local
To:
<sip:030987654321@10.1.1.148:5123>;tag=75c88a497c1ef184e8ac0d2e60c130e4.0580
Content-Length: 0
Max-Forwards: 70
05:49:11.166542 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto
UDP (17), length 1195)
10.1.1.148.6050 > 10.1.1.148.5123: UDP, length 1167
E.....@.@.Y.
.d.
.d.........INVITE sip:030987654321@10.1.1.148:5123 SIP/2.0
Route: <sip:10.1.1.148:5123;lr>
Date: Tue, 29 Jan 2013 04:49:11 GMT
CSeq: 2 INVITE
Via: SIP/2.0/UDP
10.1.1.148:6050;branch=z9hG4bK146145e4-3c68-e211-98e4-005056bd002b;rport
User-Agent: T38Modem/1.2.0
From: "root"
<sip:030123456789@10.1.1.148:5123>;tag=169d43e4-3c68-e211-98e4-005056bd002b
Call-ID: 16a243e4-3c68-e211-98e4-005056bd002b(a)myhost.mydomain.local
Organization: Vyacheslav Frolov
To: <sip:030987654321@10.1.1.148:5123>
Contact: <sip:030123456789@10.1.1.148:6050>
Proxy-Authorization: Digest username="979", realm="10.1.1.148",
nonce="UQdV81EHVMeoOdE8gs8P4V1EFJAb79/W",
uri="sip:030987654321@10.1.1.148:5123", algorithm=MD5,
response="48d896ef41a71720b29c56230858582f"
Allow:
INVITE,ACK,OPTIONS,BYE,CANCEL,SUBSCRIBE,NOTIFY,REFER,MESSAGE,INFO,PING
Content-Type: application/sdp
Content-Length: 262
Max-Forwards: 70
v=0
o=- 1359434951 1 IN IP4 10.1.1.148
s=Opal SIP Session
c=IN IP4 10.1.1.148
t=0 0
m=audio 5008 RTP/AVP 8 101 100
a=sendrecv
a=rtpmap:8 PCMA/8000/1
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16,32,36
a=rtpmap:100 NSE/8000
a=fmtp:100 192-193
05:49:11.167573 IP (tos 0x10, ttl 64, id 28826, offset 0, flags [none],
proto UDP (17), length 584)
10.1.1.148.5123 > 10.1.1.148.6050: UDP, length 556
E..Hp...@.*.
.d.
.d......4.oSIP/2.0 407 Proxy Authentication Required
CSeq: 2 INVITE
Via: SIP/2.0/UDP
10.1.1.148:6050;branch=z9hG4bK146145e4-3c68-e211-98e4-005056bd002b;rport=6050
From: "root"
<sip:030123456789@10.1.1.148:5123>;tag=169d43e4-3c68-e211-98e4-005056bd002b
Call-ID: 16a243e4-3c68-e211-98e4-005056bd002b(a)myhost.mydomain.local
To:
<sip:030987654321@10.1.1.148:5123>;tag=75c88a497c1ef184e8ac0d2e60c130e4.263a
Proxy-Authenticate: Digest realm="10.1.1.148",
nonce="UQdV81EHVMeoOdE8gs8P4V1EFJAb79/W"
Server: kamailio (3.3.3 (x86_64/linux))
Content-Length: 0
05:49:11.169220 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto
UDP (17), length 710)
10.1.1.148.6050 > 10.1.1.148.5123: UDP, length 682
E.....@.@.Z.
.d.
.d.........ACK sip:030987654321@10.1.1.148:5123 SIP/2.0
Route: <sip:10.1.1.148:5123;lr>
CSeq: 2 ACK
Via: SIP/2.0/UDP
10.1.1.148:6050;branch=z9hG4bK146145e4-3c68-e211-98e4-005056bd002b;rport
From: "root"
<sip:030123456789@10.1.1.148:5123>;tag=169d43e4-3c68-e211-98e4-005056bd002b
Call-ID: 16a243e4-3c68-e211-98e4-005056bd002b(a)myhost.mydomain.local
To:
<sip:030987654321@10.1.1.148:5123>;tag=75c88a497c1ef184e8ac0d2e60c130e4.263a
Proxy-Authorization: Digest username="979", realm="10.1.1.148",
nonce="UQdV81EHVMeoOdE8gs8P4V1EFJAb79/W",
uri="sip:030987654321@10.1.1.148:5123", algorithm=MD5,
response="3056b266b15a92f5cc8cc8e1c073fbcb"
Content-Length: 0
Max-Forwards: 70
</siptrace>
What do I have to adjust to make this work?
Any help and pointers highly appreciated.
Thanks in advance and greetings,
Carsten.
--
Blinkenlichten (Maass & Sacha GbR) - Open Source Solutions
Weigandufer 45 - 12059 Berlin - http://www.blinkenlichten.de
FON: ++49 +30 13896247 - MAIL: cm(a)blinkenlichten.de
FAX: ++49 +30 13896249 - PGP: Key Id 0x2CBCA806
St.Nr. 16/274/61636
29 Jan
29 Jan
1:40 p.m.
Hello,
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.
On 01/29/2013 06:41 AM, Carsten Maass wrote:
Hi all,
I am trying to set up a fax gateway in the following way:
PSTN-GW (10.1.1.150) <--> Kamailio (10.1.1.148:5123) <--> t38modem
(10.1.1.148:6050) <--> Hylafax
PSTN-GW is a standalone Berofix appliance and Kamailio 3.3.3, t38modem
1.2 and Hylafax 6.0.3 running on the same host under Redhat EL6.
I used the default kamailio.cfg and just adjusted the PSTN route pattern
to "if(!($rU=~"^(\+|00|0)[1-9][0-9]{3,20}$"))", to route all calls
starting with 0 to the PSTN-GW.
Both PSTN-GW and t38modem Successfully register to Kamailio but when I
try to send out a fax from t38modem, Kamailio doesn't ACK the
Proxy-Authorization request and t38modem terminates the call:
...
</siptrace>
What do I have to adjust to make this work?
Any help and pointers highly appreciated.
Thanks in advance and greetings,
Carsten.
5:25 p.m.
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.
--
Blinkenlichten (Maass & Sacha GbR) - Open Source Solutions
Weigandufer 45 - 12059 Berlin - http://www.blinkenlichten.de
FON: ++49 +30 13896247 - MAIL: cm(a)blinkenlichten.de
FAX: ++49 +30 13896249 - PGP: Key Id 0x2CBCA806
St.Nr. 16/274/61636
5:31 p.m.
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.
5:52 p.m.
Hi Andrew,
On 29.01.2013 17:31, Andrew Pogrebennyk wrote:
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
My kamailio.cfg is at http://pastebin.com/Aqk9s4KK
Thanks again and greetings,
Carsten.
--
Blinkenlichten (Maass & Sacha GbR) - Open Source Solutions
Weigandufer 45 - 12059 Berlin - http://www.blinkenlichten.de
FON: ++49 +30 13896247 - MAIL: cm(a)blinkenlichten.de
FAX: ++49 +30 13896249 - PGP: Key Id 0x2CBCA806
St.Nr. 16/274/61636
8:25 p.m.
Hi Andrew,
On 29.01.2013 17:52, Carsten Maass wrote:
On 29.01.2013 17:31, Andrew Pogrebennyk wrote:
> 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
if I comment out the offending code block around line 721
# authenticate requests
if (!auth_check("$fd", "subscriber", "1"))
{
auth_challenge("$fd", "0");
exit;
}
the call indeed passes through.
What I learned from
http://kamailio.org/dokuwiki/doku.php/pseudovariables:3.1.x
the pseudo-variable $fd references to domain in URI of 'From' header,
which in this case is
From: "root" <sip:030123456789@10.1.1.148:5123>
Does this mean, the authentication is rejected because the domain part
of the URI is identical to the one from Kamailio?
Or does it mean, the authentication is rejected because the local part
030123456789 in URI does not match the subscriber 979?
Greetings,
Carsten.
--
Blinkenlichten (Maass & Sacha GbR) - Open Source Solutions
Weigandufer 45 - 12059 Berlin - http://www.blinkenlichten.de
FON: ++49 +30 13896247 - MAIL: cm(a)blinkenlichten.de
FAX: ++49 +30 13896249 - PGP: Key Id 0x2CBCA806
St.Nr. 16/274/61636
9 p.m.
New subject: [Solved] REGISTER OK but on send "407 Proxy Authentication Required" with no ACK
Hi Andrew,
problem solved. I changed the outbound CID in t38modem to match the
subscriber ID in Kamailio and now the authentication succeeds and the
calls pass through.
Thanks a lot for sending me on the right path and your valuable time.
Cheers,
Carsten.
On 29.01.2013 20:25, Carsten Maass wrote:
Hi Andrew,
On 29.01.2013 17:52, Carsten Maass wrote:
--
Blinkenlichten (Maass & Sacha GbR) - Open Source Solutions
Weigandufer 45 - 12059 Berlin - http://www.blinkenlichten.de
FON: ++49 +30 13896247 - MAIL: cm(a)blinkenlichten.de
FAX: ++49 +30 13896249 - PGP: Key Id 0x2CBCA806
St.Nr. 16/274/61636
On 29.01.2013 17:31, Andrew Pogrebennyk wrote:
> 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
if I comment out the offending code block around line 721
# authenticate requests
if (!auth_check("$fd", "subscriber", "1"))
{
auth_challenge("$fd", "0");
exit;
}
the call indeed passes through.
What I learned from
http://kamailio.org/dokuwiki/doku.php/pseudovariables:3.1.x
the pseudo-variable $fd references to domain in URI of 'From' header,
which in this case is
From: "root" <sip:030123456789@10.1.1.148:5123>
Does this mean, the authentication is rejected because the domain part
of the URI is identical to the one from Kamailio?
Or does it mean, the authentication is rejected because the local part
030123456789 in URI does not match the subscriber 979?
Greetings,
Carsten.
30 Jan
30 Jan
10:53 a.m.
Carsten,
On 01/29/2013 08:25 PM, Carsten Maass wrote:
Or does it mean, the authentication is rejected
because the local part
030123456789 in URI does not match the subscriber 979?
Indeed, this is what happens when you call auth_check with flag "1":
if (!auth_check("$fd", "subscriber", "1")) {..}
flags - set of flags to control the behaviour of the function. If it is
1, then the function will check to see if the authentication username
matches either To or From header username, a matter of whether it is for
a REGISTER request or not..
Glad you solved it.
Andrew
4112
days inactive
4113
days old
7 comments
2 participants
participants (2)
-
Andrew Pogrebennyk -
Carsten Maass