Page 1 of 1

show conference call channel information

PostPosted: Thu May 08, 2008 7:59 pm
by pylinuxian
Is the panel "show conference call channel information" important for the actual daily work of agents ? (can we just hide it ?)

I mean do an agent need to always keep an eye on this panel for open channels & manually hung up those who he does not use any more ?

What would happen if I hide this pannel ? whats are the purposes behind this panel ? isn't vicidial in charge of terminating calls & conferences ? why agent intervention ?

I ask this because I get asked about this panel & what is it for & how the agent would use it. & I also need to know the theory behind it.

what happens if agents didn't monitor well this panel ? would we end up paying telephone bills for those forgotten open channels ? how long would a forgotten channel stay open (hope its not untill next reboot if campain time is 24h) ?

I think this issue is important to discuss because it may lead to loss of money if users did not really understand the inner workings of the process of call/conference termination & management.

Thanks everyone.

PostPosted: Fri May 09, 2008 3:08 am
by mflorell
On a properly configured and NOT overloaded system there should be no reason for an agent to go into this panel.

The usual reasons for going into this panel are to raise/lower/mute volume for specific participants or to hangup channels that need to be hungup in special circumstances.

i have one client that uses "D1 - DIAL" to launch automated messages and if they need to stop those messages they use this panel to hangup the channel.

PostPosted: Fri May 09, 2008 4:04 am
by pylinuxian
Thank you Matt, what about the other question :
what happens if agents didn't monitor well this panel ? would we end up paying telephone bills for those forgotten open channels ? how long would a forgotten channel stay open (hope its not untill next reboot if campain time is 24h) ?

PostPosted: Fri May 09, 2008 8:24 am
by mflorell
Open channels should not be a problem on most systems. Usually I have noticed that if a system is properly scaled and there are problems with channels not hanging up that it can be a carrier issue.

One other note on this, if you are using 2.0.4.1rc1 or higher then all channels in an agent's session will hangup upon agent logout.

PostPosted: Fri May 09, 2008 3:41 pm
by pylinuxian
On a properly configured and NOT overloaded system there should be no reason for an agent to go into this panel.


Matt,

Is this a green light for me to go on & hide the panel ?

you know I worked a few hours on the interface .. & I think it needs a complete rewrite, by move formatting to a separate ccs file, move the javascript code to a separate file, & this java code should be independent of the php code as java can always parse the page for its variables, put login interfaces on separate files... etc

but it was too complexe, I could only move panels around the page, resize them, but could never rewrite the page, the pieces are just too tied to each other.

so i guess I need some sort of help if I want to go any further. ..

PostPosted: Fri May 09, 2008 7:48 pm
by mflorell
Sure, go ahead and hide the panel, let me know if you run into any problems.

As for a rewrite, it would take a long time. The existing code for vicidial.php and it's affiliated scripts took about 3 years to get where it is today and it is quite massive and complex, but so is the application in general. Separating the Javascript from the PHP code is not a bad idea, but would require some changing of how the script functions since some of the PHP code generates some of the Javascript code on the fly. A separate CSS and DHTML syle sheet/template is also a good idea, but there are over 100 elements that need to have position data, so it would still be a bit of work to create fully functional templates.

PostPosted: Sat May 10, 2008 7:30 am
by pylinuxian
what about you make the javascript independent from php ? & I try to take it from there ?

PostPosted: Sat May 10, 2008 9:46 am
by mflorell
Making the javascript completely independant from the PHP would still be difficult because of the many places where the javascript is generated BY the PHP script because it need to be dynamic.

All of those functions would need to be rewritten and possibly completely re-engineered to work, which is not a trivial change.