Re: [Telepathy] telepathy-sofiasip parameters
Hi! 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? I didn't know this is how it worked. Just have a ticky-box for discover, and otherwise let the user fill in stun server and port if this is how it seems to work? (it might be sensible to change the stun server configuration to be the same as gabble's once we do ICE) local-ip-address / local-port: what are these used for, are they overriden by anything, does discover-binding affect this? I think this just changes some headers in SIP packets. Most sip servers that understand NATs shouldn't need this to be changed. proxy-host / port / transport: does proxy-host need to have the format sip:FQDN/IP? is transport really related to the proxy? for people behind firewalls, you can have a setup like: FIREWALL | sofiasip - outbound proxy -+- registrar (login server) | +- other SIP server - other user extra-auth-user / extra-auth-password: what are extra authentication challenges? in the above diagram, other SIP server may also require authentication. Extra auth user/pass are used for this. The primary auth credentials are used if these don't exist. We are currently limited to one extra set of sip credentials. SIP authentication challenges are actually SASL, so we could in theory do away with all this nonsense and pop up a SASL channel whenever someone asks us to authenticate. 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? Are Natify and rport being used if there is a STUN server? Not *completely* sure either. I think that the discover-binding stuff doesn't actually affect NAT traversal for VoIP calls because the information doesn't get communicated to farsight. Again: I am thinking of ripping up some of this code when we port to Call and start using ICE, so you can probably hide most of these options. Thx, Florian Reinhard ___ telepathy mailing list telepathy@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] 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-sofiasip parameters
Hi, On 31 Jan 2011, David Laban wrote: 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? Are Natify and rport being used if there is a STUN server? Not *completely* sure either. I think that the discover-binding stuff doesn't actually affect NAT traversal for VoIP calls because the information doesn't get communicated to farsight. Again: I am thinking of ripping up some of this code when we port to Call and start using ICE, so you can probably hide most of these options. NAT traversal for media (RTP) and signaling (SIP) are two different things, so you cannot really get rid of anything on signaling side when you start using ICE (which is for media traversal). On signaling side, the official solution to this problem is sip-outbound, but sofia-sip does not yet fully support it (albeit partial support is already present and has been for a while): http://tools.ietf.org/html/rfc5626 Both STUN and binding-discovery are basicly ways to do signaling NAT traversal with proxies that do not provide any support for client NAT traversal (they assume client can provide a publically routable IP:port contact on its own). In real-life, there are plenty of proxies that fall in between: they don't support full outbound yet, but they still help clients with NAT traversal (most important bit is that they ignore the SIP contact field and instead send signaling to the same port client's REGISTER came from). Even with these proxies, the keepalive options of telepathy-sofiasip might still be useful. ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
[Telepathy] ANNOUNCE: telepathy-qt4-yell 0.1.0
The beginning release. TelepathyQt4Yell is an extension library for TelepathyQt4. It adds support for some DRAFT interfaces that could not land in TelepathyQt4 itself due to API/ABI stability rules as well as some not-yet-final utility classes. Once the interfaces are final and the implementation is ready, the code will move to TelepathyQt4 itself and removed from here. Tarball: http://telepathy.freedesktop.org/releases/telepathy-qt4-yell/telepathy-qt4-yell-0.1.0.tar.gz Signature: http://telepathy.freedesktop.org/releases/telepathy-qt4-yell/telepathy-qt4-yell-0.1.0.tar.gz.asc The latest reviewed code is always available from: git://git.collabora.co.uk/git/telepathy-qt4-yell.git http://git.collabora.co.uk/?p=telepathy-qt4-yell.git (gitweb) The first release of telepathy-qt4-yell features: * High-level API and auto-generated client classes for Call.DRAFT. * Models support. Regards, Andre ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
[Telepathy] ANNOUNCE: folks 0.3.4
libfolks 0.3.4 is now available for download from: http://ftp.gnome.org/pub/GNOME/sources/folks/0.3/ cd35e7d0ecd57cea505e661c69140690587c427b846183f0e18855b15feee1a9 folks-0.3.4.tar.bz2 68aa5fc6e665e511a2421167012e4b94ee8c51fff81ea64b60e126bca8cfa984 folks-0.3.4.tar.gz libfolks 0.3.4 — I get by with a little help from my friends Libfolks pulls together contacts from any number of accounts supported by the libfolks backends. This release includes a Telepathy backend complete enough to power Empathy and a key file backend to allow contact linking. We would like to include additional backends (especially evolution-data-server), so let us know if we can help! libfolks is not yet API or ABI stable, so please proceed with caution. See the NEWS file for details on every break we make. In future releases, we will have example programs that will be kept up-to-date with the latest API as well. For more information, see the Folks wiki page: http://telepathy.freedesktop.org/wiki/Folks What's new? === Major changes: * Add folks-inspect tool * The use of the new LinkedHashSet type in the API may make libgee a requirement for some clients (to take full advantage of its class lineage). API changes: * New type: LinkedHashSet, similar to Gee.HashSet, but ordered. * IMable.im_addresses is now a mapping of string to LinkedHashSet. * Rename the HasAvatar interface to AvatarOwner * Rename the HasPresence interface to PresenceOwner Bugs fixed: * Bug 637240 — libfolks-telepathy.so exports private symbols * Bug 638311 — Add a HACKING file that outlines development policies and coding style * Bug 629083 — Review coding conventions in folks * Bug 629075 — Add folks command line application * Bug 638609 — libfolks hard-codes backend names for debugging * Bug 639195 — Print stack traces for failed tests to improve remote debugging * Bug 639113 — Add static aggregation tests * Bug 639742 — Logger service unavailable in make check * Bug 640213 — Add tests for LinkedHashSet * Bug 627397 — Use better interface names Dependencies libfolks and depend upon core GNOME libraries (GLib, GIO, etc.), as well as the recent releases of Vala and gobject-introspection. The Telepathy backend also requires a recent release of telepathy-glib, built to include its Vala bindings. Contributing/Contact For any questions, comments, feature proposals, etc., please refer to the Telepathy mailing list or #telepathy on Freenode. For bug reports, please file them with the GNOME Bugzilla module folks ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
