Subject: Re: [siprec] #31: Do we need REQ-019 and REQ-020 on metadata transport?

From: Leon Portman <[email-masked]>
Date: Mon, 12 Jul 2010 11:57:04 +0300

John, Hi

But what about events that's are outside CS? Like presence or login/logout, ready/not ready? 

Regards

Leon

----- Original Message -----
From: Elwell, John <[email-masked]>
To: Leon Portman; siprec issue tracker <[email-masked]>; [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>
Sent: Mon Jul 12 09:33:55 2010
Subject: RE: [siprec] #31: Do we need REQ-019 and REQ-020 on metadata transport?

Leon,

So you seem to be agreeing that we need a requirement for delivering metadata from the SRC to the SRS. In my opinion, it is not necessary in the requirements document to say whether it is in-dialog or out-of-dialog (that is a solution matter), so I would propose a single requirement something like this:
"REQ-019 The mechanism MUST support the ability to transport metadata from the SRC to the SRS at the start of and during a CS."
(REQ-020 would be removed)

John (as individual)

> -----Original Message-----
> From: Leon Portman [mailto:[email-masked]] 
> Sent: 11 July 2010 08:35
> To: siprec issue tracker; [email-masked]; Elwell, John
> Cc: [email-masked]
> Subject: RE: [siprec] #31: Do we need REQ-019 and REQ-020 on 
> metadata transport?
> 
> The original intent for REQ-20 was exactly like you stated: 
> Subscribe/Notify event package that reports in real time (not 
> CDR) call events and metadata from SRC to SRS for following 
> main use cases:
> 1. Recording decision for the case SRS decides on the 
> recording (for example recording 10 calls per agent per 
> shift, SRC does not know anything about agent shifts) and 
> SRS->SRC recording invocation
> 2. Reporting additional events like presence status (can be 
> done by other means as well) that are outside of CS
> 3. Possible replacement of traditional CTI/CDR interfaces 
> like JTAPI,TSAPI,CSTA - probably out of scope however from 
> implementation point of view why to have two different methods
> 
> I think it is very important that SIPREC will define at least 
> mandatory XML schema for basic metadata events and parameters 
> (like Paul already started) otherwise we will miss the goal 
> for standardization of the recording interfaces: we cannot 
> build a recording solution without metadata reporting.
> 
> Leon
> 
> 
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of siprec issue tracker
> Sent: Thursday, July 08, 2010 6:46 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: [siprec] #31: Do we need REQ-019 and REQ-020 on 
> metadata transport?
> 
> #31: Do we need REQ-019 and REQ-020 on metadata transport?
> ------------------------------------------------+-------------
> --------------
>  Reporter:  john.elwell@...                       |       
> Owner:  krehor@...        
>      Type:  defect                              |      
> Status:  new             
>  Priority:  minor                               |   
> Milestone:                  
> Component:  Requirements                        |     
> Version:                  
>  Severity:  Active WG Document                  |    
> Keywords:                  
> ------------------------------------------------+-------------
> --------------
> 
> Comment(by john.elwell@...):
> 
>  Further thoughts.:
> 
>  These requirements are rather solution specific, so if we 
> really need one
>  or both of these, they should at least be worded differently, without
>  talking about SIP dialogs.
> 
>  From off-line discussions, I gather that REQ-20 was written 
> with non-SIP
>  means in mind, e.g., JTAPI. Previously I had interpreted 
> REQ-20 as being
>  aimed at SIP but outside the context of the INVITE-initiated 
> SIP dialog
>  used for the RS (e.g., using SIP PUBLISH or SUBSCRIBE/NOTIFY), but it
>  seems this was perhaps not the intention.
> 
>  So in that case, I think the real question is whether we have a
>  requirement for delivering metadata from the SRC to the SRS 
> as part of
>  SIPREC (in which case it would be some form of SIP-based 
> solution) and/or
>  whether we have a requirement for the SRS to obtain metadata 
> from some
>  other source via non-SIP means (e.g., from CDR via JTAPI). I 
> believe the
>  latter would be outside the scope of SIPREC, in which case 
> we are left
>  with just the former.
> 
>  The SIPREC charter includes "Session metadata content and 
> format", and I
>  had interpreted this (rightly or wrongly) as meaning that we should
>  include a mechanism for delivering metadata as part of the 
> solution, and
>  delivery should be SIP-based. This would indeed suggest that 
> we have a
>  requirement for delivering metadata from the SRC to the SRS 
> via SIP. So
>  perhaps we need REQ-19 (suitably reworded) but not REQ-20.
> 
>  John (as individual)
> 
> -- 
> Ticket URL: 
> <http://trac.tools.ietf.org/wg/siprec/trac/ticket/31#comment:1>
> siprec <http://tools.ietf.org/siprec/>
> 
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec
>

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 12 Jul 2010 11:45:36 +0200

This will depend on our definition of metadata content, as discussed on a separate thread. However, I would note that the requirements draft mainly talks about "session metadata" and "call metadata", which would seem to exclude the sort of things you mention below. The definition of metadata is "Data that describes the Communication Session and Recording Session", which again would seem to exclude the things you mention below.

Also we have existing presence documents and protocols, so I am doubtful about defining anything new in that space.

John (as individual)

> Sent: 12 July 2010 09:57
> To: Elwell, John; [email-masked]'; [email-masked]'
> Cc: [email-masked]'
> So you seem to be agreeing that we need a requirement for 
> delivering metadata from the SRC to the SRS. In my opinion, 
> it is not necessary in the requirements document to say 
> whether it is in-dialog or out-of-dialog (that is a solution 
> matter), so I would propose a single requirement something like this:
> "REQ-019 The mechanism MUST support the ability to transport 
> metadata from the SRC to the SRS at the start of and during a CS."

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 12 Jul 2010 09:17:42 -0400

> But what about events that's are outside CS? Like presence or login/logout, ready/not ready? 

I'm having a conceptual problem here.

Potentially there can be a number of SRSs.
Presumably an SRC, when it wishes to establish an RS, picks an SRS to 
use. Then data sent by the SRC to that SRS, about that RS, will be all 
arriving at one place and associated with an RS.

If two different SRCs get involved with the same CS, then they may pick 
different SRSs, and the RSs they create will (presumably) be distinct. 
Its going to take some effort to get those RSs linked. One possibility 
is that one of the SRCs is given a reference (e.g. URL) to the other RS, 
by somebody involved with the other SRC. Another way is for the various 
SRSs (or the database servers they employ) to be aware of one another 
and exchange information to establish correlations.

When you start talking about random events outside of a CS, you compound 
that problem. To send metadata about such a thing, some agent aware of 
the event (an SRC?) but pick an SRS and then send the data. Does that 
result in creating an RS for that one event? If so, then there may be a 
lot more RSs for which correlations must be discovered. If not, then 
there is some additional metadata structure that hasn't yet been 
discussed that will have its own linkage issues.

I realize this is simpler if you simply assume that all SRSs talk to a 
common database. But I think that is an unrealistic assumption for this WG.

Also, I thought there had been agreement that metadata transport would 
be confined to an RS, and that everything else was out of scope.

	Thanks,
	Paul

---

From: Leon Portman <[email-masked]>
Date: Mon, 12 Jul 2010 16:41:28 +0300

Paul, Hi

We should not treat SRS as a bunch of dumb recording servers that only serves as a sink of the media and metadata. In real word implementation SRS is an application server with multiple media servers that handles not only voice but also screen and other types of interaction. In addition it provides of course analytics capabilities including real time guidance etc. It is also usually multi layered solution (store&forward) where captured voice is then forwarded to some central location and archiving for long term.
>From CS and RS correlation point of view, the problem is usually not multiple SRS (because they have centralized A/S) but "cradle to grave" where we need to follow and record call through transfers between different PBxs (like Dave's example)

Regards

Leon

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Monday, July 12, 2010 4:18 PM
To: Leon Portman
Cc: [email-masked]'; [email-masked]'; [email-masked]'; [email-masked]'
Subject: Re: [siprec] #31: Do we need REQ-019 and REQ-020 on metadata transport?

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 12 Jul 2010 11:28:25 -0400

>>From CS and RS correlation point of view, the problem is usually not multiple SRS (because they have centralized A/S) but "cradle to grave" where we need to follow and record call through transfers…

I'd like to hear other viewpoints on that.

Its my impression that "dumb recording servers that only serves as a 
sink of the media and metadata" are at least in scope. Smarter ones are 
presumably also in scope. But how much of the extra smarts are 
themselves in scope is not at all clear to me.

	Thanks,
	Paul

---

From: Leon Portman <[email-masked]>
Date: Mon, 12 Jul 2010 18:37:45 +0300

Paul, 

Just additional comment, that "dumb types of SRS" usually will be part of Communication System (PBX), Gateways, SBC that just records everything (SRS and SRC are the same component), and the main use case for SIPREC is where SRS and SRC are separate components.

Regards

Leon

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Monday, July 12, 2010 6:28 PM
To: Leon Portman
Cc: [email-masked]'; [email-masked]'; [email-masked]'; [email-masked]'
Subject: Re: [siprec] #31: Do we need REQ-019 and REQ-020 on metadata transport?

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 12 Jul 2010 17:52:16 +0200

I indicated in Anaheim that we should try to limit the scope of initial deliverables from SIPREC, and this might be an area where we can just cover the simple case in initial deliverables.

John (as chair) 

> Sent: 12 July 2010 16:28
> Cc: Elwell, John; [email-masked]'; [email-masked]'; 
> [email-masked]'
> > We should not treat SRS as a bunch of dumb recording 
> servers that only serves as a sink of the media and metadata. 
> In real word implementation SRS is an application server with 
> multiple media servers that handles not only voice but also 
> screen and other types of interaction. In addition it 
> provides of course analytics capabilities including real time 
> guidance etc. It is also usually multi layered solution 
> (store&forward) where captured voice is then forwarded to 
> some central location and archiving for long term.
> >>From CS and RS correlation point of view, the problem is 
> usually not multiple SRS (because they have centralized A/S) 
> but "cradle to grave" where we need to follow and record call 
> through transfers between different PBxs (like Dave's example)
> 
> > Cc: [email-masked]'; 
> [email-masked]'; [email-masked]'; [email-masked]'
> >> To: Leon Portman; siprec issue tracker 
> <[email-masked]>; [email-masked] <[email-masked]>
> >> "REQ-019 The mechanism MUST support the ability to 
> transport metadata from the SRC to the SRS at the start of 
> and during a CS."