| Summary: | sends session-accept before the Tp user has responded | ||
|---|---|---|---|
| Product: | Telepathy | Reporter: | Simon McVittie <smcv> |
| Component: | fargo | Assignee: | Simon McVittie <smcv> |
| Status: | RESOLVED FIXED | QA Contact: | David Laban <david.laban> |
| Severity: | normal | ||
| Priority: | high | Keywords: | patch |
| Version: | git master | ||
| Hardware: | Other | ||
| OS: | All | ||
| URL: | http://git.collabora.co.uk/?p=user/smcv/telepathy-fargo.git;a=shortlog;h=refs/heads/acceptance | ||
| Whiteboard: | milestone4.7 est=7h | ||
| i915 platform: | i915 features: | ||
| Bug Depends on: | 26413 | ||
| Bug Blocks: | |||
7h? It's just a matter of re-ordering events, but they're quite subtle events and will need careful testing. smcv/acceptance has patches. Fixed in git The reverse of the originally-reported problem has been reinstated as a hackish way to get calls working again. ... or, in fact, not, because Sjoerd is ninja. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
# FIXME: should Fargo really accept the call before the XMPP client # has accepted the call? # In this case, it's the only way to get the codecs out of # telepathy so we can send session-initiate, so yes. EventPattern('dbus-method-call', handled=False, interface=cs.CHANNEL_IFACE_GROUP, method='AddMembers', path=chan.object_path, args=[[conn.self_handle], '']), 14:00 < smcv> alsuren: er, is it really necessary to call AddMembers before doing all the codec wibbling? 14:00 < smcv> alsuren: I would expect that that ought to work even while the local user is still in local-pending state 14:07 < alsuren> smcv: I was going by the description on: file:///usr/share/gtk-doc/html/telepathy-spec/org.freedesktop.Telepathy.Channel.Type.StreamedMedia.html. I guess you could set the stream direction yourself before you accept the call 14:08 < alsuren> not tried it though 14:08 < smcv> mm 14:08 < smcv> I should try that 14:09 < smcv> it doesn't look very good for a user of this gateway if Fargo claims the XMPP user has answered the call, before they actually have 14:09 < smcv> the SIP user will potentially be going "hello? hello? you there?" for several seconds