[VoiceOps] Issues with ISPs blocking SIP 5060 - 5061

[Ryan Delgrosso]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20131121/92564c8f/attachment.html>