Subject: [siprec] Use Case 10 & 12

From: Bruce Chrustie <[email-masked]>
Date: Wed, 7 Mar 2012 21:43:41 +0000

Hi gang,

Looking at these use cases in the RFC I see the need for the SRC to terminate a CS based upon an autonomous activities within the SRS. I see a couple options on how this would happen:

-SRS terminates the RS and the SRC has an implementation to terminate the CS in such instances. The struggle I have with this is that it is vendor dependent on if/how it is implemented. Especially relevant to #12. There is nothing I see within the drafts that would force a SRC to drop a CS because a RS was dropped. It would not make sense to do so either without it being explicitly requested.

-SRS sends BYE with metadata to terminate the CS by the SRC. Not able to today.

Can you enlighten me with some signaling scenarios on what the initial solutions were to these two scenarios? My preference is there is explicit capability within protocol & metadata that a CS be terminated when a SRS sends a BYE (or some variation).

Bruce,

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Thu, 8 Mar 2012 06:24:42 +0000

Bruce,

CS termination in SRC based on RS termination from SRS is a policy decision in SRC and  It is clear in usecase 10(High availability) as follows:

      o  The Communication Session must be terminated (or suitable
         notification given to parties) in the event of a recording
         failure.

In case of recording failure, SRC may indicate the notification to the parties using "record" attribute in draft-ietf-siprec-protocol or send BYE towards both parties.

For usecase #12,

Real-time analytics may be employed for automatic intervention (stopping

   interaction or alerting) if for example, a trader is not following

   regulations.

In case of real-time analytics, SRC application has to be terminate CS or alert the user about failure to record in case of RS is terminated.

Thanks
Partha

From: [email-masked] [mailto:[email-masked]] On Behalf Of Bruce Chrustie
Sent: Thursday, March 08, 2012 3:14 AM
To: [email-masked]
Subject: [siprec] Use Case 10 & 12

Hi gang,

Bruce,

---

From: Bruce Chrustie <[email-masked]>
Date: Thu, 8 Mar 2012 15:26:03 +0000

Hi Partha,

We agree on the action the SRC should take. My issue is that there is nothing in draft-ietf-siprec-protocol-02 that calls this behavior out explicitly in section 5 & 6 and it needs to be there.

Further, there are two scenarios: 'financial bank' and 'webstore callcenter'

'financial bank' is mandated to record all calls, and if the RS drops the corresponding CS should be dropped

'webstore callcenter' records for informational purposes a fraction of their calls. Having a RS fail would not dictate a CS termination.

This variability in what happens in the SRC right now is ambiguous and I think it needs to be addressed explicitly both in addition to callflows between the SRS to SRC when it wants a CS terminated as well as SRC behavior upon a RS termination during an active CS.

Bruce

From: Ravindran, Parthasarathi [mailto:[email-masked]]
Sent: Thursday, March 08, 2012 1:25 AM
To: Bruce Chrustie; [email-masked]
Subject: RE: Use Case 10 & 12

Bruce,

For usecase #12,

   regulations.

Thanks
Partha

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Bruce Chrustie
Sent: Thursday, March 08, 2012 3:14 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [siprec] Use Case 10 & 12

Hi gang,

Bruce,

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Wed, 14 Mar 2012 14:05:25 +0000

Bruce,

SIPREC model is much more complicated in terms of relationship between RS and CS. The possible combination of RS & CS relationship are

1 RS :  1 CS
1 RS :  N CS
N RS :  1 CS

So, each of the model may prefer the different action and it is upto the specific deployment. N RS: 1 CS deployment will continue CS irrespective of the RS termination.

Also in case the intention is to terminate CS using RS SIP mechanism, it is certainly outside the scope of SIPREC as it falls under SIP "action" or call control functionality.

Thanks
Partha

From: [email-masked] [mailto:[email-masked]] On Behalf Of Bruce Chrustie
Sent: Thursday, March 08, 2012 8:56 PM
To: [email-masked]
Subject: Re: [siprec] Use Case 10 & 12

Hi Partha,

Bruce

From: Ravindran, Parthasarathi [mailto:[email-masked]]
Sent: Thursday, March 08, 2012 1:25 AM
To: Bruce Chrustie; [email-masked]<mailto:[email-masked]>
Subject: RE: Use Case 10 & 12

Bruce,

For usecase #12,

   regulations.

Thanks
Partha

Hi gang,

Bruce,