|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Some other
RFCs & Drafts
related to
SIP
|
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Last Update: May 9, 2008
-- Color Legend: RFC Editor Queue
/ Processed by IESG
/ ID Exists
/ Recently Expired
-- Each I-D name is a link to an I-D description, which points to a text version, a two-page and fit-in-window PDF version, as well as the IETF Tools' HTML version.
|
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| -
|
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | |
guy-iax-04
Approved-
announcement
to be sent::
Point Raised -
writeup needed
Mar 30, 2008
(108 p.)
[pdf(2)]
[html]
|
M. Spencer
B. Capouch
E. Guy
F. Miller
K. Shumard |
|
IAX: Inter-Asterisk eXchange Version 2 |
This document describes IAX, the Inter-Asterisk eXchange protocol, an
application-layer control and media protocol for creating, modifying,
and terminating multimedia sessions over Internet Protocol (IP)
networks. IAX was developed by the open source community for the
Asterisk PBX and is targeted primarily at Voice over Internet
Protocol (VoIP) call control, but it can be used with streaming video
or any other type of multimedia.
IAX is an "all in one" protocol for handling multimedia in IP
networks. It combines both control and media services in the same
protocol. In addition, IAX uses a single UDP data stream on a static
port greatly simplifying Network Address Translation (NAT) gateway
traversal, eliminating the need for other protocols to work around
NAT, and simplifying network and firewall management. IAX employs a
compact encoding which decreases bandwidth usage and is well suited
for Internet telephony service. In addition, its open nature permits
new payload types additions needed to support additional services.
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
| | |
resnick-
2822upd-06
Waiting for
AD Go-Ahead
Feb 7, 2008
(56 p.)
[pdf(2)]
[html]
|
P. Resnick |
|
Internet Message Format |
|
This document specifies the Internet Message Format (IMF), a syntax
for text messages that are sent between computer users, within the
framework of "electronic mail" messages. This specification is a
revision of Request For Comments (RFC) 2822, which itself superseded
Request For Comments (RFC) 822, "Standard for the Format of ARPA
Internet Text Messages", updating it to reflect current practice and
incorporating incremental changes that were specified in other RFCs.
|
|
|
| |
| Up List |
Intended Status: | Draft Standard |
|
|
|
|
|
|
|
|
| | |
yu-tel-dai-04
AD is watching
Nov 18, 2007
(18 p.)
[pdf(2)]
[html]
|
J. Yu
D. Hancock
F. Andreasen |
|
DAI Parameter for the "tel" URI |
|
This document defines a "dai" parameter for the "tel" Uniform
Resource Identifier (URI) to support the Dial Around Indicator (DAI).
The "dai" parameter is associated with the "cic" parameter, defined
in [RFC4694], and indicates how the carrier identified in the "cic"
parameter was selected. This document also expands the use of the
"cic" parameter to support pre-subscribed and dialed long-distance
carrier requirements.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
| | |
lemonade-
streaming-05
ID Exists
Apr 23, 2008
(29 p.)
[pdf(2)]
[html]
|
N. Cook |
|
Streaming Internet Messaging Attachments |
This document describes a method for streaming multimedia attachments
received by a resource constrained and/or mobile device from an IMAP
server. It allows such clients, which often have limits in storage
space and bandwidth, to play video and audio e-mail content.
The document describes a profile for making use of the IMAP URLAUTH
extension (RFC 4467), the Network Announcement SIP Media Service
(RFC 4240),
and the Media Server Control Markup Language (RFC 5022).
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
| | |
pmol-sip-
perf-metrics-00
ID Exists
Feb 25, 2008
(28 p.)
[pdf(2)]
[html]
|
D. Malas |
|
SIP End-to-End Performance Metrics |
|
This document defines a set of metrics and their usage to evaluate
the performance of end-to-end Session Initiation Protocol (SIP) based
services in both production and testing environments. The purpose of
this document is to combine a set of common metrics, allowing
interoperable performance measurements, easing the comparison of
industry implementations.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | |
andreasen-mgcp-
fax-07
ID Exists
Nov 18, 2007
(37 p.)
[pdf(2)]
[html]
|
F. Andreasen
D. Hancock |
|
Media Gateway Control Protocol Fax Package |
|
This document defines a Media Gateway Control Protocol (MGCP)
package to support fax calls. The package allows for fax calls to
be supported in two different ways. The first one utilizes ITU-T
Recommendation T.38 for fax relay under the control of the Call
Agent. The second one lets the gateway decide upon a method for fax
transmission as well as handle the details of the fax call without
Call Agent involvement.
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
| | |
begen-fecframe-
sdp-elements-00
ID Exists
Nov 11, 2007
(14 p.)
[pdf(2)]
[html]
|
A. Begen |
|
SDP Elements for FEC Framework |
|
This document specifies the use of Session Description Protocol (SDP)
to describe the parameters required to signal the Forward Error
Correction (FEC) Framework Configuration Information between the
sender(s) and receiver(s). This document also provides the semantics
for grouping multiple source and repair flows together for the
applications that simultaneously use multiple instances of the FEC
Framework.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
hellstrom-text-
conference-00
ID Exists
Jan 2, 2008
(8 p.)
[pdf(2)]
[html]
|
G. Hellstrom
A. van Wijk |
|
Text media handling in RTP based real-time and message conferences |
|
This memo specifies methods for text media handling in multi-party
calls, where the text is carried by the RTP protocol. Real-time text
is carried in a time-sampled mode according to
RFC 4103. Centralized
multi-party handling of real-time text is achieved through a media
control unit coordinating multiple RTP text streams into one RTP
session, identifying each stream with its own SSRC. Identification
for the streams are provided through the RTCP messages. This
mechanism enables the receiving application to present the received
real-time text medium in different ways according to user
preferences. Some presentation related features are also described
explaining suitable variations of transmission and presentation of
text. Call control features are described for the SIP environment,
while the transport mechanisms should be suitable for any IP based
call control environment using RTP transport.
|
|
|
| |
| Up List |
Intended Status: | Best Current Practice |
|
|
|
|
|
|
|
|
| | |
hellstrom-
textpreview-05
ID Exists
Jan 29, 2008
(18 p.)
[pdf(2)]
[html]
|
G. Hellstrom
N. Williams
A. van Wijk
G. Vanderheiden |
|
Presentation of Text Conversation in realtime and en-bloc form |
|
This specification defines methods for presentation of a text
conversation with focus on the real-time features. The aim is to
give the participants in a conversation a good opportunity to
perceive the real-time flow of the conversation and also provide a
display of the history of the conversation that makes it easy to
read. Both two-party and multi-party situations are defined.
|
|
|
| |
| Up List |
Intended Status: | Best Current Practice |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
| | |
hellstrom-txtgwy-00
ID Exists
Nov 10, 2007
(16 p.)
[pdf(2)]
[html]
|
G. Hellstrom
B. Dingle
A. van Wijk
G. Gybels |
|
Real-time text interworking between PSTN and IP networks |
IP networks can support real-time text communication. SIP-based
real- time text is called Text-over-IP or ToIP. PSTN networks
support real-time text using textphones (or TTYs). When real-time
text is supported by different networks, gateways are needed to
provide interoperability. Real-time text capable gateways may also
support real-time voice.
This specification describes procedures for interworking between ToIP
and PSTN textphones using a real-time text capable gateway (RTT
gateway). It also describes ways to route calls to RTT gateways for
several call scenarios.
Procedures that support the phased introduction of RTT gateways and
procedures that support the invocation of text channels at any time
during the call are included. Interworking of PSTN textphones that
do not support simultaneity of voice and text with IP User Agents
that support simultaneous voice and text is also described.
|
|
|
| |
| Up List |
Intended Status: | Best Current Practice |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
nagelberg-m2ua-
implementors-
guide-00
ID Exists
Nov 2, 2007
(27 p.)
[pdf(2)]
[html]
|
B. Nagelberg |
|
M2UA Implementor's Guide |
|
This document contains a compilation of all defects found since the
publication date for M2UA [RFC3331]. These defects may be of an
editorial or technical nature. This document may be thought of as a
companion document to be used in the implementation of M2UA to
clarify errors in the original M2UA document. This document updates
RFC3331 and text within this document supersedes the text found in
RFC3331.
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Best Current Practice |
|
|
|
|
|
|
|
|
| | |
peterson-rai-
rfc3427bis-00
ID Exists
Nov 8, 2007
(14 p.)
[pdf(2)]
[html]
|
J. Peterson
C. Jennings |
|
Change Process for SIP |
|
This memo documents a process intended to apply architectural
discipline to the future development of the Session Initiation
Protocol (SIP). There have been concerns with regards to new SIP
proposals. Specifically, that the addition of new SIP features can
be damaging towards security and/or greatly increase the complexity
of the protocol. The RAI Area directors, along with the SIP and
Session Initiation Proposal Investigation (SIPPING) working group
chairs, have provided suggestions for SIP modifications and
extensions.
|
|
|
| |
| Up List |
Intended Status: | Best Current Practice |
|
|
|
|
|
|
|
|
| | |
poretsky-bmwg-
sip-bench-meth-02
ID Exists
Nov 19, 2007
(20 p.)
[pdf(2)]
[html]
|
S. Poretsky
V. Gurbani
C. Davids |
|
Methodology for Benchmarking SIP Networking Devices |
|
This document describes the methodology for benchmarking Session
Initiation Protocol (SIP) performance as described in Terminology
document [draft-poretsky-sip-bench-term]. The methodology and terminology are to be used for
benchmarking signaling plane performance with varying signaling and
media load. Both scale and establishment rate are measured by
signaling plane performance. The SIP Devices to be benchmarked may
be a single device under test (DUT) or a system under test (SUT).
Benchmarks can be obtained and compared for different types of
devices such as SIP Proxy Server, SBC, P-CSCF, and Server paired with
a Firewall/NAT device.
|
|
|
|
|
|
|
|
|
|
|
| | |
rosenberg-internet-
waist-hourglass-00
ID Exists
Feb 11, 2008
(8 p.)
[pdf(2)]
[html]
|
J. Rosenberg |
|
UDP and TCP as the New Waist of the Internet Hourglass |
|
One of the fundamental design principles of the Internet is that IP
represents a common intermediate protocol layer, linking together a
variety of link layer technologies underneath with a large number of
applications on top. When drawn graphically, this can be show as an
hourglass with IP in the middle. The preponderence of NATs and
firewalls in the Internet has changed this reality, such that UDP and
TCP are now the waist of the hourglass. This document discusses this
change and describes its implications for protocol and application
design.
|
|
|
| |
| Up List |
Intended Status: | Best Current Practice |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
| | |
stiemerling-
rtsp-announce-01
ID Exists
Feb 25, 2008
(16 p.)
[pdf(2)]
[html]
|
T. Ura
K. Oku
H. Harada
A. Kobayashi
M. Stiemerling |
|
RTSP 2.0 Asynchronous Notification |
|
Some IPTV deployments that are using the Real Time Streaming Protocol
(RTSP) require the ability of the server to notify clients about
asynchronous events occurring during an RTSP session. Current
deployments typically use the ANNOUNCE method of RTSP 1.0 for sending
such asynchronous events from a server to clients by using some
proprietary extensions. However, the ANNOUNCE method has been
removed from the current RTSP 2.0 draft, leaving the new
specification without a mechanism for sending asynchronous messages
from the server. This memo describes a use case for such an
asynchronous message and proposes a new RTSP 2.0 method.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
tuexen-
dtls-for-sctp-02
ID Exists
Nov 17, 2007
(8 p.)
[pdf(2)]
[html]
|
M. Tuexen
E. Rescorla |
|
Datagram Transport Layer Security for Stream Control Transmission Protocol |
This document describes the usage of the Datagram Transport Layer
Security (DTLS) protocol over the Stream Control Transmission
Protocol (SCTP).
The user of DTLS over SCTP can take advantage of all features
provided by SCTP and its extensions, especially support of
- multiple streams to avoid head of line blocking.
- multi-homing to provide network level fault tolerance
- unordered delivery.
- partial reliable data transfer.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
worley-redundancy-
response-02
ID Exists
Nov 18, 2007
(9 p.)
[pdf(2)]
[html]
|
D. Worley |
|
Supporting Multiple Path Routing in SIP |
|
An increasing number of SIP architectures implement multiple path
routing (MPR), which is the providing of more than one path for a
call to reach a destination user agent (UA). To implement MPR well,
the proxy which forks a request onto the redundant paths needs to be
able to determine if a fork that failed reached the destination UA
and was rejected by the UA (and so an alternate path should not be
tried), or if the fork failed before reaching the UA (and so an
alternate path should be attempted). This document is to begin a
discussion of strategies for making this determination.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
worley-
service-example-01
ID Exists
Jan 16, 2008
(22 p.)
[pdf(2)]
[html]
|
D. Worley |
|
SIP Service Example -- Music on Hold |
|
The "music on hold" feature is one of the most desired features of
telephone systems in the business environment. "Music on hold" is
when one party to a call has the call "on hold", the other party
receives a media stream (often either music or advertising).
Architectural features of SIP make it difficult to implement music-on-hold
in a way that is fully compliant with the standards. The
implementation of music-on-hold described in this document is fully
effective and standards-compliant, but is simpler than the methods
previously documented.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
|
|
