Pause on VOIP

BitComet BitComet Feature Requests
1

Is there a feature to pause or stop downloads on an incoming VOIP call until the call is finished?

Would it be a Bitcomet feature or other program?

I am using Bitcomet 1.31 on cable broadband with a separate modem and router.

Router is using DD-WRT v24-sp2 (10/30/08) micro.

The MagicJack Plus is ethernet cabled to the router and powered from the wall and RJ-11 to all phones.

There is one desktop wired to router and the laptop wireless to router. Both are Windows XP home.

The Bitcomet is on wireless laptop.

Windows firewall and Avira antivirus on both PC’s.

Thanks in advance.

2

Bittorrent has no “pause” action built in to it, and that isn’t really possible because there is no central source. Your download comes from many people all over the world, and there’s no way to get word out to all of them at once.

You can simply suspend BitComet’s active tasks, but all those people out there are going to continue to try to send to you for half an hour or more until they give up on you. Many of them may have choked you for much longer, then tried you later, so you could continue to have packets sent to you for a lot longer than that.

When you suspend, you simply stop receiving or acknowledging packets. Eventually the most active senders give up on you.

To the extent that this crowds your bandwidth, there’s nothing to be done about it for the short term of a normal phone call – a couple of minutes. As time goes on the situation improves, but as time goes on most calls hang up, having said what they wanted to say.

If you anticipate an important call far in advance, then I suggest you arbitrarily limit your bandwidth in both directions to about half of tested capacity. That should leave enough for a phone call to use without compromising quality – that is, instead of trying to slow BitComet, never let it get up near full speed in the first place. Obviously you don’t want to do that all the time, though.

3

Well, usually TriplePlay equipments (the ones which offer data, voice and video on the same device) use separate VLANs (virtual LANs) for voice and data and possible even a third one for video.

This happens precisely for the purpose of tagging data and voice with different VLAN ID and inside the VLAN ID with different QoS (quality of service) classes.

QoS is a mechanism for prioritizing packets/frames based on their Layer 2 or Layer 3 Cos (class of service) value, inside the frame tag or in the DSCP field of the IP header. It is a very intricate subject in iteslf but the end result should be that frames/packets with higher priority (i.e. voice and video) should be given priority by your modem/router device over traffic on the data VLAN. This happens transparently and without any configuration from your part (all should be already done by your ISP when they install you the device).

Now, if you’re just using VoIP calls over a simple data VLAN like it seems to be your case (as in Skype or messenger calls over an Internet connection which provides data services) all your traffic goes on the same VLAN as the rest of the data so you don’t benefit from any traffic classification from your router.

In this case your VoIP traffic doesn’t have any “emergency lane” to take so all you can do is to free up as much bandwidth as you can and hope for the best, as kluelos suggests.

@ kluelos: Actually, I think that by suspending the active tasks BC accomplishes two things not just one:

It stops all outgoing traffic, which frees up the uplink immediately;

It either sends a TCP ACK with window size 0 on each TCP connection (which effectively will grind to a halt the incomming traffic on each connection from any remote host trasmitting towards the local client) or a FIN/RST packet which will close the TCP connection. I haven’t actually sniffed BC traffic to analyze it and see if what I mention at the second point happens for sure, but I’ve empirically seen that actually the download bandwidth is becoming virtually instantly available for other applications upon suspending active connections, which suggests such behavior. Besides, it would be plainly stupid to just drop incomming traffic **after **it passes and burdens your whole LAN up to your PC, without notifying the remote hosts not to bother sending anymore when the means to do it, exist.

I don’t argue that the former peers of the swarms for your running torrents may still try to connect to you for about the half hour you mention, but those will merely be TCP SYN packets which are very small and which won’t find any echo on your side, so there won’t be any real bothering traffic going on since there are no connections being set up. The only traffic that you really won’t be able to do anything about will be the UDP traffic, but in terms of bandwidth that’s usually negligible on today’s connections.

4

Yes but that’s not a suspension, Wiz. That’s a stop.

The difference is that you can’t pick up those connections where you left off, because you closed them and told the other end to go away. So instead of resuming, you have to establish all new connections. Then too, simply closing a connection in bittorent doesn’t mean that the former connectee isn’t going to try to connect to you again.

As far as I know, the “suspend” action does not close out those connections – if you come back a short period of time later, they haven’t all been closed out and told to go away. This makes me think that the suspend function just stops acknowledging rather than sending FIN/RST’s. If you can find out for sure though, I’d like to know.

5

I use magic jack too and had the same problem. I tried using QoS, but it crippled my torrents speed even when viop wasn’t used. I ended up forwarding the ports that magicjack used in my router and that helped a lot, but you’ll still have issues if your calls have to fight for bandwidth with hundreds of bittorrent connections.