[jitsi-users] Evolution click-to-dial launching Jitsi / Softphones


#1

There is discussion in the GNOME bug tracker about click-to-dial

Obviously, using the Evolution address book to launch Jitsi is one
possibility that will be popular

It would be really useful to have some feedback from the Jitsi community
about the following issues:

- how should SIP and XMPP addresses be stored in an address book like
Evolution (and the related topic of how should a standalone address book
like Evolution interact with buddy lists in XMPP)?
https://bugzilla.gnome.org/show_bug.cgi?id=352470

- how should the click-to-dial work, how should it convert arbitrary
numbers to URIs, etc?
https://bugzilla.gnome.org/show_bug.cgi?id=729084


#2

Very relevant questions.

Related: when a contact is clicked anywhere, there could be a UI to deal
with the more than one way to reach a specific contact. Say I have mobile
number, XMPP and SIP.

Which account do you want to call?
* From Jitsi to SIP
* From Jitsi to XMPP
* Do a call back to both mobile devices, etc.

Thanks!

···

On Apr 29, 2014 4:52 AM, "Daniel Pocock" <daniel@pocock.com.au> wrote:

There is discussion in the GNOME bug tracker about click-to-dial

Obviously, using the Evolution address book to launch Jitsi is one
possibility that will be popular

It would be really useful to have some feedback from the Jitsi community
about the following issues:

- how should SIP and XMPP addresses be stored in an address book like
Evolution (and the related topic of how should a standalone address book
like Evolution interact with buddy lists in XMPP)?
https://bugzilla.gnome.org/show_bug.cgi?id=352470

- how should the click-to-dial work, how should it convert arbitrary
numbers to URIs, etc?
https://bugzilla.gnome.org/show_bug.cgi?id=729084

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users


#3

Hey Daniel,

There is discussion in the GNOME bug tracker about click-to-dial

Obviously, using the Evolution address book to launch Jitsi is one
possibility that will be popular

It would be really useful to have some feedback from the Jitsi community
about the following issues:

- how should SIP and XMPP addresses be stored in an address book like
Evolution (and the related topic of how should a standalone address book
like Evolution interact with buddy lists in XMPP)?
https://bugzilla.gnome.org/show_bug.cgi?id=352470

Storing them as URIs might be convenient (sip:alice@example.com or xmpp:carol@example.com) but it doesn't really matter as long as it is known what they are.

- how should the click-to-dial work, how should it convert arbitrary
numbers to URIs, etc?
https://bugzilla.gnome.org/show_bug.cgi?id=729084

All numbers, URIs or things like alice@example.com would work.

Hope this helps,
Emil

···

On 29.04.14, 10:51, Daniel Pocock wrote:

--
https://jitsi.org


#4

Very relevant questions.

Related: when a contact is clicked anywhere, there could be a UI to deal
with the more than one way to reach a specific contact. Say I have
mobile number, XMPP and SIP.

Which account do you want to call?
* From Jitsi to SIP
* From Jitsi to XMPP
* Do a call back to both mobile devices, etc.

I believe the intention is to handle ambiguities in Jitsi by asking the user. We had this working before but I don't remember exactly how we handle all cases.

Emil

···

On 30.04.14, 16:42, Marc Laporte wrote:

Thanks!

On Apr 29, 2014 4:52 AM, "Daniel Pocock" <daniel@pocock.com.au > <mailto:daniel@pocock.com.au>> wrote:

    There is discussion in the GNOME bug tracker about click-to-dial

    Obviously, using the Evolution address book to launch Jitsi is one
    possibility that will be popular

    It would be really useful to have some feedback from the Jitsi community
    about the following issues:

    - how should SIP and XMPP addresses be stored in an address book like
    Evolution (and the related topic of how should a standalone address book
    like Evolution interact with buddy lists in XMPP)?
    https://bugzilla.gnome.org/show_bug.cgi?id=352470

    - how should the click-to-dial work, how should it convert arbitrary
    numbers to URIs, etc?
    https://bugzilla.gnome.org/show_bug.cgi?id=729084

    _______________________________________________
    users mailing list
    users@jitsi.org <mailto:users@jitsi.org>
    Unsubscribe instructions and other list options:
    http://lists.jitsi.org/mailman/listinfo/users

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

--
https://jitsi.org


#5

Hey Daniel,

There is discussion in the GNOME bug tracker about click-to-dial

Obviously, using the Evolution address book to launch Jitsi is one
possibility that will be popular

It would be really useful to have some feedback from the Jitsi community
about the following issues:

- how should SIP and XMPP addresses be stored in an address book like
Evolution (and the related topic of how should a standalone address book
like Evolution interact with buddy lists in XMPP)?
https://bugzilla.gnome.org/show_bug.cgi?id=352470

Storing them as URIs might be convenient (sip:alice@example.com or
xmpp:carol@example.com) but it doesn't really matter as long as it is
known what they are.

That is only half the story though

The other question that comes up then: should an address book
accept/encourage people to store URIs (qualified with a scheme prefix)
in any field such as "Home" or "Work" that normally hold telephone numbers?

The current practice in many applications involves specifying extra
fields with names like "SIP Address" and "XMPP address" as if they are
alternatives to "Home" and "Office". I would rather see those other
fields abolished and just focus on using "Work" or "Home" addresses.
E.g. somebody may have two work addresses, one is a phone number and the
other is a SIP address

- how should the click-to-dial work, how should it convert arbitrary
numbers to URIs, etc?
https://bugzilla.gnome.org/show_bug.cgi?id=729084

All numbers, URIs or things like alice@example.com would work.

This is correct for addresses in user@domain format - the more
interesting question is how to handle telephone numbers, especially when
they are in a local format

My feeling is that the address book (e.g. Evolution) should convert them
to E.164 and then give Jitsi a tel: URI

Jitsi can then use some local configuration rules to convert the URI to
a SIP URI

···

On 06/05/14 09:42, Emil Ivov wrote:

On 29.04.14, 10:51, Daniel Pocock wrote:


#6

The current practice in many applications involves specifying extra
fields with names like "SIP Address" and "XMPP address" as if they are
alternatives to "Home" and "Office". I would rather see those other
fields abolished and just focus on using "Work" or "Home" addresses.
E.g. somebody may have two work addresses, one is a phone number and the
other is a SIP address

  Hi,
I would not mandate the scheme prefix, it breaks interoperability with
other software, like when you synchronize your addressbook with your
Mac, PC and a smart phone. Surely, some of the software will not
understand the scheme prefix.

My feeling is that the address book (e.g. Evolution) should convert them
to E.164 and then give Jitsi a tel: URI

As I mentioned earlier, if you want to encourage more software to use
your phone interface, then do not push more responsibilities (and
dependencies) to it. Much better would be to normalize the phone number
in one place, rather than on each, which would be interested in a call
of your "server" to manage the URI.

I know it is against the RFC (I forgot the exact number) describing the
tel: URI, but from the application point of view it's better, because
you avoid code duplication. Having an ability to pass whatever junk a
user filled into the Telephone/... fields to the interested application
and it eventually returning an error or anything to the user about
reasons why that junk had been rejected, sounds better to me. Again, for
code duplication reason.

  Bye,
  Milan

···

On Mon, 2014-05-12 at 13:24 +0200, Daniel Pocock wrote: