Ditto. We have gone down this path but a few things to be aware of we have learned. 1: When switching from UDP to TCP for sip you introduce a failure point on the access side (tcp session). Devices that are rebooted etc will begin a new TCP session and thus create a new registration. If you are using a forking proxy this will create an additional registration orphaning the previous. Depending on your network config rapid reboots of CPE can have subscribers hitting a cap on concurrent registrations where under UDP, after reboots they would have resumed the existing one since there wasnt session state to deal with. 2: You can almost as effectively hide the sip traffic by using different ports (this also prevents your endpoints from getting slammed regularly by sipvicious) On 11/21/2013 10:15 AM, Paul Timmins wrote:
I keep wanting to just deploy SIP/TLS and SRTP for this. You can't SIP ALG what you can't see.
On Thu, 11/21/2013 12:55 PM, Matt Yaklin <myaklin at g4.net> wrote:
On Thu, 21 Nov 2013, J. Oquendo wrote:
> On Thu, 21 Nov 2013, Matt Yaklin wrote: > >> >> >> Will tunneling the sip/rtp packets be more common in the near future >> for SIP phone providers? >> >> matt >> > >> From the ITSP side (where we provide trunks). Tunnels would > be a nightmare, so they are a no-no. Now you're throwing > in too many variables (Aggressive, Main, set ups, different > equipment). Not to mention the overhead it would add to an > SBC. > >> From the Managed PBX side of the equation... NO, but before > I ramble on, define tunneling. Tunneling as in VPN? If the
Yes, a VPN tunnel that the CPE/SBC would have to handle and connect back to a centralized location that the SIP provider controls. Every SIP device behind the CPE/SBC would have to go through the CPE/SBC.
The reason I mention it was recent SBC installs I did at customer sites had tunnel options but I am unsure at the moment if it was for site to site (full mesh setup) connectivity for security reasons or more for getting back to the provider for alternative reasons.
But the more I think about it... it does add complexity that we would all like to avoid.
matt
> concern is security, TLS is suitable from the managed PBX > side as we can firewall trusted CIDRs on the firewall to > prevent recording/tampering. > > If you meant VPN tunneling... Would only work on a softphone > because I have YET to see any VoIP device (phone, ATA, FXO, > FXS) have any parameters to set up a tunnel. So I am unsure > how one would truly call a VoIP Tunnel in a VPN sense, any > kind of true tunneling. (Tunnel in Tunnel maybe, been a > while since I dove into CCIP/IE like material. > > -- > =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ > J. Oquendo > SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT, RWSP, GREM > > "Where ignorance is our master, there is no possibility of > real peace" - Dalai Lama > > 42B0 5A53 6505 6638 44BB 3943 2BF7 D83F 210A 95AF > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x2BF7D83F210A95AF > _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org <mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops