Subject: [IPFIX] FW: [dispatch] Session recording in SIP

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 10 Jun 2009 11:25:11 +0200

I threw a comment in this discussion that IPFIX may be a technology to
be considered for session recording. 

Any opinions or suggestions on this idea? 

Dan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Vijay K. Gurbani
Sent: Wednesday, June 10, 2009 12:02 AM
To: [email-masked]
Cc: Leon Portman; Jain,Rajnish; Hadriel Kaplan
Subject: [dispatch] Session recording in SIP

Hi: I realize that the deadline for charter proposals was yesterday, but
I hope that it is not too late to submit one more.

A few interested people (Hadriel Kaplan, Dan Wing, Rajnish Jain, Leon
Portman, Andrew Hutton and I) have been interested in RTP session
recording in SIP.  The requirement draft will be released shortly.

We would like to request agenda time in dispatch to propose the
formation of a new working group to define protocol extensions and an
architecture for RTP recording.

Session recording in SIP
Mailing Lists: TBD
Chairs: TBD
Area Directorate: Real Time Applications (RAI)

Purpose:

Session recording is a critical operational requirement in many
businesses, especially where voice is used as a medium for commerce and
customer support. A prime example where voice is used for trade is the
financial industry. The call recording requirements in this industry are
quite stringent. The recorded calls are used for dispute resolution and
regulatory compliance. Other businesses such as customer support call
centers typically employ call recording for quality control or business
analytics.

Depending on the country and its regulatory requirements, financial
trading floors typically must record all calls. The recorded media
content must be an exact copy of the actual conversation (i.e.
clipping and loss of media are unacceptable).  Some deployments and
regulations require that calls be aborted or rejected if the recording
device is unavailable.

This group will specify requirements for a SIP based protocol interface
between a communications system and a recorder. The Communications
System is responsible for establishing media sessions where the actual
business is conducted. The Recorder is the sink of the recorded media.

The recorded sessions can be of any kind such as voice, video and
instant messaging. A recorded session is typically comprised of actual
media content and the call metadata. The call metadata allows recording
archives to be searched and filtered at a later time.
The conveyance of call metadata from the communications system to the
recorder is outside the scope of this document.

This group will only looks into active recording, where the recorded
system purposefully streams media to a recording device. Passive
recording, where a recording device detects media directly from the
network, is outside the scope of this document. In addition, lawful
intercept is outside the scope of the group.

Proposed deliverables:

1) Requirements document;
2) Solutions document, including reference architecture.

Thanks,

- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane,
Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
Web:   http://ect.bell-labs.com/who/vkg/
_______________________________________________
dispatch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dispatch

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 10 Jun 2009 11:50:21 +0200

> Any opinions or suggestions on this idea? 

They want to record complete media streams. IPFIX supports the export
of flow summary records. I do not see a relation here.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 10 Jun 2009 12:49:07 +0200

You are correct about media recording. A session is however composed out
of media and signaling (sometimes going on different paths). For the
signaling part IPFIX may be sufficient.

Dan

> From: Juergen Schoenwaelder 
> [mailto:[email-masked]] 
> Sent: Wednesday, June 10, 2009 12:50 PM
> To: Romascanu, Dan (Dan)
> Cc: IETF IPFIX Working Group
> Subject: Re: [IPFIX] FW: [dispatch] Session recording in SIP
> 
> They want to record complete media streams. IPFIX supports 
> the export of flow summary records. I do not see a relation here.
> 
> /js
> 
> --

---

From: Sven Anderson <[email-masked]>
Date: Wed, 10 Jun 2009 16:06:15 +0200

> signaling part IPFIX may be sufficient.

I just presented SIPFIX at the IM 2009 conference, which is an IPFIX  
based SIP monitoring scheme [1]. We will soon submit an Internet-Draft  
as well. They might be interested in it.

[1] http://sven.anderson.de/publications/sipfix.pdf

Sven

> IPFIX mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipfix
>

---

From: Atsushi Kobayashi <[email-masked]>
Date: Thu, 11 Jun 2009 00:43:19 +0900

Dear Sven, and Dan,

SIPFIX is interesting approach. Complete call records including the
caller URI, callee URI, RTP media quality, and etc. are created after
correlating SIP summary records and RTP summary records in mediation.

As another approach, I presented the following in last IEPG meeting. 
http://www.nttv6.net/~akoba/iepg_ipfix.pdf

The approach continuously measures the SIP signaling, and then extracts the
media information from SDP on SIP packet. If necessary, IPFIX-CONFIG
including the filtering rule for RTP packets can be configured on Exporter,
and then it measures the RTP media stream on demand.

Both approaches illustrate that IPFIX can contribute to monitor the SIP
signaling and RTP media stream. I hope that the topic can be discussed
in next IPFIX meeting.

Regards,
Atsushi KOBAYASHI

On Wed, 10 Jun 2009 16:06:15 +0200

> >> the export of flow summary records. I do not see a relation here.

--- 
Atsushi KOBAYASHI  <[email-masked]>
NTT Information Sharing Platform Lab.
tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5637

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 10 Jun 2009 17:55:50 +0200

I am looking forward to your proposal, but SIP session recording (which
is where the discussion started from) has different requirements than
SIP monitoring.  

Dan

> From: Atsushi Kobayashi [mailto:[email-masked]] 
> Sent: Wednesday, June 10, 2009 6:43 PM
> To: Sven Anderson
> Cc: Romascanu, Dan (Dan); IETF IPFIX Working Group
> Subject: Re[2]: [IPFIX] FW: [dispatch] Session recording in SIP
> 
> 
> Dear Sven, and Dan,
> 
> SIPFIX is interesting approach. Complete call records 
> including the caller URI, callee URI, RTP media quality, and 
> etc. are created after correlating SIP summary records and 
> RTP summary records in mediation.
> 
> The approach continuously measures the SIP signaling, and 
> then extracts the media information from SDP on SIP packet. 
> If necessary, IPFIX-CONFIG including the filtering rule for 
> RTP packets can be configured on Exporter, and then it 
> measures the RTP media stream on demand.
> 
> Both approaches illustrate that IPFIX can contribute to 
> monitor the SIP signaling and RTP media stream. I hope that 
> the topic can be discussed in next IPFIX meeting.
> 
> Regards,
> Atsushi KOBAYASHI
> 
> > > You are correct about media recording. A session is 
> however composed 
> > > out of media and signaling (sometimes going on different 
> paths). For 
> > > the signaling part IPFIX may be sufficient.
> > 
> > >> They want to record complete media streams. IPFIX supports the 
> > >> export of flow summary records. I do not see a relation here.
> > >>
> > >> /js
> > >>
> > >> --

---

From: Gerhard Muenz <[email-masked]>
Date: Sun, 14 Jun 2009 22:56:10 +0200

Hi Sven, all,

I had a look at your paper. Indeed, it's an interesting use-case for
IPFIX which shows that the IPFIX protocol is flexible enough to
transport many different kinds of information.

However, I do not see any standardization issue here, apart from a
couple of new Information Elements. Also, the concept of Mediators is
not as essential for your purpose as you claim. The correlation of
different records can also be done at the Collector.

What about encryption? With IPSec, TLS, or DTLS, you won't be able to
extract any of the SIP fields with passive monitoring. This is a strong
limitation of the approach.

Regards,
Gerhard

-- 
Dipl.-Ing. Gerhard Münz
Chair for Network Architectures and Services (I8)
Department of Informatics
Technische Universität München
Boltzmannstr. 3, 85748 Garching bei München, Germany
Phone:  +49 89 289-18008       Fax: +49 89 289-18033
E-mail: [email-masked]    WWW: http://www.net.in.tum.de/~muenz

---

From: Atsushi Kobayashi <[email-masked]>
Date: Mon, 15 Jun 2009 20:41:30 +0900

Hi Gerhard, Sven, and all,

In my opinion, although any networks, especially carrier network,
transmit a large amount of VoIP and IPTV packets which are sensitive
about network performance, there is no effective passive monitoring
method regretfully. Although IPFIX/PSAMP covers the QoS measurement, its
implementation has not appeared so far. I believe IPFIX can play a role
for this work.

We can try making the reference model of measurement infrastructure
using current existing IPFIX/PSAMP specification, such as PSAMP selector,
IPFIX-CONFIG, and mediation to encourage the implementation.

It might start from problem statement, or come out some informational
documents, and standard document describing some new information
elements.

Regards,
Atsushi KOBAYASHI

On Sun, 14 Jun 2009 22:56:10 +0200

---

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 15 Jun 2009 13:56:10 +0200

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Atsushi Kobayashi
> Sent: Monday, June 15, 2009 2:42 PM
> To: Gerhard Muenz
> Cc: Sven Anderson; IETF IPFIX Working Group
> In my opinion, although any networks, especially carrier 
> network, transmit a large amount of VoIP and IPTV packets 
> which are sensitive about network performance, there is no 
> effective passive monitoring method regretfully. Although 
> IPFIX/PSAMP covers the QoS measurement, its implementation 
> has not appeared so far. I believe IPFIX can play a role for 
> this work.
> 

See RFC 3611 and RFC 4710-4712. 

Dan