StreamHandler in channel.py picks a resource arbitrarily, in __init__.
I think the real fix would involve picking the resource for the entire channel - it would make no sense to have two streams in the same channel go to different resources.
Related to #26218 - as a minimum, we need to pick a resource with appropriate caps, and do so for the whole channel.
It would be nice if, when presented with more than one resource (e.g. Empathy and N900), we'd also pick the most available, but I think doing the minimum quoted above, then downgrading this bug to minor/low, would also be acceptable for now.
If we don't know *any* resources yet, this can result in failure:
INFO:telepathy.bases:Listening to Channel /org/freedesktop/Telepathy/Connection/sofiasip/sip/_3362967_40eu_2evoxalot_2ecom/MediaChannel1
ERROR:dbus.connection:Exception in handler for D-Bus signal:
Traceback (most recent call last):
File "/usr/lib/pymodules/python2.5/dbus/connection.py", line 214, in maybe_handle_message
File "/home/smcv/Collabora/telepathy/fargo/telepathy_fargo/connection.py", line 161, in NewChannels
File "/home/smcv/Collabora/telepathy/fargo/telepathy_fargo/connection.py", line 173, in _new_channel
channel = factory(weakref.proxy(self), object_path, properties)
File "/home/smcv/Collabora/telepathy/fargo/telepathy_fargo/channel.py", line 75, in __init__
self.client_jid = self.conn.client_resources.keys()
IndexError: list index out of range
(In reply to comment #2)
> If we don't know *any* resources yet, this can result in failure:
I've worked out how this can happen: when registering a new user, we connect to SIP on their behalf before receiving presence from them. If they are called before we have completed the presence exchange, we lose.
I think I'll clone that as a separate bug; we can do the rest later, but the part where calls actually fail should be fixed soon.
*** Bug 26218 has been marked as a duplicate of this bug. ***