[Home]

Summary:ASTERISK-11767: the Authenticate app does not authenticate my second call
Reporter:Edgar Landivar (elandivar)Labels:
Date Opened:2008-04-01 19:35:26Date Closed:2011-06-07 14:08:27
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Applications/app_authenticate
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) authenticate.cli.failed.txt
( 1) authenticate.cli.success.txt
( 2) authenticate.var.log.asterisk.full.failed.txt
( 3) authenticate.var.log.asterisk.full.success.txt
( 4) test2.log
Description:Hello Folks,

I have a very weird issue here when I try to authenticate my calls with a pinset. This is the scenario:

I place a call from an extension to an outside number, the system asks for a pin, i dial the pin, the call is authenticated succesfuly and everything ok.

If I put this call on hold and call another outside number, the system ask for a pin, i dial the right pin but the system says that the password is incorrect.

I'm entering the password correctly. To verify this i modified some lines of the app_authenticate.c file to print the password i'm entering.

This is the block of code I modified:

       /* Start asking for password */
       prompt = "agent-pass";
       for (retries = 0; retries < 3; retries++) {
               res = ast_app_getdata(chan, prompt, passwd, maxdigits, 0);
               if (res < 0)
                       break;
               res = 0;
               /* here is my line to print the password */
               ast_log(LOG_WARNING, "XXXXXXXXXXXXXXXXX: The password is %s\n", passwd);

The first time i can see my password in the asterisk log file but the second time the password is empty. I have tried dozens of times.

I'm using freePBX (which comes with Elastix). So, the dialplan logic to handle the authentication is very simple:

[macro-pinsets]
include => macro-pinsets-custom
exten => s,1,GotoIf(${ARG2} = 1?cdr,1)
exten => s,n,Authenticate(/etc/asterisk/pinset_${ARG1},)
exten => cdr,1,Authenticate(/etc/asterisk/pinset_${ARG1},a)

Thanks a lot for any help.
Comments:By: Joshua C. Colp (jcolp) 2008-04-02 10:32:40

What technology are you using to call in on? If SIP what is the DTMF mode in use? Can you please upload complete console output, along with core debug.
By: Edgar Landivar (elandivar) 2008-04-02 14:10:58

The technology is IAX. I'm going to ask the customer to access his equipment this afternoon.
By: Edgar Landivar (elandivar) 2008-04-07 12:18:55

Hello Folks,

I finally could access the customer equipment and notice that the technology is SIP instead of IAX, configured with rfc2833. I also tested with "inbound" but it does not solve the problem.

Also, we tested with an IAX extension to be sure and the problem was not present. So, maybe it is related to the SIP technology. I hope this helps.

I'm attaching CLI output and the full log excerpts for two scenarios:

1) The IAX extension (the test was succesful)
     - authenticate.cli.success.txt
     - authenticate.var.log.asterisk.full.success.txt
2) The SIP extension (the test failed)
     - authenticate.cli.failed.txt
     - authenticate.var.log.asterisk.full.failed.txt
By: Joshua C. Colp (jcolp) 2008-04-07 12:23:25

core debug is not present in these logs. It can be enabled by adding debug in logger.conf to the console line, and typing core set debug 9 in the CLI. As well what is the remote side? Have you tried rfc2833compensate=yes for the SIP peer?
By: Edgar Landivar (elandivar) 2008-04-07 12:34:56

Wow, very fast response... I'm just uploading the files. The files are uploaded now. ;)

The remote side are generic phones sold by a company called VanAccess. I will ask the customer if he knows a model name or more specific brand name.

I have not tried the rfc2833compensate=yes parameter; so, I'll ask the customer to give me access to his equipment this night when the box is on low traffic to get more info for you and run the tests.
By: Joshua C. Colp (jcolp) 2008-04-07 12:36:31

Debug level was not at a level where DTMF information would show up unfortunately, so the provided files aren't useful.
By: Edgar Landivar (elandivar) 2008-04-07 12:43:15

I hope to upload more detailed files this night.
By: Joshua C. Colp (jcolp) 2008-04-09 10:38:40

I don't see any DTMF in this log either... so that would mean that 1. The RTP Stack is not correctly recognizing it or 2. That it is not being negotiated or 3. That the phone isn't sending it
By: Joshua C. Colp (jcolp) 2008-04-09 10:40:45

An rtp debug would be useful... but I wonder if there's a bug in the phone's firmware which is causing it to not send RFC2833 packets when you put a call on hold and initiate a new one.
By: Edgar Landivar (elandivar) 2008-04-09 12:32:00

Do you want me to try with some other phone models? And do you want me to activate RTP debug?
By: Joshua C. Colp (jcolp) 2008-04-09 12:34:29

Trying another phone would definitely eliminate a possibility, as would an rtp debug. The rtp debug will *for sure* show whether the phone is sending the RFC2833 packets, if not it is for sure the phone.
By: Edgar Landivar (elandivar) 2008-04-09 12:34:44

Also, as you may see in the last log (test2.log), the first attempt the DTMFs are being sent but the second attempt does not.
By: Joshua C. Colp (jcolp) 2008-04-09 12:37:15

Yes, which is why I'm strongly leaning towards a phone firmware issue.
By: Edgar Landivar (elandivar) 2008-04-13 19:34:02

Hello Folks,

Finally we could access the customer equipment and test with a softphone (Zoiper configured with SIP) and the problem did not appear.

So, I also think that the problem could be the phone firmware. Do you need some further testing or you think that definitively is a firmware issue?
By: Joshua C. Colp (jcolp) 2008-04-14 08:50:55

After looking at the provided logs, plus after reading about further testing with a separate phone this does indeed seem to be a phone issue. There is nothing more that can be done on our end.