Subject: Re: [siprec] Communication Session Group in SIPREC metadata

From: Leon Portman <[email-masked]>
Date: Thu, 2 Dec 2010 16:44:11 +0200

Hi

The example below can be even more complex if C is also external - like external agent. 

Leon
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of De Villiers de Wet
Sent: Wednesday, December 01, 2010 9:57 AM
To: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat)
Cc: [email-masked]
Subject: Re: [siprec] Communication Session Group in SIPREC metadata

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 

> -----Original Message-----
> 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
> 
> On 11/29/2010 7:07 AM, De Villiers de Wet wrote:
> > 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.
> 
> 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?

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

> 
> > 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.
> 
> 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
> 
> > 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,
> >
> > 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.
> >
> >
> > _______________________________________________
> > siprec mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/siprec
> >
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec

_______________________________________________
siprec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/siprec

---

From: "De Villiers de Wet" <[email-masked]>
Date: Thu, 2 Dec 2010 16:54:08 +0200

I'm interested in what way it can be more complex, Leon?

De Villiers

-----Original Message-----
From: Leon Portman [mailto:[email-masked]] 
Sent: 02 December 2010 16:44
To: De Villiers de Wet; Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat)
Cc: [email-masked]
Subject: RE: [siprec] Communication Session Group in SIPREC metadata

Hi

The example below can be even more complex if C is also external - like
external agent. 

Leon
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of De Villiers de Wet
Sent: Wednesday, December 01, 2010 9:57 AM
To: Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat)
Cc: [email-masked]
Subject: Re: [siprec] Communication Session Group in SIPREC metadata

Hi

Consult transfer

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 

and
grouped

Regards,
Ram

---

From: Leon Portman <[email-masked]>
Date: Thu, 2 Dec 2010 17:10:38 +0200

In such case, the call after agent disconnect, usually even not will be monitored by PBX. And from SBC or GW point of view, it will see only two unrelated inbound and outbound legs

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of De Villiers de Wet
Sent: Thursday, December 02, 2010 4:54 PM
To: Leon Portman
Cc: [email-masked]
Subject: Re: [siprec] Communication Session Group in SIPREC metadata

De Villiers

-----Original Message-----
From: Leon Portman [mailto:[email-masked]] 
Sent: 02 December 2010 16:44
To: De Villiers de Wet; Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat)
Cc: [email-masked]
Subject: RE: [siprec] Communication Session Group in SIPREC metadata

Hi

Leon
-----Original Message-----

Hi

Consult transfer

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 

and
grouped

Regards,
Ram

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Thu, 2 Dec 2010 22:43:38 +0530

De Villiers, 

Could you please look into draft-jones-ipmc-session-id-00.txt and let us know whether grouping using UUID solves your required callflows. 

Please let me know in case external agent transfer scenario is performed using RE-INVITE instead of REFER whether the problem will be simplified? IOW, PBX is involved in the signaling even after the transfer for tracking the CS group. 

Thanks 

Partha

________________________________

From: [email-masked] on behalf of Leon Portman
Sent: Thu 12/2/2010 8:40 PM
To: De Villiers de Wet
Cc: [email-masked]
Subject: Re: [siprec] Communication Session Group in SIPREC metadata

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of De Villiers de Wet
Sent: Thursday, December 02, 2010 4:54 PM
To: Leon Portman
Cc: [email-masked]
Subject: Re: [siprec] Communication Session Group in SIPREC metadata

De Villiers

-----Original Message-----
From: Leon Portman [mailto:[email-masked]]
Sent: 02 December 2010 16:44
To: De Villiers de Wet; Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat)
Cc: [email-masked]
Subject: RE: [siprec] Communication Session Group in SIPREC metadata

Hi

Leon
-----Original Message-----

Hi

Consult transfer

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

and
grouped

Regards,
Ram

---

From: "De Villiers de Wet" <[email-masked]>
Date: Tue, 7 Dec 2010 10:48:25 +0200

Partha

The proposed Session ID in draft-jones-ipmc-session-id-00.txt looks like
it will take care of the concerns  I raised, because it combines the
UUIDs for each participant together, basically modelling the linking
between sessions from the perspective of each participant.

Regarding RE_INVITE vs. REFER for the transfer to an external party, I
don't have enough experience with SIP itself to say whether it will
simplify the problem.

De Villiers

From: Parthasarathi R (partr) [mailto:[email-masked]] 
Sent: 02 December 2010 19:14
To: Leon Portman; De Villiers de Wet
Cc: [email-masked]
Subject: RE: [siprec] Communication Session Group in SIPREC metadata

De Villiers, 

Could you please look into draft-jones-ipmc-session-id-00.txt and let us
know whether grouping using UUID solves your required callflows. 

Please let me know in case external agent transfer scenario is performed
using RE-INVITE instead of REFER whether the problem will be simplified?
IOW, PBX is involved in the signaling even after the transfer for
tracking the CS group. 

Thanks 

Partha

In such case, the call after agent disconnect, usually even not will be
monitored by PBX. And from SBC or GW point of view, it will see only two
unrelated inbound and outbound legs

Leon

-----Original Message-----

De Villiers

-----Original Message-----
From: Leon Portman [mailto:[email-masked]]
Sent: 02 December 2010 16:44
To: De Villiers de Wet; Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat)
Cc: [email-masked]
Subject: RE: [siprec] Communication Session Group in SIPREC metadata

Hi

Leon
-----Original Message-----

Hi

Consult transfer

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

and
grouped

Regards,
Ram

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Tue, 7 Dec 2010 17:20:02 +0530

De Villiers/Paul,
 
Thanks for your comments. draft-jones-ipmc-session-id-00.txt is still in
debate (of DISPATCH) and it is outside the scope of SIPREC. As you
mentioned, most of the scenarios are covered by
draft-jones-ipmc-session-id-00.txt  but another set of deployment may
prefer to use other session-id like Hadriel Session-id (SIPSCOTCH
mechanism).

>From the SIPREC metadata model perspective, shall we conclude that 
 
1) SRC SHALL send 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
2) SRC MUST ensure the uniqueness of Unique-id mechanism in case
multiple SRC interacts with the same SRS (Addressing Paul's duplication
comment incorporation)
 
Please let me know in case any other consideration has to be taken care
for CS-Group unique id handling.
 
Please read inline.
 
Thanks
Partha

From: De Villiers de Wet [mailto:[email-masked]] 
Sent: Tuesday, December 07, 2010 2:18 PM
To: Parthasarathi R (partr)
Cc: [email-masked]; Leon Portman
Subject: RE: [siprec] Communication Session Group in SIPREC metadata

Partha

<Partha> I have mentioned RE-INVITE because I have observed the callflow
in few softswitches and IP PBX to control the signaling. </Partha> 

De Villiers

De Villiers, 

Thanks 

Partha

Leon

-----Original Message-----

De Villiers

-----Original Message-----
From: Leon Portman [mailto:[email-masked]]
Sent: 02 December 2010 16:44
To: De Villiers de Wet; Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat)
Cc: [email-masked]
Subject: RE: [siprec] Communication Session Group in SIPREC metadata

Hi

Leon
-----Original Message-----

Hi

Consult transfer

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

and
grouped

Regards,
Ram

---

From: "De Villiers de Wet" <[email-masked]>
Date: Tue, 7 Dec 2010 14:07:29 +0200

Partha

(1) and (2) sounds reasonable as it stands.  When you say the mechanism
is outside the scope, I understand you mean whether to do it as in
draft-jones-ipmc-session-id-00.txt or perhaps the SIPSCOTCH mechanism.
However,  are the rules for grouping also outside the scope, i.e. WHEN
sessions must belong to the same CS Group and when not?

De Villiers

From: Parthasarathi R (partr) [mailto:[email-masked]] 
Sent: 07 December 2010 13:50
To: De Villiers de Wet; Paul Kyzivat (pkyzivat)
Cc: [email-masked]; Leon Portman
Subject: RE: [siprec] Communication Session Group in SIPREC metadata

De Villiers/Paul,

Please read inline.

Thanks

Partha

Partha

De Villiers

De Villiers, 

Thanks 

Partha

Leon

-----Original Message-----

De Villiers

-----Original Message-----
From: Leon Portman [mailto:[email-masked]]
Sent: 02 December 2010 16:44
To: De Villiers de Wet; Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat)
Cc: [email-masked]
Subject: RE: [siprec] Communication Session Group in SIPREC metadata

Hi

Leon
-----Original Message-----

Hi

Consult transfer

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

and
grouped

Regards,
Ram

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Tue, 7 Dec 2010 23:01:55 +0530

De Villiers,
 
The grouping rule is decided by SRC and CS grouping varies based upon the deployment. The unique id mechanism selection in SRC decides whether the session belongs to same CS group or different CS group. Even in case SRC creates the different grouping rule locally and generate the unique-id locally, this proposed model will work. Please let me in case you foresee any issue with this grouping rule model.
 
Thanks
Partha

From: De Villiers de Wet [mailto:[email-masked]]
Sent: Tue 12/7/2010 5:37 PM
To: Parthasarathi R (partr)
Cc: [email-masked]; Leon Portman; Paul Kyzivat (pkyzivat)
Subject: RE: [siprec] Communication Session Group in SIPREC metadata

Partha

(1) and (2) sounds reasonable as it stands.  When you say the mechanism is outside the scope, I understand you mean whether to do it as in draft-jones-ipmc-session-id-00.txt or perhaps the SIPSCOTCH mechanism.  However,  are the rules for grouping also outside the scope, i.e. WHEN sessions must belong to the same CS Group and when not?

De Villiers

De Villiers/Paul,

Thanks for your comments. draft-jones-ipmc-session-id-00.txt is still in debate (of DISPATCH) and it is outside the scope of SIPREC. As you mentioned, most of the scenarios are covered by draft-jones-ipmc-session-id-00.txt  but another set of deployment may prefer to use other session-id like Hadriel Session-id (SIPSCOTCH mechanism).

>From the SIPREC metadata model perspective, shall we conclude that 

1) SRC SHALL send 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

2) SRC MUST ensure the uniqueness of Unique-id mechanism in case multiple SRC interacts with the same SRS (Addressing Paul's duplication comment incorporation)

Please let me know in case any other consideration has to be taken care for CS-Group unique id handling.

Please read inline.

Thanks

Partha

Partha

The proposed Session ID in draft-jones-ipmc-session-id-00.txt looks like it will take care of the concerns  I raised, because it combines the UUIDs for each participant together, basically modelling the linking between sessions from the perspective of each participant.

Regarding RE_INVITE vs. REFER for the transfer to an external party, I don't have enough experience with SIP itself to say whether it will simplify the problem. 

<Partha> I have mentioned RE-INVITE because I have observed the callflow in few softswitches and IP PBX to control the signaling. </Partha> 

De Villiers

De Villiers, 

Thanks 

Partha

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of De Villiers de Wet
Sent: Thursday, December 02, 2010 4:54 PM
To: Leon Portman
Cc: [email-masked]
Subject: Re: [siprec] Communication Session Group in SIPREC metadata

De Villiers

-----Original Message-----
From: Leon Portman [mailto:[email-masked]]
Sent: 02 December 2010 16:44
To: De Villiers de Wet; Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat)
Cc: [email-masked]
Subject: RE: [siprec] Communication Session Group in SIPREC metadata

Hi

Leon
-----Original Message-----

Hi

Consult transfer

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

and
grouped

Regards,
Ram

---

From: "De Villiers de Wet" <[email-masked]>
Date: Wed, 8 Dec 2010 13:44:51 +0200

Partha

This can work - I just wanted to clarify whether the grouping rules
themselves will be standardized as part of SIPREC or not.

De Villiers

From: Parthasarathi R (partr) [mailto:[email-masked]] 
Sent: 07 December 2010 19:32
To: De Villiers de Wet
Cc: [email-masked]; Leon Portman; Paul Kyzivat (pkyzivat)
Subject: RE: [siprec] Communication Session Group in SIPREC metadata

De Villiers,

The grouping rule is decided by SRC and CS grouping varies based upon
the deployment. The unique id mechanism selection in SRC decides whether
the session belongs to same CS group or different CS group. Even in case
SRC creates the different grouping rule locally and generate the
unique-id locally, this proposed model will work. Please let me in case
you foresee any issue with this grouping rule model.

Thanks
Partha

Partha

De Villiers

De Villiers/Paul,

Please read inline.

Thanks

Partha

Partha

De Villiers

De Villiers, 

Thanks 

Partha

Leon

-----Original Message-----

De Villiers

-----Original Message-----
From: Leon Portman [mailto:[email-masked]]
Sent: 02 December 2010 16:44
To: De Villiers de Wet; Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat)
Cc: [email-masked]
Subject: RE: [siprec] Communication Session Group in SIPREC metadata

Hi

Leon
-----Original Message-----

Hi

Consult transfer

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

and
grouped

Regards,
Ram

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 08 Dec 2010 11:00:57 -0500

On 12/8/2010 6:44 AM, De Villiers de Wet wrote:
> Partha
>
> This can work – I just wanted to clarify whether the grouping rules

I think we cannot reasonably standardize the procedure to be used by SRC 
to determine the groupings.

We *might* be able to standardize some grouping "reasons".
That depends on somebody proposing a list.

	Thanks,
	Paul

> De Villiers
>
> *From:*Parthasarathi R (partr) [mailto:[email-masked]]
> *Sent:* 07 December 2010 19:32
> *To:* De Villiers de Wet
> *Cc:* [email-masked]; Leon Portman; Paul Kyzivat (pkyzivat)
> *Subject:* RE: [siprec] Communication Session Group in SIPREC metadata
>
> De Villiers,
>
> ------------------------------------------------------------------------
>
> *From:*De Villiers de Wet [mailto:[email-masked]]
> *Sent:* Tue 12/7/2010 5:37 PM
> *To:* Parthasarathi R (partr)
> *Cc:* [email-masked]; Leon Portman; Paul Kyzivat (pkyzivat)
> *Subject:* RE: [siprec] Communication Session Group in SIPREC metadata
>
> Partha
>
> draft-jones-ipmc-session-id-00.txtor perhaps the SIPSCOTCH mechanism.
> *From:*Parthasarathi R (partr) [mailto:[email-masked]]
> *Sent:* 07 December 2010 13:50
> *To:* De Villiers de Wet; Paul Kyzivat (pkyzivat)
> *Cc:* [email-masked]; Leon Portman
> *Subject:* RE: [siprec] Communication Session Group in SIPREC metadata
>
> De Villiers/Paul,
>
> ------------------------------------------------------------------------
>
> *From:*De Villiers de Wet [mailto:[email-masked]]
> *Sent:* Tuesday, December 07, 2010 2:18 PM
> *To:* Parthasarathi R (partr)
> *Cc:* [email-masked]; Leon Portman
> *Subject:* RE: [siprec] Communication Session Group in SIPREC metadata
>
> Partha
>
> don’t have enough experience with SIP itself to say whether it will
> simplify the problem.
>
> *From:*Parthasarathi R (partr) [mailto:[email-masked]]
> *Sent:* 02 December 2010 19:14
> *To:* Leon Portman; De Villiers de Wet
> *Cc:* [email-masked]
> *Subject:* RE: [siprec] Communication Session Group in SIPREC metadata
>
> De Villiers,
>
> ------------------------------------------------------------------------
>
> *From:[email-masked] on behalf of Leon Portman
> *Sent:* Thu 12/2/2010 8:40 PM
> *To:* De Villiers de Wet
> *Cc:* [email-masked]
> *Subject:* Re: [siprec] Communication Session Group in SIPREC metadata
>

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Wed, 8 Dec 2010 21:50:44 +0530

De Villiers,
 
Thanks for your agreement about CSG unique-id metadata model.
 
The grouping rules depends upon the deployment and SIP entity (UA, B2BUA, focus) which acts as SRC. I really doubt whether it is possible to standardize grouping rules as part of SIPREC. IMO,SIPREC solution document shall recommend few grouping rules as a guideline to implementers. In case you foresee any possibility for standardizing grouping rules in SIPREC, pls let us know.
 
Thanks
Partha

From: De Villiers de Wet [mailto:[email-masked]]
Sent: Wed 12/8/2010 5:14 PM
To: Parthasarathi R (partr)
Cc: [email-masked]
Subject: RE: [siprec] Communication Session Group in SIPREC metadata

Partha

This can work - I just wanted to clarify whether the grouping rules themselves will be standardized as part of SIPREC or not.

De Villiers

De Villiers,

Thanks
Partha

Partha

De Villiers

De Villiers/Paul,

Please read inline.

Thanks

Partha

Partha

De Villiers

De Villiers, 

Thanks 

Partha

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of De Villiers de Wet
Sent: Thursday, December 02, 2010 4:54 PM
To: Leon Portman
Cc: [email-masked]
Subject: Re: [siprec] Communication Session Group in SIPREC metadata

De Villiers

-----Original Message-----
From: Leon Portman [mailto:[email-masked]]
Sent: 02 December 2010 16:44
To: De Villiers de Wet; Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat)
Cc: [email-masked]
Subject: RE: [siprec] Communication Session Group in SIPREC metadata

Hi

Leon
-----Original Message-----

Hi

Consult transfer

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

and
grouped

Regards,
Ram

---

From: Leon Portman <[email-masked]>
Date: Thu, 9 Dec 2010 09:07:53 +0200

+1

Leon

From: [email-masked] [mailto:[email-masked]] On Behalf Of Parthasarathi R (partr)
Sent: Wednesday, December 08, 2010 6:21 PM
To: De Villiers de Wet
Cc: [email-masked]
Subject: Re: [siprec] Communication Session Group in SIPREC metadata

De Villiers,

Thanks
Partha

De Villiers

De Villiers,

Thanks
Partha

De Villiers

De Villiers/Paul,

Please read inline.

Thanks
Partha

De Villiers

De Villiers,

Thanks

Partha

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of De Villiers de Wet
Sent: Thursday, December 02, 2010 4:54 PM
To: Leon Portman
Cc: [email-masked]
Subject: Re: [siprec] Communication Session Group in SIPREC metadata

De Villiers

-----Original Message-----
From: Leon Portman [mailto:[email-masked]]
Sent: 02 December 2010 16:44
To: De Villiers de Wet; Ram Mohan R (rmohanr); Paul Kyzivat (pkyzivat)
Cc: [email-masked]
Subject: RE: [siprec] Communication Session Group in SIPREC metadata

Hi

Leon
-----Original Message-----

Hi

Consult transfer

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

and
grouped

Regards,
Ram