Subject: [siprec] Do we need both SRS-to-SRC establishment and persistent recording?

From: "Elwell, John" <[email-masked]>
Date: Thu, 24 Jun 2010 13:11:06 +0200

(as individual)
>From the related thread on session establishment SRS to SRC, I seem to be picking up conflicting information.

On the one hand, I am hearing the message that persistent recording is required (and moreover an RTP stream needs to be kept open permanently) because there is no time for a re-INVITE on the RS (let alone a new INVITE to establish an RS) when the CS starts. This is to avoid clipping.

On the other hand, I am hearing that the SRS needs to receive "metadata" about a CS that is starting up, apply its own filtering rules to decide whether to record, and then establish an RS from SRS to SRC. But surely this is going to be time consuming and very likely to involve clipping?

These seem to be in conflict. Perhaps it is possible to find a solution that satisfies both concerns. For example, we could have a persistent session that keeps open the RTP stream. When a CS starts and the SRS receives the "metadata", it can decide whether to record content from the received RTP packets or throw them away. It could also do a re-INVITE to set the stream to 'inactive' if it doesn't want to record, although that might be problematic if it suddenly decides, e.g., through receipt of fresh metadata, that it does want to record. So I am not sure we can satisfy both requirements (SRS choosing whether to record versus avoiding clipping), unless we accept the bandwidth penalty of sending RTP that will be thrown away. Perhaps we need fresh proposals.

Alternatively, it could be that for any given deployment you have to adopt one or the other model and accept its limitations. This means we would be specifying two solutions, which sounds like a bad thing.

(as chair)
We urgently need some clarification in this area, so please continue discussion. I don't feel I am able to even open a sensible ticket on the tracker without some further clarification of what the issue really is.

John

---

From: Leon Portman <[email-masked]>
Date: Thu, 24 Jun 2010 15:24:53 +0300

I want to present two typical recording use cases.

Use Case 1: Large financial institute with 10,000 phones in the Back Office. Only specific calls/part of the calls supposed to be recorded (where some financial advice is given by back office expert). It is not feasible for each and every call, PBX (SRC) to try to create a SIP session with recording system (SRS) or even more, just keep recording channel allocated (persistent use case) for each phone. It is more elegant, just to have one open SIP SUBSCRIBE session between SRC and SRS and report metadata for all calls and initiate RS only when required. 
Important clarification: even if calls are not recorded , recording system usually is required to store metadata.

Use Case 2: Same financial institute, 2000 seats Contact Center. All calls must be recorded. In such case, obviously, the best solution where PBX (SRC) for each and every call for these agents, will send INVITE to the recording system (SRS) with the metadata and it will get recorded. Or even, better, RS will be initiated upon agent login to the phone - persistent use case.

My personal opinion, that we should for the first phase focus on SRC->SRC direction with metadata as part of the INVITE + INFO package, and defer other options to later stages.

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Elwell, John
Sent: Thursday, June 24, 2010 2:11 PM
To: [email-masked]
Subject: [siprec] Do we need both SRS-to-SRC establishment and persistent recording?

(as individual)

(as chair)

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

---

From: Brian Rosen <[email-masked]>
Date: Thu, 24 Jun 2010 08:49:32 -0400

Where is it written that it's harder to maintain 10,000 SIP sessions vs 10,000 SIP subscriptions?
It is easy enough to keep a SIP session, especially if media is disabled, open to each phone.  You wouldn't "allocate a recording channel" for each of these, but you could pass metadata within the session, and activate the media whenever you needed to.  Of course, activating the media is a complete SIP transaction.

Brian

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 24 Jun 2010 14:58:02 +0200

> From: Leon Portman [mailto:[email-masked]] 
> Sent: 24 June 2010 13:25
> To: Elwell, John; [email-masked]
> Subject: RE: Do we need both SRS-to-SRC establishment and 
> persistent recording?
> 
> Use Case 1: Large financial institute with 10,000 phones in 
> the Back Office. Only specific calls/part of the calls 
> supposed to be recorded (where some financial advice is given 
> by back office expert). 
[JRE] Only the agent will know on which calls / which parts of calls, he/she is giving advise, so this seems to argue for SRC-initiated recording.

> It is not feasible for each and every 
> call, PBX (SRC) to try to create a SIP session with recording 
> system (SRS) or even more, just keep recording channel 
> allocated (persistent use case) for each phone. It is more 
> elegant, just to have one open SIP SUBSCRIBE session between 
> SRC and SRS and report metadata for all calls and initiate RS 
> only when required. 
[JRE] For the SRS to make the decision, that metadata must include information about whether financial advice is being given at any point in time, and only the agent will know that, so there has to be some stimulus at the UA's user interface, and this needs to be conveyed to the SRC (which might be collocated). So I would expect the SRC to know before the SRS knows, so why can't the SRC initiate recording?

> Important clarification: even if calls are not recorded , 
> recording system usually is required to store metadata.
[JRE] This relates to the issue I just opened on the tracker. However, storing of metadata (in the sense of information about what calls are taken place) seems to be a CDR issue, not a session recording issue, and whilst the SRS might happen also to be the sink of CDR, I think that is outside the scope of SIPREC.

> 
> Use Case 2: Same financial institute, 2000 seats Contact 
> Center. All calls must be recorded. In such case, obviously, 
> the best solution where PBX (SRC) for each and every call for 
> these agents, will send INVITE to the recording system (SRS) 
> with the metadata and it will get recorded. Or even, better, 
> RS will be initiated upon agent login to the phone - 
> persistent use case.
> 
> My personal opinion, that we should for the first phase focus 
> on SRC->SRC direction with metadata as part of the INVITE + 
> INFO package, and defer other options to later stages.
[JRE] I assume you meant to say SRC->SRS direction. In which case, I agree this would be a sensible first step and one on which we might reach agreement earlier. The only caveat is whether, for the other cases, we would be unable to reuse much of this.

John (as individual)

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Elwell, John
> From the related thread on session establishment SRS to SRC, 
> I seem to be picking up conflicting information.
> 
> On the one hand, I am hearing the message that persistent 
> recording is required (and moreover an RTP stream needs to be 
> kept open permanently) because there is no time for a 
> re-INVITE on the RS (let alone a new INVITE to establish an 
> RS) when the CS starts. This is to avoid clipping.
> 
> On the other hand, I am hearing that the SRS needs to receive 
> "metadata" about a CS that is starting up, apply its own 
> filtering rules to decide whether to record, and then 
> establish an RS from SRS to SRC. But surely this is going to 
> be time consuming and very likely to involve clipping?
> 
> These seem to be in conflict. Perhaps it is possible to find 
> a solution that satisfies both concerns. For example, we 
> could have a persistent session that keeps open the RTP 
> stream. When a CS starts and the SRS receives the "metadata", 
> it can decide whether to record content from the received RTP 
> packets or throw them away. It could also do a re-INVITE to 
> set the stream to 'inactive' if it doesn't want to record, 
> although that might be problematic if it suddenly decides, 
> e.g., through receipt of fresh metadata, that it does want to 
> record. So I am not sure we can satisfy both requirements 
> (SRS choosing whether to record versus avoiding clipping), 
> unless we accept the bandwidth penalty of sending RTP that 
> will be thrown away. Perhaps we need fresh proposals.
> 
> 
> Alternatively, it could be that for any given deployment you 
> have to adopt one or the other model and accept its 
> limitations. This means we would be specifying two solutions, 
> which sounds like a bad thing.
> 
> (as chair)
> We urgently need some clarification in this area, so please 
> continue discussion. I don't feel I am able to even open a 
> sensible ticket on the tracker without some further 
> clarification of what the issue really is.
> 
> John

---

From: Leon Portman <[email-masked]>
Date: Thu, 24 Jun 2010 16:06:23 +0300

I agree from the pure SIP point of view, however from the actual implementation point of view, where these SIP sessions are supposed to be handled by resilient SIP Proxies with state replication (because the need to hide the actual topology of SRS recording servers) and do some kind of REFERs or SDP updates to actual recording boxes, it became very heavy and resource intensive. In addition, at least for our SIP stack implementation, handling of new INVITE is much heavier task then receiving notify event as part of the established SIP session.

Leon

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Thursday, June 24, 2010 3:50 PM
To: Leon Portman
Cc: Elwell, John; [email-masked]
Subject: Re: [siprec] Do we need both SRS-to-SRC establishment and persistent recording?

Brian

---

From: Leon Portman <[email-masked]>
Date: Thu, 24 Jun 2010 16:14:48 +0300

Please  see below

Leon

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Thursday, June 24, 2010 3:58 PM
To: Leon Portman; [email-masked]
Subject: RE: Do we need both SRS-to-SRC establishment and persistent recording?

[JRE] Only the agent will know on which calls / which parts of calls, he/she is giving advise, so this seems to argue for SRC-initiated recording.
[LeonP] Usually, it is agent desktop application that reports this events to the SRS and not actual button on the phone.

[JRE] For the SRS to make the decision, that metadata must include information about whether financial advice is being given at any point in time, and only the agent will know that, so there has to be some stimulus at the UA's user interface, and this needs to be conveyed to the SRC (which might be collocated). So I would expect the SRC to know before the SRS knows, so why can't the SRC initiate recording?
[LeonP] As I mention before, it is usually is detected on the desktop side.

[JRE] I assume you meant to say SRC->SRS direction. In which case, I agree this would be a sensible first step and one on which we might reach agreement earlier. The only caveat is whether, for the other cases, we would be unable to reuse much of this.
[LeonP] Yes, SRC->SRS. Our experience as SRS vendor tells us that it is possible to support all use cases with this option. It just not will be always cost effective or elegant: for example it will require definition of the recording rules also on SRS and SRC sides

John (as individual)

---

From: "Jain, Rajnish" <[email-masked]>
Date: Thu, 24 Jun 2010 09:21:23 -0400

Seems like we may be reaching consensus. Pls. see inline:

> [JRE] I assume you meant to say SRC->SRS direction. In which case, I agree
> this would be a sensible first step and one on which we might reach
> agreement earlier. The only caveat is whether, for the other cases, we
> would be unable to reuse much of this.
> [LeonP] Yes, SRC->SRS. Our experience as SRS vendor tells us that it is
> possible to support all use cases with this option. It just not will be
> always cost effective or elegant: for example it will require definition
> of the recording rules also on SRS and SRC sides

[RJ] +1. The fact that an RS is persistent is completely independent from the fact that whether the RS is established from SRC to SRS or vice-versa.

Raj

DISCLAIMER: This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. Unintended recipients are prohibited from taking action on the basis of information in this e-mail.E-mail messages may contain computer viruses or other defects, may not be accurately replicated on other systems, or may be intercepted, deleted or interfered with without the knowledge of the sender or the intended recipient. If you are not comfortable with the risks associated with e-mail messages, you may decide not to use e-mail to communicate with IPC. IPC reserves the right, to the extent and under circumstances permitted by applicable law, to retain, monitor and intercept e-mail messages to and from its systems.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 24 Jun 2010 09:47:03 -0400

Elwell, John wrote:
> These seem to be in conflict.

I don't get the impression that these are "in conflict".
They simply seem to be different use cases.
Or in some cases just different approaches to addressing the same use case.

So I don't think the problem is with them being "in conflict".
But I remain to be convinced that metadata conveyance outside of an RS 
needs to be in scope. Those that want to obtain that data to make their 
solutions work already have various technologies to do it. If those 
aren't enough, then maybe that can be a separate effort - I doubt it is 
specific to recording.

> Perhaps it is possible to find a solution that satisfies both concerns. For example, we could have a persistent session that keeps open the RTP stream. When a CS starts and the SRS receives the "metadata", it can decide whether to record content from the received RTP packets or throw them away. It could also do a re-INVITE to set the stream to 'inactive' if it doesn't want to record, although that might be problematic if it suddenly decides, e.g., through receipt of fresh metadata, that it does want to record.

Certainly that is a possible use case.
Is it necessary to document it?
If somebody thinks so, then that should be ok.

The clipping doesn't sound so bad in that case, because the signal that 
carries the metadata can also carry the offer for the media too.
All that is required is for an answer to get back before media can be 
received. That could be a small lag, but that depends on the details of 
the circumstance that caused recording to be interesting. For instance, 
if it was a change in participant, then there is corresponding signaling 
on the CS session that can go on in parallel.

In the worst case there will be no substitute for having the media 
stream open all the time.

> So I am not sure we can satisfy both requirements (SRS choosing whether to record versus avoiding clipping), unless we accept the bandwidth penalty of sending RTP that will be thrown away. Perhaps we need fresh proposals.
> 

IMO what is being developed is a tool kit that can be used in many 
different ways depending on the particular problem and its constraints.
The trick is to make it general enough while not making it too difficult 
to implement.

Of course it should be possible to demonstrate that the important use 
cases can indeed be solved *at least* one way with the technology. But 
its not a problem if there turn out to be multiple ways.

In this respect its no different from SIP itself. There are many 
different ways to employ sip to build a telephony system. That is not a 
bad thing.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 24 Jun 2010 10:24:45 -0400

> Use Case 1: Large financial institute with 10,000 phones in the Back Office. Only specific calls/part of the calls supposed to be recorded (where some financial advice is given by back office exper…

IIUC you are suggesting that the SRS has a subscription to the SRC and 
receives a notification about each call. Then the SRS initiates an RS 
with the SRC for those calls it finds interesting.

So what is the nature of the notification? Is it just a CDR describing 
the caller and callee? Or does it contain an explicit indication from 
one of the participants that this call requires recording?

It takes the same time to initiate the RS, regardless of which end 
initiates it. If the SRC initiates the session you can avoid the 
subscription and the notification.

The case where this *doesn't* work is when the notification contains 
only CDR-type data and the SRS has policy to choose calls for recording 
based on only that data.

As somebody else said, CDR data should probably be handled independently 
of siprec.

> Use Case 2: Same financial institute, 2000 seats Contact Center. All calls must be recorded. In such case, obviously, the best solution where PBX (SRC) for each and every call for these agents, wil…

There are many ways to skin this cat depending on your priorities.

- the RC can be established at agent login, with a media stream.
   The SRC can replicate all packets to it.

- The RC can be established at agent login without a media stream.
   The SRC can update the session with a media stream when there is
   a call.

- in both of the above, the RC could be established by the SRC
   or by the SRS, or by something else aware of the agent login
   sending a REFER to either SRC or SRS.

- The SRC can establish the RC separately for each call.

I don't see why siprec needs to take a position on which of these should 
be used.

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 24 Jun 2010 17:48:21 +0200

I have had off-line discussions with a few people who have spoken on this and the related thread, and I sense the following proposal might be helpful.

SIPREC should focus initially on RS established in direction SRC->SRS. The RS may be on-demand or persistent.

Considering just on the on-demand case for now, the SRC could initiate the RS (send an INVITE request) based on the following:
- the SRC is aware locally of policy / rules; or
- the SRC communicates by some out-of-band means (e.g., web services, JTAPI or whatever) with some other entity (which may be collocated with the SRS even) that is aware of policy / rules and can make the decision and instruct the SRC.

The out-of-band means in the second case would be outside the scope of SIPREC.

This means that the purpose of the metadata (see ticket#22) would be to provide information about
a CS that is to be or is being recorded, in order to advise the SRS how to record and playback the CS. This would then only need to be sent at the start of or during the lifetime of the RS, not in advance of the RS. The precise transport mechanism can be decided later.

Establishment in the direction SRC->SRS is simpler in terms of addressing. We can just assume the SRC is provisioned with a SIP-URI for the SRS and rely on normal RFC 3263 procedures.

John (as individual)

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: 24 June 2010 15:25
> To: Leon Portman
> by back office expert). It is not feasible for each and every 
> > My personal opinion, that we should for the first phase 
> focus on SRC->SRC direction with metadata as part of the 
> INVITE + INFO package, and defer other options to later stages.
> > 
> > Leon
> > 
> >>From the related thread on session establishment SRS to 
> SRC, I seem to be picking up conflicting information.
> > 
> > On the other hand, I am hearing that the SRS needs to 
> receive "metadata" about a CS that is starting up, apply its 
> own filtering rules to decide whether to record, and then 
> > These seem to be in conflict. Perhaps it is possible to 
> find a solution that satisfies both concerns. For example, we 
> > Alternatively, it could be that for any given deployment 
> you have to adopt one or the other model and accept its

---

From: Deepanshu Gautam <[email-masked]>
Date: Fri, 25 Jun 2010 11:21:38 +0800

Inline with [DG]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Leon Portman
Sent: 2010年6月24日 20:25
To: Elwell, John; [email-masked]
Subject: Re: [siprec] Do we need both SRS-to-SRC establishment and
persistentrecording?

Use Case 1: Large financial institute with 10,000 phones in the Back Office.
Only specific calls/part of the calls supposed to be recorded (where some
financial advice is given by back office expert). It is not feasible for
each and every call, PBX (SRC) to try to create a SIP session with recording
system (SRS) or even more, just keep recording channel allocated (persistent
use case) for each phone. It is more elegant, just to have one open SIP
SUBSCRIBE session between SRC and SRS and report metadata for all calls and
initiate RS only when required. 
Important clarification: even if calls are not recorded , recording system
usually is required to store metadata.

Use Case 2: Same financial institute, 2000 seats Contact Center. All calls
must be recorded. In such case, obviously, the best solution where PBX (SRC)
for each and every call for these agents, will send INVITE to the recording
system (SRS) with the metadata and it will get recorded. Or even, better, RS
will be initiated upon agent login to the phone - persistent use case.

My personal opinion, that we should for the first phase focus on SRC->SRC
direction with metadata as part of the INVITE + INFO package, and defer
other options to later stages.
[DG]  I would like to see this feature (SRS->SRC) to be supported in the
first release. And I think it is not related with persistent recording these
are two different usecases. SRS->SRC have its own requirement, todays
systems are depeloyed exploting this feature. It has many usecases "Agent
Performance Check" (which I explained is another thread) is one of them. I
can understand SRC->SRS in case where there are known recording rules (which
can be defined in SRC), but when we require on-the-fly recording decisions
(dynamic recording usecase) then we must have to rely on SRS->SRC. Metadata
will be flowing to SRS out-side of RS dialog (this seems to be the consensus
of the group) which will be used to take decisions about recording.

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Elwell, John
Sent: Thursday, June 24, 2010 2:11 PM
To: [email-masked]
Subject: [siprec] Do we need both SRS-to-SRC establishment and persistent
recording?

(as individual)
>From the related thread on session establishment SRS to SRC, I seem to be
picking up conflicting information.

On the one hand, I am hearing the message that persistent recording is
required (and moreover an RTP stream needs to be kept open permanently)
because there is no time for a re-INVITE on the RS (let alone a new INVITE
to establish an RS) when the CS starts. This is to avoid clipping.

On the other hand, I am hearing that the SRS needs to receive "metadata"
about a CS that is starting up, apply its own filtering rules to decide
whether to record, and then establish an RS from SRS to SRC. But surely this
is going to be time consuming and very likely to involve clipping?

These seem to be in conflict. Perhaps it is possible to find a solution that
satisfies both concerns. For example, we could have a persistent session
that keeps open the RTP stream. When a CS starts and the SRS receives the
"metadata", it can decide whether to record content from the received RTP
packets or throw them away. It could also do a re-INVITE to set the stream
to 'inactive' if it doesn't want to record, although that might be
problematic if it suddenly decides, e.g., through receipt of fresh metadata,
that it does want to record. So I am not sure we can satisfy both
requirements (SRS choosing whether to record versus avoiding clipping),
unless we accept the bandwidth penalty of sending RTP that will be thrown
away. Perhaps we need fresh proposals.

Alternatively, it could be that for any given deployment you have to adopt
one or the other model and accept its limitations. This means we would be
specifying two solutions, which sounds like a bad thing.

(as chair)
We urgently need some clarification in this area, so please continue
discussion. I don't feel I am able to even open a sensible ticket on the
tracker without some further clarification of what the issue really is.

John

---

From: Deepanshu Gautam <[email-masked]>
Date: Fri, 25 Jun 2010 11:42:00 +0800

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Elwell, John
Sent: 2010年6月24日 23:48
To: Paul Kyzivat; Leon Portman
Cc: [email-masked]
Subject: Re: [siprec] Do we need both SRS-to-SRC establishment and
persistent recording?

I have had off-line discussions with a few people who have spoken on this
and the related thread, and I sense the following proposal might be helpful.

SIPREC should focus initially on RS established in direction SRC->SRS. The
RS may be on-demand or persistent.

Considering just on the on-demand case for now, the SRC could initiate the
RS (send an INVITE request) based on the following:
- the SRC is aware locally of policy / rules; or
- the SRC communicates by some out-of-band means (e.g., web services, JTAPI
or whatever) with some other entity (which may be collocated with the SRS
even) that is aware of policy / rules and can make the decision and instruct
the SRC.

The out-of-band means in the second case would be outside the scope of
SIPREC.
[DG] How about we forget about that out-of-band mechanism and SRC being
cummunicating with *some other entity* (to start the RS) because both the
them are out-of-scope, anyway. And, Probably that *some other entity* will
come out as SRS only, then why not let SRS initiates are RS instead of
instructing SRC to do so. Isn't sound lucrative?

This means that the purpose of the metadata (see ticket#22) would be to
provide information about a CS that is to be or is being recorded, in order
to advise the SRS how to record and playback the CS. This would then only
need to be sent at the start of or during the lifetime of the RS, not in
advance of the RS. The precise transport mechanism can be decided later.

Establishment in the direction SRC->SRS is simpler in terms of addressing.
We can just assume the SRC is provisioned with a SIP-URI for the SRS and
rely on normal RFC 3263 procedures.

John (as individual)

> the Back Office. Only specific calls/part of the calls supposed to be 
> recorded (where some financial advice is given by back office expert). 
> It is not feasible for each and every call, PBX (SRC) to try to create 
> a SIP session with recording system (SRS) or even more, just keep 
> recording channel allocated (persistent use case) for each phone. It 
> is more elegant, just to have one open SIP SUBSCRIBE session between 
> SRC and SRS and report metadata for all calls and initiate RS only 
> when required.
> 
> only CDR-type data and the SRS has policy to choose calls for 
> recording based on only that data.
> 
> As somebody else said, CDR data should probably be handled 
> independently of siprec.
> 
> Center. All calls must be recorded. In such case, obviously, the best 
> solution where PBX (SRC) for each and every call for these agents, 
> will send INVITE to the recording system (SRS) with the metadata and 
> it will get recorded. Or even, better, RS will be initiated upon agent 
> login to the phone - persistent use case.
> 
> I don't see why siprec needs to take a position on which of these 
> should be used.
> 
> 	Thanks,
> 	Paul
> 
> focus on SRC->SRC direction with metadata as part of the INVITE + INFO 
> package, and defer other options to later stages.
> > 
> > Leon
> > 
> recording is required (and moreover an RTP stream needs to be kept 
> open permanently) because there is no time for a re-INVITE on the RS 
> (let alone a new INVITE to establish an
> receive "metadata" about a CS that is starting up, apply its own 
> filtering rules to decide whether to record, and then establish an RS 
> from SRS to SRC. But surely this is going to be time consuming and 
> very likely to involve clipping?
> > 
> find a solution that satisfies both concerns. For example, we could 
> have a persistent session that keeps open the RTP stream. When a CS 
> starts and the SRS receives the "metadata", it can decide whether to 
> record content from the received RTP packets or throw them away. It 
> could also do a re-INVITE to set the stream to 'inactive' if it 
> doesn't want to record, although that might be problematic if it 
> suddenly decides, e.g., through receipt of fresh metadata, that it 
> does want to record. So I am not sure we can satisfy both requirements 
> (SRS choosing whether to record versus avoiding clipping), unless we 
> accept the bandwidth penalty of sending RTP that will be thrown away. 
> Perhaps we need fresh proposals.
> > 
> > 
> you have to adopt one or the other model and accept its limitations. 
> This means we would be specifying two solutions, which sounds like a 
> bad thing.
> > 
> > (as chair)
> continue discussion. I don't feel I am able to even open a sensible 
> ticket on the tracker without some further clarification of what the 
> issue really is.
> > 
> > John

---

From: "Jain, Rajnish" <[email-masked]>
Date: Fri, 25 Jun 2010 09:41:15 -0400

Inline:

> first release. And I think it is not related with persistent recording
> these are two different usecases.

I agree that these are two different use cases. I also think that there is nothing fundamentally wrong about establishing RS from SRS to SRC. We've probably mischaracterized the issue. I believe the key issue is *metadata transport outside of RS SIP dialog*. I believe the reason some of these issues got mixed up is because typically for SRS to initiate an RS it must receive metadata.

Some on the list have pointed out that SRS receiving metadata outside of RS SIP dialog is a CDR issue and should be treated outside the scope of SIPREC. I think we can live for that for now.

Raj

---

From: "Henry Lum" <[email-masked]>
Date: Fri, 25 Jun 2010 09:44:51 -0700

> always cost effective or elegant: for example it will require
> definition of the recording rules also on SRS and SRC sides

[hlum] I do agree that SRC->SRS should cover all the use cases
described, but I don't think the SRC side is required to have recording
rules; SRC can always INVTE all calls to SRS, and SRS can reject some RS
based on the recording rules. Of course SRC can also apply rules before
it even attempts to establish the RS, but this is more of a choice of
implementation. 

> > clarification of what the issue really is.

-------------------------------------------------------------------------------------------------------------------
CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities.

---

From: "Henry Lum" <[email-masked]>
Date: Fri, 25 Jun 2010 09:59:51 -0700

Wouldn't SIP subscriptions have the same problem as a SIP dialog with
maintaining the state if you want to replicate with a backup instance? 

I do understand from implementation point of view that INVITE sessions
can potentially cost more to maintain especially if the recorder
reserves media for each SIP dialog even if no media is required. If an
SRS sits on reserved media resources but no recording is happening then
it can be costly to deploy. However, I think implementations can avoid
this problem for dynamic recording by using mechanisms like REFER to
send the RS to an actual recorder instance with media resources.

Henry

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Leon Portman
> Sent: June-24-10 9:06 AM
> To: Brian Rosen
> Cc: [email-masked]
> I agree from the pure SIP point of view, however from the actual
> implementation point of view, where these SIP sessions are supposed to
> be handled by resilient SIP Proxies with state replication (because
the
> need to hide the actual topology of SRS recording servers) and do some
> kind of REFERs or SDP updates to actual recording boxes, it became
very
> heavy and resource intensive. In addition, at least for our SIP stack
> implementation, handling of new INVITE is much heavier task then
> receiving notify event as part of the established SIP session.
> 
> Leon
> 
> Where is it written that it's harder to maintain 10,000 SIP sessions
vs
> 10,000 SIP subscriptions?
> It is easy enough to keep a SIP session, especially if media is
> disabled, open to each phone.  You wouldn't "allocate a recording
> channel" for each of these, but you could pass metadata within the
> session, and activate the media whenever you needed to.  Of course,
> activating the media is a complete SIP transaction.
> 
> Brian
> 
> > Use Case 1: Large financial institute with 10,000 phones in the Back
> Office. Only specific calls/part of the calls supposed to be recorded
> (where some financial advice is given by back office expert). It is
not
> feasible for each and every call, PBX (SRC) to try to create a SIP
> session with recording system (SRS) or even more, just keep recording
> channel allocated (persistent use case) for each phone. It is more
> elegant, just to have one open SIP SUBSCRIBE session between SRC and
> SRS and report metadata for all calls and initiate RS only when
> required.
> > Important clarification: even if calls are not recorded , recording
> system usually is required to store metadata.
> >
> > Use Case 2: Same financial institute, 2000 seats Contact Center. All
> calls must be recorded. In such case, obviously, the best solution
> where PBX (SRC) for each and every call for these agents, will send
> INVITE to the recording system (SRS) with the metadata and it will get
> recorded. Or even, better, RS will be initiated upon agent login to
the
> phone - persistent use case.
> >
> > My personal opinion, that we should for the first phase focus on
SRC-
> >SRC direction with metadata as part of the INVITE + INFO package, and
> defer other options to later stages.
> >
> > Leon
> >
> > From the related thread on session establishment SRS to SRC, I seem
> to be picking up conflicting information.
> >
> > On the one hand, I am hearing the message that persistent recording
> is required (and moreover an RTP stream needs to be kept open
> permanently) because there is no time for a re-INVITE on the RS (let
> alone a new INVITE to establish an RS) when the CS starts. This is to
> avoid clipping.
> >
> "metadata" about a CS that is starting up, apply its own filtering
> rules to decide whether to record, and then establish an RS from SRS
to
> SRC. But surely this is going to be time consuming and very likely to
> involve clipping?
> >
> > These seem to be in conflict. Perhaps it is possible to find a
> solution that satisfies both concerns. For example, we could have a
> persistent session that keeps open the RTP stream. When a CS starts
and
> the SRS receives the "metadata", it can decide whether to record
> content from the received RTP packets or throw them away. It could
also
> do a re-INVITE to set the stream to 'inactive' if it doesn't want to
> record, although that might be problematic if it suddenly decides,
> e.g., through receipt of fresh metadata, that it does want to record.
> So I am not sure we can satisfy both requirements (SRS choosing
whether
> to record versus avoiding clipping), unless we accept the bandwidth
> penalty of sending RTP that will be thrown away. Perhaps we need fresh
> proposals.
> >
> >
> > Alternatively, it could be that for any given deployment you have to
> adopt one or the other model and accept its limitations. This means we
> would be specifying two solutions, which sounds like a bad thing.
> >
> > (as chair)
> discussion. I don't feel I am able to even open a sensible ticket on
> the tracker without some further clarification of what the issue
really
> is.

---

From: "Jain, Rajnish" <[email-masked]>
Date: Sun, 27 Jun 2010 06:38:05 -0400

While theoretically SIP dialogs created through INVITE or SUBSCRIBE should be equivalent in terms of SRS and SRC UA scalability, the reality is that most implementations reserve RTP channels for INVITEs. Mechanims have been designed to avoid that (e.g. black-holed SDP or setting m= line port number to zero), but I think most implementations are not interoperable in that respect.

REFER or redirection (302) are probably acceptable solutions to this.

Raj
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Henry Lum [[email-masked]]
Sent: Friday, June 25, 2010 12:59 PM
To: Leon Portman; Brian Rosen
Cc: [email-masked]
Subject: Re: [siprec] Do we need both SRS-to-SRC establishment and      persistent      recording?

Henry

the
very
vs
not
the
SRC-
> Behalf Of Elwell, John
to
and
also
whether
really

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 28 Jun 2010 09:01:34 -0400

> While theoretically SIP dialogs created through INVITE or SUBSCRIBE should be equivalent in terms of SRS and SRC UA scalability, the reality is that most implementations reserve RTP channels for IN…

Do you have data to back this up?

Note that discussion seems to be going in the direction of multiple 
m-lines (to deal with independent streams for participants and media), 
with the number of such m-lines being variable. Under such an approach 
the recording server must assign ports dynamically based on the m-lines 
received. In that environment, what would be the reason to reserve ports 
for m-lines that don't exist, have been rejected, or that are black-holed.

	Thanks,
	Paul