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

["Henry Lum" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf
Of Peter Musgrave
Sent: July-02-10 3:49 PM
To: Paul Kyzivat
Cc: [e-mail]
Subject: Re: [siprec] FW:
I-DAction:draft-hutton-siprec-session-recording-arch-01.txt

 

Inline

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



Peter Musgrave wrote:

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.

 

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

	
	       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
	         |                        |                        |
|
	         |                        |                        |
|
	         |                        |                        |
|
	         |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 <[e-mail]
<mailto:[e-mail]>> 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.
	 >
	 > 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
	 >
	 >> Regards
	 >> Andy
	 >>   >>>
	 >>> -----Original Message-----

	 >>> From: Peter Musgrave [mailto:[e-mail]
<mailto:[e-mail]>] Sent: 21 June
	 >>> 2010 18:58
	 >>> To: Hutton, Andrew

	 >>> Cc: [e-mail] <mailto:[e-mail]>
	 >>> 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

	 >>> <[e-mail]
<mailto:[e-mail]>> wrote:
	 >>>>
	 >>>> From: [e-mail]
<mailto:[e-mail]>
	 >>>

	 >>> [mailto:[e-mail]
<mailto:[e-mail]>] On Behalf Of
	 >>> [e-mail] <mailto:[e-mail]>

	
	 >>>>
	 >>>> Sent: 18 June 2010 17:30

	 >>>> To: [e-mail] <mailto:[e-mail]>

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

	 >>>> [e-mail] <mailto:[e-mail]>

	
	 >>>> https://www.ietf.org/mailman/listinfo/siprec
	 >>>>
	 >>>>
	 >> _______________________________________________
	 >> siprec mailing list

	 >> [e-mail] <mailto:[e-mail]>

	
	 >> 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.