Login Form
RECENT IETF DRAFTS
SIP internet drafts statistics
- 145 SIP related internet drafts (IETF).
- 12 new and updated drafts posted in the last 14 days.
| Title | Author | Date |
| A Hitchhiker\'s Guide to the Session Initiation Protocol (SIP) | Jonathan Rosenberg | 2008-02-24 |
| The Session Initiation Protocol (SIP) is the subject of numerous specifications that have been produced by the IETF. It can be difficult to locate the right document, or even to determine the set of Request for Comments (RFC) about SIP. This specification serves as a guide to the SIP RFC series. It lists the specifications under the SIP umbrella, briefly summarizes each, and groups them into categories. | ||
| Identification of Communications Services in the Session Initiation Protocol (SIP) | Jonathan Rosenberg | 2008-02-24 |
| This document considers the problem of service identification in the Session Initiation Protocol (SIP). Service identification is the process of determining the user-level use case that is driving the signaling being utilized by the user agent. This document discusses the uses of service identification, and outlines several architectural principles behind the process. It identifies several perils associated with service identification, including fraud, interoperability failures and stifling of innovation. | ||
| Allowing SIP Resource-Priority Header in SIP Responses | James Polk | 2008-02-23 |
| The Session Initiation Protocol (SIP) Resource-Priority Header is ignored in SIP responses, according to RFC 4412. This was a design choice during RFC 4412\'s development. This is now considered a bad design choice in certain scenarios. This document corrects RFC 4412\'s communications model by optionally allowing a SIP server or user agent (UA) to process the Resource-Priority Header in a response. | ||
| SIP Identity using Media Path | Dan Wing, Hadriel Kaplan | 2008-02-23 |
| This document defines a new SIP identity mechanism which operates through SBCs and B2BUAs. This new identity mechanism creates a signature over certain SIP headers and certain SDP lines. When the SIP body contains SDP, both the SIP signaling path and the media path are used to perform the identity function; when the SIP body contains non-SDP body parts, they are signed in their entirety. | ||
| A Session Initiation Protocol (SIP) Response Code for Interactive Connectivity Establishment (ICE) Failures | Jonathan Rosenberg | 2008-02-23 |
| Interactive Connectivity Establishment (ICE) defines an extension to the offer/answer model used by the Session Initiation Protocol (SIP). This extension allows endpoints to traverse firewalls and NATs. However, in cases where highly restrictive firewalls exist, or where network failures have occurred, ICE may not be able to successfully find a media path. This document provides an error response code that can be used with SIP in these cases. | ||
| P2PSIP Client Protocol | Song Yongchao, XingFeng Jiang, Hewen Zhang, Hui Deng | 2008-02-23 |
| This document defines P2PSIP client protocol, one protocol for client-peer communication, which is used to create, implement and maintain the services between a client and its associated peers. | ||
| The use of the SIPS URI Scheme in the Session Initiation Protocol (SIP) | Francois Audet | 2008-02-23 |
| This document provides clarifications and guidelines concerning the use of the SIPS URI scheme in the Session Initiation Protocol (SIP). It also makes normative changes to SIP. This document also provides a discussion of possible future steps in specification. | ||
| Session Initiation Protocol (SIP) Overload Control | Volker Hilt, Indra Widjaja, Daryl Malas, Henning Schulzrinne | 2008-02-22 |
| 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 proposes new overload control mechanisms for SIP. | ||
| Providing guidance for Session Initiation Protocol (SIP) services | Arnaud Ligot, Thomas Froment | 2008-02-22 |
| Implementing Session Initiation Protocol (SIP) advanced features and services requires to use numerous specifications. Today, for each service in the scope of BLISS, one can already find references to many possible specifications which do not cover the same things. Some of them are primitive operations, requirements or call flow examples, some have a scope larger than the others, or can not be compared at the same level. Very often, architecture hypothesis are hidden behind the same service name, either assuming that an intermediary; like an application server, has an active role in the service, or, as opposed, assuming a pure end-to-end model where only endpoint implementations are involved. The goal of this document is not to present the best solutions or give recommendations; but to give an overview of every standard specification related to these services, centralizing and categorizing them as input to the working group. | ||
| The SIP Identity Baiting Attack | Hadriel Kaplan, Dan Wing, Intellectual Property | 2008-02-22 |
| This document identifies a potential SPIT and Phishing attack, which subverts the RFC 4474 SIP Identity and RFC 4916 Connected Identity mechanisms in a particular way. The attack is termed "Baiting", as it uses a RFC4474-signed call as the bait for malicious use. | ||
| Addressing Record-Route issues in the Session Initiation Protocol (SIP) | Thomas Froment, Christophe Lebel | 2008-02-22 |
| A typical function of a Session Initiation Protocol (SIP) Proxy is to set a Record-Route header on initial requests in order to make subsequent requests pass through it. This header contains a SIP Uniform Resource Identifier (URI) indicating where and how the subsequent requests should be sent to reach the proxy. Like any SIP URI, it can contain sip or sips schemes, IPV4 or IPV6 addresses, and URI parameters that could influence the routing like different transport parameters (UDP, TCP, SCTP...), or a compression indication like "comp=sigcomp". When a proxy has to change some of those parameters between its incoming and outgoing interfaces (multi-homed proxies, transport protocol switching, sip to sips or IPV4 to IPV6 scenarios...), the question arises on what should be put in Record- Route header(s). It is just not possible to make one header having the characteristics of both sides at the same time. This document aims to clarify these scenarios and fix bugs already identified on this topic; it formally recommends the use of the double Record-Route technique as an alternative to the current RFC3261 text, which describes only a Record-Route rewriting solution. | ||
| An Analysis of Automatic Call Handling Implementation Issues in the Session Initiation Protocol (SIP) | John Elwell | 2008-02-21 |
| This discusses problems associated with automatic call handling (ACH) when using the Session Initiation Protocol (SIP). This work is being discussed on the bliss@ietf.org mailing list. | ||
| Private Session Initiation Protocol (SIP) Proxy-to-Proxy Extensions for Supporting the PacketCable Distributed Call Signaling Architecture | Flemming Andreasen, Bernie McKibben, Bill Marshall | 2008-02-21 |
| 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. | ||
| Implementing Call Park and Retrieve using the Session Initiation Protocol (SIP) | Michael Procter | 2008-02-21 |
| Call Park and Call Retrieve are useful telephony services that are familiar to many users. Existing implementations using the Session Initiation Protocol (SIP) show that a variety of approaches can be taken, with varying degrees of interoperability. This draft discusses a number of feature variations, and how they may be implemented. | ||
| Use of the Reason header filed in Session Initiation Protocol (SIP) responses | Roland Jesske | 2008-02-20 |
| This document proposes the use of the Reason header field in SIP responses. | ||
| Sieve Notification Mechanism: SIP MESSAGE | Alexey Melnikov, Henning Schulzrinne, Qian Sun | 2008-02-18 |
| This document describes a profile of the Sieve extension for notifications, to allow notifications to be sent over the SIP MESSAGE. | ||
| Indirect Presence Publication with the Session Initiation Protocol(SIP) | Miguel Garcia-Martin, Hannes Tschofenig, Henning Schulzrinne | 2008-02-18 |
| SIP is extended by the SIP-events framework to provide subscriptions and notifications of SIP events. One example of such event notification mechanism is \'presence\' and this presence information is carried in Presence Information Data Format (PIDF) documents. The SIP PUBLISH method specified in RFC 3903 carrying a PIDF document is typically used when presentities publish their own presence since these presentities are typically the source of the information. However, there are cases when the presentity is not the direct source of the presence information. One such example is location information where the end host may obtain a reference to location information as opposed to as a value. The endpoint is typically not interested in knowing its own location information, but other users or entities might be. So, if the endpoint gets its own location information with a reference and wants to publish it embedded in its presence information, it first needs to de-reference it for getting a value, and then it can embed that value in its presence information. While this is certainly a correct sequence, it adds a round-trip to the presence publication, in addition to a demand processing power and network bandwidth consumption. There is a need for a mechanism that the presentity can use to publish indirect references, such as indirect location references. This document discusses a few variants that may be used to provide this functionality. | ||
| Spam score for SIP: a proposal for semantics | Jan Seedorf, Saverio Niccolini, Henning Schulzrinne | 2008-02-18 |
| 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. | ||
| SIP Usage Scenarios Similar to SPIT | Dan York | 2008-02-18 |
| This document outlines scenarios in which legitimate SIP traffic may appear similar to traffic associated with voice spam, also known as "SPIT" or "Spam for Internet Telephony. This document is created to provide input into the current discussions about how best to address the issue of SPIT. | ||
| Provisioning Protocol Requirements for ENUM-SIP Addressing Servers | Tom Creighton, Jean-Francois Mule | 2008-02-18 |
| This document presents use cases and protocol requirements for provisioning ENUM-SIP addressing servers. The provisioned data is used by an addressing server to return part of the session establishment data to SIP entities so that they can route SIP sessions to the target destinations. | ||
| Using Extended Key Usage (EKU) for Session Initiation Protocol (SIP) X.509 Certificates | Scott Lawrence, Vijay Gurbani | 2008-02-18 |
| This memo documents an extended key usage (EKU) X.509 certificate extension for identifying the holder of a certificate as authoritative for a Session Initiation Protocol (SIP) service in the domain named by the DNS name in the certificate. | ||
| UA-Driven Privacy Mechanism for SIP | Mayumi Munakata, Shida Schubert, Takumi Ohba | 2008-02-18 |
| To withhold a user\'s identity and related information, RFC 3323 defines a Privacy mechanism for SIP, which requires the use of an privacy service. This document proposes a new privacy mechanism that a user agent can facilitate to conceal privacy-sensitive information without the need for aid from a privacy service. | ||
| Example calls flows of race conditions in the Session Initiation Protocol (SIP) | Miki Hasebe, Jun Koshiko, Yasushi Suzuki, Tomoyuki Yoshikawa, Paul Kyzivat | 2008-02-18 |
| This document gives examples call flows of race conditions in the Session Initiation Protocol (SIP). Race conditions are inherently confusing and difficult to thwart; this document shows the best practices to handle them. The elements in these call flows include SIP User Agents and SIP Proxy Servers. Call flow diagrams and message details are given. | ||
| Feature Referral in the Session Initiation Protocol (SIP) | Francois Audet, Alan Johnston, Rohan Mahy, Cullen Jennings | 2008-02-17 |
| 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. | ||
| Litmus Tests for Usage of the Session Initiation Protocol (SIP) INFO Method | Jonathan Rosenberg | 2008-02-16 |
| The Session Initiation Protocol (SIP) Working Group is considering the standardization of a framework for conveying application data through the INFO method. However, the INFO method is just one of several techniques available in SIP for the transfer of application data. Others include through the SIP events framework and through a media session. This document provides guidelines and litmus tests for determining which is the right technique to use. | ||
| << Start < Prev 1 2 3 4 5 6 Next > End >> | ||
| Display # Results 51 - 75 of 145 | ||
SIP SPOKESPERSON
Henning Schulzrinne is an Assoc. Prof. in the Department of Computer Science and the Department of Electrical Engineering at Columbia University.
