I think George's problems on Gabble tubes are this race: scenario: contact1 offers a tube to contact2:
      - contact2 connects
      - contact2 ask contact1's caps
      - contact1 receives contact2's presence
      - contact1 offer a tube to contact2
      - contact2 accept the tube
      - local application on contact2 computer connects on the tube
      - contact2 still didn't received caps from contact1
      - contact2 is looking for the right resource on contact1 to send bytestream initiation, which is the resource which has the tube capabilities (maybe it should just be the resource which offered the tube)
      - contact2 is confused: no tube capabilities on contact1's resources
      - contact2 closes the tube
      - contact2 receives contact1's caps, eventually

This is in src/tube-stream.c start_stream_initiation() line 514.

Possible solution:
1. either delay accepting the tube when we don't have the caps from the offerer (weird solution to me)
2. or remember the resource which offered the tube and send SI to that resource

The second solution looks better to me because even if the caps are received instantly everywhere, I think the tube code is wrong: we should not send the SI to *any* resource which has the right caps but to the resource which offer the tube. If contact1 has several gabble running on different computers with different resources (all with the tube caps), it will randomly work/don't work with the current implementation, depending which resource it chooses.