|Summary:||should pick resources more intelligently|
|Product:||Telepathy||Reporter:||Simon McVittie <smcv>|
|Component:||fargo||Assignee:||David Laban <david.laban>|
|Status:||NEW ---||QA Contact:||Simon McVittie <smcv>|
|i915 platform:||i915 features:|
|Bug Depends on:||26218, 26268|
Description Simon McVittie 2010-01-25 08:56:57 UTC
StreamHandler in channel.py picks a resource arbitrarily, in __init__.
Comment 1 Simon McVittie 2010-01-25 09:44:57 UTC
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.
Comment 2 Simon McVittie 2010-01-26 10:43:24 UTC
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 self._handler(*args, **kwargs) File "/home/smcv/Collabora/telepathy/fargo/telepathy_fargo/connection.py", line 161, in NewChannels self._new_channel(object_path, properties) 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
Comment 3 Simon McVittie 2010-01-27 05:06:39 UTC
(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.