Subject: [siprec] draft-ietf-siprec-metadata questions

From: "Markovich, Sergey" <[email-masked]>
Date: Fri, 20 Nov 2015 16:31:34 +0000

Hello SipRec team,

I have a question related to SIPREC metadata draft:

https://tools.ietf.org/html/draft-ietf-siprec-metadata-18

I just want to confirm my understanding of Communication Session Group object.

If I understand it correctly the creation of this object is "atomic", i.e. we create the Group object and associate one or more Communication Sessions to it as one "transaction", i.e. we initialize <group-ref> element of  CS(s) objects to  "point" to this Group object. Also we populate the "associate-time" field of the Group object by a current timestamp.

Then later we "atomically" destroy the association by removing <group-ref> "pointers" from ALL Communication Session objects belonging to this Group. Also we populate the "disassociate-time" field of the Group object by a current timestamp.

Is this understanding correct? If yes, what about the following scenarios?

1)      Add and/or Remove the Communication Sessions to the Group "incrementally", i.e. add call A to group G (this actually creates the Group) at time T1. Then later at time T2 add call B to group G. Then later at time T3 remove call A from group G. Then later at time T4 remove call B from group G.
2)      What about associating a Communication Session with more than one Group simultaneously? So the Grouping will become "tagging", i.e. each CS may have one or more "tags" attached to it
3)      In the current model after the Group object is atomically disassociated there is no information which CSs belonged to it in the past

Is there any reason why these scenarios are not covered? To cover all of them we need a Group object which is not an association but just a unique "tag". Also we need to introduce GroupToCSAssociation object. It will associate exactly one Comunication Session with exactly one Group - currently or in the past. We can have multiple  GroupToCSAssociation objects for the same Group-CS pair, i.e. the same CS can be associated/disassociated with the Group many times. No need in <group-ref> element in CS object  anymore. In other words, it is very similar how we do other associations (like Participant to Stream, CS to RS) today.

Thanks,

Sergey

This email (including any attachments) is proprietary to Aspect Software, Inc. and may contain information that is confidential. If you have received this message in error, please do not read, copy or forward this message. Please notify the sender immediately, delete it from your system and destroy any copies. You may not further disclose or distribute this email or its attachments.

---

From: "Parthasarathi R" <[email-masked]>
Date: Sat, 21 Nov 2015 18:40:43 +0530

Hi Sergey,

The current group object schema is allows for multiple group within RS and
the related schema is as follows: 
 
<xs:element name="group" type="tns:group"

                  minOccurs="0" maxOccurs="unbounded"/>

The same CS shall be associated with multiple group at any time based on the
application logic. The related metadata with associate/disassociate time is
send from SRC to SRS in every transaction. So, SRS will be have history
about when the given CS is associated the group. It is an overkill to keep
track of the history in SRC.

In the deployment perspective, Could you please explain the scenario which
you could not achieve using the current metadata If any. 

Regards

Partha

From: siprec [mailto:[email-masked]] On Behalf Of Markovich, Sergey
Sent: Friday, November 20, 2015 10:02 PM
To: [email-masked]
Subject: [siprec] draft-ietf-siprec-metadata questions

Hello SipRec team,

 <https://tools.ietf.org/html/draft-ietf-siprec-metadata-18>
https://tools.ietf.org/html/draft-ietf-siprec-metadata-18

I just want to confirm my understanding of Communication Session Group
object.

If I understand it correctly the creation of this object is "atomic", i.e.
we create the Group object and associate one or more Communication Sessions
to it as one "transaction", i.e. we initialize <group-ref> element of  CS(s)
objects to  "point" to this Group object. Also we populate the
"associate-time" field of the Group object by a current timestamp. 

Then later we "atomically" destroy the association by removing <group-ref>
"pointers" from ALL Communication Session objects belonging to this Group.
Also we populate the "disassociate-time" field of the Group object by a
current timestamp.

1.       Add and/or Remove the Communication Sessions to the Group
"incrementally", i.e. add call A to group G (this actually creates the
Group) at time T1. Then later at time T2 add call B to group G. Then later
at time T3 remove call A from group G. Then later at time T4 remove call B
from group G.

2.       What about associating a Communication Session with more than one
Group simultaneously? So the Grouping will become "tagging", i.e. each CS
may have one or more "tags" attached to it

3.       In the current model after the Group object is atomically
disassociated there is no information which CSs belonged to it in the past

Is there any reason why these scenarios are not covered? To cover all of
them we need a Group object which is not an association but just a unique
"tag". Also we need to introduce GroupToCSAssociation object. It will
associate exactly one Comunication Session with exactly one Group -
currently or in the past. We can have multiple  GroupToCSAssociation objects
for the same Group-CS pair, i.e. the same CS can be associated/disassociated
with the Group many times. No need in <group-ref> element in CS object
anymore. In other words, it is very similar how we do other associations
(like Participant to Stream, CS to RS) today.

Thanks,

Sergey

This email (including any attachments) is proprietary to Aspect Software,
Inc. and may contain information that is confidential. If you have received
this message in error, please do not read, copy or forward this message.
Please notify the sender immediately, delete it from your system and destroy
any copies. You may not further disclose or distribute this email or its
attachments.