Subject: Re: [siprec] FW: I-D Action:draft-hutton-siprec-session-recording-arch-01.txt

From: "Hutton, Andrew" <[email-masked]>
Date: Fri, 2 Jul 2010 19:19:54 +0200

Hi Peter,

I am not sure how this would work using a stateful proxy maybe if you sent me a picture and/or some text describing how a stateful proxy could create the recording session it would help.

Sorry for the slow response.

Regards
Andy

> -----Original Message-----
> From: Peter Musgrave [mailto:[email-masked]] 
> Sent: 21 June 2010 18:58
> To: Hutton, Andrew
> Cc: [email-masked]
> Subject: Re: [siprec] FW: I-D 
> Action:draft-hutton-siprec-session-recording-arch-01.txt
> 
> Hi Andrew,
> 
> I agree with the sentiment that the doc is in good shape.
> 
> My only question is whether the two architectural choices (B2B or
> endpoint) are enough. Do we see any need for looking at an
> architecture which would allow a stateful proxy to ensure recording
> occurs on calls? If this is viewed as a logical sub-case of the B2B
> man-in-middle mode then perhaps that could be explicitly stated?
> 
> Regards,
> 
> Peter Musgrave
> 
> On Fri, Jun 18, 2010 at 12:33 PM, Hutton, Andrew
> <[email-masked]> wrote:
> >
> > From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> > Sent: 18 June 2010 17:30
> > To: [email-masked]
> > Subject: I-D 
> Action:draft-hutton-siprec-session-recording-arch-01.txt
> >
> > A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> >
> >        Title           : An Architecture for Media 
> Recording using the Session Initiation Protocol
> >        Author(s)       : A. Hutton, et al.
> >        Filename        : 
> draft-hutton-siprec-session-recording-arch-01.txt
> >        Pages           : 15
> >        Date            : 2010-06-18
> >
> > 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-hutton-siprec-sessio
> n-recording-arch-01.txt
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > Below is the data which will enable a MIME compliant mail reader
> > implementation to automatically retrieve the ASCII version of the
> > Internet-Draft.
> >
> > _______________________________________________
> > siprec mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/siprec
> >
> >
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 02 Jul 2010 13:47:50 -0400

> I am not sure how this would work using a stateful proxy maybe if you sent me a picture and/or some text describing how a stateful proxy could create the recording session it would help.

I too am scratching my head to decide if this could be feasible.

The only thing that comes to mind is:

If a proxy in the signaling path for a CS decides that recording is 
required, it could send a REFER to an SRS with the Refer-To uri being 
one of the participants in the CS, and with a Join header referencing 
the CS dialog.

In that case, the SRC would end up being the UAC or UAS of the CS. The 
proxy would not even need to be stateful in that case. In effect it is 
just one more way for the SRS to be the initiator of the RC.

There are however lots of limitations to this that may result in it not 
being an interesting solution.

	Thanks,
	Paul

---

From: Peter Musgrave <[email-masked]>
Date: Fri, 2 Jul 2010 14:40:14 -0400

Hi Paul/Andrew,

I guess what I had in mind was something like the flow below (where the
proxy is in the signalling path and the RS is inserted as a recording media
relay). It's essentially a low-tech 3PCC approach. The same kind of thing
could be done mid-call with reINVITEs. I suspect there are better approaches
- but hopefully this is illustrative.

The proxy uses 3PCC to get A to send to r1 and B to send to r2. The RS
relays media from r1 <-> r2 and records each stream.

I think recording is more likely to be implemented in the SIP server (be
that a B2B or proxy) and I think excluding proxies from the recording
architecture is a fairly serious limitation. [It's actually ironic I'm
sticking up for proxies - since I spent most of my time in a previous job
working on B2B's].

Cheers,

Peter

        Alice                   SProxy                     RS
        Bob
          |                        |                        |
         |
          |                        |                        |
         |
          |                        |                        |
         |
          |INVITE callid=1 (sdp a) |                        |
         |
          |----------------------->|                        |
         |
          |                        |                        |
         |
          |                        |                        |
         |
          |                        |INVITE callid=2(no sdp) |
         |
          |                        |----------------------->|
         |
          |                        |                        |
         |
          |                        |                        |
         |
          |                        |200 OK (sdp r1:r2)      |
         |
          |                        |<-----------------------|
         |
          |                        |                        |
         |
          |                        |                        |
         |
          |                        |INVITE callid=1(sdp r2) |
         |
          |
 |------------------------------------------------>|
          |                        |                        |
         |
          |                        |                        |
         |
          |                        |200 OK (sdp b)          |
         |
          |
 |<------------------------------------------------|
          |                        |                        |
         |
          |                        |                        |
         |
          |                        |ACK (sdp a:b)           |
         |
          |                        |----------------------->|
         |
          |                        |                        |
         |
          |                        |                        |
         |
          |200 OK (sdp r1)         |                        |
         |
          |<-----------------------|                        |
         |
          |                        |                        |
         |
          |                        |                        |
         |
          |ACK                     |                        |
         |
          |----------------------->|                        |
         |
          |                        |                        |
         |
          |                        |                        |
         |
          |                        |                        |
         |

On Fri, Jul 2, 2010 at 1:47 PM, Paul Kyzivat <[email-masked]> wrote:
>
>
> Hutton, Andrew wrote:
>>
>> Hi Peter,
>>
>> I am not sure how this would work using a stateful proxy maybe if you
sent
>> me a picture and/or some text describing how a stateful proxy could
create
>> the recording session it would help.
>
> required, it could send a REFER to an SRS with the Refer-To uri being one
of
> the participants in the CS, and with a Join header referencing the CS
> dialog.
>
proxy
> would not even need to be stateful in that case. In effect it is just one
> more way for the SRS to be the initiator of the RC.
>
>>> From: Peter Musgrave [mailto:[email-masked]] Sent: 21 June
>>> 2010 18:58
>>> To: Hutton, Andrew
>>> Cc: [email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 02 Jul 2010 15:18:17 -0400

Peter Musgrave wrote:
> proxy is in the signalling path and the RS is inserted as a recording 
> media relay). It's essentially a low-tech 3PCC approach. The same kind 
> of thing could be done mid-call with reINVITEs. I suspect there are 
> better approaches - but hopefully this is illustrative.
> 

If I understand what you are proposing, it puts the SRS in the media 
path between Alice and Bob.

As shown I don't see how it works. The SRS must provide both an offer 
for Bob and an answer for Alice (that it will splice together) without 
even having seen Alice's offer. If there is *any* variability in media 
types, codecs, codec parameters, format numbering, etc. that isn't going 
to work.

	Thanks,
	Paul

> sticking up for proxies - since I spent most of my time in a previous 
> job working on B2B's]. 
> 
> Cheers, 
> 
> Peter
> 
>         Alice                   SProxy                     RS           
>             Bob
>           |                        |                        |           
>              |
>           |                        |                        |           
>              |
>           |                        |                        |           
>              |
> On Fri, Jul 2, 2010 at 1:47 PM, Paul Kyzivat <[email-masked] 
> <mailto:[email-masked]>> wrote:
>  >
>  >
>  > Hutton, Andrew wrote:
>  >>
>  >> Hi Peter,
>  >>
>  >> I am not sure how this would work using a stateful proxy maybe if 
> you sent
> one of
>  > In that case, the SRC would end up being the UAC or UAS of the CS. 
> The proxy
>  >>> From: Peter Musgrave [mailto:[email-masked] 
> <mailto:[email-masked]>] Sent: 21 June
>  >>> 2010 18:58
>  >>> To: Hutton, Andrew
>  >>> Cc: [email-masked] <mailto:[email-masked]>
>  >>> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>  >>>>
> <mailto:[email-masked]>
>  >>>
>  >>> [mailto:[email-masked] 
> <mailto:[email-masked]>] On Behalf Of
>  >>> [email-masked] <mailto:[email-masked]>
>  >>>>
>  >>>> Sent: 18 June 2010 17:30
>  >>>> To: [email-masked] <mailto:[email-masked]>
>  >>>> Subject: I-D
>  >>>
>  >>>> [email-masked] <mailto:[email-masked]>
>  >> [email-masked] <mailto:[email-masked]>

---

From: Peter Musgrave <[email-masked]>
Date: Fri, 2 Jul 2010 15:48:46 -0400

Inline

On Fri, Jul 2, 2010 at 3:18 PM, Paul Kyzivat <[email-masked]> wrote:

> If I understand what you are proposing, it puts the SRS in the media path
> between Alice and Bob.
>
Yes. This is a blessing and a curse. It ensures that calls where the RS is
unavailable do not succeed - so it is likely only appropriate for
applications where recording is critical. (Although the proxy could issue
reINVITEs and reconnect A and B directly if it can detect the RS has
failed).

>
> As shown I don't see how it works. The SRS must provide both an offer for
> Bob and an answer for Alice (that it will splice together) without even
> having seen Alice's offer. If there is *any* variability in media types,
> codecs, codec parameters, format numbering, etc. that isn't going to work.
>
Doh! Your are correct.

This can be fixed up by sending A's SDP to the RS.  There might be better
3PCC sequences as well. The take away is that the proxy can mess with the
SDPs so as to insert the RS into the media path.

I'm not saying it's a great approach - but if I'm a proxy and I want to do
recording I can make it happen. I think a doc which tries to define
architectures for recording should say something about proxies (or say that
stateful proxy architectures have been considered but have limitations).

Cheers,

Peter

>> On Fri, Jul 2, 2010 at 1:47 PM, Paul Kyzivat <[email-masked] <mailto:
>> [email-masked]>> wrote:
>>  >
>>  >
>>  > Hutton, Andrew wrote:
>>  >>
>>  >> Hi Peter,
>>  >>
>>  >>> From: Peter Musgrave [mailto:[email-masked] <mailto:
>> [email-masked]>] Sent: 21 June
>>  >>> 2010 18:58
>>  >>> To: Hutton, Andrew
>>  >>> <[email-masked] <mailto:
>> [email-masked]>> wrote:
>>  >>>>
>>  >>>> From: [email-masked] <mailto:
>> [email-masked]>
>>  >>>
>>  >>> [mailto:[email-masked] <mailto:
>> [email-masked]>] On Behalf Of

---

From: "Henry Lum" <[email-masked]>
Date: Mon, 5 Jul 2010 08:03:47 -0700

Hi Peter,

Another problem with the proxy approach is that the proxy must share the
SRTP private keys in the CS to the recorder in the 3pcc call leg since
the recorder is acting both as the recorder and the media relay. This
could potentially be a security risk and there is a requirement REQ-032
that states we cannot do this.

Regards,

Henry

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Peter Musgrave
Sent: July-02-10 3:49 PM
To: Paul Kyzivat
Cc: [email-masked]
Subject: Re: [siprec] FW:
I-DAction:draft-hutton-siprec-session-recording-arch-01.txt

Inline

Peter Musgrave wrote:

Hi Paul/Andrew,

Yes. This is a blessing and a curse. It ensures that calls where the RS
is unavailable do not succeed - so it is likely only appropriate for
applications where recording is critical. (Although the proxy could
issue reINVITEs and reconnect A and B directly if it can detect the RS
has failed).

	As shown I don't see how it works. The SRS must provide both an
offer for Bob and an answer for Alice (that it will splice together)
without even having seen Alice's offer. If there is *any* variability in
media types, codecs, codec parameters, format numbering, etc. that isn't
going to work.

Doh! Your are correct. 

This can be fixed up by sending A's SDP to the RS.  There might be
better 3PCC sequences as well. The take away is that the proxy can mess
with the SDPs so as to insert the RS into the media path.

I'm not saying it's a great approach - but if I'm a proxy and I want to
do recording I can make it happen. I think a doc which tries to define
architectures for recording should say something about proxies (or say
that stateful proxy architectures have been considered but have
limitations). 

Cheers,

Peter

	       Thanks,
	       Paul

	I think recording is more likely to be implemented in the SIP
server (be that a B2B or proxy) and I think excluding proxies from the
recording architecture is a fairly serious limitation. [It's actually
ironic I'm sticking up for proxies - since I spent most of my time in a
previous job working on B2B's]. 
	Cheers, 
	Peter
	
	       Alice                   SProxy                     RS
Bob
	         |                        |                        |
|
	         |                        |                        |
|
	         |                        |                        |
|

	On Fri, Jul 2, 2010 at 1:47 PM, Paul Kyzivat <[email-masked]
<mailto:[email-masked]>> wrote:
	 >
	 >
	 > Hutton, Andrew wrote:
	 >>
	 >> Hi Peter,
	 >>
	 >> I am not sure how this would work using a stateful proxy
maybe if you sent
	 >> me a picture and/or some text describing how a stateful
proxy could create
	 > required, it could send a REFER to an SRS with the Refer-To
uri being one of
	 > In that case, the SRC would end up being the UAC or UAS of
the CS. The proxy

	 >> https://www.ietf.org/mailman/listinfo/siprec

-------------------------------------------------------------------------------------------------------------------
CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities.

---

From: Peter Musgrave <[email-masked]>
Date: Mon, 5 Jul 2010 11:37:52 -0400

Agreed.

So perhaps some text in the architecture doc about limitations and
restrictions w.r.t. proxy implementations would be worthwhile? I suspect
implementors will be tempted to try and it would be good to shine a light on
the issues.

Peter

On Mon, Jul 5, 2010 at 11:03 AM, Henry Lum <[email-masked]>wrote:

> SRTP private keys in the CS to the recorder in the 3pcc call leg since the
> recorder is acting both as the recorder and the media relay. This could
> potentially be a security risk and there is a requirement REQ-032 that
> states we cannot do this.
>
>
>
> Regards,
>
> Henry
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Peter Musgrave
> *Sent:* July-02-10 3:49 PM
> *To:* Paul Kyzivat
> *Cc:* [email-masked]
> *Subject:* Re: [siprec] FW:
> CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain
> confidential and proprietary information of Alcatel-Lucent and/or its
> affiliated entities. Access by the intended recipient only is authorized.
> Any liability arising from any party acting, or refraining from acting, on
> any information contained in this e-mail is hereby excluded. If you are not
> the intended recipient, please notify the sender immediately, destroy the
> original transmission and its attachments and do not disclose the contents
> to any other person, use it for any purpose, or store or copy the
> information in any medium. Copyright in this e-mail and any attachments
> belongs to Alcatel-Lucent and/or its affiliated entities.
>