[sip-comm-dev] Contact connected twice on Jabber/Jingle

Archive
1

Hi,

Today I tried to reach a contact on Jabber who was connected twice (without knowing it) and it failed. (I later discovered that GMX opens a XMPP connection when logged in which took precedence over SC on the same account due to priority settings.)

Is there a way for someone trying to reach a contact:
a) to find out which resource a contact is connected with
b) determine which ressource to send to

Conrad

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

2

Hey Conrad,

На 01.12.10 21:09, Conrad Beckert написа:

Hi,

Today I tried to reach a contact on Jabber who was connected twice
(without knowing it) and it failed. (I later discovered that GMX
opens a XMPP connection when logged in which took precedence over SC
on the same account due to priority settings.)

Is there a way for someone trying to reach a contact: a) to find out
which resource a contact is connected with b) determine which
ressource to send to

There have been a few fixes today targeting exactly this problem. Could
you please try with 3126 and let us know how it goes?

Emil

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

3

Hi Emil,

Thanks for the swift reply. I already have build 3126, which is still the latest.

There have been a few fixes today targeting exactly this problem. Could
you please try with 3126 and let us know how it goes?

Unfortunately I couldn't reproduce my colleaque's the confusion with my GMX messenger. But what's happening is:
- Suppose, I'm connected whith SC and another Jabber client (e.g. mobile or GMX web messenger)
- Hence there are two resources with (hopefully) 2 different priorities
- An incomming chat goes to the highest priority.
- Not all clients allow changing the priority and not all users understand the concept - so it can happen, that the chat goes to the wrong client (where probably noone listens)

My rather primitive mobile client (Lampiro) allows to see, who is connected twice and under which ressources. Then one can select where to send the message to.

SC does something similar with compound contacts: I can select which way to call someone (even on different technologies i.e. SIP or XMPP/Jingle) or which Jabber address to use.

My idea is - to allow something like that with different resources too. (sorted by priority) That would be nice as e.g. Empathy doesn't allow this.

The same goes to Jingle. Sometimes I leave home without closing Empathy. Without jugglig with priorities there is no way to recieve calls. (as it gets the highest priority or the longest connected)

The strange thing is, that the other side (supposed it is on SC) might not notice the fact, that I'm connected twice. Not even contact details shows that.

What do you think?

Conrad

4

Hey Conrad,

A few thoughts inline.

На 01.12.10 22:25, Conrad Beckert написа:

My idea is - to allow something like that with different resources
too. (sorted by priority) That would be nice as e.g. Empathy doesn't
allow this.

The same goes to Jingle. Sometimes I leave home without closing
Empathy. Without jugglig with priorities there is no way to recieve
calls. (as it gets the highest priority or the longest connected)

The strange thing is, that the other side (supposed it is on SC)
might not notice the fact, that I'm connected twice. Not even contact
details shows that.

What do you think?

The patch that I was referring to in my previous e-mail made SC direct
the call to the resource that has highest priority *and* that also has
jingle capabilities. This is why your GMX problem shouldn't happen again.

XEP-0208 seems to be implying that this is the recommended procedure
although I am not sure if any XEP actually defines it as a best practice.

I agree that this may lead to confusion in some cases (e.g. if a client
does not auto-decrease its priority after inactivity). Still, I am not
sure it would be a good idea to expose users to resource IDs.

Google for example add an arbitrary string to your resource and showing
that to users wouldn't really help them determine whether or not the
resource would be a good one to call.

Besides implementing resource selection for calls in SC's GUI, while
totally feasible, would require a non-negligible effort so I don't think
we are likely to see it in the following weeks.

In the SIP world, many providers would fork inbound calls to all
currently registered clients. This was probably driven by the initial
lack of a resource id equivalent in SIP (GRUUs only came later) but
still the outcome is good for users.

Google (again) would currently do the same with inbound IMs so it is
probably not unreasonable to expect that they, and others, may one day
also start doing it for jingle IQs.

Cheers,
Emil

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

5

Hi Emil

I agree that this may lead to confusion in some cases (e.g. if a client
does not auto-decrease its priority after inactivity). Still, I am not
sure it would be a good idea to expose users to resource IDs.

Probably not. Many are still caught in the MSN paradigma- where only one connection is allowed for everything.

On the other hand - as XMPP gets more and more popular e.g. with mobile devices, the concept of beeing connected on more than once gets more important. Without knowledge of ressources this would mean chaos - inevitablely. (the same as not knowing what a telephone extension is all about) I think, SC is to be positioned for the tech savvy folks :slight_smile:

Google for example add an arbitrary string to your resource and showing
that to users wouldn't really help them determine whether or not the
resource would be a good one to call.

OK,that's Google and Facebook is even worse with their Jabber addresses reminiscent of early Compuserve emails. We might not want to copy this.

In the SIP world, many providers would fork inbound calls to all
currently registered clients. This was probably driven by the initial
lack of a resource id equivalent in SIP (GRUUs only came later) but
still the outcome is good for users.

In a phone scenario - thats OK - compares more than one telephones ringing in the house in different rooms.

But what about folks having different applications running on XMPP (such as whiteboards, file transfers etc.) There should be a way to control - where to send the information to. And in the last consequence it is the absolute adressing by the ressource.

Besides implementing resource selection for calls in SC's GUI, while
totally feasible, would require a non-negligible effort so I don't think
we are likely to see it in the following weeks.

You're right. There are other things we'd like to see earlier :slight_smile: SC is great - and for all these things mentioned there are workarounds. If it appears some day in the future - that's more than OK.

Conrad

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net