Summary:ASTERISK-05031: after the second register happens from asterisk 2 to asterisk 1 asterisk 1 cannot call asterisk 2, authentication error
Reporter:C F (shmaltz)Labels:
Date Opened:2005-09-08 18:20:19Date Closed:2011-06-07 14:10:04
Versions:Frequency of
Environment:Attachments:( 0) ast1.sip.conf
( 1) ast1.sip.conf.2
( 2) ast1bad.txt
( 3) ast1good.txt
( 4) ast2.sip.conf
( 5) ast2.sip.conf.2
( 6) ast2bad.txt
( 7) ast2good.txt
( 8) register.extensions.conf
Description:I have asterisk 1 on a public address x.x.x.x and asterisk 2 on a natted address y.y.y.y, I configured asterisk 2 to register with asterisk 1, everytime ast2 registers, I can make calls to ast1, until the registration becomes stale (ast1 can't reach ast2), at which point when ast2 re-registers and becomes available again to ast1, ast1 cannot make any phone calles to ast2 with the error that it needs to authenticate.


It could be worked around by:
A. Using IAX2, which I'm doing now, but I don't like the sound quality, so I want SIP.
B. Configuring static mapping and static routes between IP/udp addresses/ports.
C. By issuing a reload before you make the phone call (like this, exten => X,1,System(asterisk -rx "reload"), exten => X,2,Dial(Sip/ast2), but since in HEAD (which is what I'm running) a reload takes some time (sometimes) this is not realy an option.
Comments:By: C F (shmaltz) 2005-09-08 18:42:32

ast1.sip.conf contains sip.conf for ast1
ast2.sip.conf contains sip.conf for ast2
x.x.x.x is the public ip address of ast1
y.y.y.y is the public ip address of ast2

By: C F (shmaltz) 2005-09-08 18:43:57

ast1good.txt, and ast2good.txt contain the sip debug when it does work, like after issuing the reload command
ast1bad.txt, and ast2bad.txt contain the sip debug when it does not work.

By: C F (shmaltz) 2005-09-08 18:45:38

I think this can be major, but I decided to be conservative.

By: C F (shmaltz) 2005-09-08 18:50:00

There is a mistake in the description, it reads:
everytime ast2 registers, I can make calls to ast1,
it should read:
everytime ast2 registers, I can make calls from ast1,

By: Olle Johansson (oej) 2005-09-09 04:00:25

I suspect this is a configuration issue. You need to turn on NAT keepalives by configuring AST1 with qualify=yes. Your NAT is killing all communication a time period after registration.

By: C F (shmaltz) 2005-09-09 08:30:00

While it is tru that my nat is killing all comunication, even with qualify=yes on both or on just either side, I still get no access to ast2 (nat is killing it), I have this same thing with a polycom phone, that after like 45 seconds nat kills it, but as soon as the polycom registers again, I can call the polycom again. In short I don't think it's a configuration issue.

By: Olle Johansson (oej) 2005-09-09 09:28:39

This is clearly a configuration issue, as discussed on IRC. When you can pinpoint a bug and prove it with a SIP debug, please re-open. Find someone on the #asterisk IRC channel to help you or read the available configurations out there.

By: C F (shmaltz) 2005-09-09 10:35:25

After talking on IRC with oej about this, here is some updated info. First I had the wrong sip.confs uploaded, my fault.
second, after some more testing (thanks to oej insisting that it's misconfigured, and me trying to prove meself, which helped so I got my box up and running for the meanwhile), it appears that if the secret is blank the problem desn't exist, only if secret is set to something then it happens.

By: C F (shmaltz) 2005-09-09 10:42:51

ast1.sip.conf.2 and ast2.sip.conf.2 are the right files.
If you want sip traces of the good ones with secret balnk please let me know, as the ones uploaded (ast1good.txt/ast2good.txt) are when it works because of the reload.

By: Olle Johansson (oej) 2005-09-09 10:54:03

You need to show us more of the configuration - how do ast2 register with ast1, how do you call from ast1 to ast2 and how do you call from ast2 to ast1 in the dial plan?

username= should not be used here, propably not authuser either.

By: C F (shmaltz) 2005-09-10 20:29:51

Sorry I was out since I added the last note, I wont be fully back till Monday. But here are a few more things I noticed over the weekend:
1. Since I took out the password, ast2 doesn't become stale anymore, it is always reachable, while in the olden days, when the password was still in, I would get:
Peer '5520' is now UNREACHABLE, I still have to investigate this further. I have some Polycom clients that always get this UNREACHABLE message, and I can't call them until they reregister, I will take out the password to see what happnes, but this will have to wait till Monday, I will try what you said to take out the username and authname, and report back, but I don't think before Monday, I will upload the regiser statement as well as the relevent extensions.conf for ast1 now.

By: C F (shmaltz) 2005-09-12 13:06:06

taking out username and authname didn't help a thing, as I reported before, whenever I put in a password, the registeration will become stale (meaning I will get on the CLI chan_sip.c:10721 sip_poke_noanswer: Peer '5520' is now UNREACHABLE!  Last qualify: 17), and phone calls don't go thru at all with the no route to destinaion error, that goes on like this, until ast2 reregisters, at which point it becomes reachable, but I get the authentication error, unless I do a reload or sip reload, if I take out the password then I never see on the CLI chan_sip.c:10721 sip_poke_noanswer: Peer '5520' is now UNREACHABLE!  Last qualify: 17, and I can always make phone calls.
What I wasn't sure is why I get the authentication error, it might be for one of the following reasons:
1. It becomes stale (the reason for this is something with the password not being blank), at which point when the reregister happens it doesn't go thru. Or:
2. There is an additional problem that it becomes stale, which also has to do with the password not being blank.
I did the following small test, I took out the register line from ast2 and waited until I see on ast1 UNREACHABLE, at that point I tried making the phone call from ast1 to ast2 which of course didn't go thru:
app_dial.c:1098 dial_exec_full: Unable to create channel of type 'Sip' (cause 3 - No route to destination)
I then put the register line back to sip.conf on ast2, reloaded ast2 but not ast1, which when the password is not blank just reloading ast2 doesn't help, and tried again from ast1 to ast2 and it worked no errors whatsoever, even without a reload on ast1, which brings me to the conclusion that the password not being blank creats 2 problems:
1. Sip channels become unreachable (stale) much earlier than they should.
2. After reregistering we get an authentication error.

I will now run this test with my Polycom phones. I will report back later.

By: C F (shmaltz) 2005-09-12 13:23:49

OK, with the polycom I took out the password, and I'm still getting the UNREACHABLE (I get it about 25 seconds before the reregister), I guess on this one I have to make sure that the NAT device (not the same as ast2) keeps the udp translations for longer.
Which so far shows that this problem is only from asterisk to asterisk.

By: C F (shmaltz) 2005-09-12 13:36:14

Just to take out confusion, even with a blank password, I get UNREACHABLE for ast2 on ast1s CLI, however with a none blank password, it happens sooner and more often/consistent, while with a blank password, it happens less often and less consistent, and even when it does I can still make phone calls from ast1 to ast2 sometimes, even before I see on the CLI REACHABLE.

By: C F (shmaltz) 2005-09-12 13:40:00

The Polycom is still in without the password, and I'm not sure if what I reported earlier is true, I think that now I don't receive the UNREACHABLE that often anymore (like with ast1 and ast2). I will let you know more in a few minutes.

By: C F (shmaltz) 2005-09-12 13:45:22

I need some more help here, I have a Polycom behind a NATed westell DSL router/modem. The Polycom registers with Asterisk, Asterisk doesn't have NAT. After a few minutes (like 2 minutes) the Polycom is UNREACHABLE to asterisk. That goes on all the time, however I think (and that is where I need help from others) if I make it into a blank password, the UNREACHABLE doesn't happen as often.

By: Olle Johansson (oej) 2005-10-02 14:26:50

UNREACHABLE has nothing to do with authentication or registration. It means that the packets we send (when you have qualify=on in sip.conf) doesn't get a reply. There is some sort of problem with the IP network configuration or something else is going on in your network. Check a SIP debug output log for OPTIONS packets and their answers or lack of answers.

By: C F (shmaltz) 2005-10-02 15:58:31

oej, I can't disagree with you about the UNREACHABLE however this was my observation, for now I believe we shuold just focus on the real problem and not on the UNREACHABLE.

By: C F (shmaltz) 2005-10-03 11:14:29

I'm posting this because of this post:
I will be out the next 2 days 4th and the 5th of October.

By: Serge Vecher (serge-v) 2005-11-12 11:24:47.000-0600

shmaltz: Is this still an issue with 1.2.RC2?

By: C F (shmaltz) 2005-11-12 19:00:15.000-0600

I'll test it this week and report back, it might take till Tue-Wed but I'll try my best.

By: Olle Johansson (oej) 2006-01-04 12:24:48.000-0600

No feedback, closing this issue.

By: Olle Johansson (oej) 2006-01-04 12:24:49.000-0600

No feedback, closing this issue.