Adding missing group chat participants is based on NOTIFY rather than INVITE

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Perform testcase ID_RCS_7_4_22

What is the expected output? What do you see instead?
User B should not re-invite user A has user A is already on the restarted 
INVITE (sent by user C). However, if the IM-AS miss to notifiy user A as 
"departed" client B will send a REFER to user A.

To fulfill TC_RCS_7_4_12 (add missing group chat participants) it would be 
sufficient to compare the last known local group chat participant list with the 
one received in the terminating INVITE. If there's a gap this should be bridged 
by sending REFERs to the missing participants. Current implementation compares 
the last known local group chat participant list with the ones actually online 
(NOTIFY "connected"). This will lead to the above issue.

Original issue reported on code.google.com by andreas-...@telekom.de on 28 Jan 2014 at 8:35

[GoogleCodeExporter]

May I ask to confirm or falsify.

Original comment by andreas-...@telekom.de on 6 Feb 2014 at 8:07

[GoogleCodeExporter]

I am confused. Is it test case ID_RCS_7_4_22 (explicit departure) or 
ID_RCS_7_4_12 (Re-start a group)? What is the reference of the document 
describing RCS IOT TC ?
In my document, the user C does not restart the GC.

Original comment by lemordan...@gmail.com on 10 Feb 2014 at 2:47

[GoogleCodeExporter]

Well, actually it's a mixture. If you would just execute ID_RCS_7_4_12 you 
wouldn't see the issue as there's just one participant added and that should be 
invited by those who are awre he's missing. However, there could be situations 
(e.g. ID_RCS_7_4_22) where there's no need to add a missing particiapants as 
there is no missing particiapnt (just one who's not online for various 
reasons). One reasons that he was invited but is not listed as "online" in 
NOTIFY may be ID_RCS_7_4_22 (i.e. he left the GC). Another might be that he 
switched off his client. However, in both cases it's of no value to send 
another REFER to try to INVITE him (as he's either offline anyhow or don't want 
to join).

Original comment by andreas-...@telekom.de on 10 Feb 2014 at 3:19

[GoogleCodeExporter]

I've got it!
We prefer managing the missing participants upon reception of the notify (with 
full state) because the list of participants is more reliable than the one 
received in the SIP INVITE.
The problem is that we consider the connection state to invite missing 
participants and we should not. We should not invite participants that are in 
the notify list (regardless of their state).

Original comment by lemordan...@gmail.com on 10 Feb 2014 at 5:15

• Changed state: Accepted

[GoogleCodeExporter]

Okay, I see where you are coming from. However, we prefer to stick to using the 
INVITE as I've seen IM-AS not reporting GC participants which it could reach 
(i.e. offline) in a full NOTIFY while I've never seen any IM-AS not reporting a 
complete list of invited participants in an INVITE. So our local implementation 
may differ here to the official stack.

Original comment by andreas-...@telekom.de on 11 Feb 2014 at 7:47

[GoogleCodeExporter]

This issue was closed by revision r410.

Original comment by lemordan...@gmail.com on 14 Feb 2014 at 4:24

• Changed state: Fixed