Advice on scalable design pattern
Hello all, I'm currently looking at the various different ways you can deploy FreeSWITCH in a scalable manner, but struggle a little bit on design. The sweet spot I'm trying to find is one where I can scale out capacity by simply throwing more servers at it. In an ideal world, this would mean support for; * Have multiple users from multiple domains to be spread over multiple servers... a single domain should not be restricted to a single FreeSWITCH instance * Have no single point of failure within the structure * Have no single point of bottleneck within the structure * Should not use OpenSIPS.. (I suspect this might get me a lot of flack, but seriously, I'd rather write my own in python or ZXTM traffic script than use OpenSIPS lol). So far, the best option I can come up with is (although I'm not sure if it's the best available); * Proxy sitting in front of all backend FreeSWITCH instances, acting in a media proxy fashion only (dual pair of proxies in active/passive mode) * Proxy tracks registrations to the appropriate backend instance, and makes their session sticky * If backend instance needs to make a call to another user in the same domain, it bridges to the call to back to the proxy, the proxy then determines which other FreeSWITCH instance has the user then routes the request accordingly. If the call is to an external destination, the proxy will route it to the traffic aggregation switches (which is basically another pair of FreeSWITCH instances), which then gets routed to the upstream provider.. this means you only have to maintain 2 sets of trunk configuration.. so when you need to scale out your freeswitch backends, it doesn't require putting in a request to your upstream providers for an additional set of trunks. * The bottleneck within these clusters is the dual proxies in active/passive mode.. you could fix this by allocating customers to a specific cluster (rather than instance), thus controlling which customers go to which proxy.. if an entire cluster dies, you can re-route that clusters traffic to a different cluster. The other simpler option is to allocate domains to a specific backend instance.. but this really doesn't feel clean.. it means a customer cannot scale past the floor limit of a single instance, it has less redundancy, and overall just feels wrong. Any general thoughts/comments on this would be much appreciated. Thanks Cal
Have you looked at how 2600hz do this kind of thing with Kazoo? Regards, Ben Langfeld On 14 March 2013 03:02, Cal Leeming [Simplicity Media Ltd] < cal.leeming@simplicitymedialtd.co.uk> wrote:
Hello all,
I'm currently looking at the various different ways you can deploy FreeSWITCH in a scalable manner, but struggle a little bit on design.
The sweet spot I'm trying to find is one where I can scale out capacity by simply throwing more servers at it.
In an ideal world, this would mean support for;
* Have multiple users from multiple domains to be spread over multiple servers... a single domain should not be restricted to a single FreeSWITCH instance * Have no single point of failure within the structure * Have no single point of bottleneck within the structure * Should not use OpenSIPS.. (I suspect this might get me a lot of flack, but seriously, I'd rather write my own in python or ZXTM traffic script than use OpenSIPS lol).
So far, the best option I can come up with is (although I'm not sure if it's the best available);
* Proxy sitting in front of all backend FreeSWITCH instances, acting in a media proxy fashion only (dual pair of proxies in active/passive mode) * Proxy tracks registrations to the appropriate backend instance, and makes their session sticky * If backend instance needs to make a call to another user in the same domain, it bridges to the call to back to the proxy, the proxy then determines which other FreeSWITCH instance has the user then routes the request accordingly. If the call is to an external destination, the proxy will route it to the traffic aggregation switches (which is basically another pair of FreeSWITCH instances), which then gets routed to the upstream provider.. this means you only have to maintain 2 sets of trunk configuration.. so when you need to scale out your freeswitch backends, it doesn't require putting in a request to your upstream providers for an additional set of trunks. * The bottleneck within these clusters is the dual proxies in active/passive mode.. you could fix this by allocating customers to a specific cluster (rather than instance), thus controlling which customers go to which proxy.. if an entire cluster dies, you can re-route that clusters traffic to a different cluster.
The other simpler option is to allocate domains to a specific backend instance.. but this really doesn't feel clean.. it means a customer cannot scale past the floor limit of a single instance, it has less redundancy, and overall just feels wrong.
Any general thoughts/comments on this would be much appreciated.
Thanks
Cal
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
I've looked at a countless number of set ups (including Kazoo), the problem here is choice.. there's many different ways of doing things. Some people have even gone to the extent of implementing a bunch of switching logic within their proxies.. others use them as dumb transport layers. Cal On Thu, Mar 14, 2013 at 3:43 PM, Ben Langfeld <ben@langfeld.co.uk> wrote:
Have you looked at how 2600hz do this kind of thing with Kazoo?
Regards, Ben Langfeld
On 14 March 2013 03:02, Cal Leeming [Simplicity Media Ltd] < cal.leeming@simplicitymedialtd.co.uk> wrote:
Hello all,
I'm currently looking at the various different ways you can deploy FreeSWITCH in a scalable manner, but struggle a little bit on design.
The sweet spot I'm trying to find is one where I can scale out capacity by simply throwing more servers at it.
In an ideal world, this would mean support for;
* Have multiple users from multiple domains to be spread over multiple servers... a single domain should not be restricted to a single FreeSWITCH instance * Have no single point of failure within the structure * Have no single point of bottleneck within the structure * Should not use OpenSIPS.. (I suspect this might get me a lot of flack, but seriously, I'd rather write my own in python or ZXTM traffic script than use OpenSIPS lol).
So far, the best option I can come up with is (although I'm not sure if it's the best available);
* Proxy sitting in front of all backend FreeSWITCH instances, acting in a media proxy fashion only (dual pair of proxies in active/passive mode) * Proxy tracks registrations to the appropriate backend instance, and makes their session sticky * If backend instance needs to make a call to another user in the same domain, it bridges to the call to back to the proxy, the proxy then determines which other FreeSWITCH instance has the user then routes the request accordingly. If the call is to an external destination, the proxy will route it to the traffic aggregation switches (which is basically another pair of FreeSWITCH instances), which then gets routed to the upstream provider.. this means you only have to maintain 2 sets of trunk configuration.. so when you need to scale out your freeswitch backends, it doesn't require putting in a request to your upstream providers for an additional set of trunks. * The bottleneck within these clusters is the dual proxies in active/passive mode.. you could fix this by allocating customers to a specific cluster (rather than instance), thus controlling which customers go to which proxy.. if an entire cluster dies, you can re-route that clusters traffic to a different cluster.
The other simpler option is to allocate domains to a specific backend instance.. but this really doesn't feel clean.. it means a customer cannot scale past the floor limit of a single instance, it has less redundancy, and overall just feels wrong.
Any general thoughts/comments on this would be much appreciated.
Thanks
Cal
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Sorry, hit send too fast! I think ultimately this is going to come down to trial and error, and a heck of a lot of testing.. If I can avoid having to re-do the work of other people then great, but it may just be one of those "gotta find out for yourself" things. Cal On Thu, Mar 14, 2013 at 4:00 PM, Cal Leeming [Simplicity Media Ltd] < cal.leeming@simplicitymedialtd.co.uk> wrote:
I've looked at a countless number of set ups (including Kazoo), the problem here is choice.. there's many different ways of doing things.
Some people have even gone to the extent of implementing a bunch of switching logic within their proxies.. others use them as dumb transport layers.
Cal
On Thu, Mar 14, 2013 at 3:43 PM, Ben Langfeld <ben@langfeld.co.uk> wrote:
Have you looked at how 2600hz do this kind of thing with Kazoo?
Regards, Ben Langfeld
On 14 March 2013 03:02, Cal Leeming [Simplicity Media Ltd] < cal.leeming@simplicitymedialtd.co.uk> wrote:
Hello all,
I'm currently looking at the various different ways you can deploy FreeSWITCH in a scalable manner, but struggle a little bit on design.
The sweet spot I'm trying to find is one where I can scale out capacity by simply throwing more servers at it.
In an ideal world, this would mean support for;
* Have multiple users from multiple domains to be spread over multiple servers... a single domain should not be restricted to a single FreeSWITCH instance * Have no single point of failure within the structure * Have no single point of bottleneck within the structure * Should not use OpenSIPS.. (I suspect this might get me a lot of flack, but seriously, I'd rather write my own in python or ZXTM traffic script than use OpenSIPS lol).
So far, the best option I can come up with is (although I'm not sure if it's the best available);
* Proxy sitting in front of all backend FreeSWITCH instances, acting in a media proxy fashion only (dual pair of proxies in active/passive mode) * Proxy tracks registrations to the appropriate backend instance, and makes their session sticky * If backend instance needs to make a call to another user in the same domain, it bridges to the call to back to the proxy, the proxy then determines which other FreeSWITCH instance has the user then routes the request accordingly. If the call is to an external destination, the proxy will route it to the traffic aggregation switches (which is basically another pair of FreeSWITCH instances), which then gets routed to the upstream provider.. this means you only have to maintain 2 sets of trunk configuration.. so when you need to scale out your freeswitch backends, it doesn't require putting in a request to your upstream providers for an additional set of trunks. * The bottleneck within these clusters is the dual proxies in active/passive mode.. you could fix this by allocating customers to a specific cluster (rather than instance), thus controlling which customers go to which proxy.. if an entire cluster dies, you can re-route that clusters traffic to a different cluster.
The other simpler option is to allocate domains to a specific backend instance.. but this really doesn't feel clean.. it means a customer cannot scale past the floor limit of a single instance, it has less redundancy, and overall just feels wrong.
Any general thoughts/comments on this would be much appreciated.
Thanks
Cal
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Well i have done a lot of "trail and error" on this specific problem in past 3 years and have come to conclusion that, 1. You need at least one layer 4 switching service that manages all routing between your end-users and your internal cluster of media services. It checks and validates inbound traffic, decides which partition (if your cluster is sub-group into different service types) or portion (if your cluster consists of similar nodes) of your cluster serves it and forwards traffic to it. What software you use for this purpose is entirely your choice? I have used OpenSIPS, Kamailio, OverSIP and even a small proxy i wrote in PERL. The fundamental principle for choosing the right software is how you want to handle traffic? e.g. a). You can use redirection using SIP response code 302. b). You can do state-full relay, by creating and managing SIP transactions. c). You can do bridging, e.g. by using B2BUA. 2. You need layer 5 switching cluster, providing the actually services the end-user needs. You can break the cluster in small groups service-wise, e.g. IVR Service, Voicemail Service, Billing Service, Transcoding Service etc. etc. OR if you can have each node serving all services on its own. 3. Often to handle outbound traffic you can setup another layer 4 switching service or use same as the one for inbound. Generally for very very large setup e.g. >10M users you should have a separate termination gateway. Thank you. On Thu, Mar 14, 2013 at 5:02 PM, Cal Leeming [Simplicity Media Ltd] < cal.leeming@simplicitymedialtd.co.uk> wrote:
Sorry, hit send too fast!
I think ultimately this is going to come down to trial and error, and a heck of a lot of testing.. If I can avoid having to re-do the work of other people then great, but it may just be one of those "gotta find out for yourself" things.
Cal
On Thu, Mar 14, 2013 at 4:00 PM, Cal Leeming [Simplicity Media Ltd] < cal.leeming@simplicitymedialtd.co.uk> wrote:
I've looked at a countless number of set ups (including Kazoo), the problem here is choice.. there's many different ways of doing things.
Some people have even gone to the extent of implementing a bunch of switching logic within their proxies.. others use them as dumb transport layers.
Cal
On Thu, Mar 14, 2013 at 3:43 PM, Ben Langfeld <ben@langfeld.co.uk> wrote:
Have you looked at how 2600hz do this kind of thing with Kazoo?
Regards, Ben Langfeld
On 14 March 2013 03:02, Cal Leeming [Simplicity Media Ltd] < cal.leeming@simplicitymedialtd.co.uk> wrote:
Hello all,
I'm currently looking at the various different ways you can deploy FreeSWITCH in a scalable manner, but struggle a little bit on design.
The sweet spot I'm trying to find is one where I can scale out capacity by simply throwing more servers at it.
In an ideal world, this would mean support for;
* Have multiple users from multiple domains to be spread over multiple servers... a single domain should not be restricted to a single FreeSWITCH instance * Have no single point of failure within the structure * Have no single point of bottleneck within the structure * Should not use OpenSIPS.. (I suspect this might get me a lot of flack, but seriously, I'd rather write my own in python or ZXTM traffic script than use OpenSIPS lol).
So far, the best option I can come up with is (although I'm not sure if it's the best available);
* Proxy sitting in front of all backend FreeSWITCH instances, acting in a media proxy fashion only (dual pair of proxies in active/passive mode) * Proxy tracks registrations to the appropriate backend instance, and makes their session sticky * If backend instance needs to make a call to another user in the same domain, it bridges to the call to back to the proxy, the proxy then determines which other FreeSWITCH instance has the user then routes the request accordingly. If the call is to an external destination, the proxy will route it to the traffic aggregation switches (which is basically another pair of FreeSWITCH instances), which then gets routed to the upstream provider.. this means you only have to maintain 2 sets of trunk configuration.. so when you need to scale out your freeswitch backends, it doesn't require putting in a request to your upstream providers for an additional set of trunks. * The bottleneck within these clusters is the dual proxies in active/passive mode.. you could fix this by allocating customers to a specific cluster (rather than instance), thus controlling which customers go to which proxy.. if an entire cluster dies, you can re-route that clusters traffic to a different cluster.
The other simpler option is to allocate domains to a specific backend instance.. but this really doesn't feel clean.. it means a customer cannot scale past the floor limit of a single instance, it has less redundancy, and overall just feels wrong.
Any general thoughts/comments on this would be much appreciated.
Thanks
Cal
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Mit freundlichen Grüßen Muhammad Shahzad ----------------------------------- CISCO Rich Media Communication Specialist (CRMCS) CISCO Certified Network Associate (CCNA) Cell: +49 176 99 83 10 85 MSN: shari_786pk@hotmail.com Email: shaheryarkh@googlemail.com
Have multiple FS servers (and each FS server has a warm standby), each with multiple domains. Have a central location for configuration and dialplan (XML_CURL) All inbound calls from carriers go through a FS server acting as a proxy which directs it to correct FS server. All calls from UAs are checked against dialplan to either go to another FS server or out a carrier.
Thanks for the detailed comments, anyone else have any thoughts on this? Cal On Thu, Mar 14, 2013 at 5:22 PM, Muhammad Shahzad <shaheryarkh@gmail.com>wrote:
Well i have done a lot of "trail and error" on this specific problem in past 3 years and have come to conclusion that,
1. You need at least one layer 4 switching service that manages all routing between your end-users and your internal cluster of media services. It checks and validates inbound traffic, decides which partition (if your cluster is sub-group into different service types) or portion (if your cluster consists of similar nodes) of your cluster serves it and forwards traffic to it. What software you use for this purpose is entirely your choice? I have used OpenSIPS, Kamailio, OverSIP and even a small proxy i wrote in PERL. The fundamental principle for choosing the right software is how you want to handle traffic? e.g.
a). You can use redirection using SIP response code 302. b). You can do state-full relay, by creating and managing SIP transactions. c). You can do bridging, e.g. by using B2BUA.
2. You need layer 5 switching cluster, providing the actually services the end-user needs. You can break the cluster in small groups service-wise, e.g. IVR Service, Voicemail Service, Billing Service, Transcoding Service etc. etc. OR if you can have each node serving all services on its own.
3. Often to handle outbound traffic you can setup another layer 4 switching service or use same as the one for inbound. Generally for very very large setup e.g. >10M users you should have a separate termination gateway.
Thank you.
On Thu, Mar 14, 2013 at 5:02 PM, Cal Leeming [Simplicity Media Ltd] < cal.leeming@simplicitymedialtd.co.uk> wrote:
Sorry, hit send too fast!
I think ultimately this is going to come down to trial and error, and a heck of a lot of testing.. If I can avoid having to re-do the work of other people then great, but it may just be one of those "gotta find out for yourself" things.
Cal
On Thu, Mar 14, 2013 at 4:00 PM, Cal Leeming [Simplicity Media Ltd] < cal.leeming@simplicitymedialtd.co.uk> wrote:
I've looked at a countless number of set ups (including Kazoo), the problem here is choice.. there's many different ways of doing things.
Some people have even gone to the extent of implementing a bunch of switching logic within their proxies.. others use them as dumb transport layers.
Cal
On Thu, Mar 14, 2013 at 3:43 PM, Ben Langfeld <ben@langfeld.co.uk>wrote:
Have you looked at how 2600hz do this kind of thing with Kazoo?
Regards, Ben Langfeld
On 14 March 2013 03:02, Cal Leeming [Simplicity Media Ltd] < cal.leeming@simplicitymedialtd.co.uk> wrote:
Hello all,
I'm currently looking at the various different ways you can deploy FreeSWITCH in a scalable manner, but struggle a little bit on design.
The sweet spot I'm trying to find is one where I can scale out capacity by simply throwing more servers at it.
In an ideal world, this would mean support for;
* Have multiple users from multiple domains to be spread over multiple servers... a single domain should not be restricted to a single FreeSWITCH instance * Have no single point of failure within the structure * Have no single point of bottleneck within the structure * Should not use OpenSIPS.. (I suspect this might get me a lot of flack, but seriously, I'd rather write my own in python or ZXTM traffic script than use OpenSIPS lol).
So far, the best option I can come up with is (although I'm not sure if it's the best available);
* Proxy sitting in front of all backend FreeSWITCH instances, acting in a media proxy fashion only (dual pair of proxies in active/passive mode) * Proxy tracks registrations to the appropriate backend instance, and makes their session sticky * If backend instance needs to make a call to another user in the same domain, it bridges to the call to back to the proxy, the proxy then determines which other FreeSWITCH instance has the user then routes the request accordingly. If the call is to an external destination, the proxy will route it to the traffic aggregation switches (which is basically another pair of FreeSWITCH instances), which then gets routed to the upstream provider.. this means you only have to maintain 2 sets of trunk configuration.. so when you need to scale out your freeswitch backends, it doesn't require putting in a request to your upstream providers for an additional set of trunks. * The bottleneck within these clusters is the dual proxies in active/passive mode.. you could fix this by allocating customers to a specific cluster (rather than instance), thus controlling which customers go to which proxy.. if an entire cluster dies, you can re-route that clusters traffic to a different cluster.
The other simpler option is to allocate domains to a specific backend instance.. but this really doesn't feel clean.. it means a customer cannot scale past the floor limit of a single instance, it has less redundancy, and overall just feels wrong.
Any general thoughts/comments on this would be much appreciated.
Thanks
Cal
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Mit freundlichen Grüßen Muhammad Shahzad ----------------------------------- CISCO Rich Media Communication Specialist (CRMCS) CISCO Certified Network Associate (CCNA) Cell: +49 176 99 83 10 85 MSN: shari_786pk@hotmail.com Email: shaheryarkh@googlemail.com _________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
participants (4)
-
Ben Langfeld
-
Cal Leeming [Simplicity Media Ltd]
-
Muhammad Shahzad
-
Vik Killa