Subject: [siprec] Persistent RS case, when should a recorder consider a CS has ended ?

From: <[email-masked]>
Date: Fri, 28 Oct 2011 14:23:57 +0100

Consider the following scenario

several phones connected to PBX, all voice record their calls from the phone by each having  a persistent RS.

All calls get initially answered by receptionist, who then conferences in someone to handle the call, then drops out.

So there are two phones are conferenced onto same external call, so both phones send metadata for thier RS's to include the call's CS.
Since each phone has knowledge of all the conference participants, the CS it sends has 3 partiicipants, the two phones and the far party.  Also the CS Id and participant Id's sent by each phone are identical.

Now one phone (receptionist) leaves the call, and both phones will sends a metadata update to say one participant has dissassociated.

Now for as long as the call persists, should the receptionists phone, that has left the call, still include the CS in any full metadata updates it sends, or could it omit the CS ?

If it must included it, then over time the receptionists phone may end up having to track multiple calls so as to send metadata updates, it is preferable if it could just forget about the call as it is no longer involved in it.

So does removing a CS from an RS indicate the CS has ended, or will a recorder only consider a CS ended when it receives metadata with the CS having and end-time element ?

Rgds
John Stafford | Solution Architect 1 | BT Global Services

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Fri, 28 Oct 2011 19:28:41 +0530

Hi John,

IMO, your requirement is already addressed as part of SIPREC metadata
with group (CSG) mechanism.

1)      Receptionist to customer is CS1 with CSG1 using RS1. RS1 is from
Receptionist to SRS.

2)      Agent1 to customer is CS2 with CSG1 with RS2. RS2 is from agent
to SRS.

SRS will be able to group this session (CSG) because of the unique CSG
id and able to differentiate CS between receptionist & agent 1 using CS
id. How CSG id passed across between receptionist & agent1 is outside
the scope of SIPREC. Each update shall be go asynchronously and
unique-id helps to group it together in SRS. Please let me know in case
I'm missing something in your requirement.

Thanks

Partha

From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Friday, October 28, 2011 6:54 PM
To: [email-masked]
Subject: [siprec] Persistent RS case,when should a recorder consider a
CS has ended ?

several phones connected to PBX, all voice record their calls from the
phone by each having  a persistent RS.

All calls get initially answered by receptionist, who then conferences
in someone to handle the call, then drops out.

So there are two phones are conferenced onto same external call, so both
phones send metadata for thier RS's to include the call's CS. 

Since each phone has knowledge of all the conference participants, the
CS it sends has 3 partiicipants, the two phones and the far party.  Also
the CS Id and participant Id's sent by each phone are identical.

Now one phone (receptionist) leaves the call, and both phones will sends
a metadata update to say one participant has dissassociated.

Now for as long as the call persists, should the receptionists phone,
that has left the call, still include the CS in any full metadata
updates it sends, or could it omit the CS ?

If it must included it, then over time the receptionists phone may end
up having to track multiple calls so as to send metadata updates, it is
preferable if it could just forget about the call as it is no longer
involved in it.

So does removing a CS from an RS indicate the CS has ended, or will a
recorder only consider a CS ended when it receives metadata with the CS
having and end-time element ?  

Rgds

---

From: <[email-masked]>
Date: Fri, 28 Oct 2011 16:16:11 +0100

Partha,

I think that when all three parties are conferenced there is only one CS, not two CS's and a CSG.
There may have been a CSG while the conference was being setup with a consult call.

In any case the question would be similar, should the phone that is no longer on the call still include the call's CS/ CSG in its persistent RS ?,
and if it doesn't will the recorder assume  CS has ended,even though the sane CS is included in the RS from the other phone.

ie the key question is
Does removing a CS from a persistent RS indicate the CS has ended, or will a recorder only consider a CS ended when it receives metadata with the CS having an end-time element ?

rgds John

________________________________
From: Ravindran Parthasarathi [mailto:[email-masked]]
Sent: 28 October 2011 14:59
To: Stafford,J,John,JRJ3X C; [email-masked]
Subject: RE: [siprec] Persistent RS case,when should a recorder consider a CS has ended ?

Hi John,

IMO, your requirement is already addressed as part of SIPREC metadata with group (CSG) mechanism.

1)      Receptionist to customer is CS1 with CSG1 using RS1. RS1 is from Receptionist to SRS.

2)      Agent1 to customer is CS2 with CSG1 with RS2. RS2 is from agent to SRS.

SRS will be able to group this session (CSG) because of the unique CSG id and able to differentiate CS between receptionist & agent 1 using CS id. How CSG id passed across between receptionist & agent1 is outside the scope of SIPREC. Each update shall be go asynchronously and unique-id helps to group it together in SRS. Please let me know in case I'm missing something in your requirement.

Thanks
Partha

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, October 28, 2011 6:54 PM
To: [email-masked]
Subject: [siprec] Persistent RS case,when should a recorder consider a CS has ended ?

Rgds

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 28 Oct 2011 13:08:48 -0400

Partha commented on this, but rather than inject in that conversation 
I'll make a separate response:

> phones send metadata for thier RS's to include the call's CS.

Are you assuming that the PBX is a B2BUA, that implements a sip dialog 
for each half-call? Or are you assuming a more classic sip model, where 
the PBX is a proxy/registrar?

I'm too lazy to draw the call flows, but in summary,

for the half-call model:
- first there is dialog 1b between caller and pbx
- then there is dialog 2b between pbx and receptionist
- (1b/2b spliced by the pbx)
- then there is dialog  3b between receptionist and pbx
   (for consult with callee)
- then there is dialog 4b between pbx and callee
- (dialogs 3b/4b spliced by pbx)
- the conference is formed between 1b,2b,4b mixed by the pbx,
   dialog 3b ends
- dialog 2b ends. The pbx switches from mixing to splicing
   1b/4b

for the "classic" model:
- first there is dialog 1a between caller and receptionist
- then there is a separate consult dialog between receptionist and
   internal callee (dialog 2a)
- then there is a conference of receptionist, caller, and callee.
   (dialogs 1a & 2a, joined at receptionist, or dialogs 3a,4a,5a between
   each of the three and a mixer, with 1a and 1b ending.)
- a direct dialog 6a is formed between the caller and callee
- then conference ends (dialogs 1a,1b or 3a,4a,5a end)

> Since each phone has knowledge of all the conference participants, the

That is an assumption that isn't necessarily true, but this is your 
example, so I'll assume its true

> the CS Id and participant Id's sent by each phone are identical.

This is another assumption - its a choice to do it this way. (Partha 
proposed a different way.) But again I'll accept your assumption. Its 
going to take some work for all the phones to arrive at the same ID for 
this CS.

> a metadata update to say one participant has dissassociated.

Well, I suppose all three phones send an update.

> updates it sends, or could it omit the CS ?

Given your assumptions, when the receptionist leaves the call it ought 
to send an update indicating that it is dissociated from the CS and the 
related streams it was associated with. Then it presumably forgets about 
the CS and never mentions it again.

This is also an assumption. If it somehow continues to track the state 
of the call I guess it could continue to report the state changes.

> So does removing a CS from an RS indicate the CS has ended,

That would clearly be the wrong thing to do in this case, since the CS 
is shared by multiple RSs and the others aren't done with it.

> or will a

IMO the SRS can generally assume the CS ended when all participants and 
streams have dissociated from it. Even after that, in principle, it 
could have another participant or stream associate to it. If so, I guess 
it will have to figure out how to deal with that. (It is probably an 
error, but in the interest of reliable recording it will want to do 
*something* - either graft the new stuff onto the the existing CS, or 
start a new CS with the same ID.)

	Thanks,
	Paul

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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 28 Oct 2011 13:10:47 -0400

(Revised. I realized I had extra stuff in here that I then decided I 
didn't need.)

	Thanks,
	Paul

---

From: <[email-masked]>
Date: Mon, 31 Oct 2011 12:29:58 +0000

Paul,

I agree that a SRS should treat a call as ended when all participants have dissassociated, 
or I guess if it gets a CS with and end-time.

But I saw discussion about allowing a CS to have zero participants, so then, for persistent RS,  we are back to needing to use CS end-time.

Rgds
John Stafford | Solution Architect 1 | BT Global Services | Tel:+44 (0)1932 773504   | E: [email-masked]  |  www.bt.com/globalservices
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Paul Kyzivat [[email-masked]]
Sent: 28 October 2011 18:10
To: [email-masked]
Subject: Re: [siprec] Persistent RS case, when should a recorder consider a CS has ended ?

        Thanks,
        Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 31 Oct 2011 10:34:03 -0400

On 10/31/11 8:29 AM, [email-masked] wrote:
> But I saw discussion about allowing a CS to have zero participants,

You did? Where?

We have been talking about a participant with no CSs, but AFAIK not 
about a CS with no participants.

	Thanks,
	Paul

> so then, for persistent RS,  we are back to needing to use CS end-time.
>
>
> Rgds

---

From: <[email-masked]>
Date: Mon, 31 Oct 2011 15:09:46 +0000

Paul,
Ok,  my mistake, as I see in latest matadata draft, CS must have 2 participants.
thanks
Rgds
John Stafford | Solution Architect 1 | BT Global Services 
________________________________________
From: Paul Kyzivat [[email-masked]]
Sent: 31 October 2011 14:34
To: Stafford,J,John,JRJ3X C
Cc: [email-masked]
Subject: Re: [siprec] Persistent RS case, when should a recorder consider a CS has ended ?

You did? Where?

        Thanks,
        Paul

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Mon, 31 Oct 2011 08:22:02 -0700

Actually, I thought we did agree to relax this to be 0 or more. Here is
the conclusion of the thread:
http://www.ietf.org/mail-archive/web/siprec/current/msg02616.html

Cheers,
Charles

> -----Original Message-----
> Sent: Monday, October 31, 2011 8:10 AM
> To: [email-masked]
> Cc: [email-masked]
> > John Stafford | Solution Architect 1 | BT Global Services | Tel:+44
(0)1932 773504   | E:
> [email-masked]  |  www.bt.com/globalservices
> > From: [email-masked] [[email-masked]] On Behalf Of
Paul Kyzivat
> [[email-masked]]

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 31 Oct 2011 13:22:00 -0400

> http://www.ietf.org/mail-archive/web/siprec/current/msg02616.html

Unless I am missing something, that mail mentions one-or-more, but I 
don't see a mention of zero-or-more.

OTOH, it talks about being lenient in what you accept, perhaps 
suggesting accepting zero.

The tradeoff here is in whether you can assume that a CS that has all of 
its participants removed is "done". But I'm not sure that is a question 
that requires an answer. It is a normal state of affairs that a CS with 
a non-zero number of participants is *not* done. And conversely when a 
CS *is* done it is reduced to zero participants.

But perhaps we should admit the possibility that a CS that has been 
reduced to zero participants may subsequently have participants added to 
it. It may seem odd, but if an SRC does that, the SRS is probably well 
advised to accept that for what it is and keep going. And if that is 
supported, then why not allow a CS to be created with no participants, 
and then have participants added to it later. Given our XML schema, that 
is what will happen in any case - its just a matter of whether the 
creation of the CS and the addition of a participant to it occur in the 
same message or separate messages.

Is there a need to declare a CS *done* in a final sort of way that 
guarantees that nothing more will ever be added to it???

	Thanks,
	Paul