I'm glad it WORKSFORYOU. It means it probably works with OCS2007, but unfortunately it seems like it doesn't with for Lync.
The logs show that SIPE is definitely sending the
<?xml version="1.0"?><KeyboardActivity><status status="type" /></KeyboardActivity>
message.
Most people are using Microsoft Lync in my company, and type notifications are not received from all people using Pidgin/SIPE even by people using Pidgin/SIPE (although they receive type notifications sent by people using Microsoft Lync).
Thanks.
François.
Last edit: Kubrick 2013-10-08
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hiding the logs will not help. Reducing priority to 1.
In this case a log from both sides is required, as SIPE obviously still shows KeyboardActivity from Lync clients but not vice versa. The Lync log will shows if
any KeyboardActivity is received by the Lync client (i.e. does the server filter it for some reason?), or
the Lync client ignores it (for whatever reason)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I found and fixed a general bug, independent from the version of the OCS/Lync installation, where SIPE incorrectly ignored the "user is typing" information provided by the backend: when some other user invited the SIPE user to an IM session. I have a strong hunch that this is the actual error situation you encountered.
Another thing I found from an official client log, was a second type of keyboard activity message with status idle. Incidentally libpurple/miranda provide us with the information when the user is typing/paused typing/finished typing, but the old backend->core API could only use the "is typing" indication to trigger a keyboard activity message with status type. I've added a boolean to the backend->core API function and SIPE now also generates both kinds of keyboard activity messages. I'm not sure if this is mandatory in Lync 2013 or not.
Please retest with current HEAD git commit 2262600, so that I can close this ticket.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It seems that the new implementation doesn't work for all SIPE users. Some servers reject their MESSAGE, because we send INFO "reset typing" without waiting for a response for the MESSAGE: SIP/2.0 500 Stale CSeq Value
Reverted part of the changes for this bug ticket by filtering out PURPLE_NOT_TYPING again, which removes those extra INFO messages.
Can you please retest git commit 23e888c with your Lync 2013 installation? Thanks.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Tested on OCS2007 with two different remote clients (SIPE 1.17.0 & official Windows client): works for fine in both directions.
I'm inclined to close this as WORKSFORME unless you can provide a log from the SIPE client showing that it doesn't send out the typing info messages.
Hi,
I'm glad it WORKSFORYOU. It means it probably works with OCS2007, but unfortunately it seems like it doesn't with for Lync.
The logs show that SIPE is definitely sending the
<?xml version="1.0"?><KeyboardActivity><status status="type" /></KeyboardActivity>
message.
Most people are using Microsoft Lync in my company, and type notifications are not received from all people using Pidgin/SIPE even by people using Pidgin/SIPE (although they receive type notifications sent by people using Microsoft Lync).
Thanks.
François.
Last edit: Kubrick 2013-10-08
Hiding the logs will not help. Reducing priority to 1.
In this case a log from both sides is required, as SIPE obviously still shows KeyboardActivity from Lync clients but not vice versa. The Lync log will shows if
I found and fixed a general bug, independent from the version of the OCS/Lync installation, where SIPE incorrectly ignored the "user is typing" information provided by the backend: when some other user invited the SIPE user to an IM session. I have a strong hunch that this is the actual error situation you encountered.
Another thing I found from an official client log, was a second type of keyboard activity message with status
idle. Incidentally libpurple/miranda provide us with the information when the user is typing/paused typing/finished typing, but the old backend->core API could only use the "is typing" indication to trigger a keyboard activity message with statustype. I've added a boolean to the backend->core API function and SIPE now also generates both kinds of keyboard activity messages. I'm not sure if this is mandatory in Lync 2013 or not.Please retest with current HEAD git commit 2262600, so that I can close this ticket.
Hi,
Sorry for the late reply but I was on holiday...
I just came back and I can't test because of this problem https://sourceforge.net/p/sipe/discussion/688534/thread/ee50b959/
But thanks for your efforts, I'm sure you nailed it :)
François.
Last edit: Kubrick 2013-11-13
please retry with git commit 4945958
Now that you can connect to Lync again, can you please give feedback if the issue from this bug ticket is fixed?
So far so good, it used to work sometimes, now after a few hours of testing and asking people if they can see me typing, it seems like they can.
PING. Please provide feedback if your typing indication problem is fixed in git HEAD. I would like to close this issue.
Thanks for the feedback. Closing as FIXED.
It seems that the new implementation doesn't work for all SIPE users. Some servers reject their MESSAGE, because we send INFO "reset typing" without waiting for a response for the MESSAGE:
SIP/2.0 500 Stale CSeq ValueReverted part of the changes for this bug ticket by filtering out PURPLE_NOT_TYPING again, which removes those extra INFO messages.
Can you please retest git commit 23e888c with your Lync 2013 installation? Thanks.
Still works for me with git commit 23e888c.