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.

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: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