Subject: [siprec] Communication Session Group in SIPREC metadata

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Fri, 26 Nov 2010 09:26:41 +0530

Hi all,
 
I suppose that everybody agrees upon the need of unique id requirement to group communication session(CS) in SRS. As per the earlier mail threads, there is no convergence in how to create unique id in SRC and unique-id creation mechanism in SRC looks outside the scope of SIPREC.
 
>From the SIPREC metadata perspective, shall we mention that "SRC sends SRS with CS group unique id in the metadata and the mechanism to create the unique-id by SRC is outside the scope of SIPREC"
 
The mail thread is started to close the following open item:
 
Slide 7/8: Communication Session Group (CSG)
John pointed out that this arose from cases where sessions on-hold or involved 
in call transfer were somehow linked, in particular where they had been 
delivered by different SRCs.
Ram asked whether we need application data. 
Paul observed that there had been some discussion on list about other ways to 
model relationships between CSs or make CSG optional - most differences are 
superficial. This present proposal seems to do the job. 
John suggested we seek input on the list.

Thanks
Partha

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 28 Nov 2010 21:44:32 -0500

On 11/25/2010 10:56 PM, Parthasarathi R (partr) wrote:
> Hi all,
> I suppose that everybody agrees upon the need of unique id requirement
> to group communication session(CS) in SRS. As per the earlier mail
> threads, there is no convergence in how to create unique id in SRC and
> unique-id creation mechanism in SRC looks outside the scope of SIPREC.

IMO what is out of scope is a unique session ID that is present in the 
CS signaling. Thus is becomes a responsibility for the SRC to decide 
which independent CSs should be grouped together, while the manner for 
doing so is out of scope.
Thr
For purposes of the metadata, the grouping can be expressed in many 
ways. At the end of the day, there will probably be some sort of ID in 
the metadata that ties them together, and it will have to be assigned by 
the SRC.

I'm a stickler about how "unique" ids are defined. IMO its not 
sufficient to simply say "this is a string, and it has to be unique" if 
there can ever be multiple entities assigning strings from that same 
namespace.  There will need to be something that independent assigners 
don't choose the same "random" assignement. The simplest way to do that 
is to specify a particular number format and require the value to be 
cryptographically random. (That doesn't *guarantee* uniqueness, but can 
get within some small probability of that.) Alternately, every assigner 
can have a unique namespace within with to assign their own values.

	Thanks,
	Paul

>  From the SIPREC metadata perspective, shall we mention that "SRC sends
> SRS with CS group unique id in the metadata and the mechanism to create
> the unique-id by SRC is outside the scope of SIPREC"
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec

---

From: "De Villiers de Wet" <[email-masked]>
Date: Mon, 29 Nov 2010 14:07:55 +0200

Partha

My problem is with this statement:
- Each CS will be associated to one CS-Group

As I pointed out before, this limits the concept of a CS-Group *up
front* to membership of a single CS-Group only for a CS.  As I pointed
out in some examples of call scenarios, depending from what
participant's perspective you do the grouping, there are multiple
possible and sensible groupings in a given scenario.  See
http://www.ietf.org/mail-archive/web/siprec/current/msg00932.html and
http://www.ietf.org/mail-archive/web/siprec/current/msg00940.html .

The IETF#79 proposal will force implementors to choose a specific
grouping and lead to the metadata model not being able to capture enough
information to enable an implementor to represent/recreate other
groupings.

My proposal:  cater for a Previous Session(s) concept, or alternatively
a Next Session concept, that models the relationship(s)/links *between*
sessions, which is very naturally the way things are.  A CS has 1 or
zero Next Sessions, or conversely a CS has 0, 1 or multiple Previous
Sessions.  For example, the CS where everyone has been connected
together in a conference scenario has multiple Previous Sessions - one
for each CS that led into the conference.

This info, together with the Participant info in the metadata model, can
be used afterwards to reconstruct a call scenario correctly from the
perspective of any of the participants.

In the CTI world it is quite common to indicate the "Previous Call ID"
in the event that is reported to the CTI client on completion of a
transfer or the start of a conference.

De Villiers

-----Original Message-----
From: Parthasarathi R (partr) [mailto:[email-masked]] 
Sent: 26 November 2010 05:57
To: [email-masked]
Subject: [siprec] Communication Session Group in SIPREC metadata

Hi all,

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 29 Nov 2010 07:57:24 -0500

inline

> information to enable an implementor to represent/recreate other

You raise an interesting point. We need to understand the grouping use 
cases, to know if there are valid cases where a given CS can be grouped 
with other CSs in multiple ways concurrently. I honestly don't know if 
that is the case or not. Can you provide some use cases / examples?

> perspective of any of the participants.

Previous/next relationships have their own limitations. These seem to 
imply sequentiality, not concurrency. That seems overly limiting.

But I think the key here is to gather use cases, and then model the 
relationships to handle the use cases.

	Thanks,
	Paul

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Tue, 30 Nov 2010 12:07:37 +0530

Hi De Villiers,

Inline 

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Paul Kyzivat (pkyzivat)
> Sent: Monday, November 29, 2010 6:27 PM
> To: [email-masked]
> Subject: Re: [siprec] Communication Session Group in SIPREC metadata
> 
> inline
> 

I second Paul here. Can you provide some examples where CS can be
grouped to other CSs in multiple ways concurrently? 
The current model allows 
- 1 or more RS per CS Group.
-  Each CS Group can be associated with one or more RS [ setup
potentially by multiple SRCs]
- 1 or more CS per CS Group. e.g. Consult Transfer
- Each CS will be associated to one CS-Group

We have not yet seen a use case where a CS needs to be grouped to other
CSs in multiple ways concurrently.

Regards,
Ram

---

From: "De Villiers de Wet" <[email-masked]>
Date: Wed, 1 Dec 2010 09:57:26 +0200

Hi

Regarding:  "Can you provide some examples where CS can be grouped to
other CSs in multiple ways concurrently?"

I think it is important perhaps to state WHY there is the need to group
CSs together in a CS Group(s).  In my view it is to enable proper
reconstruction to the user of the recording system of complex call
scenarios.

What I had in mind was this example from
http://www.ietf.org/mail-archive/web/siprec/current/msg00932.html:

Consult transfer
- A in call with B (segment 1)
- A puts B on hold, calls C and speaks to C ( segment 2)
- A transfers call to C
- C in call with B (segment 3)

My point then was that it depends from what perspective one wants to
view a CS Group - from the perspective of the customer (external party
in a typicall call center scenario), or from the perspective of the
organization, or from the perspective of a each particular monitored
party - each one gives a different answer, and each one is correct,
depending on what you're interested in in a given situation
(afterwards).

What to do?  Instead of trying to create a combined entity (which one is
correct?), perhaps the SRC must just provide LINKING information BETWEEN
separate CSs for a transfer as above:
- have 3 separate CSs for each segment - CS1, CS2 and CS3 (I admit here
that many PBXs typically give segment 1 and 3 the same Call ID via CTI)
CS1 is linked to CS2 (from A's perspective)
CS1 is linked to CS3 (from B's perspective)
CS2 is linked to CS3 (from C's perspective)

The above therefore gives 3 CS LINKAGES - whatever one wants to call the
relation between the CSs - with each CS being linked to *more than one*
other CS.  My proposal retains more detailed information than one would
have afterwards if all three CSs are instead grouped into a single CS
Group.  They are not really *concurrent* linkages, but rather represent
the call flow in time from one CS to another, from the perspective of a
particular participant, hence my suggestion of Next or Previous CS.  One
could refine this further to capture the *REASON* for the link, e.g.
"consult while on hold", "transferred to", "conferenced into", etc.

A very similar use cases exist for a call put on hold for a consult to
set up a conference.

Having said all of this, I realise that a single CS Group for CS1,CS2
and CS3 represents the transitive closure of the above
links/relationships in my example, and using accurate participant info,
one can still reconstruct a call scenario accurately from any given
participant's perspective having only 1 CS Group.  The reasons for the
relationships (whether it was for transfer, consult while on hold,
conference, etc.) between the CSs would however be lost, i.e. there is
no information on the *reasons* for the grouping to present afterwards
to a recording system user, but in practice a single CS Group is
workable for the intended purpose.

Regarding the question: What cases would there be to group *concurrent*
CSs?

One case I can think of here would be a dial-in conference scenario,
where every participant typically has his/her own CS throughout on a
signalling level, although on an audio level it really is the same call.
These CSs exist concurrently, yet are grouped together by the fact that
they together form a conference.

Regards
De Villiers

-----Original Message-----
From: Ram Mohan R (rmohanr) [mailto:[email-masked]] 
Sent: 30 November 2010 08:38
To: Paul Kyzivat (pkyzivat); [email-masked]; De Villiers de Wet
Subject: RE: [siprec] Communication Session Group in SIPREC metadata

Hi De Villiers,

Inline 

Regards,
Ram