Superfecta and inbound routes


(D E) #1

Does anyone know if the bug with SQL and inbound routes has now been sorted?

I ask because I’m STILL having issues with superfecta schemes not being followed for certain caller ID patterns for which I have specific inbound routes setup.

I have a caller ID route where DID is set and CID is any and superfecta scheme is default

I have another where DID is set CID is _01302XXXXXX (local area code) and has its own superfecta scheme

But despite the fact that superfecta scheme IS referenced in the log ‘darlnumbers’, the call ends up with a CID as if it was set by the default superfecta scheme?

Log trace


(Lorne Gaetz) #2

This ticket? https://issues.freepbx.org/browse/FREEPBX-22424


(D E) #3

YES! Thank you. I tried to search but I was searching the forum not the issue tracker so didn’t find it (wasn’t sure where I’d seen it).
I’ll give that a try to see if it fixes my issue.


(D E) #4

hmmm, after “To enable the edge track, go to “Advanced settings and set “Set Module Admin to Edge mode” to “Yes”” do i need to apply config? So far I can’t upgrade superfecta to the latest version as it says it’s the same as the online version. Trying an apply config now.


(Lorne Gaetz) #5

Current version of Superfecta is 15.0.2.31 and is the same for both stable and edge.


(D E) #6

ah, right. Well, in that case, I don’t think the bug is fixed. Or there’s a different superfecta specific bug?

Just done another test dial in. If I choose the debug option from the superfecta GUI I always get the desired caller ID “Darlington number”. Despite the fact the log shows the call is coming in via the correct superfecta scheme, it always assigns “LANDLINE” - which would be the caller ID assigned via my default superfecta scheme.

It’s quite odd.

Another trace here


(D E) #7

Would this be better addressed if I raise a ticket, @lgaetz? :slight_smile:


(D E) #8

Ticket created


(Lorne Gaetz) #9

Can you provide a screen cap of the darlnumbers scheme from superfecta? The provided trace shows that scheme is being used.


(D E) #10

Agreed. it’s very odd. Can I provide by DM? I’ve obfuscated my area code you see.


(Lorne Gaetz) #11

PM is fine.


(D E) #12

Sent :slight_smile:


(Mitch Mitchell) #13

I’ll be interested to see what you find out on this one. Without seeing the two schemes involved I can’t really make an intelligent comment.


(Lorne Gaetz) #14

I’m unable to repro this. No matter how I define an inbound route, the correct Superfecta scheme always runs. Going to needs steps to repro this added to the ticket.


(Mitch Mitchell) #15

My guess is something in the correct schema is returning the wrong values.


(D E) #16

Finally semi got to the bottom of this…

Had to move the superfecta scheme around, had to relegate “trunk provided” to the bottom of the list and move abandon lookup to one rung above “trunk provided”. That fixed it. Not sure why…

super1


(Jared Busch) #17

Because that is how any ordered flow works. from top to bottom.


(D E) #18

No Jared…that doesn’t answer the conundrum because a demo run always resulted in the “abandon lookup” result, whereas an actual live run resulted in the “trunk provided” result.


(Jared Busch) #19

A demo run always checks everything, in order for you to see what each item would return.


(D E) #20

So what is the point in it saying right at the end
This scheme would set the caller id to:
are you saying that’s not true?