|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
##
## SIPPINGwg
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
|
| | |
andreasen-sipping-
rfc3603bis-05
ID Exists
Feb 21, 2008
(39 p.)
[pdf(2)]
[html]
|
F. Andreasen
B. McKibben
W. Marshall |
|
Private SIP Proxy-to-Proxy Extensions for
Supporting the PacketCable Distributed Call Signaling Architecture |
|
In order to deploy a residential telephone service at very large
scale across different domains, it is necessary for trusted elements
owned by different service providers to exchange trusted information
that conveys customer-specific information and expectations about the
parties involved in the call. This document describes private
extensions to the Session Initiation Protocol (SIP) [RFC3261] for
supporting the exchange of customer information and billing
information between trusted entities in the PacketCable Distributed
Call Signaling Architecture. These extensions provide mechanisms for
access network coordination to prevent theft of service, customer
originated trace of harassing calls, support for operator services
and emergency services, and support for various other regulatory
issues. The use of the extensions is only applicable within closed
administrative domains, or among federations of administrative
domains with previously agreed-upon policies where coordination of
charging and other functions is required.
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
| | |
audet-sipping-
feature-ref-00
ID Exists
Feb 17, 2008
(20 p.)
[pdf(2)]
[html]
|
F. Audet
A. Johnston
R. Mahy
C. Jennings |
|
Feature Referral in SIP |
|
Feature referral allows for an application to make a high level
request to a User Agent to perform an action or "feature", and let
the the User Agent actually execute the feature as it sees fit.
Feature referral uses the SIP REFER method with a Refer-To header
field containing a URN.
|
|
|
| |
| Up List |
Intended Status: | Best Current Practice |
|
|
|
|
|
|
|
|
| | |
bakker-sipping-
3gpp-ims-xml-
body-handling-00
ID Exists
Feb 12, 2008
(8 p.)
[pdf(2)]
[html]
|
J. Bakker |
|
Specification of 3GPP IM CN Subsystem XML body handling |
|
This document registers new disposition-types for the Content-Disposition
header that apply to the application/3gpp-ims+xml body
used by 3GPP, since Release 5. The applicability of these content-disposition
values are limited to 3GPP IMS. The application/
3gpp-ims+xml body has the following two distinct uses: (1) for
redirecting the emergency session to use a different domain (e.g.
using a Circuit Switched call), and (2) for delivering user profile
specific information from the SIP registrar to an Application Server.
|
|
|
| |
| Up List |
Intended Status: | Experimental |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
chadli-sipping-
overload-sub-not-01
ID Exists
Jul 11, 2008
(12 p.)
[pdf(2)]
[html]
|
Y. Chadli
X. Marjou |
|
An overload control package for SIP |
|
This document specifies an event package for the notification of
overload control using the Session Initiation Protocol (SIP) events
framework. The overload control package allows an upstream server to
retrieve overload control information from a downstream server and to
be notified when this information changes. This information is used
by the upstream server to adapt its flow toward the downstream server
and thus to avoid overloading it.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
channabasappa-
sipping-app-
profile-type-02
ID Exists
Feb 21, 2008
(11 p.)
[pdf(2)]
[html]
|
S.Channabasappa
J. Littlefield
S. Loreto |
|
Extension to the ua-profile Event Package to Support the Application
Profile Type |
|
The Framework for Session Initiation Protocol User Agent Profile
Delivery specifies an event package (ua-profile) that can be used by
user agents to retrieve profile data. The framework also allows for
optional notification of changes to the retrieved profiles. Three
profile types are specified: local-network, device, and user. This
document extends that event package to support an additional profile
type, application. This would enable User Agents to retrieve profile
data specific to one or more applications.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
choi-sipping-
experiments-spit-01
ID Exists
(Recently Expired)
Nov 16, 2007
(14 p.)
[pdf(2)]
[html]
|
Jaeduck Choi
Souhwan Jung
Yujung Jang
Yoojae Won
Youngduk Cho |
|
Experiments on SPIT in the Commercial VoIP Services |
|
This document shows some experimental results on SPIT on commercial
VoIP services, in which a SIP UA has not been secured by SIP security
protocol such as TLS. Although many service providers have been
applying the HTTP digest scheme to authenticate a SIP UA, they often
do not apply SIP signaling protection against potential threats
between the SIP UA and the SIP proxy. This cause vulnerabilities to
the VoIP services like SPIT. The aim of this memo is to inform the
service providers of SPIT threats by showing some experimental
results of SPIT on current VoIP networks.
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
| | |
dawes-sipping-
debug-event-00
ID Exists
May 3, 2008
(31 p.)
[pdf(2)]
[html]
|
P. Dawes |
|
A SIP Event Package for Debugging |
|
This document defines a Session Initiation Protocol (SIP) event
package for debugging. SIP requests and responses for session setup
can traverse a number of network entities, which might be
geographically spread over a large area. This document provides a
means by which logging of requests and responses can be configured on
a per-entity basis.
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
| | |
dawes-sipping-
debug-id-00
ID Exists
May 3, 2008
(13 p.)
[pdf(2)]
[html]
|
P. Dawes |
|
Private Extension to SIP for Debugging |
|
Networks that use SIP to start and stop sessions between their users
will frequently be upgraded with software and hardware changes.
Users will similarly frequently change their client software and the
way they user the network. In order to provide troubleshooting and
regression testing, it is useful to provide debugging as part of the
network fabric. This draft describes a SIP private header that
triggers logging of SIP signalling and identifies logs at mulitiple
SIP entities as belonging to a single end-to-end session.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
| | |
froment-sipping-
spit-requirements-03
ID Exists
Jul 14, 2008
(15 p.)
[pdf(2)]
[html]
|
H. Tschofenig
G. Dawirs
T. Froment
D. Wing
H. Schulzrinne |
|
Requirements for Authorization Policies to tackle Spam and Unwanted
Communication for Internet Telephony |
|
Spam over Internet Telephony (SPIT) is one of the foreseen future
forms of spamming that SIP open-wide networks may have to handle.
SPIT also has more impact on users than email spam since it is more
intrusive. Email as a store-and-forward communication mechanism
allows for several filtering mechanisms to be applied to the full
content before being presented to the user. Session Initiation
Protocol (SIP) interaction is, in contrast, real-time communication
and therefore does not provide much information prior to the
transmission of the content, making it both harder to filter and more
annoying to users. The responsibility for filtering, blocking calls,
or taking any other preventive action can belong to different
elements in the call flow and may depend on various factors. This
document discusses the requirements to define authorization policies
that should allow end users or other parties to setup anti-SPIT
policies for triggering these actions. These policies typically
match a particular SIP communication pattern based on a number of
attributes. The range of attributes includes information provided,
for example, by the SIP protocol itself, by the SIP identity
mechanism, by information carried within SAML assertions or by
reputation systems of social networks.
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
| | |
garcia-sipping-
file-desc-pidf-01
ID Exists
(Recently Expired)
Nov 16, 2007
(8 p.)
[pdf(2)]
[html]
|
M. Garcia-Martin
M. Matuszewski |
|
File Descriptions Extension to the Presence Information Data Format (PIDF) |
|
The Presence Information Data Format (PIDF) defines a basic format
for representing presence information for a presentity. Presentities
publish their presence information, typically towards presence
agents. PIDF has been extended to provide rich presence information,
including, for example, the location of the presentity, their
activities, mood, the capabilities of their user agents, etc.
Presentities are willing to provide the description of available
files at watcher's disposal. This might be the case for photographs
taken with a mobile device, a recorded lecture audio file, etc. This
document extends the PIDF to provide the syntax and format for the
description of files within the PIDF.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
garcia-sipping-
file-event-
package-01
ID Exists
(Recently Expired)
Nov 16, 2007
(15 p.)
[pdf(2)]
[html]
|
M. Garcia-Martin
M. Matuszewski |
|
A SIP Event Package and Data Format for Describing Files |
|
This document specifies the format and semantics associated to a
'file' event package that allows SIP endpoints to publish the
availability of files. A file can be, for example, images, video
files, audio files, etc. The event package reuses the eXtended
Mark-up Language (XML) 'file-metadata' document to provide file
descriptions. This event package also allows SIP endpoints to
subscribe to changes in the availability of files, or perform
searches for the availability and location of a given file. Support
for partial notifications and publications is also accomplished by
using XML patch operations.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
garcia-sipping-
file-sharing-
framework-01
ID Exists
(Recently Expired)
Nov 16, 2007
(20 p.)
[pdf(2)]
[html]
|
M. Garcia-Martin
M. Matuszewski
N. Beijar
J. Lehtinen |
|
Sharing Files with SIP |
|
This memo proposes a SIP framework used for advertising and searching
for shared files within a given community. The memo defines the
signaling that users to announce the availability of files stored in
their User Agents (UA). It also provides the signaling for users to
perform searches of available files and monitor changes in those
files. Additionally, this memo describes the signaling used to
access a file. These methods can be used in (but are not limited to)
SIP peer-to-peer systems based on centralized, semi-centralized or
fully distributed architectures.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
haluska-sipping-
directory-
assistance-05
ID Exists
May 8, 2008
(91 p.)
[pdf(2)]
[html]
|
J. Haluska
R. Berkowitz
P. Roder
W. Downum
R. Ahern
P. Lum Lung
N. S. Costantino
C. Blackwell
J. Mellinger
D. Scott |
|
Considerations for Information Services and Operator Services using SIP |
|
Information Services are services whereby information is provided
in response to user requests, and may include involvement of a
human or automated agent. A popular existing Information Service is
Directory Assistance (DA). Moving ahead, Information Services
providers envision exciting multimedia services that support
simultaneous voice and data interactions with full operator backup
at any time during the call. Information Services providers are
planning to migrate to SIP based platforms, which will enable such
advanced services, while continuing to support traditional DA
services. Operator Services are traditional PSTN services which
often involve providing human or automated assistance to a caller,
and often require the specialized capabilities traditionally
provided by an operator services switch. Market and/or regulatory
factors in some jurisdictions dictate that some subset of Operator
Services continue to be provided going forward. This document aims
to identify how Operator and Information Services can be
implemented using existing or currently proposed SIP mechanisms, to
identity existing protocol gaps, and to provide a set of Best
Current Practices to facilitate interoperability. For Operator
Services, the intention is to reproduce the current PSTN behaviour.
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
| | |
hilt-sipping-
overload-05
ID Exists
Jul 13, 2008
(21 p.)
[pdf(2)]
[html]
|
V. Hilt
I. Widjaja
H. Schulzrinne |
|
SIP Overload Control |
|
Overload occurs in Session Initiation Protocol (SIP) networks when
SIP servers have insufficient resources to handle all SIP messages
they receive. Even though the SIP protocol provides a limited
overload control mechanism through its 503 (Service Unavailable)
response code, SIP servers are still vulnerable to overload. This
document defines an overload control mechanism for SIP.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
hilt-sipping-
overload-design-00
ID Exists
Jul 5, 2008
(17 p.)
[pdf(2)]
[html]
|
V. Hilt |
|
Design Considerations for SIP Overload Control |
|
Overload occurs in Session Initiation Protocol (SIP) networks when
SIP servers have insufficient resources to handle all SIP messages
they receive. Even though the SIP protocol provides a limited
overload control mechanism through its 503 (Service Unavailable)
response code, SIP servers are still vulnerable to overload. This
document discusses models and design considerations for a SIP
overload control mechanism.
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
| | |
johnston-sipping-
cc-uui-04
ID Exists
Jul 10, 2008
(14 p.)
[pdf(2)]
[html]
|
A. Johnston
J. McMillen |
|
Transporting User to User Call Control Information in SIP for ISDN |
|
Several approaches to transporting the ITU-T Q.931 User to User
Information Element (UU IE) data in SIP have been implemented. As
networks move to SIP it is important that applications requiring this
data can continue to function in SIP networks as well as the ability
to interwork the information to/from ISDN for end-to-end
transparency. This document discusses the approaches and recommends
a new header field User-to-User be standardized. Example use cases
include an exchange between two User Agents, insertion of UUI by a
proxy, modification of UUI by a proxy. An example application is in
an Automatic Call Distributor (ACD) in a contact center.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
koren-sipping-
conference-
list-event-03
ID Exists
Jul 2, 2008
(17 p.)
[pdf(2)]
[html]
|
O. Koren
M. Fortinsky
I. Ravid |
|
A Conference List Information Event Package for SIP |
|
This document describes the usage of the Session Initiation Protocol
(SIP) for subscriptions and notifications related to conference
lists.
A new conference list event package is specified. This event package
allows a user to subscribe to a single event (the conference-list)
and receive notifications that contain the list of conferences to
which the user belongs and the status of each conference. The
notifications sent from the conference server can contain either the
entire list of the user's conferences or a partial list with the
updates since the previous notification.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
lamparter-sipping-
session-
duplication-00
ID Exists
(Recently Expired)
Dec 19, 2007
(16 p.)
[pdf(2)]
[html]
|
P. Imai
B. Lamparter
P. Loureiro |
|
Duplicate a SIP session |
|
Session duplication copies media of an ongoing communication session
from one device to another. After duplication the two devices have
independent control over this media. This is in particular useful
for one-way media like broadcast IPTV or Video-on-Demand. This
document describes the general methods and specifies the signaling
and media flows for providing this service using the Session
Initiation Protocol (SIP).
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
loreto-sipping-
3892bis-00
ID Exists
Jul 4, 2008
(7 p.)
[pdf(2)]
[html]
|
N. Bishai
S. Loreto
A. Haruna |
|
Updates to Referred-By in SIP |
|
SIP has a mechanism for conveying the asserted identity of the
originator of a request by means of the P-Asserted-Identity header
field. When exploding a SIP MESSAGE request to a pre-defined group
URI and when exploding a SIP INVITE request to an ad-hoc group or to
a pre-defined group URI, the Referred-By header field in the
resulting exploded requests is set to the P-Asserted-Identity header
field or to the From header field. The Referred-By header is only
included if the P-Asserted-Identity header field or From header field
needs to carry another value, e.g. the URI of a pre-defined group, or
a conference focus URI. Since the P-Asserted-Identity header field
may carry up to two values, the Referred-By definition needs to be
extended to allow up to two values as well.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
lowekamp-sipping-
ice-for-sip-00
ID Exists
(Recently Expired)
Nov 11, 2007
(11 p.)
[pdf(2)]
[html]
|
B. Lowekamp
D. Bryan |
|
Using ICE to establish SIP Dialogs |
|
This draft explores a way SIP can be extended to allow a new dialog
directly between the endpoints to replace an initial dialog that had
one or more proxies in the signalling path. This technique relies on
ICE to perform hole punching that allows a direct connection to be
used in deployments where a sip-outbound proxy or SBC is used to
establish SIP connections across NAT or firewall boundaries. It can
also be used to replace such a dialog with a secure connection
directly between the endpoints. This technique can be applied to
traditional proxy-based SIP routing as well as to emerging P2PSIP
deployments that lack centrally located proxies.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
| | |
niccolini-sipping-
spam-feedback-00
ID Exists
Feb 14, 2008
(12 p.)
[pdf(2)]
[html]
|
S. Niccolini
K. Fischer
D. Wing
M. Stiemerling
H. Tschofenig |
|
Spam feedback for SIP |
|
This document gives on overview of possible mechanisms for SIP UAs to
feedback spam information to the system (e.g. other SIP entities like
upstream SIP proxies) thus they can use this information for handling
subsequent calls (e.g. blacklist the caller, input this info to
reputation systems, compute spam-specific caller statistics, etc.).
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
niccolini-sipping-
spitstop-01
ID Exists
Feb 15, 2008
(18 p.)
[pdf(2)]
[html]
|
S. Niccolini
J. Quittek
J. Seedorf |
|
Signaling TO Prevent SPIT (SPITSTOP) Reference Scenario |
This memo discusses the need for standards that support SPam over
Internet Telephony (SPIT) prevention applications. After explaining
the general need for SPIT prevention applications the memo provides a
reference scenario for potential communication between entities that
may be involved in SPIT prevention. Within this scenario the need
for standardizing communication is analyzed for each pair of
communicating entities. The analysis is intended to serve as a
starting point for discussing the requirements for signaling
standards as well as for architectural considerations, that support
SPIT prevention applications.
This memo is not intended to suggest any solution of SPIT signaling
issues. Such work, if necessary at all, should be object of separate
documents.
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
| | |
petrie-sipping-
identity-dataset-02
ID Exists
(Recently Expired)
Nov 17, 2007
(17 p.)
[pdf(2)]
[html]
|
D. Petrie
S.Channabasappa
S. Ganesan |
|
The SIP User Agent Identity Profile Data Set |
|
This document defines the properties and data format for the SIP user
agent identity profile data set. The properties in this data set
define identities or SIP address of records (AORs) related to
incoming or outgoing SIP signaling on a user agent. The identities
may be those that are registered via the SIP REGISTER method or
identities which are provisioned on the user agent. These identities
may be used or referenced when defining identity specific handling
related to SIP features on the user agent.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
petrie-sipping-
sip-dataset-03
ID Exists
(Recently Expired)
Nov 17, 2007
(22 p.)
[pdf(2)]
[html]
|
D. Petrie
S.Channabasappa
S. Ganesan |
|
The Core SIP User Agent Protocol Data Set |
|
This document defines the properties and format for the core SIP user
agent protocol dataset. The properties defined in this document are
expected to be common to most SIP user agents regardless of whether
the user agent support audio, video, text or any combination of
media. These core SIP properties are considered to be a dataset.
Several datasets may be combined into documents or profiles that are
provided to SIP user agents so that they can operate with the desired
behavior.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
petrie-sipping-
voip-features-
dataset-02
ID Exists
(Recently Expired)
Nov 17, 2007
(13 p.)
[pdf(2)]
[html]
|
D. Petrie
S.Channabasappa
S. Ganesan |
|
The SIP User Agent VoIP Features Data Set |
|
This document defines the properties and format for the SIP user
agent VoIP Features data set. The properties defined in this
document are expected to be common to most SIP user agents that
provide VoIP capabilities. These VoIP Feature properties are
considered to be a data set. Several types of datasets may be
combined into documents that are provided to SIP user agents so that
they can operate with the desired behavior.
|
|
|
| |
| Up List |
Intended Status: | Best Current Practice |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
rosenberg-sipping-
siptrunk-00
ID Exists
Feb 15, 2008
(10 p.)
[pdf(2)]
[html]
|
J. Rosenberg |
|
What is a Session Initiation Protocol (SIP) Trunk Anyway? |
|
The term "Session Initiation Protocol (SIP) Trunk" has become almost
commonplace amongst vendors and SIP providers. Even though the
notion of a 'trunk' has a well defined meaning in circuit switched
systems, it has never been defined for SIP. This document provides a
formal definition for a SIP trunk, discusses its scope and
applications, and establishes best practices for identification and
security of SIP trunks.
|
|
|
| |
| Up List |
Intended Status: | Best Current Practice |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
| | |
schwartz-sipping-
domain-marking-
requirements-00
ID Exists
(Recently Expired)
Nov 12, 2007
(6 p.)
[pdf(2)]
[html]
|
D. Schwartz
D. Besprosvan |
|
Requirements for domain marking for the purpose of Upstream Traffic Characterization |
|
SIP as defined in RFC 3261 defines a Via header as a construct to
be used for upstream response routing and for downstream assistance
in loop detection. There is an increasing need on downstream
administrative domains (ADs) to gain visibility into all the ADs in
its upstream path. The information needed is not IP based as
internal architectures at upstream ADs is of no consequence to
downstream ADs. Logical domain marking, however, is desperately
needed for any traffic analysis to occur at the receiving side.
Gathering AD information from Via headers is non obvious and in many
instances nearly impossible. This documents identifies the
requirements for addressing this issue.
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
| | |
schwartz-sipping-
nsr-code-00
ID Exists
Jun 24, 2008
(7 p.)
[pdf(2)]
[html]
|
D. Schwartz |
|
No Service To This Number Reject Code |
|
The Session Initiation Protocol (SIP) allows for users to make calls
using telephone numbers embedded in either "sip" [RFC3261] or "tel"
[RFC3966] URIs. Either way, the telephone number (TN) itself is not
restricted and can represent an entity in the public telephone
network, an entity in a private telephone network or an entity on the
Internet. This TN resolution ambiguity highlights the difference
between the LUF and LRF functions defined in
[draft-ietf-speermint-terminology] and underscores the need for
more precise SIP error rejection codes. SIP has no way to indicate
to the calling UAC that the reason for call rejection is due to the
fact that this number does not exist in the requested domain or realm
but it does exist in the public telephone network for instance. Such
an indication is useful to allow the call to be retried at a
different context (i.e. the public PSTN in this case) with possibly
better results. This specification defines a new SIP response code
for this purpose.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
seedorf-sipping-
spam-score-
semantics-00
ID Exists
Feb 18, 2008
(8 p.)
[pdf(2)]
[html]
|
J. Seedorf
S. Niccolini
H. Schulzrinne |
|
Spam score for SIP: a proposal for semantics |
|
This document reports a proposal for semantics of SIP spam scoring in
order to achieve a flexible signalling standardization allowing an
incremental adoption of the scoring mechanism. This approach can
give early experimental implementers the possibility to start using
spam scoring extensions in an explorative fashion without running
into interoperability problems.
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
| | |
shen-sipping-
load-control-
event-package-00
ID Exists
Jul 7, 2008
(22 p.)
[pdf(2)]
[html]
|
C. Shen
H. Schulzrinne
A. Koike |
|
A SIP Load Control Event Package |
|
This document defines a load control event package for the Session
Initiation Protocol (SIP). It allows SIP servers to distribute user
load control information to SIP servers. The load control
information can throttle outbound calls based on their destination
domain, telephone number prefix or for a specific user. The
mechanism helps to prevent signaling overload and complements
feedback-based SIP overload control efforts.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | |
tschofenig-sipping-
captcha-01
ID Exists
Feb 25, 2008
(24 p.)
[pdf(2)]
[html]
|
H. Tschofenig
E. Leppanen
S. Niccolini
M. Arumaithurai |
|
Completely Automated Public Turing Test to Tell Computers and Humans
Apart (CAPTCHA) based Robot Challenges for SIP |
A common approach to deal with unwanted communication attempts is to
rely on some form of authorization policies, typically whitelists.
In order to populate the entries in such an access control list it is
helpful to have a way to challenge the entity willing to engage in a
conversation (unless they are already pre-authorized). One reason
why this is desired is to deal with robots that are aggressively
distributing messages.
This document describes how "Completely Automated Public Turing Test
to Tell Computers and Humans Apart" (CAPTCHA) tests, which require
human interaction, are applied to SIP.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
tschofenig-sipping-
framework-spit-
reduction-04
ID Exists
Jul 14, 2008
(24 p.)
[pdf(2)]
[html]
|
H. Tschofenig
H. Schulzrinne
D. Wing
J. Rosenberg
D. Schwartz |
|
A Framework to tackle Spam and Unwanted Communication for Internet Telephony |
Spam, defined as sending unsolicited messages to someone in bulk, is
likely to become a problem on SIP open-wide deployed networks. A
number of solutions have been proposed for dealing with Spam for
Internet Telephony (SPIT) and unwanted communication, such as content
filtering, black lists, white lists, consent-based communication,
reputation systems, address obfuscation, limited use addresses,
turing tests, computational puzzles, payments at risk, circles of
trust, and many others.
This document describes the big picture that illustrates how the
different building blocks fit together and can be deployed
incrementally.
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
| | |
tschofenig-sipping-
spit-policy-03
ID Exists
Jul 12, 2008
(27 p.)
[pdf(2)]
[html]
|
H. Tschofenig
D. Wing
H. Schulzrinne
T. Froment
G. Dawirs |
|
A Document Format for Expressing Authorization Policies to tackle Spam
and Unwanted Communication for Internet Telephony |
|
SPAM, defined as sending unsolicited messages to someone in bulk,
might be a problem on SIP open-wide deployed networks. The
responsibility for filtering or blocking calls can belong to
different elements in the call flow and may depend on various
factors. This document defines an authorization based policy
language that allows end users to upload anti-SPIT policies to
intermediaries, such as SIP proxies. These policies mitigate
unwanted SIP communications. It extends the Common Policy
authorization framework with additional conditions and actions. The
new conditions match a particular Session Initiation Protocol (SIP)
communication pattern based on a number of attributes. The range of
attributes includes information provided, for example, by SIP itself,
by the SIP identity mechanism, by information carried within SAML
assertions.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
vakil-sipping-
notify-pause-02
ID Exists
Mar 12, 2008
(15 p.)
[pdf(2)]
[html]
|
M. Vakil |
|
An Extension to Session Initiation Protocol (SIP) Events for Pausing and
Resuming Notifications |
|
The Session Initiation Protocol (SIP) events framework enables a
subscriber to receive asynchronous notification of various events
from other SIP user agents. It defines mechanisms to create,
refresh, terminate subscriptions. This framework also defines
mechanism to fetch (poll) an event state of a resource without
creating persistent subscriptions. There is no mechanism to
temporarily pause the notifications, while still maintaining a
subscription on the server. This lack of functionality sometime
results in a lot of superfluous notification traffic, and put
unnecessary load on the server. This draft defines an extension to
SIP events that allows the subscriber to pause, un-pause
notifications, and be able to perform fetch (poll) subscriptions
within an established (created) subscription dialog.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
| | |
wing-sipping-
spam-score-02
ID Exists
Feb 23, 2008
(12 p.)
[pdf(2)]
[html]
|
D. Wing
S. Niccolini
M. Stiemerling
H. Tschofenig |
|
Spam Score for SIP |
|
This document defines a mechanism for SIP proxies to communicate a
spam score to downstream SIP proxies and to SIP user agents. This
information can then be used as input to other decision making
engines, for example, to provide alternate call routing or call
handling.
|
|
|
| |
| Up List |
Intended Status: | Experimental |
|
|
|
|
|
|
|
|
| | |
wing-sipping-
srtp-key-03
ID Exists
Feb 24, 2008
(25 p.)
[pdf(2)]
[html]
|
D. Wing
F. Audet
S. Fries
H. Tschofenig
A. Johnston |
|
Secure Media Recording and Transcoding with SIP |
Call recording is an important feature in enterprise telephony
applications. Some industries such as financial traders have
requirements to record all calls in which customers give trading
orders. This poses a particular problem for Secure RTP systems as
many SRTP key exchange mechanisms do not disclose the SRTP session
keys to intermediate SIP proxies. As a result, these key exchange
mechanisms cannot be used in environments where call recording is
needed.
This document specifies a secure mechanism for a cooperating endpoint
to disclose its SRTP master keys to an authorized party to allow
secure call recording.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
