One the points that I left unsaid, however, is that there may be many, many reasons -- both technically and business-wise -- why an ISP would want to port- filter, or for a better generalization, "suppress" some traffic. For instance, blocking p2p traffic, or a known worm, whatever. And there very likely may be busine$$ reasons, as well. A corrollary: Is it a denial of service to suppress (dampen) a BGP route when it flaps excessively? Or perhaps an bloack-hole a RBL entry? Most would say not, certainly depending on the reason (self- and Internt-preservation and stability), but certainly someone could arguably make a federal case out of it (levity implied) or similar suppresssions or blocking of traffic. VoIP brings these issues to the forefront. In any event, it's going to be interesting to see how this evolves. - ferg -- "Church, Chuck" <cchurch@netcogov.com> wrote: Those are good points. Someone last week mentioned what I thought was a great list of priorities for an ISP: 1. Keep the network running 2. Remove those violating policies 3. Route packets (or something along those lines) A 30/50/90 kbps unicast stream isn't going to affect #1. I don't think any policies involved in #2 would cover a VoIP service either. That should leave #3 as the default for this traffic. I can picture a DDOS where infected Windows machines could send bogus SIP traffic to Vonage servers; in this case temporary blocking might be needed/justified. But until that happens, blocking SIP is just wrong. Another thing for an ISP considering blocking VoIP is the fact that you're cutting off people's access to 911. That alone has got to have some tough legal ramifications. I can tell you that if my ISP started blocking my Vonage, my next cell phone call would be my attorney... Chuck Church Lead Design Engineer CCIE #8776, MCNE, MCSE Netco Government Services - Design & Implementation Team 1210 N. Parker Rd. Greenville, SC 29609 Home office: 864-335-9473 Cell: 703-819-3495 cchurch@netcogov.com PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x4371A48D -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg@netzero.net or fergdawg@sbcglobal.net