Adam, A few (random) comments: - If you don't want to maintain two separate user lists you could frontend a FreeSWITCH instance (or multiple FreeSWITCH instances) and your commercial system with OpenSIPS or Kamailio and use the path module for registrations to your existing commercial system: http://www.opensips.org/html/docs/modules/1.7.x/path.html http://www.ietf.org/rfc/rfc3327.txt Your existing commercial system will need to support path (RFC 3327). This config will also end up getting pretty complicated as you will need to configure OpenSIPS to relay traffic between the systems supporting various encryption schemes and codecs to make sure endpoints are compatible: Endpoint (REGISTER TLS) -> OpenSIPS -> Commercial system (UDP/TCP) Endpoint (INVITE TLS w/ G.722/SILK/iLBC) -> OpenSIPS -> FreeSWITCH -> Commercial system (UDP/TCP G711) Commercial system (INVITE UDP/TCP G711) -> OpenSIPS/FreeSWITCH -> Endpoint (TLS w/ G.722/SILK/iLBC) Make no mistake: this is very complex. - The Sangoma hardware doesn't currently support SILK and last time I checked there is no planned support for it. SILK will most likely be supplanted by an IETF standard Opus once it's finalized anyway. I think only then will we start to see more "SILK" (really Opus) implementations. What are you looking for from SILK? - Depending on what kind of API and/or provisioning system is available on your commercial system you may be able to use mod_xml_curl and/or one of the OpenSIPS DB backends to access subscriber information on your commercial system. On Fri, Nov 18, 2011 at 2:31 PM, Adam Sherman <adam@sherman.ca> wrote:
Good Morning,
I have an existing SIP-based hosted PBX service running on a commercial platform. To handle some edge cases, I would like to setup a proxy to achieve two purposes: transcoding from iLBC, SILK & G.722 to G.711 and offering SIP over TLS and SRTP to customers that require it. I was originally looking to see if OpenSIPS could do this, but I now believe this is better achieved by a B2BUA and thus FreeSWITCH (please comment on that logic).
Some key points I have found, so far:
1. Since the proxy will be transcoding and/or handling SRTP streams, it will also need to handle NAT traversal;
2. It should be completely stateless, I think;
3. UACs will be registering through it (they will be configured with it as an outbound proxy);
4. If one UAC ends up being connected to another UAC (e.g. extension to extension dialling), we want the SRTP stream to simply be relayed;
5. This proxy will simply relay all signalling and decrypted/transcoded media to the existing switch;
6. If I run into scaling issues, I can use Sangoma's hardware transcoding solution with FreeSWITCH;
It would be great to hear all your comments and suggestions of what components and modules to use and any other tidbits you can provide.
Also, if anyone has done something like this already and wants to offer commercial services to replicate it for me, send me an email.
Thanks,
A.
-- Adam Sherman Technologist Deputy SARCOM, SAR Global 1 Coordonnateur de L'AQBRS, région 07 Outaouais +1 613 797 6819
_________________________________________________________________________ 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
-- Kristian Kielhofner