Summary:ASTERISK-11427: Can not register 2 different SIP accounts with provider
Reporter:Mark Huff (aussie troll)Labels:
Date Opened:2008-02-12 16:43:41.000-0600Date Closed:2008-07-08 10:37:17
Versions:Frequency of
Environment:Attachments:( 0) Asterisk_Log_file_with_both_SIP_accounts_trying_to_register.doc
( 1) Sip_configs.doc
Description:with two different SIP accounts with one provider, system will not register either. By dropping one of the accounts, the other registers with no issue.  This issue began with Asterisk V1.4.14. Is repeatable with versions 1.4.17 and 1.4.18.


Example:  Account 1 - 09XXXXX1@sip.myfone.com.au
         Account 2 - 09XXXX22@sip01.myfone.com.au

Set up registrations on both accounts. Start Asterisk, both accounts are "reachable", then quickly become unreachable. Asterisk log file shows registration "timed out". Check with SIP provider indicates incorrect passwords. Comment out registration string for either of the accounts, and the other logs in (no other changes needed).  Also, when both accounts are trying to register, all SIP extensions become "unreachable".  Again, comment out registration string for either, and the extensions become "reachable".
Comments:By: Russell Bryant (russell) 2008-02-12 16:45:53.000-0600

... configuration and SIP debug?

By: Mark Huff (aussie troll) 2008-02-12 17:53:13.000-0600

the Asterisk Log file holds three sections. part 1 - log file with both sip accoutns attempting to register. Part 2 - debug output with only one account successfully registering. Part 3 - debug output with both accounts attempting to register and failing.

By: Johan Wilfer (johan) 2008-02-12 21:38:16.000-0600

I've had a similar behaviour. Sometimes between those version you mention srvlookup in sip.conf was changed to default to yes.

I set srvlookup=no in my sip.conf and that solved my problem. Why this is so you will have to ask someone else. :)

You haven't an srvlookup entry in your sip.conf and that means your seeting has changed somewhere between those versions.

Short version; Try adding srvlookup=no to your [general] section in sip.conf

By: Mark Huff (aussie troll) 2008-02-12 23:13:32.000-0600

Sorry Johan - this didn't help, but thanks for the try....I still have the same issue. tired both svrlookup=yes and svrlookup=no, but neither corrected the problem.

By: Olle Johansson (oej) 2008-02-13 00:52:25.000-0600

In the future, please upload text files that we can read in our browsers. Thank you.

By: Olle Johansson (oej) 2008-02-13 00:58:39.000-0600

With all the retransmits you have in the log file, there seems to be another communication issue here - a NAT or firewall that intercepts packages.

By: Mark Huff (aussie troll) 2008-02-13 01:03:23.000-0600

well, all i can say on that is...

with only one sip registration everything works.  when i add the second it breaks.  this was not an issue in v1.4.13, but became one and is still one with v1.4.14 onwards.  I know of another person here in australia having the exact same issue.

and it would stand to reason if one channel is registering properly then it would not be a firewall issue (note i have double and triple checked my port forwarding on the firewall, and have made no changes since being able to run the v1.4.13 successfully.)

From what i gather from my SIP provider, they are seeing "wrong password" on their end when i try to register both accounts.  So it acts as though somehow the two registrations are walking on each other somehow...again not an issue prior to v1.4.14

By: Tilghman Lesher (tilghman) 2008-05-13 15:07:58

Are you perhaps configuring these hosts via realtime, with caching turned off?  I'm thinking that perhaps the return messages are colliding with one another and matching the wrong host on the backend, although that may not fully explain why both fail instead of just one failing.

By: Brett Bryant (bbryant) 2008-05-14 11:06:22

aussie_troll, I have a feeling that this could be related to enabling srvlookup by default in 1.4.14 as opposed to 1.4.13. Would you mind adding "srvlookup=false" to sip.conf, seeing if the problem still occurs, and attaching an output of "sip show settings" ?

By: leonidf (leonidf) 2008-05-27 03:17:34

insecure=port will solve the problem.

By: Joshua C. Colp (jcolp) 2008-06-02 09:08:17

aussie_troll: Have you tried bbryant's suggestion?

By: Ronald Chan (loloski) 2008-06-02 09:32:02

I can't reproduce this on SVN 1.4 this evidently show that this is working on fwd account.

[root@router asterisk]# asterisk -r
Asterisk SVN-branch-1.4-r119687, Copyright (C) 1999 - 2008 Digium, Inc. and others.
Created by Mark Spencer <markster@digium.com>
Asterisk comes with ABSOLUTELY NO WARRANTY; type 'core show warranty' for details.
This is free software, with components licensed under the GNU General Public
License version 2 and other licenses; you are welcome to redistribute it under
certain conditions. Type 'core show license' for details.
Connected to Asterisk SVN-branch-1.4-r119687 currently running on router (pid = 31350)
Verbosity is at least 3
router*CLI> sip reload
Reloading SIP
 == Parsing '/etc/asterisk/sip.conf': Found
 == Parsing '/etc/asterisk/users.conf': Found
 == Parsing '/etc/asterisk/sip_notify.conf': Found
router*CLI> sip show registry
Host                            Username       Refresh State                Reg.Time                
fwd.pulver.com:5060             loloski2           105 Registered           Mon, 02 Jun 2008 22:29:29
fwd.pulver.com:5060             bsdnewbie          105 Registered           Mon, 02 Jun 2008 22:29:29

By: Ronald Chan (loloski) 2008-06-02 09:34:20

test it with srvlookup=yes and srvlookup=no, it work's for me :)

By: Ronald Chan (loloski) 2008-06-17 09:03:06

can this case be close? or has anybody tested this if this is still the case?