[NCLUG] Bandwidth throttling when SIP connection is in progress.

[Scott Scriven]

Are your voip calls working now?  Silky smooth, with no noticable 
latency or jitter?

If so, then glad to be of service.  It doesn't matter to me if 
you use my suggestions, but I can say at least it works well for 
me -- it actually improved all my traffic, not just voip.

* John Gilmore <jgilmore at glycou.com> wrote:
> I can't classify packets nearly as easily b/c asterisk is 
> running on the firewall. I've found no way to classify the SIP 
> packets except to say "they're UDP".

You should be able to match based on port number and/or the TOS 
field, especially if you set a TOS explicitly in asterisk.

> couldn't find a simple way to rewrite it to regulate incoming 
> and outgoing easily.

You realize that your router has no direct control over incoming 
traffic, right?

By the time data gets to your router, any damage which is going 
to happen has already happened.  The only way it can affect 
incoming traffic is by carefully controlling outgoing traffic.

If you have a consumer class broadband connection, it's probably 
pointless to attempt any direct throttling for incoming data.  
Just pay careful attention to what you send, and the incoming 
packets will take care of themselves.

> I'm not even sure what my upload/download speeds actually are.

Whether you measure directly or ask your ISP, it takes just a few 
minutes to get that data...

> Any solution which *always* regulated packets will have to be 
> adjusted fairly precisely to actual network capacity, or risk 
> significantly slower downloads ...

Unless you're talking about bittorrent, download speeds and 
upload speeds are pretty independent.  Regular non-p2p downloads 
only need enough upstream bandwidth to send ACKs, so you could 
set your upload limit to almost anything and download just fine.

> And so that's why I decided not to use your script. ...

I don't think I understand.  It sounds like you don't believe it 
works, and don't want to spend a few minutes to test it.  I can 
relate to the first part since I'm a pretty skeptical person 
myself, but I don't really get the rest.  It seems like it'd take 
more time to reply than to find out empirically whether it works, 
much less create a custom alternative.

But that's okay.  I don't need to understand, especially if 
you've got things working now.  :)


-- Scott