Strange problem with 2.7

Hi.

I have just installed a server with FreePBX 2.7. I have (manually) migrated all settings from our old Trixbox 1.6 setup, and am currently testing the setup. Everything seems to be working, except for one, quite major, problem. We have about external SIP trunks to our VoIP provider (about half of them are disabled, because they are still in use on our old server). But it seems like I can only call in on one of the numbers, if I use any other number, I get the following error in the full log:

[Apr 23 14:32:07] VERBOSE[4018] netsock.c: == Using SIP RTP TOS bits 184
[Apr 23 14:32:07] VERBOSE[4018] netsock.c: == Using SIP RTP CoS mark 5
[Apr 23 14:32:07] VERBOSE[4018] netsock.c: == Using SIP VRTP TOS bits 136
[Apr 23 14:32:07] VERBOSE[4018] netsock.c: == Using SIP VRTP CoS mark 6
[Apr 23 14:32:07] WARNING[4018] chan_sip.c: username mismatch, have <08xxxx2505>, digest has <08xxxx2506>

I think this problem has occured some time during my testing, because I was able to call in on other numbers earlier. I can’t understand why it tries to match against the 2505 “username” no matter which trunk I call in on.
I even tried deleting the 2505 trunk, and still got this error, so it seems to be related to something else.
Does anyone have a clue what could cause this?

I run asterisk version 1.6.2.6.

I got incoming calls working by adding insecure=port,invite to the Peer details of the trunks. But there still seems to be something fishy.

It seems like it, for some reason, matches or compares something against the 2505 trunk, even when I call in on other numbers/trunks. It is like it is using the 2505 context even when calls come in on other trunks. From the full log:

[Apr 27 12:58:32] VERBOSE[4015] netsock.c: == Using SIP RTP TOS bits 184
[Apr 27 12:58:32] VERBOSE[4015] netsock.c: == Using SIP RTP CoS mark 5
[Apr 27 12:58:32] VERBOSE[4015] netsock.c: == Using SIP VRTP TOS bits 136
[Apr 27 12:58:32] VERBOSE[4015] netsock.c: == Using SIP VRTP CoS mark 6
[Apr 27 12:58:32] VERBOSE[18259] pbx.c: – Executing [[email protected]:1] Set(“SIP/08xxxx2505-00000018”, “GROUP()=OUT_7”) in new stack
[Apr 27 12:58:32] VERBOSE[18259] pbx.c: – Executing [[email protected]:2] Goto(“SIP/08xxxx2505-00000018”, “from-trunk,08xxxx2506,1”) in new stack
[Apr 27 12:58:32] VERBOSE[18259] pbx.c: – Goto (from-trunk,08xxxx2506,1)
[Apr 27 12:58:32] VERBOSE[18259] pbx.c: – Executing [[email protected]:1] Set(“SIP/08xxxx2505-00000018”, “__FROM_DID=08xxxx2506”) in new stack
[Apr 27 12:58:32] VERBOSE[18259] pbx.c: – Executing [[email protected]:2] Gosub(“SIP/08xxxx2505-00000018”, “app-blacklist-check,s,1”) in new stack
[Apr 27 12:58:32] VERBOSE[18259] pbx.c: – Executing [[email protected]:1] GotoIf(“SIP/08xxxx2505-00000018”, “0?blacklisted”) in new stack
[Apr 27 12:58:32] VERBOSE[18259] pbx.c: – Executing [[email protected]:2] Set(“SIP/08xxxx2505-00000018”, “CALLED_BLACKLIST=1”) in new stack
[Apr 27 12:58:32] VERBOSE[18259] pbx.c: – Executing [[email protected]:3] Return(“SIP/08xxxx2505-00000018”, “”) in new stack
[Apr 27 12:58:32] VERBOSE[18259] pbx.c: – Executing [[email protected]:3] ExecIf(“SIP/08xxxx2505-00000018”, “0 ?Set(CALLERID(name)=0707519917)”) in new stack
[Apr 27 12:58:32] VERBOSE[18259] pbx.c: – Executing [[email protected]:4] Set(“SIP/08xxxx2505-00000018”, “__CALLINGPRES_SV=allowed_not_screened”) in new stack
[Apr 27 12:58:32] VERBOSE[18259] pbx.c: – Executing [[email protected]:5] Set(“SIP/08xxxx2505-00000018”, “CALLERPRES()=allowed_not_screened”) in new stack
[Apr 27 12:58:32] VERBOSE[18259] pbx.c: – Executing [[email protected]:6] Goto(“SIP/08xxxx2505-00000018”, “timeconditions,6,1”) in new stack

I also tried deleting the 2505 trunk, but asterisk still tries to use that number when verifying incoming calls. I get this in the full log when calling in on another number. The 08xxxx2505 number doesn’t even exist in any of the files in /etc/asterisk

[Apr 27 13:40:13] NOTICE[4015] chan_sip.c: Call from ‘u08xxxx2505’ to extension ‘08xxxx2507’ rejected because extension not found.

I also tried restoring an old backup, but the problem did not go away. Could it be some config stored in the database or something? I am clueless.

I installed a new machine with FreePBX and migrated the configuration using backup & restore. Now it works, so the problem must have been hiding somewhere outside the config files.