RE: [Telepathy] ANN: Telepathy-SofiaSIP
Hi, A note about building the source. You'll need the telepathy-glib helper library that can be built and installed from the recent telepathy-gabble source tree. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, March 09, 2007 11:41 AM To: telepathy@lists.freedesktop.org Subject: [Telepathy] ANN: Telepathy-SofiaSIP Hello, I'm happy to announce the long-awaited release of Telepathy-SofiaSIP, a Telepathy connection manager component adding support for IETF SIP protocol, into the free software world. As can be guessed from the name, it's a thin layer wiring the Sofia-SIP protocol stack (http://sofia-sip.sourceforge.net) into the Telepathy framework. The project is now hosted at SourceForge: http://sourceforge.net/projects/tp-sofiasip/ ; you can check out the source from the SourceForge's SVN repository. More updates will follow; hopefully, we'll get a proper project webpage soon. Enjoy Best regards, Mikhail ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
[Telepathy] Display names from SIP headers as aliases?
Hi, There has been a discussion about improving the Aliasing interface. I have a tangent interest here, in that I consider using the interface to expose display names for contacts, as sent and received with SIP protocol messages. Just as in RFC2822 messages, SIP addressing headers From: and To: may include a human-friendly name along with the address URI. It would be nice to extract that name from incoming messages and make it available to the API clients, e.g. to display in a chat window, or as the initial name suggestion for a new address book entry (OTOH that will raise more security concerns than displaying a bare URI). Also, providing our own human-friendly name is an additional nicety. If the Aliasing interface is used for that, it may necessitate caching display names along with contact handles for the lifetime of a Connection. That's the only implementation concern I have with the current API. Your thoughts are welcome, Mikhail Zabaluev, Nokia Multimedia ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Display names from SIP headers as aliases?
Hi, -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext Simon McVittie Sent: Friday, May 11, 2007 4:11 PM To: telepathy@lists.freedesktop.org Subject: Re: [Telepathy] Display names from SIP headers as aliases? as sent and received with SIP protocol messages. Just as in RFC2822 messages, SIP addressing headers From: and To: may include a human-friendly name along with the address URI. Is this commonly done by other SIP clients, and do other SIP clients usually fill it in with something useful? If so, then this sounds like a nice feature. Yes, it's not imposible and I've seen it done. If the Aliasing interface is used for that, it may necessitate caching display names along with contact handles for the lifetime of a Connection. That's the only implementation concern I have with the current API. The display name should be cached as qdata on the contact handle - that's what we do in Gabble. This means if the contact handle loses all its references (so clients are no longer able to query its alias), then the display name is freed too. Thank you, sounds like it's very cheap to add it. ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
[Telepathy] ANN: telepathy-sofiasip 0.3.17
Hi, I'm glad to announce (after a few missed opportunities on previous releases) that telepathy-sofiasip version 0.3.17 has been released. Telepathy-SofiaSIP is a connection manager component implementing SIP protocol support with the help of Sofia-SIP stack. This version has minor behavioral changes that might be interesting to Telepathy clients. New in this release: * Modified the channel list destruction sequence to avoid crashing. * Emit MembersChanged with reason _NO_ANSWER when an outgoing call times out. * Set the peer as the actor in MembersChanged emitted on the peer's error response. * Reuse TP_CHANNEL_GROUP_CHANGE_REASON_BANNED as the indication of a call rejected due to not having proper auth credentials. * A lot of memory leak fixes. * Code cleanups. Enjoy, Mikhail Zabaluev, Nokia Multimedia ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Media API redesign for SIP SOA and ICE
Hi Olivier, It's my understanding, too, that the proposed changes are not for short-term modification of Farsight. See my answers below. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext Olivier Crête Sent: Tuesday, June 12, 2007 11:10 PM To: telepathy@lists.freedesktop.org Subject: Re: [Telepathy] Media API redesign for SIP SOA and ICE - There is no good way to change the effective set of codecs and effective transport addresses all at once for a stream, which is required by SOA specification on session updates. - Similarly, there is no good way to roll back the stream state if an update offer gets rejected by local or remote party. Do you know if there is any requirement for the stream to keep its RTP properties when the candidates is changes? (ie, can't we just create a completely new stream?). There is no strict prohibition against that, however: 1) It's better for call stability when only one side changes ports at a time. 2) We'd have to open new sockets, create a new set of codec pipelines duplicating the old one in most cases, deal with shared access to the media sinks, all things consuming resources and failure-prone. 3) Multiplication of streams complicates things for the client, unless we somehow hide new streams under negotiation from the media channel API clients. - No clear way to implement forking with several provisional responses arriving from different endpoints, each potentially carrying an SDP answer. Until a 200 response arrives, the implementation cannot assume which session will finally be accepted, but it must at least respond to incoming ICE checks for every session. My reading of the SDP Offer-Answer stuff was that there could be a single negotiation going on at one time. A SOA session is a per-dialog thing, and an outgoing call leg constitutes a dialog for the caller. Same goes, IIRC, for ICE process which is always tied to one SOA session. As for the SIP provisional responses, can't you just create multiple streams with remote candidates but no remote codecs and set_sending to false (so the streams don't try to send anything). And maybe something to prevent them from actually receiving any data. That's possible, but see the points 2) and 3) above. -- Mikhail ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] When is their phone ringing (was: Groupinterface usage?)
Hi, -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext Simon McVittie Sent: Tuesday, July 24, 2007 5:20 AM To: telepathy@lists.freedesktop.org Subject: Re: [Telepathy] When is their phone ringing (was: Groupinterface usage?) I suppose one plausible mapping would be to avoid adding the remote user to remote-pending state until their phone is actually ringing (so they're not in any of the membership lists until then). I think it makes more sense to put them in remote-pending as soon as we attempt to call them, though. I agree, the handle that the client has added can't be nowhere. -- Mikhail ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] some questions for telepathy spec
Hi, From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext Liangjing Zhao Sent: Monday, August 20, 2007 9:35 AM To: telepathy@lists.freedesktop.org Subject: [Telepathy] some questions for telepathy spec However, after I read the spec of telepathy http://telepathy.freedesktop.org/spec.html , I have few questions: 1. Via the methods of org.freedesktop.Telepathy.Channel.Type.Text interface, client can send and receive text message with contact. But how can I identify the encode of the messages? should I read this encode information from the channel properties? On the Telepathy side, message text and other user-readable data are considered plain text in UTF-8. 2. As we know, some protocol (SIP/SIMPLE) provides a feature that the text chatting (send / receive text message) happens in a session. Under telepathy framework, how the session can be identified ? Or currently, telepathy can not support this feature ? A chat session is represented by a channel object implementing org.freedesktop.Telepathy.Channel.Type.Text. Best regards, Mikhail ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Any sample code of using telepathy-sofiasip
Hi, From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext Tan Miaoqing Sent: Friday, November 02, 2007 4:39 PM To: telepathy@lists.freedesktop.org Subject: [Telepathy] Any sample code of using telepathy-sofiasip I am new to telepathy-sofiasip. Can anybody tell me if there is a good sample to show how to use telepathy-sofiasip? You can try looking into the SVN trunk of Empathy; it's a GUI for the Telepathy framework and it's been getting some VoIP features. Using connections and channels provided by telepathy-sofiasip should be the same as using any other Telepathy connection manager, except telepathy-sofiasip has a specific set of configuration parameters which you can look up in the sofiasip.manager file (generated as part of the build process). Look at the source in src/sip-connection-manager.c for more detailed information as to their purpose and default values. Yes, in its source package, there is a tests folder which contains some python sample code, but they are not enough. Very true. In fact, we would appreciate it very much if somebody contributes more extensive tests, e.g. to cover various call cases. Best regards, Mikhail Zabaluev, Nokia Multimedia, Helsinki ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Secure communications with Telepathy
Hi, -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext Marco Barisione Sent: Tuesday, November 27, 2007 4:32 PM To: Telepathy Subject: [Telepathy] Secure communications with Telepathy We are working on SSL in gibber and now we need a way to send/receive certificates and to send the private key to the cm. At the moment, my only idea is: - The user certificate is passed as a connection parameter to RequestConnection(). - When the connection is established with the server (of course not in salut), the cm emits CertificateReceived(handle, cert_type, cert) with handle set to 0. The client can verify the certificate and drop the connection if something is wrong. - For end-to-end encryption, the cm emits CertificateReceived() when beginning a communication with a peer with the handle of the peer as first argument. The actual verification of the certificate (maybe with user input) is left to the client. This solution has a number of problems: - How should I pass the private key to the cm? Is it a problem to pass it on dbus (it could be easily sniffed using dbus-monitor)? If somebody can attach to your session bus, they probably can just as well read your private keys. - What to do if I don't have access to the private key (e.g. smart card readers)? - In the case of a connection to a server I need to pause the connection process until the client has verified the server's certificate, to avoid sending the password to an untrusted server. - We need a ListSupportedCertificates() method to know the supported certificate types: X.509, PGP, etc. Is it some interface not currently in the spec? Any better idea? Suggestions? We really need some generic security interface on channels. I think that in order to be flexible and cover the use cases already known (e.g. SIP request authentication, end-to-end encryption), it should unify text-based authentication and certificate exchange mechanisms. Best regards, Mikhail ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
[Telepathy] Rich presence
Hi, I'd like to have a discussion on extended presence support in Telepathy. In the current spec, there is a freeform map of presence parameters to arbitrary values, and it's not specified what these parameters and values might in principle carry, or will there be some parameter names with a particular meaning commonly interpreted by Telepathy clients. In order to support things like geospatial or civic location as part of contact's presence information, I think we ought to have some common naming conventions and/or data types for corresponding parameters. Specifially in case of geolocation, this is not helped by the fact that presence information is represented differently in various network protocols (e.g. PIDF-LO in SIP and XEP-0080 in XMPP), the GeoClue framework will have its own representation, and all of these except PIDF-LO are really naïve in what kinds of location they can represent (most settle for a GPS-derived latitude-longitude-accuracy tuple, forgetting to specify such trivial matters as the reference geoid). Any ideas? -- Mikhail Zabaluev, Nokia Multimedia ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Rich presence
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 04, 2007 4:51 PM To: telepathy@lists.freedesktop.org Subject: [Telepathy] Rich presence I'd like to have a discussion on extended presence support in Telepathy. In the current spec, there is a freeform map of presence parameters to arbitrary values, and it's not specified what these parameters and values might in principle carry, or will there be some parameter names with a particular meaning commonly interpreted by Telepathy clients. In order to support things like geospatial or civic location as part of contact's presence information, I think we ought to have some common naming conventions and/or data types for corresponding parameters. Specifially in case of geolocation, this is not helped by the fact that presence information is represented differently in various network protocols (e.g. PIDF-LO in SIP and XEP-0080 in XMPP), the GeoClue framework will have its own representation, and all of these except PIDF-LO are really naïve in what kinds of location they can represent (most settle for a GPS-derived latitude-longitude-accuracy tuple, forgetting to specify such trivial matters as the reference geoid). Any ideas? To follow up, one idea is to get rid of the shapeless monster type in Presence in favor of type-specific presence interfaces. In addition to DBus typechecking, this will allow implementors to extend Telepathy by implementing their own presence types in the familiar DBus namespace. Best regards, Mikhail ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Rich presence
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext Dafydd Harries Sent: Wednesday, December 05, 2007 2:35 PM To: telepathy@lists.freedesktop.org Subject: Re: [Telepathy] Rich presence I was planning to restrict the API to using WGS 84 for geographical coordinates. This implies that clients and connection managers may need to do conversion in some cases. I think having a latitute/longitude in WGS 84 covers the majority of use cases. Further use cases are probably covered by having room/street/city/province/country etc. key/value pairs. I agree, it's good enough to cover most of implementations, (if you throw in altitude and horizontal/vertical accuracy). Now the question is, do we want it as special key names in the dictionary, or a specialized interface (or even GeoClue API infusion) will be a better approach. Best regards, Mikhail ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Rich presence
Hi, -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext Dafydd Harries Sent: Tuesday, December 04, 2007 7:05 PM To: telepathy@lists.freedesktop.org Subject: Re: [Telepathy] Rich presence Ar 04/12/2007 am 16:51, ysgrifennodd [EMAIL PROTECTED]: Hi, I'd like to have a discussion on extended presence support in Telepathy. In the current spec, there is a freeform map of presence parameters to arbitrary values, and it's not specified what these parameters and values might in principle carry, or will there be some parameter names with a particular meaning commonly interpreted by Telepathy clients. In order to support things like geospatial or civic location as part of contact's presence information, I think we ought to have some common naming conventions and/or data types for corresponding parameters. Specifially in case of geolocation, this is not helped by the fact that presence information is represented differently in various network protocols (e.g. PIDF-LO in SIP and XEP-0080 in XMPP), the GeoClue framework will have its own representation, and all of these except PIDF-LO are really naïve in what kinds of location they can represent (most settle for a GPS-derived latitude-longitude-accuracy tuple, forgetting to specify such trivial matters as the reference geoid). Any ideas? I've written a location interface loosely based on XEP 80 (dictionary with standardised key names). I'm not really familiar with PIDF-LO. PIDF-LO is an extension to PIDF, described in RFC 4119. Its usage for practical purposes (what do you want, it's IETF) is further clarified by this draft: http://tools.ietf.org/html/draft-ietf-geopriv-pdif-lo-profile It can express what XEP 80 does and more. There are interesting locations like arc bands and rectangles/prisms, which cannot be boiled down to a point-accuracy ellipsoid without losing information. Also, it takes care to specify units and the coordinate system, which go by silent assumption elsewhere. I also implemented the interface in Gabble. I'll try and put up a spec patch soon. Great, I'm looking forward to see it. BR, Mikhail ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Question in telepathy-glib DynamicHandleRepo
Hi, From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext Naveen Verma Sent: Monday, December 10, 2007 10:33 AM To: telepathy@lists.freedesktop.org Subject: [Telepathy] Question in telepathy-glib DynamicHandleRepo I am using telepathy-glib to write a connection manager. In telepathy-glib we have TpDynamicHandleRepo GObject to allocate/deallocate the handles dynamically. In the tp_dynamic_handle_repo_new(), we need to set TpDynamicHandleRepoNormalizeFunc function pointer. I did not understand the use of this function from the document.Is this function is to create a unique user id to map with a handle? Could anyone please help me to understand use of this function? Its purpose is to normalize a requested handle string accordingly to the backend protocol's normalization conventions for identifiers. For example, if your protocol says that user names are case insensitive, this function should probably convert the handle string to lowercase so that MyUser and myuser resolve to same handle. Hope this helps, Mikhail ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
[Telepathy] ANNOUNCE: telepathy-sofiasip 0.5.0
Hello, Telepathy-SofiaSIP 0.5.0 development release is now available from: http://sourceforge.net/project/showfiles.php?group_id=191149package_id=256956 This is the first release made from the 0.5 development branch. New in the release: * Moved the executable to libexecdir. * Added a manpage for telepathy-sofiasip. * Use the initial route set as means to specify the outbound proxy. * Fixes for call channel flags (sf.net bug #1840543). * Added optional support for coverage instrumentation. * Postpone session state handling until all local streams are ready. -- Mikhail Zabaluev, Nokia Devices ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Account and AccountManager objects
Hi, -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext Simon McVittie Sent: Tuesday, January 22, 2008 7:39 PM To: telepathy@lists.freedesktop.org Subject: [Telepathy] Account and AccountManager objects -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I think the first thing we need to think about for Mission Control is the concept of an account. This message is a bit of a brain-dump. Just what is an account? - - an independent identity - if I connect to XMPP as [EMAIL PROTECTED]/N810 and [EMAIL PROTECTED]/Laptop, I think we ought to think of that as one account - but if I connect to IRC as smcv on OFTC and smcv on Freenode, that's two accounts - accounts can have different aliases, avatars, presence, and even anonymity requirements - - a way to get at contacts - each of my accounts can have different contact lists - I want to only talk to each contact from the account(s) they're aware of - I might want to talk to a colleague via my and his work accounts (to discuss XMPP) or via my and his personal accounts (to suggest we go to the pub) - - something Mission Control can connect in response to environmental changes - e.g. internet tablets' auto-online - therefore we need to store the complete parameter set for each account - - not (currently) necessarily the same as a normalized ID (which is the thing you get when you inspect a contact handle) Instructive cases to think about: - - The canonical example is, as usual, Gabble. The 'account' parameter is conceptually an account (although you can be connected to the same account multiple times from one host, if you're insane - just set two different resources). The 'account' parameter is globally unique and is the same as the self-handle's normalized value - [EMAIL PROTECTED] - - telepathy-sofiasip: here the 'account' parameter is [EMAIL PROTECTED], but a normalized user ID is sip:[EMAIL PROTECTED] or tel:+441234678910. AIUI the self-handle normalizes to sip:[EMAIL PROTECTED] too. (Mikhail, Senko: would a sip: URI be accepted as 'account'?) Yes. Moreover, it's the preferred form, which will leave out any fuzzy heuristics. There's also a gorgeous idea to implement umbrella accounts, where one account in terms of UI would mean two or more connections managed by different CMs. The case in point is Gizmo XMPP/Sipphone SIP. Here, some form of a cascade connection manager would be necessary that presents a front end unifying disparate protocol connections and their handle namespaces. Best regards, Mikhail ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] straw man location API
Hi, -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext Simon McVittie Sent: Tuesday, January 29, 2008 4:09 PM To: telepathy@lists.freedesktop.org Subject: Re: [Telepathy] straw man location API -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 29 Jan 2008 at 15:42:37 +0200, [EMAIL PROTECTED] wrote: GeoClue have made an unwieldy API for it with rigid flat structures and bit flags, Win32 style :-/ There's nothing wrong with bitfield flags - Telepathy has lots of them. They're an efficient way to transfer, well, sets of flags. When flags designate which other fields of the structure have valid data, that's what I refer to as Win32-ness. It's a lot like doing variant types by hand, and it doesn't really win much compared to general D-Bus overhead. A matter of taste, probably. I don't like some of their API (human-readable strings over D-Bus? erm... are the backends expected to be localized?... and, as you say, their civic location structs are rather rigid) but it's better than inventing our own *again*. Have you brought up your concerns with the GeoClue people? I was going to, and I probably will soon. As for civic location strings, let's suppose for sanity sake that only the data source does any possible localization. It's probably the only way with most location databases of the day. I still maintain that unless GeoClue is so terrible that we consider it a complete dead-end (and IMO that's not true), the way forward is for people interested in Telepathy+geoloc to treat them as the Telepathy of geolocation and use their formats by reference; and if their formats are crap, help them to fix that before they freeze D-Bus API. I've briefly reviewed their new design proposal, and it looked like they design for a single daemon providing the device's location data. I should recheck, but I believe there are no data types defined for locations to pass around. There is also some minor ugliness in the D-Bus APIs, like passing three separate arrays of the same size where an array of structures would seem logical. -- Mikhail ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
[Telepathy] ANNOUNCE: telepathy-sofiasip 0.5.2
Hello, Telepathy-SofiaSIP development release 0.5.2 is available: http://sourceforge.net/project/showfiles.php?group_id=191149package_id=256956 New in this release: * Removed an assertion on unexpected session state, as a wider variety of session states can in fact occur during offer-answer processing. * Further offer-answer fortifications to prevent violations of RFC 3264 due to concurrent locally requested changes. -- Mikhail Zabaluev, Nokia Devices ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Account and AccountManager objects
Hi,
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
ext Simon McVittie
Sent: Tuesday, January 29, 2008 3:42 PM
To: telepathy@lists.freedesktop.org
Subject: Re: [Telepathy] Account and AccountManager objects
Account_Condition: s
A condition that might be required for an account to be available.
These may be any UTF-8 string, but they SHOULD be short
strings of ASCII
letters, digits, hyphen/minus characters and dots, starting
with a letter
or digit.
All conditions not containing a dot are reserved for the Telepathy
specification. Third-party conditions SHOULD be namespaced
by a reversed
domain name, e.g. com.example.vpn-enabled.head-office.
A string with certain conventions is good enough, but I think there are two
attributes to every condition that might be worthy to separate. One is the
condition type, that could tell a client that this condition is their domain.
Another is the unique tag as such (within the type namespace). For example,
{org.whatever.vpn, MyOfficeVPNAccount}.
It's similar to detailed GObject signals, or XML namespaces.
I think a (type, name) condition tuple could be more convenient than a
syntactic convention on the single ID string, that the clients would have to
parse in order to filter conditions interesting to them.
My two cents,
Mikhail
___
Telepathy mailing list
Telepathy@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Account conditions overengineered
Hi, -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext Alberto Mardegan Sent: Friday, February 08, 2008 10:36 AM Cc: telepathy@lists.freedesktop.org Subject: Re: [Telepathy] Account conditions overengineered I think this gives a good enough basis for conceivable automatic connectivity configurations. The clients can also implement arbitrary user-defined tags or groups with this mechanism, using a dedicated namespace. It's complete, I don't think it is; it's meant to retain some benefits of the original proposal: 1) flat structure; 2) relative human-friendliness. BTW, I think that Account_Condition_Alternative make sense only within tha namespace. That's my gut feeling, too. I think that the logic enum fairly complicates the work for the client and the deamon. If we think that NOT conditions are useful, then I would propose this: every account will have a list of rules, which are OR-ed (that is, the account will be able to connect only if at least one of them is met); every rule will consist of two arrays of ss (Account_Condition as you specified above), one for the conditions that must be met, and one (if we really need it) for the conditions that must not be met. This has the same descriptive power as what you proposed: it implements alternative conditions just by having more rules, so for example if your rule was: [ Condition(has_route, yes), Condition_Rule(essid, home, Alternative), Condition_Rule(essid, uncle, Alternative), Condition_Rule(connection, phone, Negative), ] it would result in two rules: #rule 1: [ # positive: [ has_route: yes, essid, home, ], # negative: [ connection: phone, ] ] #rule 2: [ # positive: [ has_route: yes, essid, uncle, ], # negative: [ connection: phone, ] ] Which has the disadvantage of taking some more memory, but the advantage of being sensibly simpler. I disagree: you expose the client to the science of expression forms; in the example above, it has to duplicate mandatory conditions in every term in the OR disjunction. Arbitrarily complex expressions are possible, which is problematic with UI representations. With the two-level structure, updates and notifications become either more complex, or less efficient. Given the fact that the use-cases for alternative conditions are going to be quite limited, I would see anything than a list-based approach to be too complicated. Then, I would also totally eliminate the negative conditions; this would cause a loss of expressive power, but I'm not even sure the clients are going to need it... I don't see the need either, I've added those only for completeness. The negatives are, in fact, not any harder to evaluate than mandatory rules, but the UI might have a problem here. Another thing to keep in mind is that these rules might also be specified in the .presets (and maybe also in the .manager) files, so the easier they are, the better it is. :-) That's easy: mandatory_conds and alternative_conds parameters (add blocking_conds if you feel like), each getting a flat list of condition IDs (BTW, we need to restrict the syntax of condition IDs if we think about storing them in .presets and GConf). In the latter proposal, we could combine them so that the conditions specified in the .manager and .presets files will be appended to every rule specified in the accounts; I'm wary about such a combination. Let's have the condition parameters override the presets, as do any other account parameters. Best regards, Mikhail ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Account conditions overengineered
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext Alberto Mardegan Sent: Friday, February 08, 2008 3:27 PM To: Telepathy Subject: Re: [Telepathy] Account conditions overengineered Ah, now I see that I didn't understand your proposal; so, you mean to have only one rule per account, consisting of a list of Account_Conditions and Account_Condition_Rules, right? An account (or a preset) would have a list of Account_Condition_Rules, which are combined into a logical expression. The account manager raises or drops Account_Conditions and manages connections accordingly to the accounts' rules. If so, then, you will not be able to express a condition like this: connect the account if (A and B) or (C and D), but since I cannot think of a single case where we might need similar conditions, I guess we can forget about it. Right. In the latter proposal, we could combine them so that the conditions specified in the .manager and .presets files will be appended to every rule specified in the accounts; I'm wary about such a combination. Let's have the condition parameters override the presets, as do any other account parameters. If the condition namespaces are the same, yes; but if some condition appears in the presets and not in the account, it should be taken into consideration, too. Yes, this requires more thinking; at least a use case could help. Best regards, Mikhail ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
[Telepathy] ANNOUNCE: telepathy-sofiasip 0.5.4
Hi, Telepathy-SofiaSIP development release 0.5.4 is now available: http://sourceforge.net/project/shownotes.php?release_id=576851group_id=191149 This release can be considered an interim stable checkpoint; expect more radical changes in subsequent releases of the 0.5 branch. New in this release: * Treat empty string parameters as unset. * Added connection parameter 'loose-routing' to allow disabling RFC 3261 compliant SIP routing headers for legacy behavior, as implemented in the 0.4 branch and earlier. * Serialize codec intersections. New in the preceding release 0.5.3: * More media session fixes and code cleanups. -- Mikhail Zabaluev, Nokia Devices ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Spec proposal: CallStates
Hi, Thanks, looks perfectly OK to me. Best regards, Mikhail -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext Simon McVittie Sent: Monday, February 18, 2008 9:18 PM To: telepathy@lists.freedesktop.org Subject: [Telepathy] Spec proposal: CallStates -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In response to requests from the authors of telepathy-snom and telepathy-sofiasip for call-state (ringing) notification, here's a proposed spec for call states: http://monkey.collabora.co.uk/tp-spec-smcv-callstates/ The use of a flags bitfield rather than just a boolean is so we can re-use it for any other call states that come along (e.g. call-waiting). An enum is unsuitable because SIP's 180 Ringing etc. are all optional, so it would be misleading to suggest a progression through a fixed sequence of states. Pre-rendered versions (direct links to the two interfaces I changed): http://people.collabora.co.uk/~smcv/callstate.html#org.freedesk top.Telepathy.Channel.Type.StreamedMedia http://people.collabora.co.uk/~smcv/callstate.html#org.freedesk top.Telepathy.Channel.Interface.CallState ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] telepathy-gabble: Arbitrary IQs, direct use of PEP?
Hi, -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext Eric Butler Sent: Thursday, February 28, 2008 7:15 AM To: Guillaume Desmottes Cc: Christian Hergert; telepathy@lists.freedesktop.org Subject: Re: [Telepathy] telepathy-gabble: Arbitrary IQs, direct use of PEP? Do you have an example of how I can do what I need without modifying gabble? Modify gabble to allow plugins implementing extensions? I'm interested in this kind of work because that's what we are going to do for Telepathy-SofiaSIP. Best regards, Mikhail ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
[Telepathy] ANNOUNCE: telepathy-sofiasip 0.5.7
Hi,
-Original Message-
From: ext Jan Oravec [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 09, 2008 4:40 PM
To: Zabaluev Mikhail (Nokia-D/Helsinki)
Cc: telepathy@lists.freedesktop.org
Subject: Re: [Telepathy] ANNOUNCE: telepathy-sofiasip 0.5.6
I am getting this error with 0.5.6 (while 0.5.5 compiles fine):
make[2]: Entering directory `/tmp/telepathy-sofiasip-0.5.6/tpsip'
make[2]: *** No rule to make target `signals-marshal.list', needed by
`signals-marshal.h'. Stop.
The problem is signals-marshal.list is not in ${srcdir} which is set to
current directory (tpsip).
Thanks, pushed the fix as release 0.5.7.
Best regards,
Mikhail
On Wed, 2008-04-09 at 16:04 +0300, [EMAIL PROTECTED] wrote:
Hello,
Telepathy-SofiaSIP development release 0.5.6 is available:
https://sourceforge.net/project/showfiles.php?group_id=191149p
ackage_id=256956
New in this release:
* Refactored NUA event handling to use detailed GObject signals.
* Reimplemented CallState and Hold interfaces as per
Telepathy spec 0.17.3.1.
* Use the new hold API in StreamHandler interface.
* Test suite fixes to run in Maemo scratchbox.
___
Telepathy mailing list
Telepathy@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/telepathy
[Telepathy] ANNOUNCE: telepathy-sofiasip 0.5.8
Hello, Telepathy-SofiaSIP development release 0.5.8 is available: http://sourceforge.net/project/showfiles.php?group_id=191149package_id=256956 New in this release: * Revamped behavior regarding Telepathy stream direction and pending send flags, to conform better to the specification and Gabble implementation. * Bugfixes in hold implementation. * On a stream error, close only the stream rather than terminating the whole session (sf.net bug #1944820). * Provide log divertion to a file given through the environment variable TPSIP_LOGFILE (sf.net FR #1944067). -- Mikhail Zabaluev, Nokia Devices ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
[Telepathy] ANNOUNCE: telepathy-sofiasip 0.5.10
Hello, Telepathy-SofiaSIP development release 0.5.10 is available: http://sourceforge.net/project/showfiles.php?group_id=191149package_id=256956 New in this release: * Implemented glare resolution in case of a 491 Request Pending response. * Implemented D-Bus properties for Channel and Group implementations. * Rewritten the parser for a:fmtp SDP attribute. Fixes fd.o bug #16405 New in release 0.5.9: * Avoid redundant pushes of remote codec lists to Telepathy. * Revamped test suite synced from Gabble. * Full support for RTCP stream components. * Use telepathy-glib 0.7.8 for Hold interface helpers * Make sure the call channel is always closed after a remote error response is received and signalled as peer member removal. * Fixed a regression in handling newly requested streams during an ongoing negotiation. * Fixed a race condition in updating pending send flags. -- Mikhail Zabaluev Maemo Software, Nokia Devices RD ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Uniqueness of objects
Hi, -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext Simon McVittie Sent: Tuesday, September 30, 2008 11:01 PM To: telepathy@lists.freedesktop.org Subject: [Telepathy] Uniqueness of objects Hmm... but thinking about it, even if we refcount handles in telepathy-glib, this doesn't help if telepathy-glib and telepathy-qt4 end up sharing a connection, since neither library will be willing to call into (= depend on) the other in order to update the shared handle cache :-( Any ideas? Don't do that, then? If any process happens to use two Telepathy client stacks at the same time, it's an architectural horror, isn't it? BR, Mikhail ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Uniqueness of objects
Hi, -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext Dafydd Harries Sent: Thursday, October 02, 2008 4:59 PM To: telepathy@lists.freedesktop.org Subject: Re: [Telepathy] Uniqueness of objects What's the problem with doing reference counting on the client side, and mapping the 0-1 refs boundary to HoldHandles and the 1-0 refs boundary to ReleaseHandles? That's certainly possible. There's only the problem of two Telepathy client stacks in one process using the same DBus connection unbeknownst to each other. Which is considered a freak circus for purposes of this thread. Best regards, Misha ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Uniqueness of objects
Hi, -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext Olli Salli Sent: Friday, October 03, 2008 1:12 PM To: telepathy@lists.freedesktop.org Subject: Re: [Telepathy] Uniqueness of objects Some wizardry certainly needs to be performed even inside TelepathyQt4 to prevent using multiple Connection objects associated with the same remote connection - namely, not keeping the reference counter inside a single Connection object, but share it between Connections using a (bus uuid, remote conn service name) - refcounter mapping. Can you simply protect the constructor and create Connections only through the ConnectionManager? Best regards, Misha ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] review: stream engine 'fs2-lib' branch
Hi, -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext Olivier Crête Sent: Tuesday, October 14, 2008 11:25 PM To: Dafydd Harries Cc: Telepathy Subject: Re: [Telepathy] review: stream engine 'fs2-lib' branch On Fri, 2008-10-10 at 16:06 +0100, Dafydd Harries wrote: -service_in_files = org.freedesktop.Telepathy.StreamEngine.service.in +service_in_files = org.maemo.Telepathy.StreamEngine.service.in Hmm, this seems like a slightly odd choice of name. Any other suggestions? The goal is to make it clear that the out-of-process handling is really a maemo-specific thing. Don't single us out :) Unless the standalone StreamEngine is now officially the dumping ground for whatever Maemo required, in contrast to a legitimate cross-platform option for a stand-alone IP streaming handler. Cheers, Mikhail ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
[Telepathy] ANNOUNCE: telepathy-sofiasip 0.5.11
Hello, Telepathy-SofiaSIP development release 0.5.11 is available: https://sourceforge.net/project/showfiles.php?group_id=191149package_id=256956 New in this release: * Migrated the source repository to Git. * Updated to telepathy spec 0.17.13. * Improved handle normalization. * Implemented the Aliasing interface for connections, returning a simplified rendering of remote SIP URIs. The alias for the self handle is now settable and transfers to the display name in the From: header. * The signal MembersChanged in call channels now follows protocol events more accurately. * Removed the hardcoded timeout for outgoing INVITE requests. * The final 200 response for an incoming MESSAGE now follows Telepathy acknowledgement for the message. * A Text channel is reopened if closed by the client while still having unacknowledged messages. * Depends on glib 2.16 or later. * Depends on libtelepathy-glib 0.7.17 or later. -- Mikhail Zabaluev Maemo Software, Nokia Devices RD ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Using SIP with Empathy on Ubuntu 8.10
Hi, -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext John Pye Sent: Friday, November 07, 2008 3:06 AM To: telepathy@lists.freedesktop.org Subject: [Telepathy] Using SIP with Empathy on Ubuntu 8.10 Hi all I am looking for some instructions on how to get Empathy working with SIP (specifically an Ekiga.net account) on my recently updated Ubuntu system. When I create an Ekiga account from within Empathy, I get the rather unhelpful message Network Error, and no information about what is wrong or how I can fix it. The username and password are correct, so I can't see what else to do. Any suggestions? Run telepathy-sofiasip manually with debugging information: export TPSIP_DEBUG=all export TPORT_LOG=1 TPSIP_PERSIST=1 /usr/lib/telepathy/telepathy-sofiasip Then run Empathy with the SIP account and look at the output. Hope this helps, Mikhail ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] AccountManager API?
Hi, -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext Murray Cumming Sent: Tuesday, November 25, 2008 7:32 PM To: Alberto Mardegan Cc: telepathy@lists.freedesktop.org Subject: Re: [Telepathy] AccountManager API? Do you know roughly when Mission Control 5 will be released? What version numbers are these beta versions of MC 5? In general, I don't believe it's possible for a first release to be finished. You need to make unstable releases to get feedback so you can make necessary fixes to API, so you can have confidence about declaring it stable later. That's what is happening currently, our versioning scheme is just a bit weird :) Best regards, Mikhail ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
[Telepathy] ANNOUNCE: telepathy-sofiasip 0.5.15
Hello, Telepathy-SofiaSIP development release 0.5.15 is available: http://sourceforge.net/project/showfiles.php?group_id=191149package_id=256956 New in this release: * Use the error code Invalid_Handle for failed handle normalization, as per recent revisions of telepathy-spec (fd.o bug #19612). * Ignore provisional responses to a MESSAGE. * Handle an incoming BYE with a proper media channel group change. * Restored the backwards compatible behavior of AddMembers on a media channel (fd.o bug #19652). * Updated the coverage instrumentation support, with lcov reports, taken from telepathy-gabble. * Fixed issues reported by Coverity static analysis checks. -- Mikhail Zabaluev Maemo Software, Nokia Devices RD ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Thoughs on the next gen MediaSignalling interface
Hi, -Original Message- From: telepathy-boun...@lists.freedesktop.org [mailto:telepathy-boun...@lists.freedesktop.org] On Behalf Of ext Olivier Crête Sent: Tuesday, April 14, 2009 11:44 PM To: telepathy Subject: [Telepathy] Thoughs on the next gen MediaSignalling interface o.fd.Tp.Client.StreamedMediaHandler: Methods: AddParticipants(a(ua(sv)) an array of particpants, the asv would contain nat-traversal, relay-info, stunservers, proxies, etc RemoveParticipants(au) SetCodecs(id, Codecs) (can fail if there is no intersection) AddCandidates(id, Candidates) ForceCandidates(id, Candidates) StartTelephonyEvent(event, volume) / StopTelephonyEvent(event) SetSendCodec(Codec) SetDirection(id, direction) Properties: CurrentCodecs Properties: Transmitters Properties: RecvCodecs Signals: CurrentCodecsChanged(Codecs) Signals: NewRecvCodecs(Codecs) Signals: Error(misc) I hope this helps starting the discussion on a saner MediaSignalling API. How do I restart an ICE session with this? Best regards, Misha ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] New to telepathy - help required
Hi, From: telepathy-boun...@lists.freedesktop.org [mailto:telepathy-boun...@lists.freedesktop.org] On Behalf Of ext Sai TP Sent: Friday, March 05, 2010 2:07 PM To: telepathy@lists.freedesktop.org Subject: Re: [Telepathy] New to telepathy - help required I had a look at Empathy. I need a much simpler way of doing it. Is it possible to establish a gtalk call session without having mission control or any tubes? Can I just create an account and register it with gtalk and make a call using telepathy-farsight? I do not need the presence information. It is like from a phone, login with a google account and make a gtalk call to one of the gtalk contact. Can anybody help me or point me to any help to do this? You don’t have to use tubes if you don’t need them. If Mission Control is installed in the system, you can use its AccountManager interface to discover the Google Talk (or any other suitable) account or create one. You are going to need it to request the call channel. Similarly, you don’t have to use contact list channels or presence if you don’t care about that. Just use the callee’s address when requesting a call channel, or if you want more elaborate contact validation beforehand, request its contact handle. P.S. Would Telepathy-Qt4, by chance, be better suited for your implementation? Best regards, Mikhail ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] New to telepathy - help required
Hi, If your software platform already uses Qt, it makes sense to use Telepathy-Qt4 on the client side. Otherwise, you are free to choose. There is also a Python binding, and the C client-side interface based on GLib and provided by telepathy-glib. Information on Telepathy-Qt4 is available, weird as it seems, at http://telepathy.freedesktop.org/wiki/Telepathy-Qt4 Hope this helps, Mikhail From: telepathy-boun...@lists.freedesktop.org [mailto:telepathy-boun...@lists.freedesktop.org] On Behalf Of ext Sai TP Sent: Wednesday, March 10, 2010 12:27 PM To: telepathy@lists.freedesktop.org; Zabaluev Mikhail (Nokia-D/Helsinki) Subject: Re: [Telepathy] New to telepathy - help required Hi, I couldn't find much information abt Telepathy-Qt4 anywhere online. So, didn't give a try. May be that would suit my implementation more. Given my use-case do you suggest to look at telepathy-qt4? Thanks, Sai --- On Tue, 3/9/10, mikhail.zabal...@nokia.com mikhail.zabal...@nokia.com wrote: From: mikhail.zabal...@nokia.com mikhail.zabal...@nokia.com Subject: RE: [Telepathy] New to telepathy - help required To: urfriend...@yahoo.com, telepathy@lists.freedesktop.org Date: Tuesday, March 9, 2010, 11:38 AM Hi, From: telepathy-boun...@lists.freedesktop.org [mailto:telepathy-boun...@lists.freedesktop.org] On Behalf Of ext Sai TP Sent: Friday, March 05, 2010 2:07 PM To: telepathy@lists.freedesktop.org Subject: Re: [Telepathy] New to telepathy - help required I had a look at Empathy. I need a much simpler way of doing it. Is it possible to establish a gtalk call session without having mission control or any tubes? Can I just create an account and register it with gtalk and make a call using telepathy-farsight? I do not need the presence information. It is like from a phone, login with a google account and make a gtalk call to one of the gtalk contact. Can anybody help me or point me to any help to do this? You don’t have to use tubes if you don’t need them. If Mission Control is installed in the system, you can use its AccountManager interface to discover the Google Talk (or any other suitable) account or create one. You are going to need it to request the call channel. Similarly, you don’t have to use contact list channels or presence if you don’t care about that. Just use the callee’s address when requesting a call channel, or if you want more elaborate contact validation beforehand, request its contact handle. P.S. Would Telepathy-Qt4, by chance, be better suited for your implementation? Best regards, Mikhail ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Best way to handle the client leaking connections?
Hi, this is Mikhail from Nokia. -Original Message- From: telepathy-boun...@lists.freedesktop.org [mailto:telepathy- boun...@lists.freedesktop.org] On Behalf Of ext Edward Page Sent: Wednesday, March 10, 2010 4:24 AM To: Sjoerd Simons Cc: telepathy@lists.freedesktop.org Subject: Re: [Telepathy] Best way to handle the client leaking connections? This seems to be an issue in the client. Which client are you using? Definately this shouldn't happen if mission control is used. This was all on Maemo 5 using the built in client (RTComm/MC ?). I found a related bug report for the Skype CM and posted my findings. I got a response from Mikhail at Nokia pointing the blame on connection managers. I have not gotten any further feedback on how a properly functioning connection manager should respond. To make Mission Control happy, a connection manager should not block its internal event loop which processes D-Bus method calls, at least at the time when RequestConnection is called. If the RequestConnection D-Bus call times out, Mission control will consider the connection failed, and rightly so. So, if you have any such kind of snags in your protocol stack, you ought to work around them. Look closely at any blocking calls performed: 1) at connect time; 2) at connection shutdown so they may leave a connection object lingering. Consider using asynchronous implementation for such functionality if available, or put it to a thread. Hope this helps, Mikhail ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Spec meeting notes on SASL authentication and SSL cert verification
Hi, -Original Message- From: telepathy-boun...@lists.freedesktop.org [mailto:telepathy- boun...@lists.freedesktop.org] On Behalf Of ext Eitan Isaacson Sent: Thursday, March 11, 2010 12:04 AM To: Will Thompson Cc: telepathy@lists.freedesktop.org Subject: Re: [Telepathy] Spec meeting notes on SASL authentication and SSL cert verification Hello folks. Recently I was tasked with continuing the work that Dafydd started on SASL. The good news is that this allows a more unified approach with the SSL and other authentication schemes we have been working on, specifically XTLS. The bad news is that I scratched a lot of the previous work Cosimo and I did in favor of a more symmetric and and clean interface (imho, anyway). I think most discussion items that I observed have been included in this spec, let me know if not. You could see an outline on the wiki page[1], browse the HTML spec[2], or checkout my branch[3]. I don't think the other iterations were a waste of time, on the server TLS front I have been maintaining a gabble implementation in lockstep to the rewrites and I am still sane. I feel like the actual code changes required for this are not too big (can't speak for XTLS though). First a note about English: Verification and authentication are interchangeable. I know this seems obvious, but I just feel like pointing it out. In my mind at least - verification is remote authentication, meaning we are verifying the remote peer is who she says she is. So in the new spec I scratched all mentions of verification, and I have stuck with authentication exclusively while distinguishing between remote and local authentication. In the old spec we had some weak points and some omissions that are critical to SASL: - Variable number of response/challange round trips. - Support for local authentication. the verification interface provided remote authentication, but the only local authentication we have is incomplete and hidden in the IdentityExchange interface. - Simple mechanism negotiation, not necessary, but the current NegotiateVerification iface is very complex for SASL needs. The new spec has a few benefits, imho: - One channel. Take E2E for example, we used to have 3 consecutive channels. Negotiation, verification and certificate exchange. In this design there is only one (for better or worse). - Incremental complexity: Take a look at the chatroom example[4] or the server TLS[5] example. They only require one interface. More complex exchanges like E2E[6] use more interfaces. - The Challange/Respond pattern let's us be more flexible about different authentication stages, this is how I added certificate exchange in to the SRP_BOOTSTRAP method. - The Challange/Respond pattern also makes the mechinism opaque and thus it is separate from the telepathy API. I think it was a mistake, for example, to have a certificate-specific API in telepathy. - We unify the mechanism negotiation for all protocols and schemes under a common API. Thanks. I like that the proposed way is friendly to cases when the dispatcher needs to pop up a separate authentication UI, which can even ignore differences between channel and connection auth. Also, this isolated UI process could have elevated privileges and be better secured. Few minor comments: - A challenge channel should present some human-readable string, to possibly inform what is being authenticated. The string SHOULD be formed locally by the connection manager, so as to avoid presenting remotely supplied information as trusted. - Maybe there should be a list of request tokens from the original channel request(s), available through the ChannelAuthentication interface, to refer to requested channels that will be created after the authentication is successful. Best regards, Misha ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Spec meeting notes on SASL authentication and SSL cert verification
Hi, -Original Message- From: telepathy-boun...@lists.freedesktop.org [mailto:telepathy- boun...@lists.freedesktop.org] On Behalf Of ext Simon McVittie Sent: Thursday, March 11, 2010 2:40 PM To: telepathy@lists.freedesktop.org Subject: Re: [Telepathy] Spec meeting notes on SASL authentication and SSL cert verification On Thu, 11 Mar 2010 at 13:01:34 +0100, mikhail.zabal...@nokia.com wrote: Few minor comments: - A challenge channel should present some human-readable string, to possibly inform what is being authenticated. The string SHOULD be formed locally by the connection manager, so as to avoid presenting remotely supplied information as trusted. If connection managers continue to not be localized, then the auth UI would have to form this string itself by understanding the meaning of the channel (e.g. putting together TargetHandleType=CONTACT, targetid=s...@example.com, and ideally also the local address book to say secure communication with Simon McVittie s...@example.com). I'd suggest that it should ignore (close) channels it doesn't understand well enough to present such a thing? Yes, I agree that an informational string should not really be treated as an UI-ready message. And if we always have a way to identify the peer or the destination through basic Channel properties, and connect the challenge to requests that caused it, fine. Misha ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] New to telepathy - help required
Hi, I see some confusion here. Telepathy-farsight is an implementation of RTP streaming to support VoIP calls. All connection managers alike are supported by Telepathy-Qt4 client-side bindings. Hope this helps, Mikhail From: ext Sai TP [mailto:urfriend...@yahoo.com] Sent: Friday, March 12, 2010 11:08 AM To: telepathy@lists.freedesktop.org; Zabaluev Mikhail (Nokia-D/Helsinki) Subject: Re: [Telepathy] New to telepathy - help required Hi, Thanks for the response and the suggestion. Does the telepathy-qt4 support other CMs as well or farsight only? I see examples only for telepathy-farsight. Can we use any other connection manager like tp-gabble or tp-butterfly with telepathy-qt4? Thanks, Sai --- On Wed, 3/10/10, mikhail.zabal...@nokia.com mikhail.zabal...@nokia.com wrote: From: mikhail.zabal...@nokia.com mikhail.zabal...@nokia.com Subject: Re: [Telepathy] New to telepathy - help required To: urfriend...@yahoo.com, telepathy@lists.freedesktop.org Date: Wednesday, March 10, 2010, 5:06 AM Hi, If your software platform already uses Qt, it makes sense to use Telepathy-Qt4 on the client side. Otherwise, you are free to choose. There is also a Python binding, and the C client-side interface based on GLib and provided by telepathy-glib. Information on Telepathy-Qt4 is available, weird as it seems, at http://telepathy.freedesktop.org/wiki/Telepathy-Qt4 Hope this helps, Mikhail From: telepathy-boun...@lists.freedesktop.org [mailto:telepathy-boun...@lists.freedesktop.org] On Behalf Of ext Sai TP Sent: Wednesday, March 10, 2010 12:27 PM To: telepathy@lists.freedesktop.org; Zabaluev Mikhail (Nokia-D/Helsinki) Subject: Re: [Telepathy] New to telepathy - help required Hi, I couldn't find much information abt Telepathy-Qt4 anywhere online. So, didn't give a try. May be that would suit my implementation more. Given my use-case do you suggest to look at telepathy-qt4? Thanks, Sai --- On Tue, 3/9/10, mikhail.zabal...@nokia.com mikhail.zabal...@nokia.com wrote: From: mikhail.zabal...@nokia.com mikhail.zabal...@nokia.com Subject: RE: [Telepathy] New to telepathy - help required To: urfriend...@yahoo.com, telepathy@lists.freedesktop.org Date: Tuesday, March 9, 2010, 11:38 AM Hi, From: telepathy-boun...@lists.freedesktop.org [mailto:telepathy-boun...@lists.freedesktop.org] On Behalf Of ext Sai TP Sent: Friday, March 05, 2010 2:07 PM To: telepathy@lists.freedesktop.org Subject: Re: [Telepathy] New to telepathy - help required I had a look at Empathy. I need a much simpler way of doing it. Is it possible to establish a gtalk call session without having mission control or any tubes? Can I just create an account and register it with gtalk and make a call using telepathy-farsight? I do not need the presence information. It is like from a phone, login with a google account and make a gtalk call to one of the gtalk contact. Can anybody help me or point me to any help to do this? You don’t have to use tubes if you don’t need them. If Mission Control is installed in the system, you can use its AccountManager interface to discover the Google Talk (or any other suitable) account or create one. You are going to need it to request the call channel. Similarly, you don’t have to use contact list channels or presence if you don’t care about that. Just use the callee’s address when requesting a call channel, or if you want more elaborate contact validation beforehand, request its contact handle. P.S. Would Telepathy-Qt4, by chance, be better suited for your implementation? Best regards, Mikhail -Inline Attachment Follows- ___ telepathy mailing list telepathy@lists.freedesktop.org/mc/compose?to=telepa...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Best way to handle the client leaking connections?
Hi, -Original Message- From: eop...@gmail.com [mailto:eop...@gmail.com] On Behalf Of ext Edward Page Sent: Saturday, March 13, 2010 6:51 PM To: Zabaluev Mikhail (Nokia-D/Helsinki) Cc: sjo...@luon.net; telepathy@lists.freedesktop.org Subject: Re: [Telepathy] Best way to handle the client leaking connections? Looking closer I found a couple more issues in my CM. I'm hoping working around them will reduce the average case for CM response time to RequestConnection/Connect/Disconnect that the user will rare see an issue. Despite my claim that I don't block in Disconnect, somehow my Disconnect took 6 seconds according to one log file. I'm unsure why but this can have a negative impact. Yes, it was a problem with our implementation: blocking on disconnection meant that a RequestConnection call to reestablish the connection timed out. Even if blocking is resolved, making an object linger in disconnecting state will keep the DBus object path occupied, so if the connection object paths are not randomized, this will result in a conflict if the connection is restarted. I can understand the need for the timeout, if something happened to the CM like its hung or crashed then you don't want to wait on it forever. It just seems kind of sad that I have the leisure of running asynchronously and yet I have add an extras layer of asynchronous calls. Well, as a general rule, a D-Bus service should not block for potentially long periods of time while handling method calls. By extension, it means that the service's event loop processing DBus messages should not have such blockers at all. There is no good alternative to being async. It also seems worrisome that you give up on a CM without ever notifying it that you gave up. I can understand that in an ideal situation no CM would ever hit this issue but its still good to be defensive, especially when it can impact the user experience (can't reconnect) and battery life (connection got left open with any of its keep-alives firing). For one thing, I think Mission Control should keep watch on lingering connections even after it has ceased doing anything useful with them, and react to the connection status signals. If the connection comes online after all, it could be treated positively, or it could be immediately told to disconnect just to not muddle the MC state too much. A bug on bugs.freedesktop.org could be filed. But the case of a RequestConnection timeout is worse: you don't get a connection object to watch, and DBus will not route your call result back even if the CM ultimately responds. Life is tough for misbehaving services. Best regards, Mikhail ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] forwarding spec questions
Hi,
-Original Message-
From: telepathy-boun...@lists.freedesktop.org [mailto:telepathy-
boun...@lists.freedesktop.org] On Behalf Of ext Andres Salomon
Sent: Tuesday, March 16, 2010 8:20 PM
To: telepathy@lists.freedesktop.org
Cc: Sjoerd Simons
Subject: [Telepathy] forwarding spec questions
Regarding http://bugs.freedesktop.org/show_bug.cgi?id=13351 (the
forwarding spec), I'm trying to determine just how much the spec needs
to support. The discussion of scripts is much more complex than the
GSM call-forwarding model. If that's something that telepathy needs to
support, what kind of API is envisioned?
For the Connection interface, it's enough if we can do this:
property SupportedForwardingConditions: au, read-only
property ForwardingRules: a(ua(uu))
method SetForwardingRule(u: Forwarding_Condition, a(uu): Forwarding_List) -
a(uu)
signal ForwardingRulesChanged: a(ua(uu))
enum Forwarding_Condition: u {
Unconditional,
Busy,
NoReply,
NotReachable
}
struct Forwarding_List_Entry {
u: Timeout,
u: Handle,
}
The timeout is for how many seconds should the service wait (on the original
call, or a previous forwarding attempt) before attempting forwarding to that
handle. It can be 0 if the client does not care and lets the implementation
decide, and it's reported back as 0 if the service does not advertise definite
timeouts (there could be a feature flag property about that, too).
I'm not certain of how the conditional rules should supplement each other.
Should NoReply also work if the subscriber is not reachable and the rule for
NotReachable is not set? Or vice versa? Will anything supplement Busy? Or
should it be at the discretion of the connection manager, which will be obliged
to advertise all effective rules as apply to each condition?
--
Mikhail
___
telepathy mailing list
telepathy@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] forwarding spec questions
Hi,
-Original Message-
From: ext Andres Salomon [mailto:dilin...@collabora.co.uk]
Sent: Wednesday, March 17, 2010 6:47 PM
To: Zabaluev Mikhail (Nokia-D/Helsinki)
Cc: telepathy@lists.freedesktop.org; sjoerd.sim...@collabora.co.uk
Subject: Re: [Telepathy] forwarding spec questions
method SetForwardingRule(u: Forwarding_Condition, a(uu):
Forwarding_List) - a(uu)
What happens if I attempt to call SetForwardingRule(Busy, {0, 231})
when
there's already an entry in the Forwarding_List array for Busy? Does
the old entry get overwritten, or can both Busy entries co-exist in the
array?
I think for simplicity sake, it should be overwritten. As well as any other
rule that will effectively be changed by the implementation when setting this
rule.
Maybe there is little point in reflecting the effective rule in the return
value as I indented (as there is already a signal for that), so the return
value could get the replaced rule.
I'm not certain of how the conditional rules should supplement each
other. Should NoReply also work if the subscriber is not reachable
and the rule for NotReachable is not set? Or vice versa? Will
anything supplement Busy? Or should it be at the discretion of the
connection manager, which will be obliged to advertise all effective
rules as apply to each condition?
Unconditional overrides everything else. NotReachable is a specific
case, and shouldn't (in theory) apply to Busy/NoReply. If the GSM
phone is on and in service range, Busy and NoReply should be the only
remaining options.
I would think that this maps to VOIP calls as well; NotReachable
implies the local user is not online (if the protocol doesn't allow us
to see whether or not a user's online, then NotReachable will never be
triggered). If the user is online and is capable of receiving calls,
then Busy and NoReply are all that remain.
Sounds OK to me. But I'd like to keep a provision for the service to change any
other rules as a side effect of setting one particular conditional rule. There
might be protocols that cannot distinguish some of the proposed conditions.
Also, setting Unconditional could explicitly remove all conditional rules as
reflected by the ForwardingRulesChanged signal.
In the case where the underlying network services automatically
supplement the forwarding rules, this should either be turned off, or
the CM can make that explicit (ie, setting NoReply while NotReachable
is unset results in a ForwardingRulesChanged signal that has *both* set;
Right.
likewise, setting Unconditional with nothing else set might raise the
ForwardingRulesChanged signal w/ every forwarding rule set).
That, or just one Unconditional rule survives. This way will make the job of a
UI client easier.
Some finer points about the proposal:
- Does setting an empty list nullify the rule, or do we need a separate method
to clear?
- There should be a property to limit the number of entries per list, which can
be 0 (or MAXUINT32?) if there's no explicit limit, and 1 if the protocol does
not deal with lists. The CM may have the right to shorten the list, as long as
it is properly signalled.
- As mentioned before, a Boolean property to tell if timeouts are supported.
--
Misha
___
telepathy mailing list
telepathy@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] empathy with Microsoft Livechat LX-3000
Hi, -Original Message- From: telepathy- bounces+mikhail.zabaluev=nokia@lists.freedesktop.org [mailto:telepathy- bounces+mikhail.zabaluev=nokia@lists.freedesktop.org] On Behalf Of ext ?esa? ?ad??e ?? Sent: Tuesday, May 11, 2010 2:40 PM To: telepathy@lists.freedesktop.org Subject: [Telepathy] empathy with Microsoft Livechat LX-3000 I have two audio devides, internal and a Livechat LX-3000. how can I choose the audio device used for a SIP call? This is a very interesting question. If PulseAudio is in use, telepathy-farsight could tag PA streams with something that Empathy (or possibly the central mixer application) could route to the correct device. Best regards, Mikhail ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] MXit protocol support
Hi, -Original Message- From: telepathy- bounces+mikhail.zabaluev=nokia@lists.freedesktop.org [mailto:telepathy- bounces+mikhail.zabaluev=nokia@lists.freedesktop.org] On Behalf Of ext Will Thompson Sent: Wednesday, May 12, 2010 11:54 AM To: telepathy@lists.freedesktop.org Subject: Re: [Telepathy] MXit protocol support On 11/05/10 21:10, avictor...@gmail.com wrote: I noticed that Empathy (included with Ubuntu 10.04) now includes the MXit protocol option (via telepathy-haze). It unfortunately does not work since the first time you connect to MXit it needs to authorize some account information (country, language, anti-bot captcha). This is requested from the user using purple_request_fields(), and I see that telepathy-haze doesn't implement that API (http://git.collabora.co.uk/?p=telepathy- haze.git;a=blob;f=src/request.c). Are there any issues in getting this API implemented? Yes: telepathy-haze doesn't present any UI itself, so it can't show dialog boxes. This is why the purple_request_* API isn't implemented. I think the way out of this is, unfortunately, to have a channel type for captchas and stuff, which would look pretty much like the authentication channels Eitan is working on. If anybody is going to work on this, please also consider approval of EULA/TOS. This is important for some proprietary services. Best regards, Mikhail ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] On removing/standardizing .profiles
Hi, -Original Message- From: telepathy- bounces+mikhail.zabaluev=nokia@lists.freedesktop.org [mailto:telepathy- bounces+mikhail.zabaluev=nokia@lists.freedesktop.org] On Behalf Of ext Will Thompson Sent: Monday, June 07, 2010 7:47 PM To: telepathy@lists.freedesktop.org Subject: Re: [Telepathy] On removing/standardizing .profiles On 01/06/10 19:37, Will Thompson wrote: • Add methods to filter Tp::Accounts by enabled-ness, online-ness, capabilities, etc. to Telepathy-Qt4. Relatedly: http://people.freedesktop.org/~smcv/telepathy-spec- protocols/spec/org.freedesktop.Telepathy.Protocol.DRAFT.html#org.freede sktop.Telepathy.Protocol.DRAFT.VCardField implies that we currently don't have any way to say “this protocol supports calling these kinds of identifiers”. For instance, SIP and Skype can call PSTN numbers; the sip.profile on the N900 has the following stanza: [Action call] Name = ... VCardFields = X-SIP,TEL prop-ChannelType-s = ...StreamedMedia to indicate that you can call contacts who have either an X-SIP field or a TEL field using SIP accounts. This is related to https://bugs.freedesktop.org/show_bug.cgi?id=26866, and I suspect is the purpose of the SecondaryVCardFields https://bugs.freedesktop.org/show_bug.cgi?id=24898. This may be also related to a dynamic problem: https://bugs.freedesktop.org/show_bug.cgi?id=26866 -- Mikhail ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Issue on VoIP establishment on Using empathy/telepathy
Hi, -Original Message- From: telepathy- bounces+mikhail.zabaluev=nokia@lists.freedesktop.org [mailto:telepathy- bounces+mikhail.zabaluev=nokia@lists.freedesktop.org] On Behalf Of ext Cayetanot, Sebastien Sent: Wednesday, August 25, 2010 3:59 PM To: Sjoerd Simons; telepathy@lists.freedesktop.org Subject: Re: [Telepathy] Issue on VoIP establishment on Using empathy/telepathy Sorry for the top-posting. I'm using Outlook...; I'm using it too, and I know your pain (I use it for other reasons than just an email client). You can force messages to plain text, which is good for other reasons, like not seeing pointlessly fluffy formatting by default... I have found a bug description: https://bugs.launchpad.net/ubuntu/+source/empathy/+bug/599263 But the 6.1.3 doesn't fix my issue. I will try also your solution. But I can't turn off the STUN server discovering just remove the automatic discovery but need to add an address. You can leave the STUN server name empty, it works to disable STUN. Also, try to fix your SIP transport selection to TCP (if supported) or UDP. Still, a packet dump would help understand the problem without guessing. Best regards, Mikhail ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] SIP Session without Account
Hi, -Original Message- From: telepathy- bounces+mikhail.zabaluev=nokia@lists.freedesktop.org [mailto:telepathy- bounces+mikhail.zabaluev=nokia@lists.freedesktop.org] On Behalf Of ext Olivier Crête Sent: Thursday, October 14, 2010 6:50 PM To: telepathy@lists.freedesktop.org Subject: Re: [Telepathy] SIP Session without Account On Thu, 2010-10-14 at 17:45 +0200, Esben Stien wrote: Empathy won't let me start a conversation without any accounts. SIP does not require that you have an account on a server to be able to dial it. Telepathy-SofiaSIP doesn't support P2P SIP, it sends all messages through the SIP proxy. If you really want to do P2P SIP, your best bet is probably Ekiga right now. That said, I really haven't seen anyone use P2P SIP in real life. ... But if somebody does, I'd be happy to review a patch to telepathy-sofiasip. The sofia-sip stack permits proxy-less operation. Some modifications are needed to support the p2p mode in telepathy-sofiasip. A good start is a parameter to make it omit the proxy parameter when constructing the NUA stack instance. The default IP socket binding is to INADDR_ANY on the default SIP port, so the stack should automatically become a usable UAS. It can resolve destinations for outbound requests too (one caveat here is that sofia-sip uses only DNS and ignores other host name lookup methods). There might be some issues with interpreting the request URI or the To URI as addressed to the local user; all incoming requests are currently handled as if addressed to our local user without checking. Hope this helps, Mikhail ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] I'm unable to create a channel
Hi, -Original Message- From: telepathy- bounces+mikhail.zabaluev=nokia@lists.freedesktop.org [mailto:telepathy- bounces+mikhail.zabaluev=nokia@lists.freedesktop.org] On Behalf Of ext Abhijit Bera Sent: Monday, November 08, 2010 12:59 PM To: telepathy@lists.freedesktop.org Subject: [Telepathy] I'm unable to create a channel I want to create a contact list channel using the connection object. I always get an error message: Not Implemented. There is an off chance that the contact manager you try it with does not support contact list channels. Regards, Mikhail ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] I'm unable to create a channel
Hi, -Original Message- From: telepathy- bounces+mikhail.zabaluev=nokia@lists.freedesktop.org [mailto:telepathy- bounces+mikhail.zabaluev=nokia@lists.freedesktop.org] On Behalf Of ext Simon McVittie Sent: Monday, November 08, 2010 1:36 PM To: telepathy@lists.freedesktop.org Subject: Re: [Telepathy] I'm unable to create a channel On Mon, 08 Nov 2010 at 16:29:20 +0530, Abhijit Bera wrote: map.insert(org.freedesktop.Telepathy.Channel.ChannelType,QVariant(or g.freedeskop.Telepathy.Channel.Type.ContactList)); There's a constant for ...ContactList, and there should also be one for ...ChannelType I think? Indeed there should be: the code above has a typo in the interface name, which probably explains why it doesn't work. Regards, Mikhail ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
[Telepathy] Massively complicating Folks for greater future
Hi, I have created a branch on Folks to propose a more scalable API: http://git.collabora.co.uk/?p=user/zabaluev/folks.git;a=shortlog;h=refs/heads/views The new classes are only stubs for discussion purposes. The main additions are IndividualList, providing an asynchronously retrieved live view on individuals matching a certain query, and an abstract Query class with some useful subclasses. The intent with queries is to broadly cover a few common cases, keeping the complexity of implementing queries in persona stores under control. For example, there would be only the OR-combining query to match string prefixes, and the matching should be case insensitive. If the clients want more restrictive matching (e.g. if it's in fact a QtMobility Contacts client using their overengineered query structures), they can filter the resulting list. Matching for a phone number is an interesting special case, which needs fuzzier heuristics to be applied and should perhaps ultimately be customizable. The public hash table of individuals in IndividualAggregator can be eventually deprecated, if we want support for more than a few dosen of contacts, and efficiently implement search-oriented backends. Discussion is welcome. Misha ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Massively complicating Folks for greater future
Hi, -Original Message- From: ext Travis Reitter [mailto:travis.reit...@collabora.co.uk] Sent: Monday, November 29, 2010 4:58 AM To: Zabaluev Mikhail (Nokia-MS/Helsinki) Cc: telepathy@lists.freedesktop.org Subject: Re: [Telepathy] Massively complicating Folks for greater future I have created a branch on Folks to propose a more scalable API: http://git.collabora.co.uk/?p=user/zabaluev/folks.git;a=shortlog;h=refs /heads/views Thanks for proposing this. At a high level, it looks good. I know how useful it can be to have a query interface for contacts (we could use this in Empathy's LiveSearch widget and Gnome Shell when we get around to writing a search provider). Live search is interesting enough to deserve its own specific interface. But if no known backend can optimize for incremental search, perhaps it can be done with instantiating a (subclassed) IndividualList and modifying the search query. I've already thought of some Persona-fetching rate limiting to smooth out the CPU and I/O loads after preparing the Aggregator with a few hundred Personas (which even makes Empathy seemingly block for a couple seconds on my laptop - though I haven't confirmed this is necessarily Folks' fault). This would probably fit in well with Query support. Yes; the implementation of IndividualList can possibly support lazy retrieval as the client requests slices of the list. Other than that, though, it seems it could be a while before this would let us improve performance. I would think it would only help if we can push the query back into some of the Backends. It may also help to avoid brute-forcing IndividualAggregator.individuals to get at the individuals possessing desired attributes; I have another query subclass in mind to e.g. retrieve everybody who is IMable, but I need to ponder on it a little. I don't have real examples of supersized individual lists yet, though. Maybe with Facebook? :) And e-d-s and Tracker are the only potential sources I can think of that would be able to support this. Yes, that's the general intent. Other sources where it can be useful could be LDAP directories and alike, but I'm not sure if those can be worked into the Folks concept. There is that different use case of searching in a remote directory which cannot be replicated locally. Still, this seems generally useful. So please file a bug and develop the branch further. Tests would be greatly appreciated (especially if they can suggest that queries would smooth out the initial CPU/IO spike). I can't promise at the moment that I will have much time for this, but I'll file the request. Best regards, Misha ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Massively complicating Folks for greater future
Hi, -Original Message- From: ext frederik.nn...@gmail.com [mailto:frederik.nn...@gmail.com] Sent: Monday, November 29, 2010 1:52 AM To: Zabaluev Mikhail (Nokia-MS/Helsinki) Cc: telepathy@lists.freedesktop.org Subject: Re: [Telepathy] Massively complicating Folks for greater future I have created a branch on Folks to propose a more scalable API: http://git.collabora.co.uk/?p=user/zabaluev/folks.git;a=shortlog; h=refs/heads/views The new classes are only stubs for discussion purposes. The main additions are IndividualList, providing an asynchronously retrieved live view on individuals matching a certain query, and an abstract Query class with some useful subclasses. The intent with queries is to broadly cover a few common cases, keeping the complexity of implementing queries in persona stores under control. my guess is that specialized query belongs into the client, not into Folks. Folks should provide accurate data, the client should provide ways of managing or editing this data, tailored to the use case which the respective client (app) desires to address. My main concern here is scalability. If the persona stores give you several thousand contacts (which is not a long stretch: I consider myself a modestly connected person and my phone's address book has 142 contacts), accessing all them through an explicit in-memory data structure can become a bottleneck. Also, you have to replicate this structure at every client, so there can be no benefit from caching in the filesystem. Case insensitivity and fuzzy search logic are nice features that a client can include as needed, they won't make aggregating contact information more accurate imo. No, the aggregated contacts should stay as they are; it's only the list retrieval methods that change. Best regards, Misha ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] telepathy-sofiasip parameters
Hi, -Original Message- From: ext Florian Reinhard [mailto:florian.reinh...@googlemail.com] Sent: Saturday, January 29, 2011 5:57 PM To: telepathy@lists.freedesktop.org Cc: Zabaluev Mikhail (Nokia-MS/Helsinki) Subject: telepathy-sofiasip parameters I'm working on a telepathy-accounts-kcm plugin for telepathy-sofiasip and the in-code documentation of the provided configuration parameters are not sufficient for me to be able to produce a sane configuration UI. Therefore some questions concerning telepathy-sofiasip's parameters: discover-stun, stun-server, stun-port: In the code i found that discover-stun is ignored if stun-server is set, therefore if a user sets discover-stun to TRUE stun-server needs to be empty to make this configuration work? Yes, as a parameter passed to the CM it should be empty. I think now that it is inconvenient to a plugin implementation that would not want to lose the server name value even if discovery is enabled. Can you file a bug about it? Do you want this fixed in telepathy-sofiasip 0.6? local-ip-address / local-port: what are these used for, are they overriden by anything, does discover- binding affect this? These affect the socket binding of the SIP UA. It's a way to ensure that Sofia-SIP uses a particular local IP binding on multi-homed hosts, something that it does not do in a satisfactory way automatically. These should not be exposed in account configuration, and are provided for various automatic tweaks. proxy-host / port / transport: does proxy-host need to have the format sip:FQDN/IP? No, it's supposed to be a FQDN or an IP address only. is transport really related to the proxy? This will be the transport used to contact the proxy, so yes. I think it also goes into the pre-set Route header for initial requests, if loose-routing is enabled. The route URI is mainly composed from the three parameters above. extra-auth-user / extra-auth-password: what are extra authentication challenges? This is almost obsolete now that we have authentication channels. We only need to implement digest authentication on demand in telepathy-sofiasip to make these parameters unnecessary. Currently, these values are used in response to authentication challenges not belonging to the registration domain (as discovered from the REGISTER authentication). general: since i do not exactly know how sip NAT traversal works, i guess that stun, proxy and discover-binding (which seems to make sofiasip use natify and rport) exclude another? No, STUN settings are for media streams only. The UAC implementation in sofia-sip currently does not use STUN for NAT traversal; it relies on the rport RFC and has somewhat rusty and partial support for what was the SIP outbound draft (now RFC 5626). discover-binding enables registration binding updates based on external IP address reciprocated from the proxy using rport. Proxy settings and discover-binding are orthogonal. Are Natify and rport being used if there is a STUN server? Yes. Looks like I need to spend some time documenting all these properties better. Hope this helps, Mikhail ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Telepathy farstream started
Hi, -Original Message- From: telepathy- bounces+mikhail.zabaluev=nokia@lists.freedesktop.org [mailto:telepathy- bounces+mikhail.zabaluev=nokia@lists.freedesktop.org] On Behalf Of ext Sjoerd Simons Sent: Tuesday, February 01, 2011 7:11 PM To: telepathy Subject: [Telepathy] Telepathy farstream started Furthermore we've been planning to rename Farsight2 itself to Farstream for a while now, which Olivier promised me to do within the next two weeks. While you are at it, rename transmitters to transceivers, put them into $(libdir)/farstream-1.0/transceivers to reduce plugin file name fidgetry, and maybe match up on the Tp.Ch.Type.Call vs Farsight terminology? :) Cheers, Misha ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Telepathy farstream started
Hi, -Original Message- From: ext Olivier Crête [mailto:olivier.cr...@collabora.co.uk] Sent: Tuesday, February 01, 2011 8:40 PM To: Zabaluev Mikhail (Nokia-MS/Helsinki) Cc: sjoerd.sim...@collabora.co.uk; telepathy@lists.freedesktop.org Subject: RE: [Telepathy] Telepathy farstream started Added to the todo list at http://farsight.freedesktop.org/wiki/ApiBreak Thanks. I think breaking it into two TODO items would be better, but I can't change the page myself. Best regards, Misha On Tue, 2011-02-01 at 18:32 +, mikhail.zabal...@nokia.com wrote: Hi, -Original Message- From: telepathy- bounces+mikhail.zabaluev=nokia@lists.freedesktop.org [mailto:telepathy- bounces+mikhail.zabaluev=nokia@lists.freedesktop.org] On Behalf Of ext Sjoerd Simons Sent: Tuesday, February 01, 2011 7:11 PM To: telepathy Subject: [Telepathy] Telepathy farstream started Furthermore we've been planning to rename Farsight2 itself to Farstream for a while now, which Olivier promised me to do within the next two weeks. While you are at it, rename transmitters to transceivers, put them into $(libdir)/farstream-1.0/transceivers to reduce plugin file name fidgetry, and maybe match up on the Tp.Ch.Type.Call vs Farsight terminology? :) ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] ejabberd server component with empathy
Hi, -Original Message- From: telepathy- bounces+mikhail.zabaluev=nokia@lists.freedesktop.org [mailto:telepathy- bounces+mikhail.zabaluev=nokia@lists.freedesktop.org] On Behalf Of ext Will Thompson Sent: Tuesday, February 08, 2011 5:32 PM To: telepathy@lists.freedesktop.org Subject: Re: [Telepathy] ejabberd server component with empathy On 08/02/11 01:16, Paddy Carman wrote: Hi All, I implemented an echo bot as a server component (with ejabberd) using the code given in http://metajack.im/2008/10/09/echo-bot-part-two-making-a-component/. I'm able to connect to it and receive the echoed messages when I use Gajim. However, when I use Empathy, I'm unable to connect to it (nothing happens). Why is that? Does its JID have a node part (i.e. f...@example.com) or is it just a domain part (i.e. example.com)? I assume the latter. Gabble (the XMPP backend for Telepathy used by Empathy) doesn't support receiving or sending messages to JIDs without a node part. Why? service.example.com should be as valid a JID as any other, no? Best regards, Mikhail ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] ejabberd server component with empathy
Hi, -Original Message- From: telepathy- bounces+mikhail.zabaluev=nokia@lists.freedesktop.org [mailto:telepathy- bounces+mikhail.zabaluev=nokia@lists.freedesktop.org] On Behalf Of ext Will Thompson Sent: Tuesday, February 08, 2011 6:02 PM To: telepathy@lists.freedesktop.org Subject: Re: [Telepathy] ejabberd server component with empathy On 08/02/11 15:38, mikhail.zabal...@nokia.com wrote: Why? service.example.com should be as valid a JID as any other, no? I think the rationale is to avoid confusing errors for users who enter foo.bar, expecting to talk to foo@gmail.com, or add them to their roster. I notice that Empathy just silently ignores the failing channel request, though. Excitingly, Gabble doesn't seem to emit a failed delivery report if I try to send messages to l...@lol.whut, despite receiving an error on the wire, because Prosody doesn't include the body/ element we tried to send in the error it sends back. (A send error/delivery report is emitted when I try this via ejabberd, which includes body/.) I've filed https://bugs.freedesktop.org/show_bug.cgi?id=34039 for this isue. I wonder whether the rationale is basically wrong, and we should allow it, and ensure that we report errors properly and possibly include hints in the UI as to what contact IDs should look like on each network. (For instance, if the CM says something like “domain not found”, hint “did you mean lol.w...@gmail.com?”.) Either that, or we want a way—Addressing? ;-)—to explicitly label “this is a server-like JID”. Well, only if you want to grandfather in the current fuzzy behavior. OTOH, Addressing perhaps needs to be treated more formally, so it can be used to say I want exactly this JID. Best regards, Mikhail ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] On spec additions to allow a really simple IM API
Hi,
-Original Message-
From: telepathy-
bounces+mikhail.zabaluev=nokia@lists.freedesktop.org
[mailto:telepathy-
bounces+mikhail.zabaluev=nokia@lists.freedesktop.org] On Behalf Of
ext Will Thompson
Sent: Thursday, March 03, 2011 4:40 PM
To: Olli Salli
Cc: Telepathy
Subject: Re: [Telepathy] On spec additions to allow a really simple IM
API
On 02/03/11 20:33, Olli Salli wrote:
In essence, CD would implement a method, say
CD.I.Messages.Send(s:TargetID, s:message, and perhaps some misc args
for flags, and maybe throw an a{sv} there just for the kicks), in
the
following way:
- EnsureChannel a suitable text channel for sending the message to
the recipient
- Send the message on the resulting Channel
- If sending failed, which in particular can happen at least when
Yours wasn't true and somebody else Closed it when we tried to send,
just request the channel again, and try sending again
So when considering similar solutions in the past (but not inside MC:
that's a new idea!) I was worried about going into a loop. I'm not 100%
sure that the above is loop-free in the presence of someone else
requesting the channel at the wrong time, and/or a broken observer that
closes all your channels. (But in the latter case everyone dies
anyway.)
This depends on a few things:
- If it is safe to implement CreateChannel in the CD as Ensure + not
Closing - the CD knows that it's the only other user of the Ensured
channel (unless somebody else is directly poking the Connection, but
that's broken anyway), so it could be the only one Closing it, but it
can avoid that because it knows of the new request
Technically this is wrong if it's possible to have 1 separate
conversations with a contact on a particular protocol (say, using XMPP
threads). MC would have to try to guess whether a 1-1 text channel
request was “standard” or not, or something.
For instance, check out
http://telepathy.freedesktop.org/spec/Channel_Interface_SMS.html — the
SMSChannel property allows you to ask for messages to be sent via SMS
rather than over the internet on protocols which support both.
This is the biggest worry I have with this solution to the problem:
right now, MC is completely agnostic of the contents of requests. It
just does a{sv} pattern-matching and knows no semantic details. Baking
in special knowledge of text channels makes it harder to do clever
stuff
in future without adding special-cases to MC.
- If it is safe to Close the channel when we're done if nobody
requested it in the meantime: It should be, as if we use Close
instead
of Destroy, if there were incoming messages the Channel should then
be
closed and redispatched, right?
This should be safe.
- If it is problematic that the Channel might be redispatched after
Closing with its pending message queue intact, namely for loggers not
wanting duplicate events? We haven't given the Channel to a Handler
which could ack the messages beforehand, that is.
This is the same as a handler closing a channel while it has pending
messages, and it respawning. The messages get marked as 'recovered' to
make it easier for observers.
Also, do you think this would complicate the CD implementation too
much (or be in fact impossible)?
This bit of the channel dispatcher is quite complicated already. I'm a
bit scared of baking more magic into it… I believe it's *possible*, but
may lead to hard-to-catch bugs.
I'm fine with send-only Channels -
they'd solve the issue equally well, and without any CD changes, but
would in turn require changes in ALL of the CMs, and non-trivial
tp-glib support, which looks problematic at this point to say the
least. Not to mention the fact that send-only channels are an
awkward concept at best.
I have conceptual issues with send-only channels too: they're a total
hack! It's also much harder to explain to a new-comer. There's a
certain
conceptual simplicity to having an actual JustSendAMessageToAContact()
D-Bus method that people can use without having a full Telepathy
library
to depend on. “dbus-send blah blah blah” is a much nicer answer to “how
do I send a IM to f...@bar.com” than “well, you have to ask the account
manager for all accounts, and then look at all the contact lists and
find f...@bar.com and then be a handler and then request-and-handle a
write-only text channel and then you can actually send the message”…
But if we took the write-only channels route, we could put the
SendAMessage(s: contact_identifier, s: message) magic method on (say)
the logger in the future. One doesn't preclude the other.
I'd be interested to hear from CM hackers what they think about this.
I too think send-only channels are an ugly solution and will only complicate
everything.
Remember that the case is meant mainly for simple applications sending one-shot
messages, so involving special channels in this flow looks like overkill
Re: [Telepathy] On spec additions to allow a really simple IM API
Hi, -Original Message- From: telepathy- bounces+mikhail.zabaluev=nokia@lists.freedesktop.org [mailto:telepathy- bounces+mikhail.zabaluev=nokia@lists.freedesktop.org] On Behalf Of ext Will Thompson Sent: Monday, March 07, 2011 3:10 PM To: telepathy@lists.freedesktop.org Subject: Re: [Telepathy] On spec additions to allow a really simple IM API On 07/03/11 12:58, mikhail.zabal...@nokia.com wrote: That, or maybe try client-side helpers to manage sending to a contact survivably across channel closures. I'm pretty sure it's not possible to do this without the possibility of an infinite loop, or the possibility of breaking the UI. If there's no existing channel open to a contact, this API would have to create and handle the channel to avoid popping up an IM window in the user's face. But this means that, if the user happens to try to start a conversation at the same time, that channel request will fail (if using CreateChannel) or be redispatched to the service sending a one-shot IM (EnsureChannel). This is obviously very unlikely, but sod's law … You are right. Anyone for o.fd.Tp.Conn.I.MessageSender, with suitable hacks to avoid invoking approvers/handlers for a possibly created channel? Best regards, Mikhail ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] On spec additions to allow a really simple IM API
Hi, -Original Message- From: telepathy- bounces+mikhail.zabaluev=nokia@lists.freedesktop.org [mailto:telepathy- bounces+mikhail.zabaluev=nokia@lists.freedesktop.org] On Behalf Of ext Will Thompson Sent: Monday, March 07, 2011 4:49 PM To: Zabaluev Mikhail (Nokia-MS/Helsinki) Cc: telepathy@lists.freedesktop.org Subject: Re: [Telepathy] On spec additions to allow a really simple IM API On 07/03/11 14:45, mikhail.zabal...@nokia.com wrote: Anyone for o.fd.Tp.Conn.I.MessageSender, with suitable hacks to avoid invoking approvers/handlers for a possibly created channel? The main reason I wanted to use channels for this, rather than a connection interface, is that otherwise observers will not notice the messages being sent. A connection interface is simpler but we have to figure out how these messages should get logged etc. Yes, so there should be a way to get the created channel to be observed, but not offered to approvers and/or handlers? May just setting Channel.Requested to true be enough? Best regards, Mikhail ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] The telepathy-reviewers mailing list.
Hi, -Original Message- From: telepathy- bounces+mikhail.zabaluev=nokia@lists.freedesktop.org [mailto:telepathy- bounces+mikhail.zabaluev=nokia@lists.freedesktop.org] On Behalf Of ext Sjoerd Simons Sent: Saturday, March 26, 2011 2:32 PM To: Olivier Crête Cc: telepathy@lists.freedesktop.org Subject: Re: [Telepathy] The telepathy-reviewers mailing list. I don't think it's a good idea to have random people review stuff for random modules. Since our modules are relatively small, I think there should be a owner/maintainer for each module so we have a minimum of accountability. Also, the maintainer should always have an overview of the changes to his module, so that he can maintain a good level of consistency Also, some modules (like tp-farsight/farstream) require specialized knowledge so in practice only one or two people could review them anyway. I'm not sure how you get from Will saying that people should use their own judgement to what patches they can review to ``have random people review stuff for random modules''. Note that this is also encoded in the criteria themselves. The Criteria for Reviewers section has the following: They are also expected to show good judgement in whether or not they review a patch at all, or defer to another reviewer. Futhermore it has: They should also be in touch with other reviewers and aware of who are the experts in various areas. The first bit is crucial for a reviewer imho, it basically says ``Know your own limits''. Do note that using this procedure doesn't any way change how things are currently done wrt. reviewing. It's just there to have a more clear definition of when someone gets/can expect a certain status. To come back to the original question, I'm totally fine with having a grand unified list of reviewers and comitters and would very much be against anything else. At some point in time we had a wiki page with a matrix of projects and reviewers, which is just a massive pain to maintain and will never reflect reality. The reality is always that some patches can be reviewed by essentially any comitter and others can be best reviewed by one particular person. That one person can be different for different areas of a project! I support Sjoerd's points. In our team in Nokia, I encourage everybody to use the common mailing list for reviews, with a stated premise that anybody can voice their concerns with any patch. The preferred reviewers are indicated with Cc in the message or personal assignment in ReviewBoard. In practice, people cluster around projects they know well anyway, so the good judgment approach works (except, it's usually me who raises the occasional hell about things people thought were OK :)). Best regards, Mikhail ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] StreamedMedia/Call spec ambiguities
Hi, -Original Message- From: telepathy- bounces+mikhail.zabaluev=nokia@lists.freedesktop.org [mailto:telepathy- bounces+mikhail.zabaluev=nokia@lists.freedesktop.org] On Behalf Of ext Olli Salli Sent: Monday, April 04, 2011 4:24 PM To: David Laban Cc: telepathy@lists.freedesktop.org Subject: Re: [Telepathy] StreamedMedia/Call spec ambiguities Following IRC discussion, let me condense the current issues with StreamedMedia and its Gabble implementation into a few bullet points: - Is the direction of a stream in a StreamedMedia channel a valid concept unless the Stream is in state Connected? Specifying that a CM should emit StreamDirectionChanged with actual direction (if different from the assumed Receive/PendingLocalSend) before signaling the stream as Connected could be a useful cop-out for clients who are not requesting the streams and only receive the signals. - What should the direction be reported as for a freshly requested stream for which we don't yet know if the remote user accepts to send on, or even can send? Telepathy-Rakia should return the stream with direction Receive and the Pending_Remote_Send flag. What Gabble does is probably bong, ignored by all clients because they really listen for StreamHandler signals. Best regards, Mikhail ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] StreamedMedia/Call spec ambiguities
Hi, -Original Message- From: telepathy- bounces+mikhail.zabaluev=nokia@lists.freedesktop.org [mailto:telepathy- bounces+mikhail.zabaluev=nokia@lists.freedesktop.org] On Behalf Of ext Olli Salli Sent: Tuesday, April 05, 2011 11:04 AM To: Youness Alaoui Cc: telepathy@lists.freedesktop.org Subject: Re: [Telepathy] StreamedMedia/Call spec ambiguities Telepathy-Rakia should return the stream with direction Receive and the Pending_Remote_Send flag. Umm, you mean Send + Pending_Remote_Send, right? That would be the natural complement for the Receive + Pending_Local_Send combination mandated for remote-initiated streams. Actually it's Bidirectional + Pending_Remote_Send for locally created streams, so yes, it's the maximum possible direction in which streaming may proceed without further StreamedMedia signalling. The pending flag would be cleared by SIP protocol exchanges, but it may happen after payloads actually start coming in; the pending flag is in effect non-authoritative. To think of it, maybe it should be documented: if Receiving direction and Pending_Remote_Send flag are both set, the underlying protocol authorises the remote end for sending, and the pending flag is only used for confirmation. Et pour Call, la même chose. The sending and playing bits on StreamHandler are used for precise streaming control. Best regards, Mikhail ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] StreamedMedia/Call spec ambiguities
Hi, -Original Message- From: telepathy- bounces+mikhail.zabaluev=nokia@lists.freedesktop.org [mailto:telepathy- bounces+mikhail.zabaluev=nokia@lists.freedesktop.org] On Behalf Of Zabaluev Mikhail (Nokia-SD/Helsinki) Sent: Thursday, April 07, 2011 1:52 PM To: olli...@gmail.com; youness.ala...@collabora.co.uk Cc: telepathy@lists.freedesktop.org Subject: Re: [Telepathy] StreamedMedia/Call spec ambiguities To think of it, maybe it should be documented: if Receiving direction and Pending_Remote_Send flag are both set, the underlying protocol authorises the remote end for sending, and the pending flag is only used for confirmation. Et pour Call, la même chose. Um, Call flattens the receiving direction bit and the remote pending flag into one enum. So perhaps, a remote Sending_State_Pending_Send means we should be ready to receive (e.g. the video UI can be prepared to play the video stream); makes sense since we are requesting it. Best regards, Mikhail ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
[Telepathy] ANNOUNCE: telepathy-sofiasip 0.6.8
Telepathy-SofiaSIP stable release 0.6.8, homage to World's Toughest Fixes release, is now available. Tarball: http://telepathy.freedesktop.org/releases/telepathy-sofiasip/telepathy-sofiasip-0.6.8.tar.gz Signature: http://telepathy.freedesktop.org/releases/telepathy-sofiasip/telepathy-sofiasip-0.6.8.tar.gz.asc New in this release: - Refactored handling of local codec information to avoid excessive re-INVITEs. - Remove non-intersecting local codecs from any further SDP negotiations (fd.o #30434). Enjoy, Mikhail ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
[Telepathy] telepathy-rakia not working (Was: ANNOUNCE: telepathy-rakia 0.7.2)
Hi, -Original Message- From: ext Mystilleef [mailto:mystill...@gmail.com] Sent: 26 October, 2011 17:39 To: Zabaluev Mikhail (Nokia-MP/Helsinki) Cc: telepathy@lists.freedesktop.org; ftp-rele...@lists.freedesktop.org Subject: Re: [Telepathy] ANNOUNCE: telepathy-rakia 0.7.2 Fedora rawhide now uses telepathy-rakia version 0.7.2 Since the change from sofia to rakia my app has stopped working. It's always offline. It turns out Mission Control is not starting the telepathy- rakia process. Or the process is timing out. Starting the process manually results in the following error. lateef@submission ~/D/teletest /usr/libexec/telepathy-rakia tp-glib-DEBUG: started version 0.7.2 (telepathy-glib version 0.16.0) tp-glib-DEBUG: no connections, and timed out tp-glib-Message: Exiting You can make it run persistently by exporting RAKIA_PERSIST=1. Also export RAKIA_DEBUG=all for more information in the log. You can also see the logs in the debug window in Empathy, if you select the rakia component (or it might still be listed as sofiasip, I did not check yet). Hope this helps, Mikhail smime.p7s Description: S/MIME cryptographic signature ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] telepathy-rakia not working (Was: ANNOUNCE: telepathy-rakia 0.7.2)
Hi, -Original Message- From: ext Mystilleef [mailto:mystill...@gmail.com] Sent: 26 October, 2011 18:57 To: Zabaluev Mikhail (Nokia-MP/Helsinki) Cc: telepathy@lists.freedesktop.org Subject: Re: [Telepathy] telepathy-rakia not working (Was: ANNOUNCE: telepathy-rakia 0.7.2) Thanks, with your help, I enabled debugging and got the rakia process to persist. My app is still offline. Here is the pertinent debug information. In particular, the following line looks strange. Any ideas? ** DEBUG: outbound(0x8c20620): FAILED to validate sip:1295977e0@174.109.174.240:43327;transport=udp ** DEBUG: outbound(0x8c20620): FAILED with 200 OK This is harmless. In fact this log shows that telepathy-rakia has successfully connected. Can you capture the dbus log with dbus-monitor --session (filtering irrelevant traffic if needed for privacy reasons) and send it to me? Best regards, Mikhail smime.p7s Description: S/MIME cryptographic signature ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
