P2P Bandwidth Throttling in Israel, Legal and Technological Aspects.

0. Abstract
Do Israeli Internet Service Providers throttle, delay or block peer-to-peer traffic? This question has been spreading in Israeli forums and file-sharing networks, and has introduced theories from attempts to sell enhanced Internet packages to copyright infringement monitoring. This research, which was conducted between April and September 2009, was meant to check whether the claim was true. Using simple free tools we decided to inspect the legality of DPI and traffic shaping in Israel and whether it exists.

Our findings were that there is direct and deliberate interference in P2P traffic by at least 2 out of the 3 major ISPs and that this interference exists by both P2P caching and P2P blocking. The tests, conducted by independent volunteers, were directed by myself and with the assistance of Ynet’s staff and especially Mr. Niv Lilien, who published a Hebrew summary.
1. Background:
Peer-to-peer (P2P) file transfer protocols have been in common use since the advent of networked computing, but their rising profile (as well as the controversy surrounding them) began with the introduction of P2P sharing of copyrighted materials. Initially used for sharing small music files and applications, P2P today is a legitimate and widely used system for the distribution of any electronic media, and multiple gigabyte files are commonly shared amongst users from around the world. Whilst some researches imply that there is a slight decrease in the growth of P2P (Allot, 2009), P2P is still the Killer Internet Application, responsible for 21% of the Average Mobile Traffic Cell and in charge of an estimate of 70% (ReadWriteWeb, 2006.12.06) of the global Internet traffic during 2006, accounting for around 25% on some networks (PlusNet, 2008.07.17), but according to more detailed reports, accounting for more than 50% of the network’s traffic (ipoQue, 2009, TorrentFreak 2009.02.18).

Peer to Peer traffic consists of illegal downloads of files, voice over IP calls, instant messaging and other decentralized communication. The element common to all P2P services is the lack of economical benefit to the ISP from the client’s use of P2P. According to recent studies, P2P users consume more traffic (Arstechnica, 2008.07.04), and when traffic caps are used Internet Service Providers (ISPs) benefit and earn more from P2P use (Arstechnica, 2008.05.07).
Since 2007, claims that Israeli ISPs are blocking P2P traffic have been spread all over the Israeli Web. More recently, a report by Vuze Inc, a popular service utilizing P2P in order to provide its users with high definition video content over the BitTorrent protocol found that all three major Israeli ISPs block P2P traffic to some degree . (8.13% for Smile012, 18.51%  for Bezeqint and 14.06% for Netvision). During 2009, complaints against the three major Israeli ISPs (inspected in our research) were brought to the media and were dismissed by the ISPs. Bezeq International claimed that it does not interfere with  P2P traffic and called the claims ‘baseless’ (Ynet, 2009.03.29), whereas a year earlier it claimed that it is the only company that does not block P2P (Ynet, 2007.12.05 ). Smile012 dismissed Torrentleech’s claims that it blocks P2P traffic (Ynet, 2008.01.24, Torrentleech FAQ) and Netvision-Barak dismissed the claim that it de-prioritizes P2P traffic, claiming that such activity was impossible, and were it possible, it would block all child-pornography and offensive content (Ynet, 2007.05.27). However, and even though such formal announcements were made, many reports on informal conversations with customer support representatives who have acknowledged the problem. Another recent report was that Bezeq International was actually amending .torrent files in order to add the Bezeq International Tracker and save on outbound bandwidth (Torrentfreak, 2009.04.19 ); However, Bezeq International’s CEO rejected the claim and stated to Amitai Ziv, from TheMarker that “I will not operate an illegal video library on my servers, even if my competitors do that” (TheMarker, 2009.08.05).
For example, a person claiming to be an ex-Netvision customer support representative claims that they block P2P traffic originating outside of Israel (BGU Forum, 2009.03.26 ), an informal and anonymous executive in one of Israel’s ISPs stated that due to excessive outbound traffic costs, ISPs block P2P traffic (Haaretz, 2008.05.06 ); however, until now there was no extensive research to inspect any of these claims.

1.1 Legal framework
Israeli ISPs operate under a specific license which requires them (Israel has 39 licensees, 2009 numbers, general license example) Clause 5.4.1 to the general license states that the License Holder’s activity shall not interfere with the free competition in the telecom market or harm the public interest. Moreover, clause 29 to the Israeli Telecommunication Act (1982) specifies that interfering or blocking of electronic communication over a public network is a criminal ofence. Therefore, even without any net-neutrality regulation (see, for example, Tal Zarsky’s 2009 lecture during the ISOC conference ), Israel has the appropriate regulation to interfere with attempts to prioritize network packets and to withhold other packets.

Recent letters from the Telecommunication Ministry’s CEO (CEO Letter, 2009.07.15) explicitly stated to all telecom providers to avoid interfering with all traffic and especially Skype (TheMarker 2009.07.15); whilst some ISPs claim otherwise and state that there is no legal obligation for network neutrality (Themarker 2009.07.27), Our belief is that under the current legal status, without prior explicit consent by the End-User, network neutrality must be imposed at the strictest form in order to ensure impunity from liability for End-Users’ file sharing (MGM v. Grokster). The Israeli draft for the Electronic Commerce Act (Government Bills, 2008.01.14) exempts ISPs from Caching if they had not modified the packets (Clause 9). Moreover, Clauses 7-10 exempt liability if, and only if, the ISP had not manipulated any packet.

Moreover, Deep Packet Inspection (DPI) as executed by several of the Israeli ISPs, may be considered illegal wiretapping, as it is defined in the Israeli Wiretapping Act, as “Listening to another person’s conversation, interception or copying of another person’s conversation, and all with an apparatus”; DPI may also be considered Interfering with Computer Data under the Computer Act or illegal entry to computer information. DPI occurs when an apparatus listens to the End-Users’ packets, inspects their content and according to their content manipulates them or passes them to their destination. Unlike regular routing, that only “reads” the target address and sends the packet to its destination, DPI manipulates the packet, without the End-Users’ explicit consent and may be considered illegal. The Israeli Courts continuously ruled that inspecting one’s traffic and personal files consists as a crime under the Computer Act (CA 1126/06 Lerman v. State, where Lerman installed a Trojan horse; C 40206/06 State v. Pilosof). In Pilosof, the District Court of Tel-Aviv ruled that “Inspecting the Email message in the electronic range should be made with a broad perspective on the email’s traffic from its dispatch until its arrival to its destination, therefore, intercepting a message on the ISP’s computer is “real time” interception whilst the data is transferred and prior to the termination of computer communication (…) Accepting the state’s view might lead to an unwanted result where the ISP may not be prohibited from copying and reading the messages intended for his clients, as the intrusion occurs on his computers”.

Therefore, while traffic manipulation may inflict liability on ISPs when they manipulate traffic knowingly that such traffic is copyright infringing (even if manipulation means slowing down), we believe that it is illegal for Israeli ISPs to manipulate traffic.

1.2 Comcast’s FCC ruling.
Unlike Israel, the US struggle for network neutrality and against file sharing throttling began in the early 2000s (Tim Wu: Network Neutrality, Broadband Discrimination ) and has been brought to the attention of the FCC, which ruled that its role is to preserve the open nature of the Internet (FCC 2005 ). However, only in 2008, after Comcast, the 2nd largest ISP in the US was caught throttling P2P traffic (Gigaom 2008.07.11 ), the FCC had to examine whether blocking (or delaying) P2P traffic was in accordance with US regulation.

The FCC’s ruling (FCC, 2008 ) stated that Comcast may not limit or delay any peer to peer traffic, claiming that it was unlawful intervention in competition and against the public interest: “This practice is not “minimally intrusive” but invasive and outright discriminatory. Comcast admits that it interferes with about ten percent of uploading peer-to-peer TCP connections, and independent evidence shows that Comcast’s interference may be even more prevalent. In a test of over a thousand networks over the course of more than a million machine-hours, Vuze found that the peer-to-peer TCP connections of Comcast customers were interrupted more consistently and more persistently than those of any other provider’s customers. Similarly, independent evidence suggests that Comcast may have interfered with forty if not seventy-five percent of all such connections in certain communities” (…) “On its face, Comcast’s interference with peer-to-peer protocols appears to contravene the federal policy of “[promoting] the continued development of the Internet” because that interference impedes consumers from “[running] applications . . . of their choice,” rather than those favored by Comcast, and that interference limits consumers’ ability “to access the lawful Internet content of their choice,” including the video programming made available by vendors like Vuze. Comcast’s selective interference also appears to discourage the “development of technologies” — such as peer-to-peer technologies — that “maximize user control over what information is received by individuals . .. who use the Internet” because that interference (again) impedes consumers from “run[ning] applications . . . of their choice,” rather than those favoured by Comcast”.

The question now is whether Israeli ISPs do limit or even block traffic (where the delaying of packets equals blocking, see Comcast Ruling, pp. 26-27) and whether the Israeli regulator interferes with such activity. Moreover, as Israel has an oligopoly of three ISPs with no actual competition (further aggravated by a duopoly of Network Service Providers in Bezeq and Hot), there may be a case for antitrust inquries and not only inquries by the Telecommunication ministry.

2. The Test

In order to examine whether P2P traffic was blocked, we began the experiment with two tools developed by other parties. The first is the open-source Switzerland tool, developed by the EFF. “Switzerland is an open source, command-line software tool designed to detect the modification or injection of packets of data by ISPs. Switzerland detects changes made by software tools believed to be in use by ISPs such as Sandvine and AudibleMagic, advertising systems like FairEagle, and various censorship systems. Although currently intended for use by technically sophisticated Internet users, development plans aim to make the tool increasingly easy to use” (EFF, 2008). Switzerland was released following the FCC ruling and was the tool that the EFF used in order to prove the claim that Comcast was indeed throttling P2P traffic (TorrentFreak, 2008 ).

We also used Glasnost, which is partially supported by Google and the Max Planck Institute. Glastnost is a part of Measurement Labs and  is an independent java client, running within a browser. Prior to our inspection, Glasnost found that Israeli ISPs are not throttling traffic. In its report, only 3 out of 971 tests were blocked, and out of 17 different ISPs measured in Israel, only 3 blocked P2P. However, these results do not include throttling or shaping. Therefore, we began our experiment without any additional Information.
2.1 EFF’s Switzerland
While we were unable to review the Switzerland logs, mostly due to our failure to coordinate between volunteers’ time to run the scripts, Switzerland assisted us in finding some interesting conclusions. We left a server to seed a .torrent file of a public domain video; our volunteers downloaded and uploaded the file again and again, looking for potential interference by the ISP or RST packets. We were unable to produce any substantial results or conclusions regarding traffic, mostly due to Switzerland’s interface.

However, after a massive number of attempts, we found out that another user is seeding our torrent, from the IP address 212.235.15.36 and not from the libTorrent Client we used (screenshot, screenshot ). We found a mention of such IP address in an Israeli Hardware forum describing it as one of Netvision’s caching servers  (HWZone, 2009). While the IP address is associated with Netvision, we were able to authenticate that a similar IP address is being used in eMule caching (img src) and that 212.235.x.x, which was used in other conversations, are owned by Netvision (whois data). While this is not throttling with user packets, it is considered a severe interference with communication privacy and may be considered intercepting private conversations.

We believe that additional research is required to authenticate whether such activity is taking place in additional ISPs and whether this ISP is caching additional files. Moreover, such caching has severely tampered with our ability to inspect bandwidth throttling, as our inspection of speed was irrelevant once the .torrent and the file were cached on the ISP level.

We also encountered a strange download from a cTorrent download from 213.174.157.6 (screenshot), where we could find slight affiliation with IP addresses that are affiliated with CheckTOR, a company that’s meant to assist copyright holders (Checktor).

2.2 Glasnost Results
We ran Glasnost from different computers and different ISPs, on different occasions and even through random WiFi hotspots, in order to inspect interference with BitTorrent traffic. Glasnost operates in the following manner: it inspects the connection in four different transfers: BitTorrent upload and download over a standard BitTorrent port and over a non-standard port, and TCP upload and download over a standard BitTorrent port and non-standard port. By comparing the TCP and BitTorrent results, information as to whether deep packet inspection occurs, as it prioritizes traffic according to protocol, and by comparing standard to non-standard port information whether port preference occurs.

We conducted at least 8 inspections per ISP and logged them. We compared the results and analyzed them, and our findings were as follows:

2.2.1 Netvision:
Netvision probably operates both deep packet inspection, which we already mentioned when we found that it may cache popular torrents. Our findings where that in standard port uploads, the average ratio of BitTorrent to TCP was 70%, and on non-standard ports it was 81%; however, aggregated ratios (the aggregate of all the upload speeds and download speeds) were 52% on standard ports and 59% on non-standard ports.  In downloads, we encountered similar results, providing an average BT/TCP ratio of 58% on standard ports and 50% on non-standard ports and an aggregate value of 50% on standard ports and 27% non-standard ports.

2.2.2 Bezeq International:
Bezeq International’s results were inconclusive, and because of one inspection, where BitTorrent traffic was 12 times faster than TCP on an upload, the results were inexplicable. Therefore, we omitted this inspection as it was off the standard deviation. Moreover, Bezeqint’s results were inconclusive and could be due to standard deviation in the statistical margin of error, in general, Bezeqint’s BitTorrent traffic was faster than TCP traffic. Our findings where that in standard port uploads, the average ratio of BitTorrent to TCP was 105%, and on non-standard ports it was 69%; aggregated ratios were 104% on standard ports and 52% on non-standard ports.  In downloads, however, the average BT/TCP ratio was 147% on standard ports and 130% on non-standard ports. However, the aggregate download ratio had a value of 137% on standard ports and 36% on non-standard ports. This was caused due to several tests where the ratio on non-standard download ports was below 10%. In these cases, we believe that it may be due to momentary errors and not due to intentional interference.

We can only conclude that uploads on non-standard ports had any discrepancies, and therefore believe that no actual throttling was made.

2.2.3 Internet Zahav / Smile012
Internet Zahav’s results were the hardest to obtain. Nevertheless, we found strong indication of traffic shaping. The amount of results omitted due to blocking of BitTorrent ports was material, and was sufficient to show that some P2P traffic throttling occurs. Moreover, the number of results show zero kilobytes as download speed indicate that some shaping or throttling may be practised during certain hours.

Our findings were that in standard port uploads, the average ratio of BitTorrent to TCP was 81%, and on non-standard ports it was 107%; aggregated ratios were 77% on standard ports and 103% on non-standard ports.  In downloads, we encountered similar results, providing an average BT/TCP ratio of 74% on standard ports and 118% on non-standard ports and an aggregate value of 90% on standard ports and 80% on non-standard ports.

These results indicate that throttling occurs only on standard ports, and on non-standard ports no throttling is inflicted on traffic. This may be due to either DPI or non-DPI interference.

2.2.4 Table:

ISP BT/TCP upload, Standard BT/TCP upload, non-standard BT/TCP download, standard BT/TCP download, non-standard
Netvision 69.99% (52%) 81.95% (60%) 58.61% (50%) 50% (27%)
Bezeqint 105% (104%) 69.17% (52%) 147% (137%) 130% (36%)
Zahav 81% (77%) 107% (103%) 74% (90%) 118% (80%)

Indication of low BT/TCP ratio shows DPI or throttling of TCP, differences between standard and non-standard ports show potential throttling based on ports.

3. Conclusions
Our findings are that at least 2 of the 3 major ISPs perform manipulation on traffic, and especially peer-to-peer traffic. We were able to show that deep packet inspection and P2P-caching is performed by at least one ISP and that another one probably operates some kind of preference on specific ports.

We believe that P2P-caching is the most troublesome of all activities and that it should be inspected by the regulatory authorities. Moreover, we believe that further research is required to show actual use of restricting technologies and the use of RST packets or other mechanisms. While we could not determine which technologies are being used, we believe that the use of such technologies could be used to block competition, free-speech and allow wiretapping of voice over ip conversations. The use of preferring technologies should be regarded as restriction of access and be stopped.

46 thoughts on “P2P Bandwidth Throttling in Israel, Legal and Technological Aspects.

  1. In an conversation with a provider of a tool for DPI and and throttling, I was was told that three ISPs (I was not told which) have this tool, and at least two have it setup in their production environment.
    The reason the provider was careful on providing additional information was apparently NDA’s, but also the fear that if the mechanism used would be made public, there might be an attempt to circumvent it.

  2. Pingback: Anonymous
  3. what are the “standard ports” you guys used to check bittorrent on?

  4. The new trend of content download is direct downloads from storage providers such as rapidshare (http port 80).
    I know for sure (several tests) that netvision puts traffic limitations on http host providers too but it’s more difficult to check because the bandwidth limitation does not start right away but only after you have downloaded a certain amount of data.
    release\renew of your ip address fixes the problem for a period of time but you can’t use this method if you want to download stuff overnight…

  5. This amateur attempt at showing something conclusive is a sad joke. Next time, try some self-criticism before publishing another “research”.

  6. Anonymous,

    Thanks. If you could please elaborate more? As far as I know, this is the most conclusive research ever done here.

  7. Thank you for your impressive effort. This is an important milestone in restraining the Israeli ISPs, exposing dubious traffic throttling practices, creating public awareness and instigating proper net neutrality regulation.

    Next, I recommend testing eMule traffic, Usenet/Newsgroup downloads and downloads from premium hosting services (rapidshare.com, megaupload.com etc.). Such activities also seem to be suffering from similar interference. An expansion of the tested ISP group is also in order – there are only 7 or 8 commercial ISPs in Israel (if memory serves) – why not test them all and give the Israeli consumer a well rounded picture?

    The anonymous commenter is very clearly acting on behalf of one of the transgressing ISPs, as are the authors of most of the negative comments to the ynet article. Please do not let such petty annoyances discourage you from continuing your important work.

  8. ISPs would be right to block P2P. It was designed for the purpose of piracy and is overwhelmingly used for that purpose. It also abuses the network by attempting to seize priority over legitimate trafffic and by creating a server on the ISP’s network without permission or compensation.

  9. Another anonymous coward here. Your research might be the most conclusive one ever done here indeed. But it’s still a sad joke.

    > we were unable to review the Switzerland logs
    Too bad! Next time, coordinate your volunteers better.

    > In these cases, we believe that it may be due to momentary errors and not due to intentional interference
    A grave error. You do not cherry-pick your samples and do not filter out ones you believe are invalid. We don’t know, and you cannot guarantee, that you have filtered out all the invalid ones, and only the invalid ones. You could state up front what constitutes a valid data point, and provide your reasons; then filter out all which is not valid.

    > we found out that another user is seeding our torrent
    You should have been allowing only IPs you know, those that belong to the participants of the study, to download your content. This way no bona fide user could ever seed any of your files. Any additional seeder would be a 100% reliable evidence of an ISP caching your traffic.

    > average BT/TCP ratio was 147%
    ISPs are not expected to prefer P2P traffic over other traffic. You better come up with a plausible explanation of this figure. Otherwise you have no choice but admit that it is meaningless, due to momentary errors or whatever else. But then your other figures (52% or whatever) are meaningless too, due to the exact same reason.

    Now, where’s the control group? Have you tried your tests on a LAN where no ISP is involved? What is the average BT/TCP ratio on a LAN? Could it be 200%? 20%? What are we supposed to learn from your figures without any basis for comparison?

    In summary, this is not research, this is handwaving. I personally believe there’s traffic shaping and would like to see a rigorous study that proves or disproves my belief. Yours isn’t, and doesn’t. Sorry.

  10. What about the cellular internet? Cellcom, for example, modifies every web page you go to. They change the html itself and add ads, in. Case of wap, or a toolbar, in case of their iphone package. This can be done only through ‘wiretapping’

  11. Anonymous,
    Thanks for the comments, while I do not agree with you, they were taken into consideration when performing the inspection, and when we will start the material inspection, with more participants, we will develop our own tool for it. I’d be more than glad if you’ll assist here.

    You do not cherry-pick your samples and do not filter out ones you believe are invalid. We don’t know, and you cannot guarantee, that you have filtered out all the invalid ones, and only the invalid ones.
    I filtered out only onew result for BezeqInt, which had a real discrepency and several for 012, which had zero traffic and cannot be calculated. We ommited them as they are invalid, not incoherent.

    Any additional seeder would be a 100% reliable evidence of an ISP caching your traffic.

    I think that this is what we obtained. The problem is that the seeder popped up after we only transferred the torrents via private mechanisms. This means that there was DPI.

    You better come up with a plausible explanation of this figure. Otherwise you have no choice but admit that it is meaningless, due to momentary errors or whatever else. But then your other figures (52% or whatever) are meaningless too, due to the exact same reason.
    Well, unlike the other ISPs, the STDEV of Bezeqint was too problematic to conclude anything. The results also show that standard TCP ports are deferred on BT ports, but preferred on non BT-Ports. This means that either Bezeqint blocks TCP on BT ports and BT on non-BT ports. But it was inconclusive, again.

    Now, where’s the control group?
    I cannot have a control group if I cannot access Glasnost without an ISP.

  12. 012 is a horrible ISP.
    I switched to Netvision month ago , no problems since that.
    Cannot complain about traffic blocking or manipulating or whatever. I think they are doing some QOS things, because Skype is working fine no matter how much im downloading or uploading at the time.

  13. Oh come on. If you can’t “coordinate your volunteers” try, try, again.

    Your “conclusions” have no basis in science, are not repeatable, contain no packet traces, etc.

    “We were told it’s a netvision caching server”? Seriously?

    I hereby am telling you this article does not meet the standards of scientific study. Specifically you don’t provide information to make it repeatable or reproduceable. You suck.

    E

  14. Ehud,

    Thank you for your scientific comments. I suggest you try to coordinate volunteers and to open their computers and transfer files, and do it all over for 2 months.

    All our conclusions contain full and frank result pages from Glasnost and may be reproducible unless the ISPs changed their policy on caching. We conducted dozens of tests, and used them to conclude.

    As for “we were told”: the IP resides inside Netvision, the lookup shows that. Moreover, the use of another client, the fact that it cached our torrent without our consent and the speeds obtained all indicate that it is a caching server, alongside other indications from other sources which we revealed here.

  15. This research confirms what has been known for quite some time now. Internet Zahav is heavily throttling-down P2P traffic, and lying through their teeth about it. The minute I switched from their service to Bezeq int. I saw 10 times increase in P2P throughput. Israeli forums are filled with similar stories.

    Judging from the comments, Israeli ISPs find it easier to wage anonymous flame war and publish gross denials, rather than actually providing good service to their customers and being transparent about it.

  16. As a scientist, I am impressed with the methodological expertise of this basic research into Israel ‘monopoly’ manipulation and unlawful shaping, packet interference, caching, and throttling. The ‘review of the literature’ was very helpful and helps me understand some of the extreme irregularities , as I just switched ISP’s 2 weeks ago. I am also concerned about the security issues involved as the shaping and caching (my field is NOT computer science) could affect my e-mail security as it sometimes involves sensitive material, confidential communications from private and governmental agencies. We certainly cannot rule out tampering of varying degrees by all providers and the few corporate ‘classified’ anti-trust violations. Further study is needed, but not for IMMEDIATE GOVERNMENT CEASE & DESIST Orders to be served to the 3 corporations which appear to control all of Israel’s access to bandwidth. In fact, I lost a $20,000 job because I could not download or upload some large private files via P2P in a timely manner. We pay too much to have unlawful predatory practices continue.The materials were not even Copyrighted yet, in my example.
    If successful, we should call for investigation into Cell Phone Predatory Practices and its malicious intent if we demand customer SERVICE and removal of unordered services. It is an outrage!
    Good work, friends. Dr. GMK (Modi’in via Boston)

  17. Today 27.12.09 BezeqInt ISP start to block downloading torrents files. Anybody know what is a reason of this problem?

  18. I just got off of a help chat with Skype technical support which says that some Israeli ISPs started throttling / blocking P2P traffic last week which is affecting SkypeOut calls.

    Have any of you noticed this or experienced similar problems?

    Max

    Initial Question/Comment: Other
    7:50:03 PM System says
    Thank you for contacting Skype Customer Support!
    7:50:03 PM System says
    Adam Z. – Skype Support has joined this session!
    7:50:03 PM System says
    Connected with Adam Z. – Skype Support
    7:50:06 PM sailorbob says
    Hello
    7:50:13 PM Adam Z. – Skype Support says
    Hello! As one of our most valued users, welcome to Skype Live Support! My name is Adam. How may I help you?
    7:50:14 PM sailorbob says
    I can’t make any Skypeout calls
    7:50:34 PM Adam Z. – Skype Support says
    I understand. Please give me a moment to check our logs.
    7:50:46 PM sailorbob says
    I can make regular skype calls to other skype users, but not to regular phone numbers
    7:51:13 PM sailorbob says
    These problems started around the end of last week
    7:52:18 PM Adam Z. – Skype Support says
    I understand, thank you for your patience.
    7:52:48 PM Adam Z. – Skype Support says
    Can you tell me if you are trying to make Skype calls from Israel?
    7:53:26 PM sailorbob says
    Yes. I have the international unlimited calling plan and I call both the USA and Israel, from Israel
    7:53:40 PM sailorbob says
    I have a 412 USA phone number
    7:53:53 PM Adam Z. – Skype Support says
    I see, thank you for confirming this.
    7:54:08 PM Adam Z. – Skype Support says
    Unfortunately it has been brought to our attention that our services have been blocked by certain ISPs in Israel.
    7:54:20 PM Adam Z. – Skype Support says
    Some Israeli ISPs limit P2P (peer2peer) usage on their network or try to completely block it.
    7:54:31 PM sailorbob says
    Which ISP’s and when did this start?
    7:55:14 PM sailorbob says
    I’ve been making calls for over a year without any problem. The problems just started last week.
    7:55:23 PM Adam Z. – Skype Support says
    We do not have a list of the affected providers yet, the problem started last week.
    7:55:48 PM Adam Z. – Skype Support says
    Yes, this confirms that the issue you are experiencing is related to the block.
    7:56:12 PM Adam Z. – Skype Support says
    We are sorry to say that there is very little Skype can do about this situation if the ISP is throttling down or limiting P2P traffic. As Skype is based on P2P technology then this sort of limiting will impact the normal service.
    7:56:19 PM sailorbob says
    Has skype contacted any of the ISPs to try and resolve the problem?
    7:56:20 PM Adam Z. – Skype Support says
    I apologize for the inconvenience.
    7:57:06 PM Adam Z. – Skype Support says
    No, we have not yet been successful in contacting them, but we are investigating this problem and need to ask for your patience.
    7:57:08 PM sailorbob says
    Why would this affect SkypeOut calls but not regular computer to computer Skype calls?
    7:57:51 PM Adam Z. – Skype Support says
    This is most likely related to how SkypeOut calls are forwarded to the phone gateways.
    7:57:52 PM sailorbob says
    I just had a Skype video call with my Dad in the USA with no problem
    7:58:33 PM sailorbob says
    Do you have any idea how long this will take to resolve?
    7:58:38 PM Adam Z. – Skype Support says
    Unfortunately we cannot provide more information regarding this issue as we do not have it yet.
    7:59:18 PM Adam Z. – Skype Support says
    Unfortunately not, but it is a top priority issue and we are investigating it as we speak.
    7:59:42 PM Adam Z. – Skype Support says
    If you would like to have any of your paid services refunded while this issue is resolved, please let me know.
    7:59:54 PM sailorbob says
    I use Skype as my primary phone, I don’t even own another phone line – I can’t make any calls to anyone right now
    8:00:23 PM sailorbob says
    Is there some way for me to be notified once this issue is resolved?
    8:00:59 PM Adam Z. – Skype Support says
    I understand your concern. One moment, I will check this for you.
    8:02:59 PM Adam Z. – Skype Support says
    Unfortunately there is no system established to notify you of the status this issue. We advise you to contact us again in a day or so or try to place a test call.
    8:04:11 PM sailorbob says
    OK, thanks.

  19. I can make calls to Skype members but I cannot make Skype out calls in the evenings.I have 012 as my provider.Obviously this is completely unacceptable and when I phoned them today they said it was a ” known problem ” that they were going to fix in a couple of days.If they are purposely blocking Skype and perhaps other sites and services then I would immediately migrate to a different provider.Do other people have this problem with 012 ? Is anyone hooked up to a provider who actually provides what customers want and need,if so please post the name so that we can vote with out feet,should Skype be subject to any kind of purposefull strangulation!!

  20. It looks like skype had changed their protocol configuration and that is the reason for the problem.

    I know that Israeli ISPs are trying to contact skype to work with them and they do not cooperate at all.

  21. 012.net.il. utorrent Look.at trackers.If It says “connection closed by peer”, that is a sign that ISP has blocked the download. In my case Smile 012.net.il

Comments are closed.