asiby wrote:
This means that the simulator did not find any matching route and rate. I can assure you that the simulator works right out of the box.
It sounds VERY strange... I can make calls to the corresponding route and rate_engine can find corresponding rate during a call. May be that is due to different queries used in web and in time of call processing? The query I found in A2BCustomer_UI/lib/Class.RateEngine.php is very complex. When I tried to process it in mysql-client latter said "Illegal mix of collations (latin1_swedish_ci,IMPLICIT) and (utf8_general_ci,COERCIBLE) for operation '='" and refused to execute. I'd try to make it more simple but I was afraid I would miss some background nuance that author have foreseen.
Added after 1 hours 13 minutes: asiby wrote:
This means that the simulator did not find any matching route and rate. I can assure you that the simulator works right out of the box.
Ok. I've digged inside script and found that when I try to find a rate to 01174956960606 (just f.e. because I now I can call there) simulator executes following query:
SELECT tariffgroupname, lcrtype, idtariffgroup, cc_tariffgroup_plan.idtariffplan, tariffname, destination, cc_ratecard.id, dialprefix, destination, buyrate, buyrateinitblock, buyrateincrement, rateinitial, initblock, billingblock, connectcharge, disconnectcharge, stepchargea, chargea, timechargea, billingblocka, stepchargeb, chargeb, timechargeb, billingblockb, stepchargec, chargec, timechargec, billingblockc, cc_tariffplan.id_trunk AS tp_id_trunk, tp_trunk.trunkprefix AS tp_trunk, tp_trunk.providertech AS tp_providertech, tp_trunk.providerip AS tp_providerip, tp_trunk.removeprefix AS tp_removeprefix, cc_ratecard.id_trunk AS rc_id_trunk, rt_trunk.trunkprefix AS rc_trunkprefix, rt_trunk.providertech AS rc_providertech, rt_trunk.providerip AS rc_providerip, rt_trunk.removeprefix AS rc_removeprefix, musiconhold, tp_trunk.failover_trunk AS tp_failover_trunk, rt_trunk.failover_trunk AS rt_failover_trunk, tp_trunk.addparameter AS tp_addparameter_trunk, rt_trunk.addparameter AS rt_addparameter_trunk FROM cc_tariffgroup RIGHT JOIN cc_tariffgroup_plan ON (cc_tariffgroup.id=4) INNER JOIN cc_tariffplan ON (cc_tariffplan.id=cc_tariffgroup_plan.idtariffplan ) LEFT JOIN cc_ratecard ON (cc_ratecard.idtariffplan=cc_tariffplan.id) LEFT JOIN cc_trunk AS rt_trunk ON (cc_ratecard.id_trunk=rt_trunk.id_trunk) LEFT JOIN cc_trunk AS tp_trunk ON (cc_tariffplan.id_trunk=tp_trunk.id_trunk) where (dialprefix=SUBSTRING('01174959690606',1,length(dialprefix)) OR dialprefix='defaultprefix') AND startingdate<= CURRENT_TIMESTAMP AND (expirationdate > CURRENT_TIMESTAMP OR expirationdate IS NULL OR LENGTH(expirationdate)<5) AND startdate<= CURRENT_TIMESTAMP AND (stopdate > CURRENT_TIMESTAMP OR stopdate IS NULL OR LENGTH(stopdate)<5) AND (starttime <= 8247 AND endtime >=8247) AND idtariffgroup='4' AND (cc_tariffplan.dnidprefix LIKE '01174959690606%' OR cc_tariffplan.dnidprefix='all') ORDER BY LENGTH(dialprefix) DESC;
Exactly as above this query returns nothing. But when I cut of this query that condition:
AND (cc_tariffplan.dnidprefix LIKE '01174959690606%' OR cc_tariffplan.dnidprefix='all')
Query runs fine! Probably I'll try to comment this code out and check the web's result...
Added after 15 minutes: andy0 wrote:
asiby wrote:
This means that the simulator did not find any matching route and rate. I can assure you that the simulator works right out of the box.
It sounds VERY strange... I can make calls to the corresponding route and rate_engine can find corresponding rate during a call. May be that is due to different queries used in web and in time of call processing? The query I found in A2BCustomer_UI/lib/Class.RateEngine.php is very complex. When I tried to process it in mysql-client latter said "Illegal mix of collations (latin1_swedish_ci,IMPLICIT) and (utf8_general_ci,COERCIBLE) for operation '='" and refused to execute. I'd try to make it more simple but I was afraid I would miss some background nuance that author have foreseen.
Added after 1 hours 13 minutes: asiby wrote:
This means that the simulator did not find any matching route and rate. I can assure you that the simulator works right out of the box.
Ok. I've digged inside script and found that when I try to find a rate to 01174956960606 (just f.e. because I now I can call there) simulator executes following query:
SELECT tariffgroupname, lcrtype, idtariffgroup, cc_tariffgroup_plan.idtariffplan, tariffname, destination, cc_ratecard.id, dialprefix, destination, buyrate, buyrateinitblock, buyrateincrement, rateinitial, initblock, billingblock, connectcharge, disconnectcharge, stepchargea, chargea, timechargea, billingblocka, stepchargeb, chargeb, timechargeb, billingblockb, stepchargec, chargec, timechargec, billingblockc, cc_tariffplan.id_trunk AS tp_id_trunk, tp_trunk.trunkprefix AS tp_trunk, tp_trunk.providertech AS tp_providertech, tp_trunk.providerip AS tp_providerip, tp_trunk.removeprefix AS tp_removeprefix, cc_ratecard.id_trunk AS rc_id_trunk, rt_trunk.trunkprefix AS rc_trunkprefix, rt_trunk.providertech AS rc_providertech, rt_trunk.providerip AS rc_providerip, rt_trunk.removeprefix AS rc_removeprefix, musiconhold, tp_trunk.failover_trunk AS tp_failover_trunk, rt_trunk.failover_trunk AS rt_failover_trunk, tp_trunk.addparameter AS tp_addparameter_trunk, rt_trunk.addparameter AS rt_addparameter_trunk FROM cc_tariffgroup RIGHT JOIN cc_tariffgroup_plan ON (cc_tariffgroup.id=4) INNER JOIN cc_tariffplan ON (cc_tariffplan.id=cc_tariffgroup_plan.idtariffplan ) LEFT JOIN cc_ratecard ON (cc_ratecard.idtariffplan=cc_tariffplan.id) LEFT JOIN cc_trunk AS rt_trunk ON (cc_ratecard.id_trunk=rt_trunk.id_trunk) LEFT JOIN cc_trunk AS tp_trunk ON (cc_tariffplan.id_trunk=tp_trunk.id_trunk) where (dialprefix=SUBSTRING('01174959690606',1,length(dialprefix)) OR dialprefix='defaultprefix') AND startingdate<= CURRENT_TIMESTAMP AND (expirationdate > CURRENT_TIMESTAMP OR expirationdate IS NULL OR LENGTH(expirationdate)<5) AND startdate<= CURRENT_TIMESTAMP AND (stopdate > CURRENT_TIMESTAMP OR stopdate IS NULL OR LENGTH(stopdate)<5) AND (starttime <= 8247 AND endtime >=8247) AND idtariffgroup='4' AND (cc_tariffplan.dnidprefix LIKE '01174959690606%' OR cc_tariffplan.dnidprefix='all') ORDER BY LENGTH(dialprefix) DESC;
Exactly as above this query returns nothing. But when I cut of this query that condition:
AND (cc_tariffplan.dnidprefix LIKE '01174959690606%' OR cc_tariffplan.dnidprefix='all')
Query runs fine! Probably I'll try to comment this code out and check the web's result...
Well. Now I have working web's simulator. Asiby, what functionality will suffer without "AND (cc_tariffplan.dnidprefix LIKE '01174959690606%' OR cc_tariffplan.dnidprefix='all')" in the rate_engine_findrates or whatever other places?
really I cannot see any reason in that construction "cc_tariffplan.dnidprefix LIKE '$mydnid%'" 'cos of $mydnid in most cases is telephone number given by user and it's very uprobably that someone's dnidprefix will have that length.