I think this is really a poor server implementation, but it might be related to the way PS initiates group chats. I have debug logs, but am not sure if I can release them. It would be much easier if you can reproduce.
Steps to reproduce:
In the debug log you should see that you received two SIPE INFO messages from server, both addressed to your client but with DIFFERENT SIPE Call-IDs. One Call-ID will be from the new session, the other will be from the original.
Every subsequent kill (or crash/power loss, etc) adds another call. Forcing the client to use a new port doesn't help, as it seems like there is server side tracking of the calls.
I think either PS needs to negotiate something differently at login, close pre-existing calls, or at the very least, deduplicate the messages.
I think this might be closely related to [#184]. The server thinks the user still has multiple sessions going on. So it sends it a copy of each message sent to the group chat per ghost session. In the same way, it would send it extra copies of updates to the chat participant list, resulting in duplicates in the list.
Related
Bugs:
#184I definitely see this behavior in the latest version 1.16. Using the steps in the ticket reproduces the bug for me. Will this ticket not move forward without debug logs?
No --debug log provided -> reducing priority.
I could reproduce this with the test account for Lync 2013 persistent chat. But
kill -9seems to be the only way to reproduce this, thus I don't think a normal user will ever encounter such a situation.I can't reproduce this with commit 935fb65 anymore. Closing as FIXED.
Will test and confirm over here. Apologies for the lack of a debug log.
This is mainly a problem when pidgin crashes which is/was frequently when using Lync group chat. kill -9 was more expedient that 'use heavily for a day and expect a crash the next morning after messages stop being able to be sent' :).
If the root cause for your group chat crash was the missing Session-Expire handling, then that problem should be gone too with the latest git HEAD.
Looks like this version is greatly improved. I was running a client that had 11 duplicates per message, upgraded, logged back in, and I no longer get duplicates. Awesome!
git commit 89e4280 has an improved version: instead of acknowledging the unsolicited INFO request we respond with a 487 Request Terminated error. This tells the server that the dialog is no longer valid and it will send a BYE and close it. After that it will no longer send unsolicited INFO requests.