You got the general concept correct. Encryption should be done between your client towards a switch that supports your proprietary encryption. The switch should be in a network that allows SIP to flow. All communications to the outside internet should always traverse the switch as the first hop. UA-Blocked [encrypted] -> ((Blocked Network)) -> [encrypted] Switch-Non-Blocked [SIP] -> ((Open-Internet)) -> Carrier One piece of advise. You don't have to use complex encryption to achieve this. A simple XOR on RTP and SIP using a shared key would be enough. This would make your encryption algo light weight. This is getting a bit off-topic in this list. Just send me an off-list message if you have more questions before the mailing list police kicks us out . From: varun pratapsingh Sent: Friday, July 24, 2009 5:44 PM To: pjsip list Subject: Re: SIP blocked countries issue. Do any bodyhavethesolution? Hi Joegen and Syd, Mr. Syd can you tell me any VPN name which would be suitable for it. Can you provide me some implementation details too. It would be a better solution if you have already used VPN solutions in such cases and you ca guide me in the implementation. Mr. Joegen I got your point, according to your discussion I have an implentation in my mind. How will it be if we use some encrypted Tunnelling in this. The summary of the implemantaion is as below. Please see it and do tell me the limitations of the model if you feel beacuse then i will be working on it. All suggestions are invited: I will be using the ecryption like blowfish and deffie hellman key exchange. The architecture would be like that the program would support two modes one is server mode running on the Softswitch in my case and one is client end mode running on the softphone end in my case. The server end program would be running as always as the server is always up and waiting for the clients to setup the tunnel using the secret key sharing using deffie hellman algo then they the further communication would be agreed on some defined ports hence making the tunnel then the further communication would go through this tunnel. The packets in this tunnel are too encrypted by using the blowfish encryption. Now as we know SIP signalling is through 5060 port and RTP through 4000 port but now using our program the ports would be changed after encryption and two new tunnels would be formed one for SIP and other for RTP by the user end and server end by using deffie hellman. So I think this model can be used for SIP communication without any need of VPN overhead and SIP blocked areas would not be able to catch the type of communication. Please anyone who goes through this mail please if you see any loop holes in this model. Kindly let me know immediately because it would be a great help and will be appreciable. An especially mr. Joegen and Mr Syd I expect you some special comments on this. So please find anu bugs and provide me any suggestion for making this system more robust then I will provide a complete documented design and architecture of this model to be revised again. and one day i hope we will have a god solution added to pjsip in this regard. Thanks and Regards: Ravi On Fri, Jul 24, 2009 at 2:07 PM, syd <cherkazoo at live.co.uk> wrote: A VPN solution would work in this case. On the plus side, is it will not require changes on your soft switch set up, but you will need to make sure your client set up handles the VPN traffic correctly. It is widely being used for such purposes. Syd From: pjsip-bounces@xxxxxxxxxxxxxxx [mailto:pjsip-bounces at lists.pjsip.org] On Behalf Of Joegen Baclor Sent: 24 July 2009 09:25 To: pjsip list Subject: Re: SIP blocked countries issue. Do any body havethesolution? TLS/SRTP is not guaranteed. Since SRTP is still RTP, it is distinguishable by the filters so even if you get TLS to penetrate the filters there is a big possibility that you won't get any audio. You have to find a way to mangle the RTP packets in some way that they won't be recognized by the filters. And so far, the only way it can be done is through proprietary means. From: varun pratapsingh Sent: Friday, July 24, 2009 3:57 PM To: pjsip list Subject: Re: SIP blocked countries issue. Do any body havethesolution? Hi Joegen, So using TLS/SRTP in Pjsip will resolve the issue. Will it be a right choice. Can you guide me something more on this implementation. What are the limitations which you have tried to point out in the your reply in using TLS /SRTP. Thanks .... Regards: Ravi On Fri, Jul 24, 2009 at 9:33 AM, Joegen Baclor <joegen.baclor at gmail.com> wrote: In countries that are blocked (mostly in middle east), they are using deep penetration packet analyzers for both SIP and RTP. So changing the ports wont usually work. You might get away with a TLS/SRTP combo but this is an end to end requirement limiting the softphone to only work with providers that support both. Another option would be to install SBC's with proprietary encryption support within the blocked country and in another location where SIP is allowed. This would hide SIP and RTP from the filters. OpenSBC for example works with grandstream proprietary CBCom encryption and is tested to bypass these types of blockage. Joegen -------------------------------------------------- From: "Paulo Rog?rio Panhoto" <paulo@xxxxxxxxxxxxxxxxxxxxxx> Sent: Thursday, July 23, 2009 10:57 PM To: "pjsip list" <pjsip at lists.pjsip.org> Subject: Re: SIP blocked countries issue. Do any body have thesolution? Hello Ravi, I guess someone might have asked this before: is SIPS also blocked? varun pratapsingh wrote: Hi All, In some countries SIP is blocked means our softphones are not working. Is there any way which can be used to reslove this issue. some peoples are suggesting VPNs but can,t it be like if we do some encryption of our SIP traffic. Please if any body can give a real solution then it would be a great help. Regards: Ravi ------------------------------------------------------------------------ _______________________________________________ Visit our blog: http://blog.pjsip.org pjsip mailing list pjsip at lists.pjsip.org http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org _______________________________________________ Visit our blog: http://blog.pjsip.org pjsip mailing list pjsip at lists.pjsip.org http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org _______________________________________________ Visit our blog: http://blog.pjsip.org pjsip mailing list pjsip at lists.pjsip.org http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org ------------------------------------------------------------------------------ _______________________________________________ Visit our blog: http://blog.pjsip.org pjsip mailing list pjsip at lists.pjsip.org http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org _______________________________________________ Visit our blog: http://blog.pjsip.org pjsip mailing list pjsip at lists.pjsip.org http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org -------------------------------------------------------------------------------- _______________________________________________ Visit our blog: http://blog.pjsip.org pjsip mailing list pjsip at lists.pjsip.org http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20090725/3ad81007/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 257 bytes Desc: not available URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20090725/3ad81007/attachment.gif>
