Issues with ISPs blocking SIP 5060 - 5061
Has anyone been having problems lately with ISPs? actively blocking UDP 5060 ? 5061? I?m having problems with Road Runner in Hawaii apparently blocking those ports preventing me from communicating with the customers PBX. My customer has a ticket open with them but we aren?t confident that we?ll get anywhere with them. If we don?t is there an authority that we can speak with that can make them open those ports or face sanctions? David Thompson Network Services Support Technician (O) 858.357.8794 (F) 858-225-1882 (E) dthompson at esi-estech.com (W) www.esi-estech.com
I don't know of anything that obligates an ISP to carry any particular form of traffic. All the AUPs that I've seen have plenty of room for them to block pretty much whatever they want, but it's been a while since I've one do this kind of thing. You might get some traction with your state consumer protection or public utility office. David From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of David Thompson Sent: Wednesday, November 20, 2013 15:51 To: voiceops at voiceops.org Subject: [VoiceOps] Issues with ISPs blocking SIP 5060 - 5061 Has anyone been having problems lately with ISPs' actively blocking UDP 5060 - 5061? I'm having problems with Road Runner in Hawaii apparently blocking those ports preventing me from communicating with the customers PBX. My customer has a ticket open with them but we aren't confident that we'll get anywhere with them. If we don't is there an authority that we can speak with that can make them open those ports or face sanctions? David Thompson Network Services Support Technician (O) 858.357.8794 (F) 858-225-1882 (E) dthompson at esi-estech.com<mailto:dthompson at esi-estech.com> (W) www.esi-estech.com<http://www.esi-estech.com> This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.
In 2005, the FCC fined a NC based ISP $15,000 for blocking VoIP ports. http://transition.fcc.gov/eb/Orders/2005/DA-05-543A2.html Since that time, in my IANAL way, I've always worked as if "section 201(b) of the Communications Act of 1934, as amended" meant you couldn't block VoIP ports simply for the sake of preventing VoIP use.
mark at ecg.co +1-229-316-0013 http://ecg.co/lindsey
On Nov 20, 2013, at 19:14 , Hiers, David <David.Hiers at adp.com> wrote:
I don?t know of anything that obligates an ISP to carry any particular form of traffic. All the AUPs that I've seen have plenty of room for them to block pretty much whatever they want, but it's been a while since I've one do this kind of thing.
You might get some traction with your state consumer protection or public utility office.
David
From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of David Thompson Sent: Wednesday, November 20, 2013 15:51 To: voiceops at voiceops.org Subject: [VoiceOps] Issues with ISPs blocking SIP 5060 - 5061
Has anyone been having problems lately with ISPs? actively blocking UDP 5060 ? 5061? I?m having problems with Road Runner in Hawaii apparently blocking those ports preventing me from communicating with the customers PBX. My customer has a ticket open with them but we aren?t confident that we?ll get anywhere with them. If we don?t is there an authority that we can speak with that can make them open those ports or face sanctions?
David Thompson Network Services Support Technician (O) 858.357.8794 (F) 858-225-1882 (E) dthompson at esi-estech.com (W) www.esi-estech.com
This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
We have run into with them and ask for them to to turn off nat mode and put the modem into bridge mode and then a reboot of the modem usually solves the problem... Some of the combo modems with fxs voice ports have been known to intercept the sip traffic and we ultimately had to have them replace the modem model as they didn't know how to disable it and wouldn't grant us access to the modem Sent from my iPhone On Nov 20, 2013, at 8:16 PM, "Mark R Lindsey" <mark at ecg.co<mailto:mark at ecg.co>> wrote: In 2005, the FCC fined a NC based ISP $15,000 for blocking VoIP ports. http://transition.fcc.gov/eb/Orders/2005/DA-05-543A2.html Since that time, in my IANAL way, I've always worked as if "section 201(b) of the Communications Act of 1934, as amended" meant you couldn't block VoIP ports simply for the sake of preventing VoIP use.
mark at ecg.co<mailto:mark at ecg.co> +1-229-316-0013 http://ecg.co/lindsey
On Nov 20, 2013, at 19:14 , Hiers, David <David.Hiers at adp.com<mailto:David.Hiers at adp.com>> wrote: I don?t know of anything that obligates an ISP to carry any particular form of traffic. All the AUPs that I've seen have plenty of room for them to block pretty much whatever they want, but it's been a while since I've one do this kind of thing. You might get some traction with your state consumer protection or public utility office. David From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of David Thompson Sent: Wednesday, November 20, 2013 15:51 To: voiceops at voiceops.org<mailto:voiceops at voiceops.org> Subject: [VoiceOps] Issues with ISPs blocking SIP 5060 - 5061 Has anyone been having problems lately with ISPs? actively blocking UDP 5060 ? 5061? I?m having problems with Road Runner in Hawaii apparently blocking those ports preventing me from communicating with the customers PBX. My customer has a ticket open with them but we aren?t confident that we?ll get anywhere with them. If we don?t is there an authority that we can speak with that can make them open those ports or face sanctions? David Thompson Network Services Support Technician (O) 858.357.8794 (F) 858-225-1882 (E) dthompson at esi-estech.com<mailto:dthompson at esi-estech.com> (W) www.esi-estech.com<http://www.esi-estech.com/> ________________________________ This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. _______________________________________________ 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<mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops
On 11/20/13 3:51 PM, David Thompson wrote:
Has anyone been having problems lately with ISPs? actively blocking UDP 5060 ? 5061? I?m having problems with Road Runner in Hawaii apparently blocking those ports preventing me from communicating with the customers PBX. My customer has a ticket open with them but we aren?t confident that we?ll get anywhere with them. If we don?t is there an authority that we can speak with that can make them open those ports or face sanctions?
I haven't run into any blocking, but we're seeing more and more instances where the larger carriers will install some sort of NAT router as the handoff on residential and small business accounts as opposed to giving the customer a DHCP or static public IP. Many of these devices horribly break SIP, especially if you're putting any kind of ALG behind them. Getting the carrier to turn off all of the cruft and just give you raw access to the Internet is often an exercise in futility. -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV
On Wed, 20 Nov 2013, Jay Hennigan wrote:
I haven't run into any blocking, but we're seeing more and more instances where the larger carriers will install some sort of NAT router as the handoff on residential and small business accounts as opposed to giving the customer a DHCP or static public IP.
Many of these devices horribly break SIP, especially if you're putting any kind of ALG behind them.
Getting the carrier to turn off all of the cruft and just give you raw access to the Internet is often an exercise in futility.
We have seen a lot (A WHOLE LOT) of this occurring with Comcast. E.g., we have a client with multiple PBXs spread through about a dozen or so locations throughout CT, RI, MA. At least once per quarter, Comcast seems to push out some form of policy/rule/firmware update or other that prohibits the connection via VoIP and ONLY VoIP. This particular account uses Comcast business however, when this occurs, we get a call from this client, and see the trickle effect via our other clients (ATAs, softphones, etc.) Most other providers we deal with, could care less (Covad, Paetec, AT&T) however the cable providers (which RoadRunner is another) seem to be horrible at this game (filtering). "Getting the carrier..." We try not to inherit any of the network unless we are managing it. This frees us from any liabilities associated with say a Doctors office doing some whacky VPN to a hospital or other. Would take us too long to perform a network assessment, and make sense of a client's business needs, especially for free. -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 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
On 11/21/13 5:36 AM, J. Oquendo wrote:
"Getting the carrier..." We try not to inherit any of the network unless we are managing it. This frees us from any liabilities associated with say a Doctors office doing some whacky VPN to a hospital or other. Would take us too long to perform a network assessment, and make sense of a client's business needs, especially for free.
It's a balancing act, to be sure. Your customer will of course say that the rest of the Internet works fine, it's just your VoIP service that is failing. "I can get to Google and Yahoo, so there's nothing wrong with my Internet, but your phone doesn't work." For one-off remote phones, setting SIP transport to TCP is often a good workaround by the way. -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV
On Thu, 21 Nov 2013, Jay Hennigan wrote:
It's a balancing act, to be sure. Your customer will of course say that the rest of the Internet works fine, it's just your VoIP service that is failing. "I can get to Google and Yahoo, so there's nothing wrong with my Internet, but your phone doesn't work."
For one-off remote phones, setting SIP transport to TCP is often a good workaround by the way.
Don't you just love that? (All is working except you sux0r). We had (and have, and sometimes goes back to had) a client in Fairfield CT. According to the installer, the building they were in was wretched (wiring, etc.). They'd put in one T1, we'd slap on VoIP. "Horrible service - you suck!" They'd move over to another VoIP carrier. Two months later, they'd move back to us, with another T1 from another carrier to then come back and tell us: "You suck" (again). This went on for some time until it finally dawned on them 3 VoIP carriers later, 4 T1 providers later. "Your infrastructure is teh suck!" It becomes difficult in the ITSP/Managed VoIP game to deal with this. Moreso to find contacts in the carriers who are willing to even assist when we call on behalf of our clients. "You're not the client" Moreso, to deal with "networking" gurus who just seemed to have graduated "Fisher Price My First Network" academy who fiddle with stuff. Last VoIP was story... Two weeks ago. Client with dual connectivity (AT&T Ts and Comcast)... We fight with getting info into their network correctly. Wireshark captures galore showed they were taking IN from AT&T, then sending audio OUT Comcast. We corrected SIP ALG, NAT, FW garbage on our SBCs. Weeks go by, all is fine. Client: "Our VoIP is broken you are teh sucks!" Gigabytes of Wireshark analysis later... We show then what is happening which is on their end. Newb IT Guy: "Oh well the only thing I changed was I turned on IPS for VoIP." Sigh. I spent about 4-6 hours capturing, analyzing what was going on (no charge because remember, at the end of the day it is our fault, since they can still read Twitter). Painted some nice stick figure captures illustrating the issue. Result? Still not fixed, kludge was installed to address their issue. This was AFTER the initial install where I had already spent about 3-4 hours trying to assist them with their Astaro FW cluster^W rules. -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 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
On Thu, 21 Nov 2013, Jay Hennigan wrote:
On 11/21/13 5:36 AM, J. Oquendo wrote:
"Getting the carrier..." We try not to inherit any of the network unless we are managing it. This frees us from any liabilities associated with say a Doctors office doing some whacky VPN to a hospital or other. Would take us too long to perform a network assessment, and make sense of a client's business needs, especially for free.
It's a balancing act, to be sure. Your customer will of course say that the rest of the Internet works fine, it's just your VoIP service that is failing. "I can get to Google and Yahoo, so there's nothing wrong with my Internet, but your phone doesn't work."
For one-off remote phones, setting SIP transport to TCP is often a good workaround by the way.
Will tunneling the sip/rtp packets be more common in the near future for SIP phone providers? matt
-- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
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 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
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
An embedded and charset-unspecified text was scrubbed... Name: not available URL: <https://puck.nether.net/pipermail/voiceops/attachments/20131121/37a45e4e/att...>
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
We've found with both Bright House and Verizon that at least in Florida they impose a 5% to 40% packet loss on any PPTP tunnel. We did migrate several customers' SIP service to encrypted tunnels, and this is how BH and Verizon responded. We have not been able to get them to admit that they are shaping traffic this way, but we can perfectly see them do it. Traffic between the two routers outside the tunnel is 100% perfect, but inside the tunnel traffic takes this consistent loss. It seemed like the FCC's Comcast wrist-slapping got reversed, and they are therefore becoming more bold about doing things like this. Mike Ray, MBA, CNE, CTE Astro Companies, LLC 11523 Palm Brush Trail #401 Lakewood Ranch, FL 34202 DIRECT: 941 600-0207 http://www.astrocompanies.com -----Original Message----- From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Matt Yaklin Sent: Thursday, November 21, 2013 12:55 PM To: J. Oquendo Cc: voiceops at voiceops.org Subject: Re: [VoiceOps] Issues with ISPs blocking SIP 5060 - 5061 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 https://puck.nether.net/mailman/listinfo/voiceops
I have my SBC configured to listen on port 5060 and a couple other non-standard ports. When a customer ISP or firewall ALG gets in the way I configure them to use the other ports. It is pretty easy to add additional ports to the sip-interface of your acme packet SBC -Matt -- Matthew S. Crocker President Crocker Communications, Inc. PO BOX 710 Greenfield, MA 01302-0710 E: matthew at crocker.com P: (413) 746-2760 F: (413) 746-3704 W: http://www.crocker.com On Nov 21, 2013, at 12:32 PM, Matt Yaklin <myaklin at g4.net> wrote:
On Thu, 21 Nov 2013, Jay Hennigan wrote:
On 11/21/13 5:36 AM, J. Oquendo wrote:
"Getting the carrier..." We try not to inherit any of the network unless we are managing it. This frees us from any liabilities associated with say a Doctors office doing some whacky VPN to a hospital or other. Would take us too long to perform a network assessment, and make sense of a client's business needs, especially for free.
It's a balancing act, to be sure. Your customer will of course say that the rest of the Internet works fine, it's just your VoIP service that is failing. "I can get to Google and Yahoo, so there's nothing wrong with my Internet, but your phone doesn't work."
For one-off remote phones, setting SIP transport to TCP is often a good workaround by the way.
Will tunneling the sip/rtp packets be more common in the near future for SIP phone providers?
matt
-- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV _______________________________________________ VoiceOps mailing list 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
On 11/21/13 9:35 AM, Matthew Crocker wrote:
I have my SBC configured to listen on port 5060 and a couple other non-standard ports. When a customer ISP or firewall ALG gets in the way I configure them to use the other ports. It is pretty easy to add additional ports to the sip-interface of your acme packet SBC
Sometimes it isn't the port, but the way the CPE deals with UDP, especially if there's a NAT or firewall you can't tweak. -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV
On Thu, Nov 21, 2013 at 9:32 AM, Matt Yaklin <myaklin at g4.net> wrote:
Will tunneling the sip/rtp packets be more common in the near future for SIP phone providers?
matt
Why not just run SIP on a nonstandard port? 80/443 seems to work great behind VZW's CGN. This also bypasses 99% of crappy ALGs in home routers problems for other users.
Hello, I thought you might find this usefull: http://wiki.snom.com/Networking/Virtual_Private_Network_(VPN) It's a good way to make sure you don't have issues like these, also avoid bad NAT ALGs and the usual stuff... The alternative is to use CISCO phones. With recent 9.x firmware, you can get them to build a VPN to an ASA that could be next to your SIP server. The licence price for this feature is a "litle" high. I don't work for neither of them. --- Cumprimentos / Best regards Marco Teixeira email/gtalk/msn: admin at marcoteixeira.com skype: admin-marcoteixeira.com --- Did you know that Marco Teixeira is an independent, industry expert, senior consultant ? His expertise is available for hire. --- On Thu, Nov 21, 2013 at 5:32 PM, Matt Yaklin <myaklin at g4.net> wrote:
On Thu, 21 Nov 2013, Jay Hennigan wrote:
On 11/21/13 5:36 AM, J. Oquendo wrote:
"Getting the carrier..." We try not to inherit
any of the network unless we are managing it. This frees us from any liabilities associated with say a Doctors office doing some whacky VPN to a hospital or other. Would take us too long to perform a network assessment, and make sense of a client's business needs, especially for free.
It's a balancing act, to be sure. Your customer will of course say that the rest of the Internet works fine, it's just your VoIP service that is failing. "I can get to Google and Yahoo, so there's nothing wrong with my Internet, but your phone doesn't work."
For one-off remote phones, setting SIP transport to TCP is often a good workaround by the way.
Will tunneling the sip/rtp packets be more common in the near future for SIP phone providers?
matt
--
Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV _______________________________________________ VoiceOps mailing list 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
I expect the EFF would be interested in hearing about these events, especially in light of the pending decision on Verizon. If anyone has hard proof of this, I'd be interested in an off list reply. --Chris
We see this with alarming regularity. Often it conveniently corresponds with a marketing push from the MSO for triple play offerings. I recall this happened at my home when I was with one of those players, and suddenly my home line on my network stopped being able to talk to my border elements. The MSO support played the "well youll need to talk to your ITSP about that, OR you could just switch to our phone service" card at which point I explained I was my ITSP and then it magically started to work... Eventually we just abandoned the usual ports completely. When this happens to the customer the perception is you suck and the MSO has their act together because THEIR phone works. Not worth the fight, since you will have it every promotional cycle and evidence is VERY difficult to collect. On 11/20/2013 03:51 PM, David Thompson wrote:
Has anyone been having problems lately with ISPs' actively blocking UDP 5060 -- 5061? I'm having problems with Road Runner in Hawaii apparently blocking those ports preventing me from communicating with the customers PBX. My customer has a ticket open with them but we aren't confident that we'll get anywhere with them. If we don't is there an authority that we can speak with that can make them open those ports or face sanctions?
David Thompson Network Services Support Technician (O) 858.357.8794 (F) 858-225-1882 (E) dthompson at esi-estech.com <mailto:dthompson at esi-estech.com> (W) www.esi-estech.com <http://www.esi-estech.com>
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
participants (14)
-
admin＠marcoteixeira.com -
cboyd＠gizmopartners.com -
David.Hiers＠adp.com -
dthompson＠esi-estech.com -
jackson.tim＠gmail.com -
jay＠west.net -
mark＠ecg.co -
matthew＠corp.crocker.com -
mike＠astrocompanies.com -
myaklin＠g4.net -
paul＠timmins.net -
ryandelgrosso＠gmail.com -
sil＠infiltrated.net -
twolf＠unifiedtechnologies.com