Subject: [siprec] Recording Session establishment from SRS to SRC

From: "Jain, Rajnish" <[email-masked]>
Date: Wed, 23 Jun 2010 09:43:00 -0400

There was a discussion around the need for RS establishment from SRS to SRC at the SIPREC WG interim meeting on 2010-06-22. REQ-006 (quoted below) in draft-ietf-siprec-req-00 captures that requirement.

  o REQ-006 The mechanism MUST support establishing Recording Sessions
   from the SRS to the SRC.  This requirement typically applies when the
   decision on whether a session should be recorded or not resides in
   the RS.

A related issue was raised about sending metadata from SRC to SRS out-of-band to the RS SIP dialog. REQ-020 (quoted below) in the same draft captures that requirement.

   o REQ-020 The mechanism MUST support the ability to transport the
   metadata outside of the Recording Session SIP dialog.

Regards,

Raj Jain

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: Brian Rosen <[email-masked]>
Date: Wed, 23 Jun 2010 10:05:50 -0400

<as individual>
I have no concerns with REQ-006.

I do have concerns with REQ-020.  In general, I think it will be very difficult to invent an out of dialog metadata interface.   I think the SIP crowd would have a very hard time with a mechanism that continually updated an SRS with a potential SRC's status.

Perhaps an example is needed, because I suspect there are existing mechanisms that will get the information the SRS needs, or, if necessary, an existing mechanism can be extended to provide it.

Brian

On Jun 23, 2010, at 9:43 AM, Jain, Rajnish wrote:

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

---

From: "Jain, Rajnish" <[email-masked]>
Date: Wed, 23 Jun 2010 14:54:46 -0400

Pls. see inline.

________________________________________
From: Brian Rosen [[email-masked]]
Sent: Wednesday, June 23, 2010 10:05 AM
To: Jain, Rajnish
Cc: [email-masked]
Subject: Re: [siprec] Recording Session establishment from SRS to SRC

<as individual>

[RJ] We need to understand your concern better. Conceptually, with respect to an out-of-band mechanism and continuous updates, I think we can draw some similarities between this and RFC 4235 (dialog-package). An RFC 4235 compliant subscriber UA interested in the state of a dialog will receive dialog events (inside a SUBSCRIBE-initiated dialog). The UA MAY decide to act on those events at its discretion (for instance, it may want to participate in the dialog by issuing an INVITE w/ Join, but the target dialog's metadata events are not inside this INVITE-initiated dialog).

[RJ] A similar situation applies in siprec. The SRS passively observes the CS events (metadata) as they occur in the SRC and MAY decide to act upon them by initiating recording based on its policy. 

[RJ] I think we've something missing in the metadata definition that could have lead to this issue -- the metadata is not just the data describing the CS. It also includes User AoR registration state data. This is necessary because the lifespans of CS and RS are independent. The uses cases described in the draft highlight this fact.

[RJ] The persistent recording use case (#4) provides some description. The business scenario is that the policies, business rules etc. for deciding when to record or not are quite complex (regulatory, country based etc.) and have traditionally been implemented in the SRS. The SRCs tend to focus on telephony and switching and are agnostic to policies pertaining to recording.

Raj

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 23 Jun 2010 15:21:05 -0400

> Pls. see inline.

In the dialog event package, there is a subscription to *some* resource.
(E.g. an AoR.) Notifications are relative to changes in state of that 
resource.

> [RJ] A similar situation applies in siprec. The SRS passively observes the CS events (metadata) as they occur in the SRC and MAY decide to act upon them by initiating recording based on its policy. 

If you want to subscribe to some event package at some resource that 
gives you info to decide you want to record, then go for it. You could 
potentially use the dialog event package plus a resource list so you 
could subscribe to a bunch of potential callers/callees.

But if you want to create something *new* to provide you with this 
information then you have a strong sales job. And its probably not 
something that would be specific to recording.

> [RJ] I think we've something missing in the metadata definition that could have lead to this issue -- the metadata is not just the data describing the CS. It also includes User AoR registration sta…

The definition of metadata is too thin at the moment.
IMO a data model is required that covers the important metadata and 
their relationships to one another. When there is a strawhorse for that, 
it will be easier to argue if something is lacking.

But IMO based on discussions so far I think the metadata of interest 
will indeed be metadata about *a* recording session and its constituents.

Some have suggested that multiple RSs must be correlated. If that is so, 
then that should show up in the model too.

You are asking for addressing metadata that isn't associated with any 
RS. I think you will have to sell people on the need for that.

> [RJ] The persistent recording use case (#4) provides some description. The business scenario is that the policies, business rules etc. for deciding when to record or not are quite complex (regulato…

Is there a reason why that can't be addressed by establishing the RS and 
then having the SRS decide it doesn't want to record anything?

If the RS is persistent, then it will get revised each time there is a 
new CS to be included in it. The SRS can then decide if it wants to 
record that CS or not. If not, it can make the media stream inactive, or 
reject it, so that media is no longer flowing to it.

	Thanks,
	Paul

---

From: Brian Rosen <[email-masked]>
Date: Wed, 23 Jun 2010 15:21:23 -0400

<as individual>

Please get specific.   So far, I don't see anything that is going to get through the IETF as recording specific.

Using your example of registration state: I highly doubt we can get a siprec specific mechanism that informs a 3rd party (SRS) of registration status of a UA.  

We could conceivably run a generic mechanism that would get that information through the SIP process, but a recording specific mechanism won't fly, in my opinion.

Also, we have history that we generally put intelligence in endpoints, and not in central servers.  Generally, we find that scales much better.  I think you are illustrating this.  It would be easy to put some kind of "business rule" evaluator in an endpoint.  It would be harder, generally, to distribute the state of the endpoint to the server adequately.  The former is just a set of rules and an interpreter.  The latter is a complex protocol interaction that has scalability issues; you have a time constraint because when the state of the client changes, you need to get a recording started without losing any media of importance.  Mechanisms that react that fast at internet scale are hard.

Brian

---

From: "Jain, Rajnish" <[email-masked]>
Date: Wed, 23 Jun 2010 15:50:43 -0400

[RJ] It's a bit early to speak about a new event-package for siprec. I think the siprec metadata requirements could possibly be covered by a combined registration and dialog event-package implementation. Although, I can forsee that we'll need to extend the dialog event-package (similar to the way the BLISS shared-apperances draft did -- dialog;recording) because we've events that don't affect the SIP dialog state but they do affect the "call" state (an example is push-to-talk on/off events). Regardless, whether the event-package is new or we use some existing ones, the point is that these event-packages are out-of-band the RS INVITE-initiated dialog. We need to establish this first because that appears to be Brian's main concern.

[RJ] I think you meant communications session and its constituents. Regardless of how we slice the metadata (over separate event-packages), but overall it includes CS data and also User AoR registration state data.

[RJ] Perhaps, the User AoR registration state data is not officially deemed as metadata in siprec definition, but it is needed for the solution to work. I think this is a workable problem.

[RJ] You don't to waste RTP ports on SRC and SRS if you don't intend to record. Eastblishing RS means that RTP ports get chewed.

If the RS is persistent, then it will get revised each time there is a
new CS to be included in it. 

[RJ] Nope. The metadata carries the revision info pertaing to CSs getting added or deleted. The RS is simply an RTP pipe.

The SRS can then decide if it wants to
record that CS or not. If not, it can make the media stream inactive, or
reject it, so that media is no longer flowing to it.

[RJ] That won't work because an RS can carry multiple CSs in it.

Raj

        Thanks,
        Paul

---

From: "Jain, Rajnish" <[email-masked]>
Date: Wed, 23 Jun 2010 16:04:45 -0400

Inline:
________________________________________
From: Brian Rosen [[email-masked]]
Sent: Wednesday, June 23, 2010 3:21 PM
To: Jain, Rajnish
Cc: [email-masked]
Subject: Re: [siprec] Recording Session establishment from SRS to SRC

<as individual>

[RJ] It doesn't have to be siprec specific. We could possibly use registration event package for the registration state metadata and extensions of dialog event package for CS metadata. 

[RJ] An SRS vendor can probably speak more in depth about how complex the software behind the intelligence is. I believe it is fairly complex and the SRC vendors don't find it compelling to implement it. I think that's because customers requiring recording is typically a small subset of the overall SRC market (well, we wouldn't call it SRC when there is no recording). 

Raj

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 23 Jun 2010 17:34:40 -0400

> [RJ] It's a bit early to speak about a new event-package for siprec. I think the siprec metadata requirements could possibly be covered by a combined registration and dialog event-package implement…

That is a *bit* better.
But I think you had better come up with a very explicit use case. I 
suspect someone is going to be able to suggest an entirely different way 
to achieve the result.

> [RJ] I think you meant communications session and its constituents.

No, I very explicitly meant for it to be about *one* RS and its 
constituents. Notable constituents of an RS are CSs. So data about the 
CSs in the RS is in scope. But metadata about CSs that are not part of 
any RS is not, IMO, in scope.

 > Regardless of how we slice the metadata (over separate 
event-packages), but overall it includes CS data and also User AoR 
registration state data.

I'm not convinced of the registration state data.
I guess you could say:
- an RS consists of one or more CSs
- A CS has one or more Participants
- a participant has an AOR
- an AOR has current registration state

and that *might* justify why registration state might be relevant 
metadata for the RS.

OTOH, you could also say that
- a Participant may have a human user
- the human user has a favorite color
- thus the favorite color of the user could be metadata of the RS.
And that is just plain silly.

> [RJ] You don't to waste RTP ports on SRC and SRS if you don't intend to record. Eastblishing RS means that RTP ports get chewed.

You only have to waste ports when the SRS actually wants to record.
The SRC can offer it some media, and it can decide to refuse it by 
setting the port to zero, or by black hole'ing it with no address.

> [RJ] Nope. The metadata carries the revision info pertaing to CSs getting added or deleted. The RS is simply an RTP pipe.

With a persistent RS, I would expect that there would be a sip session 
with no media sessions until there was a CS of potential interest.
At that point there would be a reinvite offering the media from the CS, 
together with metadata describing it. The SRS could then decide to 
accept it or not.

> [RJ] That won't work because an RS can carry multiple CSs in it.

Not a problem. Assume there are two different CSs each involving two 
participants using only audio. This could be offered to the SRS as an 
offer with four media streams, one from each participant, together with 
metadata describing the two CSs and how they map onto those streams.

Of course this isn't practical if there are 1000 CSs. In that case a 
persistent RS isn't the right answer.

	Thanks,
	Paul

---

From: "Jain, Rajnish" <[email-masked]>
Date: Wed, 23 Jun 2010 20:07:53 -0400

That is a *bit* better.

[RJ] Not sure I undertsand what use case we can describe in more detail. We're talking about deployed systems here, so I'm sure we'll be able to explain this based on what's out there (I think it's more of a matter of us getting on the same page and syncing up our terminology as opposed to fundamental technical issues). Based on your comment, I'm assuming that we're still not convinced that an out-of-band metadata delivery mechanism will work.

No, I very explicitly meant for it to be about *one* RS and its
constituents. Notable constituents of an RS are CSs. So data about the
CSs in the RS is in scope.

[RJ] I misread the previous statement in that case.

But metadata about CSs that are not part of
any RS is not, IMO, in scope.

[RJ] We need to decide upon the relationship between Metadata and CS and RS. IMHO, Metadata is orthogonal to CS' and/or RS' existence.

[RJ] That's not the point. The point is that you establish RSs to the agent UA phone as soon as the agent logs in (read as SIP Registration). These are persistent RSs (RTP pipes) that'll stay alive throughout the agent login lifespan. CSs will come and go throuthout the day (silence suppression is a crucial part of this because silence is not recorded). Therefore, User AoR registration state notification is a critical part of this solution.

[RJ] Possibly, this works in theory but in practicality, I think most implemenations don't and won't support such behaviors.

[RJ] What does that mean? Something like an RS with a black-holed SDP (don't we want to stay away from such things)?

[RJ] That doesn't work. The issue is media clipping. We can't afford the latency that comes with a RE-INVITE. There are environments where they can't afford to miss a syllable in recording. That's the whole reason behind persistent recording sessions.

[RJ] Okay. I should mention that CS:RS ratio in our industry revolves around 5:1.

Raj

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 23 Jun 2010 21:32:50 -0400

> [RJ] That's not the point. The point is that you establish RSs to the agent UA phone as soon as the agent logs in (read as SIP Registration). These are persistent RSs (RTP pipes) that'll stay alive…

OK. Now we're getting to something tangible!
What you want is to establish a persistent RS to an agent phone when the 
agent logs in.

The next thing to do is determine what, in sip terms, constitutes an 
agent "logging in". Is it a transition from no registrations to one 
registration on his AOR? Or is it registration to his AOR from a 
"special" phone? Or what?

If its just the first registration to the AOR, then the reg event 
package can do the trick.

But much better is for the the phone, or the call center application the 
agent logs into from his PC, or whatever, to initiate the persistent RC.

There is so much call-center-specific stuff that surely you can find 
*something* that is triggered by the login that can initiate the 
persistent RC.

> [RJ] Possibly, this works in theory but in practicality, I think most implemenations don't and won't support such behaviors.

*No* implementation currently supports the eventual output of the WG.

Its probably not the right answer for you when the criterion is whether 
the agent is logged in. But it could be the right answer when the 
criterion is who is calling.

> [RJ] What does that mean? Something like an RS with a black-holed SDP (don't we want to stay away from such things)?

Why would we want to stay away from that. Its not a recommended 
technique *for HOLD*. But it is a perfectly fine technique for a variety 
of interesting cases of which this is one.

But when the SRC doesn't want to offer any, its easier and cleaner to 
simply reject the media line by setting the port to zero. You just have 
to teach the SRC and SRS not to drop calls when there are no media streams.

> [RJ] That doesn't work. The issue is media clipping. We can't afford the latency that comes with a RE-INVITE. There are environments where they can't afford to miss a syllable in recording. That's…

The reinvite would presumably occur in parallel with the invite into the 
CS. So unless the SRS is slower, it should see no more clipping than the 
  participants do.

And, depending on how you intercept the media, you are likely to need 
the reinvite anyway because the media source ip addresses will vary with 
each CS.

But I'm sure you can come up with a configuration where this could cause 
clipping. Seems like there are other solutions shaping up for your case 
anyway.

> [RJ] Okay. I should mention that CS:RS ratio in our industry revolves around 5:1.

5 audio only calls with two participants each makes 10 m-lines in the 
offer. Doesn't seem like a problem to me.

	Thanks,
	Paul

---

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

Hi Paul,

> package can do the trick.

I think the reg event package might be sufficient.

> agent logs into from his PC, or whatever, to initiate the persistent RC.

Yes. The notion that the RS is persistent is independent from the direction of the RS INVITE (SRC -> SRS or SRS -> SRC).

> to teach the SRC and SRS not to drop calls when there are no media

Possible. A common deployed way of achieving this to keep the RS RTP stream active but utilize silence suppression i.e. don't send RS RTP packets if there are no active CSs. This avoids the latency issues that manifest from signaling level interactions (such as RE-INVITEs).

> clipping. Seems like there are other solutions shaping up for your case

No loss of media is a pretty critical requirement.

> offer. Doesn't seem like a problem to me.

The 5 CS audio streams actually get mixed, so there is typically only one m-line for the RS. This is just a typical mixing ratio between CS and RS.

I guess we'll pick up this discussion in the other thread that John has started.

Raj