Subject: [siprec] I-D Action: draft-ietf-siprec-architecture-04.txt

From: [email-masked]
Date: Mon, 12 Mar 2012 06:24:33 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP Recording Working Group of the IETF.

	Title           : An Architecture for Media Recording using the Session Initiation Protocol
	Author(s)       : Andrew Hutton
                          Leon Portman
                          Rajnish Jain
                          Ken Rehor
	Filename        : draft-ietf-siprec-architecture-04.txt
	Pages           : 16
	Date            : 2012-03-12

   Session recording is a critical requirement in many communications
   environments such as call centers and financial trading.  In some of
   these environments, all calls must be recorded for regulatory,
   compliance, and consumer protection reasons.  Recording of a session
   is typically performed by sending a copy of a media stream to a
   recording device.  This document describes architectures for
   deploying session recording solutions in an environment which is
   based on the Session Initiation Protocol (SIP).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-siprec-architecture-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-siprec-architecture-04.txt

---

From: Leon Portman <[email-masked]>
Date: Tue, 13 Mar 2012 17:49:57 +0200

Main changes. They are mainly consist from Gonzalo and other mailing lists comments.

1. Definitions: Adding recording unaware UA definition and fixing some other definitions
2. Consistent abbreviation usage in the document
3. Figures fixes
4. Adding policy mentions in Endpoint as SRC
5. Removing WEBRTC mentions
6. Adding more descriptions in SRS initiated flows
7.Adding support for RS without metadata

There are some small typo mistakes in v04. I have already fixed them and will update in next version

Regards

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, March 12, 2012 3:25 PM
To: [email-masked]
Cc: [email-masked]
Subject: [siprec] I-D Action: draft-ietf-siprec-architecture-04.txt

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

---

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

Leon,

Could you please explain in detail about Sec 3.2.2 update

"   o  The actual mechanism of the identification is depends on SRC
      policy."

Thanks
partha

>From: [email-masked] [mailto:[email-masked]] On Behalf
>Of Leon Portman
>Sent: Tuesday, March 13, 2012 9:20 PM
>To: [email-masked]
>Subject: Re: [siprec] I-D Action: draft-ietf-siprec-architecture-04.txt
>
>1. Definitions: Adding recording unaware UA definition and fixing some
>other definitions 2. Consistent abbreviation usage in the document 3.
>Figures fixes 4. Adding policy mentions in Endpoint as SRC 5. Removing
>WEBRTC mentions 6. Adding more descriptions in SRS initiated flows
>A New Internet-Draft is available from the on-line Internet-Drafts
>directories. This draft is a work item of the SIP Recording Working
>Group of the IETF.
>

---

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

Leon,

Adding to the previous query, the same section mentions about join header usage

" o  Identify the session that is to be recorded - Possibly using the
      Join header [RFC3911]"

The problem with Join header is that Join header maps dialog and not CS. So, it is not generic approach for SIPREC. Please clarify in case I'm missing something here.

Thanks
Partha

>Of Ravindran, Parthasarathi
>Sent: Wednesday, March 14, 2012 7:42 PM
>To: Leon Portman; [email-masked]
>>From: [email-masked] [mailto:[email-masked]] On
>>Behalf Of Leon Portman

---

From: Leon Portman <[email-masked]>
Date: Fri, 16 Mar 2012 19:43:34 +0200

Partha Hi

The ways of identification of CS to be recorded for  SRS initiated flows are very dependent on actual SRC implementation.
For example, if SRC is PBX, it can be even CTI call id, participants ids, DNS name of end point etc.

For gateways it can be IP and PORT of RTP stream for example. 

This what i meant that it is very defendant on SRC and on the way how SRS knows about CSs.

Regards

Leon

On Mar 14, 2012, at 4:12 PM, "Ravindran, Parthasarathi" <[email-masked]> wrote:

>> Of [email-masked]

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Fri, 16 Mar 2012 17:59:38 +0000

Leon,

I agree with you that it is the way proprietary SIP recording works today. For each SRS initiated callflow, unique-id of a session is generated by PBX driven or CTI, SRC is forced to develop multiple solutions accordingly as there is a lack of standard mechanism.  I have concern because SRS initiated without any specific identification continue the same trend of today's proprietary recording solution. I wish to see some well-defined protocol mechanism from SRS to SRC to identity the session which has to recorded. Please let me know your opinion. 

As you have listed number of mechanism, I'm fine in case we nailed down to one of the mechanism as standard in the worst case.

Thanks
Partha 

>From: Leon Portman [mailto:[email-masked]]
>Sent: Friday, March 16, 2012 11:14 PM
>To: Ravindran, Parthasarathi
>Cc: Leon Portman; [email-masked]
>The ways of identification of CS to be recorded for  SRS initiated flows
>are very dependent on actual SRC implementation.
>>> 1. Definitions: Adding recording unaware UA definition and fixing
>>> some other definitions 2. Consistent abbreviation usage in the
>document 3.
>>> Figures fixes 4. Adding policy mentions in Endpoint as SRC 5.
>>> Removing WEBRTC mentions 6. Adding more descriptions in SRS initiated
>>> flows 7.Adding support for RS without metadata
>>>
>>> Behalf Of [email-masked]

---

From: Leon Portman <[email-masked]>
Date: Fri, 16 Mar 2012 20:06:08 +0200

Partha,

I completely agree with you. Session identification is one of the main pain points today. May be Global session ID work will help here? 
http://tools.ietf.org/html/draft-kaplan-dispatch-session-id-01

Leon

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Fri, 16 Mar 2012 18:16:03 +0000

Leon,

I agree with you that session-id solves the reported problem.

As you might know, Session id IETF WG namely INSIPID is in the very early stage and number of drafts under discussion for IETF-83 are listed in http://www.ietf.org/mail-archive/web/insipid/current/msg00005.html. IMO, creating session-id dependency will delay SIPREC deliverable. We will brainstorm more to find some way without session-id if exists.

Thanks
Partha

>Sent: Friday, March 16, 2012 11:36 PM
>I completely agree with you. Session identification is one of the main
>pain points today. May be Global session ID work will help here?
>> I agree with you that it is the way proprietary SIP recording works
>today. For each SRS initiated callflow, unique-id of a session is
>generated by PBX driven or CTI, SRC is forced to develop multiple
>solutions accordingly as there is a lack of standard mechanism.  I have
>concern because SRS initiated without any specific identification
>continue the same trend of today's proprietary recording solution. I
>wish to see some well-defined protocol mechanism from SRS to SRC to
>identity the session which has to recorded. Please let me know your
>opinion.
>>
>> As you have listed number of mechanism, I'm fine in case we nailed
>down to one of the mechanism as standard in the worst case.
>>
>> Thanks
>> Partha
>>
>>> The ways of identification of CS to be recorded for  SRS initiated
>>> flows are very dependent on actual SRC implementation.
>>>>> Removing WEBRTC mentions 6. Adding more descriptions in SRS
>>>>> initiated flows 7.Adding support for RS without metadata
>>>>>
>>>>> environments such as call centers and financial trading.  In some
>>>>> of these environments, all calls must be recorded for regulatory,
>>>>> compliance, and consumer protection reasons.  Recording of a
>>>>> session is typically performed by sending a copy of a media stream
>>>>> to a recording device.  This document describes architectures for
>>>>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-siprec-architecture-
>04.
>>>>> txt
>>>>>

---

From: Leon Portman <[email-masked]>
Date: Fri, 16 Mar 2012 20:20:49 +0200

The main question then, if it will be required to be defined in the protocol draft and we can keep architecture draft at high level in order to move forward

Leon

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Fri, 16 Mar 2012 18:38:32 +0000

Leon,

I agree with you. Let architecture document mentions only that the mechanism is required to identify the communication session in SRS-initiated callflow and exact mechanism will be defined in protocol draft.

Thanks
Partha

>Sent: Friday, March 16, 2012 11:51 PM
>The main question then, if it will be required to be defined in the
>protocol draft and we can keep architecture draft at high level in order
>to move forward
>
>Leon
>
>> As you might know, Session id IETF WG namely INSIPID is in the very
>early stage and number of drafts under discussion for IETF-83 are listed
>in http://www.ietf.org/mail-archive/web/insipid/current/msg00005.html.
>IMO, creating session-id dependency will delay SIPREC deliverable. We
>will brainstorm more to find some way without session-id if exists.
>>
>> Thanks
>> Partha
>>
>>> I completely agree with you. Session identification is one of the
>>> main pain points today. May be Global session ID work will help here?
>>> solutions accordingly as there is a lack of standard mechanism.  I
>>> have concern because SRS initiated without any specific
>>> identification continue the same trend of today's proprietary
>>> recording solution. I wish to see some well-defined protocol
>>> mechanism from SRS to SRC to identity the session which has to
>>> recorded. Please let me know your opinion.
>>>>
>>>>> For example, if SRC is PBX, it can be even CTI call id,
>>>>> participants ids, DNS name of end point etc.
>>>>>
>>>>>>> A New Internet-Draft is available from the on-line
>>>>>>> Internet-Drafts directories. This draft is a work item of the SIP
>>>>>>> Recording Working Group of the IETF.
>>>>>>>
>>>>>>> 	Title           : An Architecture for Media Recording using
>the
>>>>>>> Session Initiation Protocol
>>>>>>> Session recording is a critical requirement in many
>>>>>>> communications environments such as call centers and financial
>>>>>>> trading.  In some of these environments, all calls must be
>>>>>>> recorded for regulatory, compliance, and consumer protection
>>>>>>> reasons.  Recording of a session is typically performed by
>>>>>>> sending a copy of a media stream to a recording device.  This
>>>>>>> document describes architectures for deploying session recording
>>>>>>> solutions in an environment which is based on the Session
>Initiation Protocol (SIP).
>>>>>>>
>>>>>>>
>>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-siprec-architectur
>>>>>>> e-
>>>>>>> 04.txt
>>>>>>>

---

From: "Hutton, Andrew" <[email-masked]>
Date: Mon, 19 Mar 2012 14:49:57 +0100

Hi Leon,

I expected the bullet in section 3.2.2 stating "Identify the session that is to be recorded - Possibly using the Join header" to be removed in this latest update. The issue was raised by Gonzalo and in my response to those on the mailing list. (See http://www.ietf.org/mail-archive/web/siprec/current/msg03125.html).

In previous discussion I thought we had agreed at least in some scenarios there was no need to define such a mechanism as it would be up to policy at the SRC and for example in the persistent recording case there may not even be a CS at the time the RS is established.

Regards
Andy

> Behalf Of Ravindran, Parthasarathi
> Sent: 16 March 2012 18:39
> To: Leon Portman
> Cc: [email-masked]
> I agree with you. Let architecture document mentions only that the
> mechanism is required to identify the communication session in SRS-
> initiated callflow and exact mechanism will be defined in protocol
> draft.
> 
> Thanks
> Partha
> 
> >>>>>>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-siprec-
> architecture
> >>>>>>> -
> >>> 04.
> >>>>>>> txt
> >>>>>>>

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Mon, 19 Mar 2012 14:00:57 +0000

Hi Andy,

As I mentioned in the below mail, the policy of SRC should not decide what recording has to be started rather it has to be clearly mentioned by SRS and it will leads to interop issue as SRS has to expect recording based on different SRC implementation.

In case CS id is not generic enough for SRS-initiated callflow. Let us work for the list of possible standard mechanism required 

1) Communication Session-id 
2) participant
3) stream???

I still think that the exact SRS-initiated recording mechanism has to be mentioned in the protocol draft rather than in the architecture document.

Thanks
Partha

>From: Hutton, Andrew [mailto:[email-masked]]
>Sent: Monday, March 19, 2012 7:20 PM
>To: Ravindran, Parthasarathi; Leon Portman
>Cc: [email-masked]
>Subject: RE: [siprec] I-D Action: draft-ietf-siprec-architecture-04.txt
>
>Hi Leon,
>
>I expected the bullet in section 3.2.2 stating "Identify the session
>that is to be recorded - Possibly using the Join header" to be removed
>in this latest update. The issue was raised by Gonzalo and in my
>response to those on the mailing list. (See http://www.ietf.org/mail-
>archive/web/siprec/current/msg03125.html).
>
>In previous discussion I thought we had agreed at least in some
>scenarios there was no need to define such a mechanism as it would be up
>to policy at the SRC and for example in the persistent recording case
>there may not even be a CS at the time the RS is established.
>
>Regards
>Andy
>
>
>
>
>> >in http://www.ietf.org/mail-
>archive/web/insipid/current/msg00005.html.
>> >>>>>>> There are some small typo mistakes in v04. I have already
>> >>>>>>> fixed them and will update in next version
>> >>>>>>>
>> >>>>>>> Regards
>> >>>>>>>
>> >>>>>>> Leon
>> >>>>>>>

---

From: Leon Portman <[email-masked]>
Date: Mon, 19 Mar 2012 16:10:18 +0200

Actually these are two separate issues, one is how to identify the communication session, and second how to indicate it in RS invite (FROM SRS to SRC). 
Back to Andy comment, even for persistent use case, SRS will send re-invite with some CS identifier so we need to have such mechanism. My understanding from the below thread was to add the policy mentioning and not just to completely remove the mechanism mentioning. I am ok with both options. 
I will remove Join example it in the next update.

Regards

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ravindran, Parthasarathi
Sent: Monday, March 19, 2012 4:01 PM
To: Hutton, Andrew; Leon Portman
Cc: [email-masked]
Subject: Re: [siprec] I-D Action: draft-ietf-siprec-architecture-04.txt

Hi Andy,

Thanks
Partha

>scenarios there was no need to define such a mechanism as it would be 
>up to policy at the SRC and for example in the persistent recording 
>case there may not even be a CS at the time the RS is established.
>
>Regards
>Andy
>
>
>
>
>> >IMO, creating session-id dependency will delay SIPREC deliverable. 
>> >We will brainstorm more to find some way without session-id if exists.
>> >>
>> >> Thanks
>> >> Partha
>> >>
>> >>> solutions accordingly as there is a lack of standard mechanism.  
>> >>> I have concern because SRS initiated without any specific 
>> >>>>>>> From: [email-masked] 
>> >>>>>>> [mailto:[email-masked]]
>> On
>> >>>>>>> Behalf Of Leon Portman
>> >>>>>>> From: [email-masked] 
>> >>>>>>> [mailto:[email-masked]]
>> On
>> >>>>>>> communications environments such as call centers and 
>> >>>>>>> financial trading.  In some of these environments, all calls 
>> >>>>>>> must be recorded for regulatory, compliance, and consumer 
>> >>>>>>> protection reasons.  Recording of a session is typically 
>> >>>>>>> performed by sending a copy of a media stream to a recording 
>> >>>>>>> device.  This document describes architectures for deploying 
>> >>>>>>> session
>> recording

---

From: "Hutton, Andrew" <[email-masked]>
Date: Mon, 19 Mar 2012 15:17:01 +0100

See below.

Regards
Andy

> From: Leon Portman [mailto:[email-masked]]
> Sent: 19 March 2012 14:10
> To: Ravindran, Parthasarathi; Hutton, Andrew; Leon Portman
> Cc: [email-masked]
> Actually these are two separate issues, one is how to identify the
> communication session, and second how to indicate it in RS invite (FROM
> SRS to SRC).
> Back to Andy comment, even for persistent use case, SRS will send re-
> invite with some CS identifier so we need to have such mechanism. 

[AndyH] - I assume this should be "SRS MAY send re-invite with some CS Identifier..." because of course it can be the SRC that makes that decision based on policy.  

>My
> understanding from the below thread was to add the policy mentioning
> and not just to completely remove the mechanism mentioning. I am ok
> with both options.

[AndyH] - I think we should remove the mechanism from the architecture draft the "Join" example was there to promote discussion even before we had a protocol draft and I think should now be removed.

> As I mentioned in the below mail, the policy of SRC should not decide
> what recording has to be started rather it has to be clearly mentioned
> by SRS and it will leads to interop issue as SRS has to expect
> recording based on different SRC implementation.
> 
> In case CS id is not generic enough for SRS-initiated callflow. Let us
> work for the list of possible standard mechanism required
> 
> I still think that the exact SRS-initiated recording mechanism has to
> be mentioned in the protocol draft rather than in the architecture
> document.
> 
> Thanks
> Partha
> 
> >> >>>>>> "   o  The actual mechanism of the identification is depends
> on
> >> >SRC
> >> >>>>>>    policy."
> >> >>>>>>
> >> >>>>>> Thanks
> >> >>>>>> partha
> >> >>>>>>
> >> >>>>>>> Internet-Drafts directories. This draft is a work item of
> the
> >> SIP

---

From: Leon Portman <[email-masked]>
Date: Mon, 19 Mar 2012 16:17:45 +0200

Agree on both comments

Leon

-----Original Message-----
From: Hutton, Andrew [mailto:[email-masked]] 
Sent: Monday, March 19, 2012 4:17 PM
To: Leon Portman; Ravindran, Parthasarathi; Leon Portman
Cc: [email-masked]
Subject: RE: [siprec] I-D Action: draft-ietf-siprec-architecture-04.txt

See below.

Regards
Andy

> communication session, and second how to indicate it in RS invite 
> (FROM SRS to SRC).

> >that is to be recorded - Possibly using the Join header" to be 
> >removed in this latest update. The issue was raised by Gonzalo and in 
> >my response to those on the mailing list. (See 
> >http://www.ietf.org/mail- archive/web/siprec/current/msg03125.html).
> >
> >> >The main question then, if it will be required to be defined in 
> >> >the protocol draft and we can keep architecture draft at high 
> >> >level in
> >> order
> >> >to move forward
> >> >
> >> >Leon
> >> >
> >> >>>>>>> financial trading.  In some of these environments, all 
> >> >>>>>>> calls must be recorded for regulatory, compliance, and 
> >> >>>>>>> consumer protection reasons.  Recording of a session is 
> >> >>>>>>> typically performed by sending a copy of a media stream to 
> >> >>>>>>> a recording device.  This document describes architectures 
> >> >>>>>>> for deploying session
> >> recording

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Mon, 19 Mar 2012 14:26:29 +0000

Andy,

Could you please explain how SRC policy based recording will not cause issue in SRS as SRS will not know what is going to be recorded when initiating RS INVITE. 

Based on my experience, I noticed that SRC policy based SRS-initiated callflow cause more issue to SRC as well. 

Thanks
Partha

>Sent: Monday, March 19, 2012 7:47 PM
>[AndyH] - I assume this should be "SRS MAY send re-invite with some CS
>Identifier..." because of course it can be the SRC that makes that
>decision based on policy.
>
>>My
>[AndyH] - I think we should remove the mechanism from the architecture
>draft the "Join" example was there to promote discussion even before we
>had a protocol draft and I think should now be removed.
>
>>
>> Regards
>>
>> Leon
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 19 Mar 2012 10:39:12 -0400

> Based on my experience, I noticed that SRC policy based SRS-initiated callflow cause more issue to SRC as well.

It is my understanding that selection of what is to be recorded in an 
SRS initiated RS is *out of scope*. We allow the SRS to initiate an RS 
but don't say anything about how the SRC then decides what to record. 
Practically speaking that makes it SRC policy. If the SRS chooses to use 
some private extension to indicate the recording target(s) then that is 
effectively still an SRC policy, since the SRC must choose to honor the 
extension.

The alternative is to put this in scope and define some specific 
mechanism(s) for the SRS to indicate the target(s) to the SRC. If we go 
that way it seems to require added normative behavior on the SRC.

	Thanks,
	Paul

---

From: "Hutton, Andrew" <[email-masked]>
Date: Mon, 19 Mar 2012 15:46:46 +0100

Hi Partha,

I am not sure I understand your concern. The minimum an SRS may know is that it needs to initiate a RS with certain SRC's but it does not necessarily need to know exactly what is going to be recorded. The SRC will tell the SRS what is being recorded using SDP and metadata.

Regards
Andy

> From: Ravindran, Parthasarathi [mailto:[email-masked]]
> Sent: 19 March 2012 14:26
> To: Hutton, Andrew; Leon Portman; Leon Portman
> Cc: [email-masked]
> Could you please explain how SRC policy based recording will not cause
> issue in SRS as SRS will not know what is going to be recorded when
> initiating RS INVITE.
>
> Based on my experience, I noticed that SRC policy based SRS-initiated
> callflow cause more issue to SRC as well.
>
> Thanks
> Partha
>
> >> >http://www.ietf.org/mail-
> >> >> >Subject: Re: [siprec] I-D Action: draft-ietf-siprec-
> architecture-
> >> >> 04.txt
> >> >> >
> >> >> >early stage and number of drafts under discussion for IETF-83
> are
> >> >> listed
> >> >> >>> main pain points today. May be Global session ID work will
> help
> >> >> here?
> >> >> >>>> I agree with you that it is the way proprietary SIP
> recording
> >> >> works
> >> >> >>> today. For each SRS initiated callflow, unique-id of a
> session
> >> is
> >> >> >>>>> This what i meant that it is very defendant on SRC and on
> the
> >> >> >>>>> way how SRS knows about CSs.
> >> >> >>>>>
> >> >> >>>>> Regards
> >> >> >>>>>
> >> >> >>>>> Leon
> >> >> >>>>>
> >> >> >>>>>>> 1. Definitions: Adding recording unaware UA definition
> and
> >> >> fixing
> >> >> >>>>>>> some other definitions 2. Consistent abbreviation usage
> in
> >> >> >>>>>>> the
> >> >> >>>>> document 3.
> >> >> >>>>>>> Figures fixes 4. Adding policy mentions in Endpoint as
> SRC
> >> 5.