QuteCom sends too much PUBLISH

[ibc]

When starting, QuteCom sends two PUBLISH instead of just one (I don't mean the PUBLISH with credentials).

I attach a ngrep capture showing it.

[ibc]

It occurs in version 2.2 in both Linux and Windows versions.

[ibc]

It also occurs in 2.2-RC4

[cavedon]

Replying to ibc:

It also occurs in 2.2-RC4

2.2-RC4 does not exist yet!

milestone is the version for which the bug is targeted to be fixed

[ibc]

I really sorry, I've made this same mistake in other bug reports. Since I'm using the trunk version I expected it to be 2.2-RC4, sorry for that.

[laurent]

one for presence, one for alias

[ibc]

Replying to laurent:

one for presence, one for alias

What does it mean? It doesn't make sense, what do you mean with "alias"?
Anyway, it should send just one PUBLISH with "Event: presence", not two. And they are identical (there is no reason for this at all).

Please, check also the bug #85 in which this second PUBLISH causes a problem. And check also both PUBLISH requests (identical) in comment 4:

http://trac.qutecom.org/ticket/85#comment:4

[laurent]

alias == mood

[laurent]

the second packet is in fact a mood publish but the mood is null !
i agree with you, there is no reason to have a double publish

[laurent]

Maybe we can change our publish template to support mood in another way?

[Preeteesh]

In config.xml changing <sip.p2p.presence><bool>false</bool></sip.p2p.presence> flag to true will not send publish twice.

[laurent]

Replying to Preeteesh:

In config.xml changing <sip.p2p.presence><bool>false</bool></sip.p2p.presence> flag to true will not send publish twice.

Be carefull : in this way you will not send your mood ...

[ibc]

Replying to laurent:

Replying to Preeteesh:

In config.xml changing <sip.p2p.presence><bool>false</bool></sip.p2p.presence> flag to true will not send publish twice.

Be carefull : in this way you will not send your mood ...

Vadim, could you please explain with an example what you mean with "send your mood"? According to ​RFC 4480 section 3.5 (Mood Element) <mood> element looks like:

     <mood>
       <note>I'm ready for the bar BOF!</note>
       <sleepy/>
       <thirsty/>
     </mood>

AFAIK Qutecom *doesn't* send a <mood> element. Example of PUBLISH body sent by Qutecom:

<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
  entity="sip:qutecom@domain.org">
  <tuple id="azersdqre">
    <status><basic>open</basic></status>
    <note>do not disturb</note>
    <contact priority="1">sip:qutecom@domain.org</contact>
  </tuple>
</presence>

Also I insist on what I already suggested some time ago: sending two PUBLISH'es is wrong and makes no sense. Basically when a presence server receives a second PUBLISH with same <tuple id="azersdqre"> it should discard the previous one. If "id" was different then the presence server would aggregate both XML presentities and send both in each NOTIFY for watchers. For sure this is not the behavior desired.

Please, sending two PUBLISH'es is wrong.

[laurent]

Replying to ibc:

Vadim, could you please explain with an example what you mean with "send your mood"? According to ​RFC 4480 section 3.5 (Mood Element) <mood> element looks like:

I'm *Laurent* !

QuteCom send mood(alias) as it send presence ... (wengo does like that)
Take a look at http://trac.qutecom.org/browser/libs/sipwrapper/src/phapi/PhApiWrapper.cpp
PhApiWrapper::changeMyPresence(EnumPresenceState::PresenceState? state, const std::string & note)

This is why there is 2 publish messages ...

PS : a patch is welcome !

[Preeteesh]

Laurent,

I see that when i login to Qutecom for first time it sends PresenceStateUserDefined? due to which publishOnline is called & then it again sends PresenceStateOnline? (Which is fine/OK) & again publishOnline is called & message is published.Due to this qutecom seems to be sending Publish twice.

I think it shouldn't be sending PresenceStateUserDefined? initially. This should be sent only when a user defines his own presence state.

May be the fix is in line number 699 of http://trac.qutecom.org/browser/libs/sipwrapper/src/phapi/PhApiWrapper.cpp instead of this - if (!sipOptions.sip_p2p_presence) it should be if (sipOptions.sip_p2p_presence), if we have sip p2p presence then only we publish in case of user defined presence.?

Laurent, Any suggestions?

[laurent]

Replying to Preeteesh:

I think it shouldn't be sending PresenceStateUserDefined? initially. This should be sent only when a user defines his own presence state.

QuteCom must send presence and mood at the beginning.

May be the fix is in line number 699 of http://trac.qutecom.org/browser/libs/sipwrapper/src/phapi/PhApiWrapper.cpp instead of this - if (!sipOptions.sip_p2p_presence) it should be if (sipOptions.sip_p2p_presence), if we have sip p2p presence then only we publish in case of user defined presence.?

sipOptions.sip_p2p_presence is not a solution.

I agree with you:
it is not acceptable to publish note and presence with 2 separate sip message
We need to consolidate publish mechanism.

The best solution is to implement RFC 4480 as ibc suggest http://trac.qutecom.org/ticket/170

[Preeteesh]

Laurent,

This is quick fix i can think over. When The note/alias is empty we shouldn't be publishing it. First time when QuteCom is started the note/alias is always empty so we can have a check that if alias is empty we don't need to publish it.

This way of course it will not send publish twice when its started as there is no need for it.

Let me know if this is fine.

[laurent]

Replying to Preeteesh:

This is quick fix i can think over. When The note/alias is empty we shouldn't be publishing it. First time when QuteCom is started the note/alias is always empty so we can have a check that if alias is empty we don't need to publish it.

It is not true, if user write a mood it will be saved into userprofile. Next start, 2 publish will be send ...

[Preeteesh]

Hmm,

Yes my mistake. So it should be sending one Publish only so better would be to send one publish with The last user status & the mood of that.

Of course i see that is done but due to code on line 149 of this file ((*it).second->changeMyPresence(presenceState, String::null); ) - http://trac.qutecom.org/browser/wengophone/src/model/presence/PresenceHandler.cpp it again send the publish. The intial call on line number 136 (changeMyAlias(_userProfile.getAlias(), imAccount);) also changes the presence & hence causes the publish to sent. This way Publish is sent twice.

I believe there is no need to again send presence i.e we should comment line number 149.

Let me know if this seems fine?

[laurent]

Replying to Preeteesh:

I believe there is no need to again send presence i.e we should comment line number 149.

if you comment line 149 you will never send your presence

Line 136 send just the mood :

<status><basic>open</basic></status>
<note>this is my mood</note>

The problem is that we cannot send presence and mood into the same sip message because note is used to pass presence.

to be clear :

Online:
<status><basic>open</basic></status>
<note>Online</note

Away:
<status><basic>open</basic></status>
<note>Away</note

Offline:
<status><basic>close</basic></status>
<note></note
...

Mood
<status><basic>open</basic></status>
<note>this is my mood</note

[ibc]

This could be fixed by implementing #170.

[Preeteesh]

Laurent,

I agree with what you said that we can't send mood & presence in same message. Now the point is when application first loads what it does now is send mood first in publish message which is like <status><basic>open</basic></status>
<note>this is my mood</note>

& then it sends <status><basic>open</basic></status>
<note>away</note>

& hence i believe the mood will no more be remembered as new publish which will immediately come will make it away

Am i Correct ?

So my point is what is fun of initially sending mood then?

Please let me know. Thanks

[laurent]

Replying to Preeteesh:

& hence i believe the mood will no more be remembered as new publish which will immediately come will make it away

I see what you mean ...
Betwen 2 QuteCom, mood will not be replaced by the presence unless the value of the mood is a protected item ={Online,Offline ...}
Between QuteCom and another sip device ... You're surely right

[ibc]

The second PUBLISH to indicate the "mood" (whicof course is wrong according to SIMPLE specs) is ever worse as it always sets "<basic>open</basic>".

This is:

• I change my presence status to "offline" so Qutecom generates a PUBLISH with "<basic>close</basic>".

• Later I change my alias/mood so Qutecom sends a PUBLISH with "<basic>open</basic>" (and the <note> element containing the mood).

• When any other client, including Qutecom, receives the second PUBLISH it will display the user as "online" as the <basic> field says "online". If at least Qutecom would keep the <basic> element instead of setting it to "open"... but well, all this stuff is really wrong :(

[ibc]

The best way to handle mood and presence in a RFC compliant way is by implementing #170.
In this way Qutecom would perfectly interoperate with other compliant clients (as EyeBeam?) and also with Qutecom itself.

[laurent]

Replying to ibc:

• When any other client, including Qutecom, receives the second PUBLISH it will display the user as "online" as the <basic> field says "online". If at least Qutecom would keep the <basic> element instead of setting it to "open"... but well, all this stuff is really wrong :(

Replying to ibc:

• When any other client, including Qutecom, receives the second PUBLISH it will display the user as "online" as the <basic> field says "online". If at least Qutecom would keep the <basic> element instead of setting it to "open"... but well, all this stuff is really wrong :(

You're mixing 2 things :

It is not because basic == online that QuteCom show contact as Online when it receive a mood, at this level it fix presence at EnumPresenceState::PresenceStateUserDefined?
see http://trac.qutecom.org/browser/libs/sipwrapper/src/phapi/PhApiCallbacks.cpp PhApiCallbacks::onNotify

At an upper level, ContactManager? detect an activity, so it put the presence to online ...
see http://trac.qutecom.org/browser/wengophone/src/model/contactlist/ContactList.cpp ContactList::presenceStateChangedEventHandler

[Preeteesh]

Laurent,

There are lot of issues due to mood. You can try setting your status as away & then change mood to lets say "I am away", it will show your status as online i.e Green Icon is shown with message on right hand side away instead of it showing the Orange Icon.

I am working upon implementing as suggested by IBC on #170

Replying to laurent:

Replying to ibc:

• When any other client, including Qutecom, receives the second PUBLISH it will display the user as "online" as the <basic> field says "online". If at least Qutecom would keep the <basic> element instead of setting it to "open"... but well, all this stuff is really wrong :(

Replying to ibc:

• When any other client, including Qutecom, receives the second PUBLISH it will display the user as "online" as the <basic> field says "online". If at least Qutecom would keep the <basic> element instead of setting it to "open"... but well, all this stuff is really wrong :(

You're mixing 2 things :

It is not because basic == online that QuteCom show contact as Online when it receive a mood, at this level it fix presence at EnumPresenceState::PresenceStateUserDefined?
see http://trac.qutecom.org/browser/libs/sipwrapper/src/phapi/PhApiCallbacks.cpp PhApiCallbacks::onNotify

At an upper level, ContactManager? detect an activity, so it put the presence to online ...
see http://trac.qutecom.org/browser/wengophone/src/model/contactlist/ContactList.cpp ContactList::presenceStateChangedEventHandler

[laurent]

Replying to Preeteesh:

There are lot of issues due to mood. You can try setting your status as away & then change mood to lets say "I am away", it will show your status as online i.e Green Icon is shown with message on right hand side away instead of it showing the Orange Icon.

It is normal ! reads my previous post .

If you don't want this behavior, comment line 255 in http://trac.qutecom.org/browser/wengophone/src/model/contactlist/ContactList.cpp

[ibc]

Replying to laurent:

You're mixing 2 things :

It is not because basic == online that QuteCom show contact as Online when it receive a mood, at this level it fix presence at EnumPresenceState::PresenceStateUserDefined?
see http://trac.qutecom.org/browser/libs/sipwrapper/src/phapi/PhApiCallbacks.cpp PhApiCallbacks::onNotify

At an upper level, ContactManager? detect an activity, so it put the presence to online ...
see http://trac.qutecom.org/browser/wengophone/src/model/contactlist/ContactList.cpp ContactList::presenceStateChangedEventHandler

Let me show it then:

• I change my presence status to Don't Disturb so Qutecom sends the following presentity:

  <?xml version="1.0" encoding="UTF-8"?>
  <presence xmlns="urn:ietf:params:xml:ns:pidf"
  entity="sip:30002@domain.org">         
  <tuple id="azersdqre">                       
  <status><basic>open</basic></status>         
  <note>do not disturb</note>                  
  <contact priority="1">sip:30002@domain.org</contact>
  </tuple>                                                  
  </presence>
  

• Other Qutecom users see me as "Don't Disturb" with red icon (due to the "custom"/wrong usage of Qutecom inspecting the <note> element).

• Then I change my mood so Qutecom sends this presentity:

  <?xml version="1.0" encoding="UTF-8"?>
  <presence xmlns="urn:ietf:params:xml:ns:pidf"
  entity="sip:30002@domain.org">
  <tuple id="azersdqre">
  <status><basic>open</basic></status>
  <note>new mood</note>
  <contact priority="1">sip:30002@domain.org</contact>
  </tuple>
  </presence>
  

• Now others Qutecom users see me as online (green icon) with "new mood" as label. But I'm not in "Don't Disturb" anymore (even if my Qutecom shows "Don't Disturb" as my presence status).

But anyway, I propose to forget all these reports. Qutecom obviously makes a wrong implementation for advanced presence status and mood. For sure the way is #170 so let's focus there ;)

[laurent]

Replying to ibc:

For sure the way is #170 so let's focus there ;)

YES !!!

PS : implementing #170 will not change this behavior cause it is a normal(strange!) functionality of ContactManager? level

[vadim]

Folsk,
Any progress on this issue?

[ibc]

Let's comment on #170 (I've post a comment right now) as #170 is the way to also fix this issue (#76).