REGISTER OK but on send "407 Proxy Authentication Required" with no ACK
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@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@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@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@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@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@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@blinkenlichten.de FAX: ++49 +30 13896249 - PGP: Key Id 0x2CBCA806 St.Nr. 16/274/61636
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.
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@10.1.100.148 AOR:: berofixtrunk@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@blinkenlichten.de FAX: ++49 +30 13896249 - PGP: Key Id 0x2CBCA806 St.Nr. 16/274/61636
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@10.1.100.148 AOR:: berofixtrunk@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.
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@blinkenlichten.de FAX: ++49 +30 13896249 - PGP: Key Id 0x2CBCA806 St.Nr. 16/274/61636
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@blinkenlichten.de FAX: ++49 +30 13896249 - PGP: Key Id 0x2CBCA806 St.Nr. 16/274/61636
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:
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@blinkenlichten.de FAX: ++49 +30 13896249 - PGP: Key Id 0x2CBCA806 St.Nr. 16/274/61636
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
participants (2)
-
Andrew Pogrebennyk -
Carsten Maass