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

From: "Elwell, John" <[email-masked]>
Date: Thu, 1 Jul 2010 09:34:56 +0200

Partha,

Thanks for pointing out that earlier thread. I note that the requirement you cite below is already captured as REQ-033.

I still believe REQ-019 and REQ-020 go beyond what is necessary in a requirements document. As long as there is metadata describing a CS and its media, and relating those media to RS media, I don't see any need for specifying, in the requirements document, anything about the RS >>dialog<<. 

I would also note that we have a rather excessive number of requirements to do with correlation.

- "REQ-017 The mechanism MUST support the ability to correlate the
   request to record a call with the session being recorded."
- "REQ-018 The mechanism MUST support the ability to correlate the
   request to record specific media sessions with the SIP session and
   media to be recorded (Recorded Session)."
- "REQ-019 The mechanism MUST support the ability to transport the
   metadata in the same SIP dialog as the Recording Session."
- "REQ-020 The mechanism MUST support the ability to transport the
   metadata outside of the Recording Session SIP dialog."
- "REQ-022 The mechanism MUST support the ability to correlate
   metadata to the Recording Session."
- "REQ-033 The mechanism SHALL support means to relate Recording
   Session(s) with Communication Session(s)."

I find these totally confusing, which accounts for some of the issues I raised on the tracker.

On the other hand there is no requirement saying that the mechanism has to provide metadata (only requirements about how to correlate it).

I think we can simplify things a lot. I believe the following two requirements are sufficient to cover the provision of metadata AND replace all 6 requirements above:

- REQ-x1 The mechanism MUST provide the SRS with metadata describing CSs that are being recorded, including the media being used and the identities of parties involved.
- REQ-x2 The mechanism MUST provide the SRS with the means to corrrelate RS media with CS media described in metadata.

If we were to do this, what would be missing?

John

> -----Original Message-----
> From: Parthasarathi R (partr) [mailto:[email-masked]] 
> Sent: 30 June 2010 18:03
> To: siprec issue tracker; Ken Rehor (krehor); Elwell, John
> Cc: [email-masked]
> Subject: RE: [siprec] #31: Do we need REQ-019 and REQ-020 on 
> metadata transport?
> 
> John,
>  
> REG-019 is opened to track the following requirement: <To 
> make the explicit requirement by which the single RS shall be 
> related to multiple CS. The requirement text shall be "The 
> mechanism SHALL support means to relate RS(s) with CS(s)" > 
> which is different from REG-30 definition of REG-19: "The 
> mechanism MUST support the ability to transport the metadata 
> in the same SIP dialog as the Recording Session".
>  
> IMO, we discussed in detail before opening REG-019 and it has 
> to be added as a requirement in requirement document. This 
> requirement is discussed on the following mail thread(s):
>  
> http://www.ietf.org/mail-archive/web/siprec/current/msg00249.h
> tml 
> <http://www.ietf.org/mail-archive/web/siprec/current/msg00249.html> 
>  
> http://www.ietf.org/mail-archive/web/siprec/current/msg00240.h
> tml 
> <http://www.ietf.org/mail-archive/web/siprec/current/msg00240.html> 
>  
> http://www.ietf.org/mail-archive/web/siprec/current/msg00241.h
> tml 
> <http://www.ietf.org/mail-archive/web/siprec/current/msg00241.html> 
> 
> REG-019 does not mention about any specific solution. It only 
> clarifies that there is a possibility of 1:N relationship 
> between RS and CS. Could you please inlcude REG-019 in the 
> requirement.
>  
> Thanks
> Partha
> 
>  
> ________________________________
> 
> From: [email-masked] on behalf of siprec issue tracker
> Sent: Tue 6/29/2010 9:47 PM
> To: Ken Rehor (krehor); [email-masked]
> Cc: [email-masked]
> Subject: [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:                 
> ------------------------------------------------+-------------
> --------------
>  REQ-019 "The mechanism MUST support the ability to transport the
>     metadata in the same SIP dialog as the Recording Session." and
>  REQ-020 "The mechanism MUST support the ability to transport the
>     metadata outside of the Recording Session SIP dialog."
>  These are getting rather solution-specific - why do we need 
> these, and if
>  we do need one, why do we need both?
> 
>  John
> 
> --
> Ticket URL: <http://trac.tools.ietf.org/wg/siprec/trac/ticket/31>
> siprec <http://tools.ietf.org/siprec/>
> 
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec
> 
> 
>

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Fri, 2 Jul 2010 19:11:04 +0530

John,

- REQ-x1 The mechanism MUST provide the SRS with metadata describing CSs
that are being recorded, including the media being used and the
identities of parties involved.
- REQ-x2 The mechanism MUST provide the SRS with the means to corrrelate
RS media with CS media described in metadata.

<Partha> The above two requirements looks good. Please update these
requirements in ticket 33. </Partha>
Thanks
Partha

John

> Subject: RE: [siprec] #31: Do we need REQ-019 and REQ-020 on metadata 
> transport?
> 
> John,
>  
> REG-019 is opened to track the following requirement: <To make the 
> explicit requirement by which the single RS shall be related to 
> multiple CS. The requirement text shall be "The mechanism SHALL 
> support means to relate RS(s) with CS(s)" > which is different from 
> REG-30 definition of REG-19: "The mechanism MUST support the ability 
> to transport the metadata in the same SIP dialog as the Recording 
> Session".
>  
> IMO, we discussed in detail before opening REG-019 and it has to be 
> added as a requirement in requirement document. This requirement is 
> discussed on the following mail thread(s):
>  
> clarifies that there is a possibility of 1:N relationship between RS 
> and CS. Could you please inlcude REG-019 in the requirement.
>  
> Thanks
> Partha
> 
>  
> Subject: [siprec] #31: Do we need REQ-019 and REQ-020 on metadata 
> transport?
> 
> 
> 
>  These are getting rather solution-specific - why do we need these, 
> and if  we do need one, why do we need both?
> 
>  John
> 
> --

---

From: "Elwell, John" <[email-masked]>
Date: Sat, 3 Jul 2010 18:05:04 +0200

> Sent: 02 July 2010 14:41
> To: Elwell, John; siprec issue tracker; Ken Rehor (krehor)
> Cc: [email-masked]
[JRE] Ticket 33? This ticket does not relate to any of the cited REQs that the two new REQs (REQ-x1/x2) above would replace (REQ-017/018/019/020/022/034). I think if we adopt these two new REQs, it will enable us to close several tickets, but not ticket #33.

John

> between RS

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Mon, 5 Jul 2010 10:17:53 +0530

John,
 
Pleae read inline.
 
Thanks
Partha

From: Elwell, John [mailto:[email-masked]]
Sent: Sat 7/3/2010 9:35 PM
To: Parthasarathi R (partr); siprec issue tracker; Ken Rehor (krehor)
Cc: [email-masked]
Subject: RE: [siprec] #31: Do we need REQ-019 and REQ-020 on metadata transport?

[JRE] Ticket 33? This ticket does not relate to any of the cited REQs that the two new REQs (REQ-x1/x2) above would replace (REQ-017/018/019/020/022/034). I think if we adopt these two new REQs, it will enable us to close several tickets, but not ticket #33.
<Partha> I'm fine with any approach as long as the above two requirements are added in WG. I thought by your earlier mail that you wish to track them as ticket #33

<SNIP JRE> Thanks for pointing out that earlier thread. I note that the requirement you cite below is already captured as REQ-033. </SNIP JRE>

</Partha>

John

---

From: Deepanshu Gautam <[email-masked]>
Date: Mon, 05 Jul 2010 16:56:25 +0800

Some points may be missing like:

1. SRS being provisioned with metadata describing CSs that are *to be*
recorded.
2. SRS being provisioned with the means to correlate RS with *different* CSs
and viceversa. (current REQ-33 is taking care of it, its better to keep it
intact)

REQ-22 is indeed wired and either should be clarified or removed. 17 and 18
may need to be calrified. I'm not sure about removing 19, 20 and 33

Regards
Deepanshu 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Elwell, John
Sent: 2010年7月1日 15:35
To: Parthasarathi R (partr); siprec issue tracker; Ken Rehor (krehor)
Cc: [email-masked]
Subject: Re: [siprec] #31: Do we need REQ-019 and REQ-020 on metadata
transport?

Partha,

Thanks for pointing out that earlier thread. I note that the requirement you
cite below is already captured as REQ-033.

I still believe REQ-019 and REQ-020 go beyond what is necessary in a
requirements document. As long as there is metadata describing a CS and its
media, and relating those media to RS media, I don't see any need for
specifying, in the requirements document, anything about the RS >>dialog<<. 

I would also note that we have a rather excessive number of requirements to
do with correlation.

I find these totally confusing, which accounts for some of the issues I
raised on the tracker.

On the other hand there is no requirement saying that the mechanism has to
provide metadata (only requirements about how to correlate it).

I think we can simplify things a lot. I believe the following two
requirements are sufficient to cover the provision of metadata AND replace
all 6 requirements above:

- REQ-x1 The mechanism MUST provide the SRS with metadata describing CSs
that are being recorded, including the media being used and the identities
of parties involved.
- REQ-x2 The mechanism MUST provide the SRS with the means to corrrelate RS
media with CS media described in metadata.

John

---

From: "siprec issue tracker" <[email-masked]>
Date: Thu, 08 Jul 2010 15:45:55 -0000

#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/>

---

From: Leon Portman <[email-masked]>
Date: Sun, 11 Jul 2010 10:34:52 +0300

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?

 Further thoughts.:

 John (as individual)

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 11 Jul 2010 16:29:06 -0400

Leon,

I still have an open mind about the mechanisms to be used to transport 
all this data. It might be sub/not, or INFO, or bodies or headers in 
INVITE, ...

I think its highly likely that XML will be used to describe the data in 
one context or another. But I think its premature to get into that level 
of detail - it would be distracting and focus on details before there is 
agreement on fundamentals.

There *might* end up to be a schema for the data as stored at the SRS, 
and another schema for each distinct "transaction" used to transmit 
metadata to the SRS. In practice there might be less. But it will be 
easier to decide after we know what all the data is, and have some at 
least tentative agreement on the mechanisms to be used to transmit it.

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 12 Jul 2010 08:33:55 +0200

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)

> From: Leon Portman [mailto:[email-masked]] 
> Sent: 11 July 2010 08:35
> To: siprec issue tracker; [email-masked]; Elwell, John
> Cc: [email-masked]
> 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
> 
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of siprec issue tracker
> Comment(by john.elwell@...):
> 
>  Further thoughts.:
> 
> Ticket URL: 
> <http://trac.tools.ietf.org/wg/siprec/trac/ticket/31#comment:1>

---

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

Paul, Hi

I completely agree with you on the order in which we should do things: agree on the use cases, agree on content that then decide on the mechanism.

Just one comment, the way how SRS stores the metadata is actually less important however it is very important for SRS to receive call events in real time and not like CDR report at the end of the call. 

Regards

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Sunday, July 11, 2010 11:29 PM
To: Leon Portman
Cc: siprec issue tracker; [email-masked]
Subject: Re: [siprec] #31: Do we need REQ-019 and REQ-020 on metadata transport?

Leon,

	Thanks,
	Paul

---

From: "siprec issue tracker" <[email-masked]>
Date: Thu, 29 Jul 2010 16:48:10 -0000

#31: Do we need REQ-019 and REQ-020 on metadata transport?
------------------------------------------------+---------------------------
 Reporter:  john.elwell@…                       |        Owner:  krehor@…        
     Type:  defect                              |       Status:  closed          
 Priority:  minor                               |    Milestone:                  
Component:  Requirements                        |      Version:                  
 Severity:  Active WG Document                  |   Resolution:  fixed           
 Keywords:                                      |  
------------------------------------------------+---------------------------
Changes (by krehor@…):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 Revised the requirements to remove requirement for SIP dialog.

-- 
Ticket URL: <http://tools.ietf.org/wg/siprec/trac/ticket/31#comment:2>
siprec <http://tools.ietf.org/siprec/>