SIP Extensions for SPIT identification
draft-niccolini-sipping-feedback-spit-03

Document Type Expired Internet-Draft (individual)
Author Saverio Niccolini 
Last updated 2007-02-23
Stream (None)
Intended RFC status (None)
Formats
Expired & archived
pdf htmlized (tools) htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Expired
Telechat date
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft can be found at
https://www.ietf.org/archive/id/draft-niccolini-sipping-feedback-spit-03.txt

Abstract

This memo analyzes the need for SIP extensions for SPIT (Spam Over Internet telephony) identification. This memo describes requirements and gives an overview of possible solutions to send feedback information using the SIP protocol for the scope of SPIT. Feedback information from the users to the SPIT identification system (e.g., working closely with the callee's SIP proxy server) are important for SPIT detection and prevention. The overall SPIT protection systems on the internet will benefit from such information. The basic idea is that each user who receives a SPIT session request, will send a feedback to SPIT identification system (for example, using a button on the user interface of the client). Information could be also exchanged among domains and/or servers in order to increase effectiveness of SPIT detection systems. The idea is that SIP proxy servers and/or B2BUAs include SPIT likeliness estimations (based on some knowledge they have which is out of the scope of this draft) as additional message headers (e.g. INVITE headers) when forwarding such messages to other domains. This memo identifies the parameters that the SPIT identification system may need in order to detect abusive behaviors; moreover it proposes an overview of technical solutions how such information can be sent back to the SPIT identification system by means of the SIP protocol. The memo also addresses the technical solutions on how forward information could be passed among domains as well as how communication initiation could be denied to users (e.g. blacklisted ones).

Authors

Saverio Niccolini (saverio.niccolini@netlab.nec.de)

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)