I'd like some feedback on my solution so far for using queues in a multi tenant configuration. For most of the configuration files I've been able to use a naming scheme for the context names, which works nicely for making multi tenant fairly transparent. However that won't work for everything and queues is one of them. In queues.conf the naming scheme will work for defining a queue. It won't work for the agents though as they all have to have unique names. My thought is to create a pool of available agent numbers, and the web gui for the tenants will let the tenant pick the agent numbers they want to assign out of the pool. As numbers are used they are taken out of the pool, and as they become available they go back into the pool. The downside to this is that a tenant won't get to pick the exact numbers they want, but that doesn't seem like too much of a compromise for a multi tenant system. Anyone have any better ideas? Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20051117/630d7937/attachment.htm
I had the exact same dilemma and switched to using AddQueueMember/ RemoveQueueMember instead of using agents. This solved my problem. - Waldo On Nov 17, 2005, at 7:13 PM, snacktime wrote:> I'd like some feedback on my solution so far for using queues in a > multi tenant configuration. For most of the configuration files > I've been able to use a naming scheme for the context names, which > works nicely for making multi tenant fairly transparent. However > that won't work for everything and queues is one of them. > > In queues.conf the naming scheme will work for defining a queue. > It won't work for the agents though as they all have to have unique > names. My thought is to create a pool of available agent numbers, > and the web gui for the tenants will let the tenant pick the agent > numbers they want to assign out of the pool. As numbers are used > they are taken out of the pool, and as they become available they > go back into the pool. The downside to this is that a tenant > won't get to pick the exact numbers they want, but that doesn't > seem like too much of a compromise for a multi tenant system. > > Anyone have any better ideas? > > Chris > _______________________________________________ > --Bandwidth and Colocation sponsored by Easynews.com -- > > Asterisk-Users mailing list > Asterisk-Users@lists.digium.com > http://lists.digium.com/mailman/listinfo/asterisk-users > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users
On 11/17/05, Waldo Rubinstein <waldo@trianet.net> wrote:> > I had the exact same dilemma and switched to using AddQueueMember/ > RemoveQueueMember instead of using agents. This solved my problem. >Thanks!! That looks like a better solution all the way around. Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20051117/bbe62fd7/attachment.htm
You could use a prefix-based agent numbering scheme, like Agent/XXYYY where XX is your customer code and YYY their own agent number. When showing activity to a customer, you strip the XX part or you may leave it alone, as it makes no big confusion to the client. Yours, l. On Fri, 18 Nov 2005 01:13:09 +0100, snacktime <snacktime@gmail.com> wrote:> I'd like some feedback on my solution so far for using queues in a multi > tenant configuration. For most of the configuration files I've been able > to > use a naming scheme for the context names, which works nicely for making > multi tenant fairly transparent. However that won't work for everything > and > queues is one of them. > > In queues.conf the naming scheme will work for defining a queue. It won't > work for the agents though as they all have to have unique names. My > thought > is to create a pool of available agent numbers, and the web gui for the > tenants will let the tenant pick the agent numbers they want to assign > out > of the pool. As numbers are used they are taken out of the pool, and as > they > become available they go back into the pool. The downside to this is > that a > tenant won't get to pick the exact numbers they want, but that doesn't > seem > like too much of a compromise for a multi tenant system. > > Anyone have any better ideas? > > Chris-- Loway Research - Home of QueueMetrics http://queuemetrics.loway.it