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?
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.
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.
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.
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.
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…
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.
