Login Form
RECENT IETF DRAFTS
SIP internet drafts statistics
- 97 SIP related internet drafts (IETF).
- 7 new and updated drafts posted in the last 14 days.
| Title | Author | Date |
| SIP Forum - Fax Over IP Task Group Problem Statement | Ximing Chen, Mike Coffee, Kevin Fleming, Gunnar Hellstrom, Paul Jones, John Lunsford, Antonios Papageorgiou, Gonzalo Salgueiro, Ed Schulz, Neil Weldon | 2009-11-17 |
| This memo is published for informational purposes to document the issues identified by the SIP Forum with respect to the transmission of facsimile signaling messages and fax page data over Internet Protocol (IP) networks. Further, it is the intent of this memo to alert the IETF to the formation of a Fax Over IP Task Group within the SIP Forum chartered to investigate and address identified issues as they relate to the deployment of fax services in Session Initiation Protocol (SIP) networks. | ||
| Emergency Text Messaging using SIP MESSAGE | Jong Yul Kim, Wonsang Song, Henning Schulzrinne, Piotr Boni, Michael Armstrong | 2009-11-17 |
| This memo describes best current practices on how to use the SIP MESSAGE method for emergency text messaging from citizen and visitors to authorities. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 20, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust\'s Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. | ||
| Private Extensions to the Session Initiation Protocol (SIP) for Service Interaction Indicator | Yuzhong Shen | 2009-11-13 |
| In SIP-based networks, a SIP session MAY involve several application servers on the originating and terminating side. In a certain case, an application server needs to set some indications in SIP message to indicate service information (what are invoked, what can be allowed and what should blocked). This kind of information will be also required for composition of SIP applications. There is a need to provide indicators for service interaction between SIP application servers or other SIP endpoints. This document describes a mechanism of service interaction indicator for the Session Initiation Protocol (SIP) that enhances service interaction between SIP application servers in a trusted network. | ||
| Use of the Reason header filed in Session Initiation Protocol (SIP) responses | Roland Jesske, Laura Liess | 2009-11-11 |
| Although the use of the Reason header field in responses is considered in RFC3326, doing so is not specified for any existing response code. Nonetheless, the Reason header field has been widely used in responses to carry Q.850 reason codes for failure responses to INVITEs that have been gatewayed to PSTN systems. This document specifies and formally permits the use of the Reason header field in SIP responses to carry Q.850 reason codes for this and other purposes. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 15, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust\'s Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. | ||
| Filtering Location Notifications in the Session Initiation Protocol (SIP) | Rohan Mahy, Brian Rosen, Hannes Tschofenig | 2009-11-08 |
| This document describes filters that limit asynchronous location notifications to compelling events, designed as an extension to RFC 4661, an XML-based format for event notification filtering, and based on RFC 3856, the SIP presence event package. The resulting location information is conveyed in existing location formats wrapped in the Presence Information Data Format Location Object (PIDF-LO). Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 12, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust\'s Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. | ||
| Session Initiation Protocol (SIP) Extensions for Blocking VoIP Spam Using PSTN Validation | Jonathan Rosenberg, Cullen Jennings | 2009-11-08 |
| Verification Involving PSTN Reachability (ViPR) is a new technique for inter-domain federation of SIP calls. ViPR makes use of a the PSTN as an introduction mechanism to verify the correctness of mappings from phone numbers to domains. The PSTN introduction mechanism can also be used as a techqnique for blocking spam - a SIP caller is only authorized when they\'re calling domain has previously called that same number over the PSTN. This document describes an extension to SIP which enables authorization of SIP calls based on a prior PSTN introduction. Legal This documents and the information contained therein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 13, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust\'s Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. | ||
| Session Initiation Protocol (SIP) Event Notification Extension for Notification Rate Control | Aki Niemi, Krisztian Kiss, Salvatore Loreto | 2009-11-08 |
| This document specifies mechanisms for adjusting the rate of Session Initiation Protocol (SIP) event notifications. These mechanisms can be applied in subscriptions to all SIP event packages. | ||
| Call Completion for Session Initiation Protocol (SIP) | Dale Worley, Martin Huelsemann, Roland Jesske, Denis Alexeitsev | 2009-10-26 |
| The call completion features allow the calling user of a failed call to be notified when the called user becomes available to receive a call. For the realization of a basic solution without queueing call- completion requests, this document references the usage of the the dialog event package [RFC4235] as described as \'automatic redial\' in [RFC5359]. For the realization of a more comprehensive solution with queueing call-completion requests, this document introduces an architecture for implementing these features in the Session Initiation Protocol: "Call completion" implementations associated with the caller\'s and callee\'s endpoints cooperate to place the caller\'s request for call completion into a queue at the callee\'s endpoint, and, when a caller\'s request is ready to be serviced, re-attempt the original, failed call. The deployment of a certain SIP call-completion solution is also dependent on the needed level of interoperability with existing call- completion solutions in other networks. | ||
| Shared Appearances of a Session Initiation Protocol (SIP) Address of Record (AOR) | Alan Johnston, Mohsen Soroushnejad, Venkatesh Venkataramanan | 2009-10-26 |
| This document describes the requirements and implementation of a group telephony feature commonly known as Bridged Line Appearance (BLA) or Multiple Line Appearance (MLA), or Shared Call/Line Appearance (SCA). When implemented using the Session Initiation Protocol (SIP), it is referred to as shared appearances of an Address of Record (AOR) since SIP does not have the concept of lines. This feature is commonly offered in IP Centrex services and IP-PBX offerings and is likely to be implemented on SIP IP telephones and SIP feature servers used in a business environment. This document discusses use cases, lists requirements and defines SIP extensions to implement this feature. | ||
| SOS Uniform Resource Identifier (URI) Parameter for Marking of Session Initiation Protocol (SIP) Requests related to Emergency Services | Milan Patel | 2009-10-26 |
| This document defines a new Session Initiation Protocol (SIP) Uniform Resource Identifier (URI) parameter intended for marking SIP registration requests related to emergency services. The URI parameter is extensible to allow future values to be defined if required by other use cases that require specific SIP registrations to be distinctly identified. The usage of this new URI parameter complements the usage of the Service Uniform Resource Name (URN) and is not intended to replace it. | ||
| An Extension to the Session Initiation Protocol (SIP) for Request History Information | Mary Barnes, Francois Audet, Shida Schubert, The Netherlands, Christer Holmberg | 2009-10-26 |
| This document defines a standard mechanism for capturing the history information associated with a Session Initiation Protocol (SIP) request. This capability enables many enhanced services by providing the information as to how and why a call arrives at a specific application or user. This document defines an optional SIP header, History-Info, for capturing the history information in requests. | ||
| Re-INVITE and Target-refresh Request Handling in the Session Initiation Protocol (SIP) | Gonzalo Camarillo, Christer Holmberg, Gao yang | 2009-10-26 |
| In this document, we clarify the handling of re-INVITEs in SIP. We clarify in which situations a UAS (User Agent Server) should generate a success response and in which situations a UAS should generate an error response to a re-INVITE. Additionally, we clarify issues related to target-refresh requests. | ||
| Session Initiation Protocol (SIP) Domain Registration | Hadriel Kaplan | 2009-10-26 |
| This document defines a means of providing reachability information for a domain of SIP AoR\'s using a SIP REGISTER method transaction. | ||
| SPEERMINT Requirements for SIP-based Session Peering | Jean-Francois Mule | 2009-10-26 |
| This memo captures protocol requirements to enable session peering of voice, presence, instant messaging and other types of multimedia traffic. It is based on the use cases that have been described in the SPEERMINT working group. This informational document is intended to link the session peering use cases to protocol solutions. | ||
| Session Initiation Protocol (SIP) Overload Control | Volker Hilt, Henning Schulzrinne | 2009-10-25 |
| 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. | ||
| A Session Initiation Protocol (SIP) Load Control Event Package | Charles Shen, Henning Schulzrinne, Arata Koike | 2009-10-25 |
| 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. | ||
| Indirect Presence Publication with the Session Initiation Protocol(SIP) | Miguel Garcia, Hannes Tschofenig, Henning Schulzrinne, Martin Thomson | 2009-10-25 |
| A method for indirectly publishing presence information is described. This allows a presentity user agent to publish a URI that can be used by the presence agent to retrieve presence information. A presence agent is then better able to acquire dynamic presence information without relying on the presentity user agent. This also allows a presentity user agent to delegate responsibility for managing changing presence data to the source of that information. | ||
| Considerations for Information Services and Operator Services Using SIP | John Haluska, Renee Berkowitz, Paul Roder, Wesley Downum, Richard Ahern, Paul Lung, Nicholas Costantino, Chris Blackwell | 2009-10-23 |
| 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 describe how current operator services can continue to be provided to PSTN based subscribers via a SIP based operator services architecture. It also looks at how current operator services might be provided to SIP based subscribers via such an architecture, but does not consider the larger question of the need for or usefulness or suitability of each of these services for SIP based subscribers. | ||
| Change Process for the Session Initiation Protocol (SIP) and the Real- time Applications and Infrastructure Area | Jon Peterson, Cullen Jennings, Robert Sparks | 2009-10-23 |
| This memo documents a process intended to organize the future development of the Session Initiation Protocol (SIP) and related work in the Real-Time Applications and Infrastructure (RAI) Area. As the environments in which SIP is deployed grow more numerous and diverse, modifying or extending SIP in certain ways may threaten the interoperability and security of the protocol; however, the IETF process must also cater to the realities of existing deployments and serve the needs of the implementers working with SIP. This document therefore defines the functions of two long-lived working groups in the RAI Area which are, respectively, responsible for the maintenance of the core SIP specifications and development of new efforts to extend and apply work in this space. This document obsoletes RFC3427. | ||
| A SIP Usage for RELOAD | Cullen Jennings, Bruce Lowekamp, Eric Rescorla, Salman Baset, Henning Schulzrinne | 2009-10-23 |
| This document defines a SIP Usage for REsource LOcation And Discovery (RELOAD), The SIP Usage provides the functionality of a SIP proxy or registrar in a fully-distributed system. The SIP Usage provides lookup service for AoRs stored in the overlay. The SIP Usage also defines GRUUs that allow the registrations to map an AoR to a specific node reachable through the overlay. The AppAttach method is used to establish a direct connection between nodes through which SIP messages are exchanged. | ||
| Session Initiation Protocol (SIP) INFO Method and Package Framework | Eric Burger, Hadriel Kaplan, Christer Holmberg | 2009-10-23 |
| This document defines a new method, INFO, for the Session Initiation Protocol (SIP) [RFC3261], and an Info Package mechanism. The document obsoletes [RFC2976]. For backward compatibility the document also specifies a "legacy" mode of usage of the INFO method that is compatible with the usage previously defined in [RFC2976], referred to as "legacy INFO Usage" in this document. | ||
| Using Extended Key Usage (EKU) for Session Initiation Protocol (SIP) X.509 Certificates | Scott Lawrence, Vijay Gurbani | 2009-10-20 |
| This memo documents an extended key usage (EKU) X.509 certificate extension for restricting the applicability of a certificate to use with a Session Initiation Protocol (SIP) service. As such, in addition to providing rules for SIP implementations, this memo also provides guidance to issuers of certificates for use with SIP. | ||
| An Analysis of Automatic Call Handling Implementation Issues in the Session Initiation Protocol (SIP) | John Elwell | 2009-10-19 |
| This discusses problems associated with automatic call handling (ACH) when using the Session Initiation Protocol (SIP) and specifies some best practices to help achieve interoperability. This work is being discussed on the bliss@ietf.org mailing list. | ||
| Evaluating OAUTH\'s suitability for SIP authentication | Wolfgang Beck | 2009-10-19 |
| The Open Authentication Protocol (OAUTH) provides a method for clients to access server resources on behalf of another party. This document evaluates OAUTH\'s suitability as an authentication mechanism for the Session Initiation Protocol (SIP) for use cases where web applications want to interact with SIP servers without sharing user credentials. | ||
| The Common Log Format (CLF) for the Session Initiation Protocol (SIP) | Vijay Gurbani, Eric Burger, Tricha Anjali, Humberto Abdelnur, Olivier Festor | 2009-10-19 |
| Well-known web servers such as Apache and web proxies like Squid support event logging using a common log format. The logs produced using these de-facto standard formats are invaluable to system administrators for trouble-shooting a server and tool writers to craft tools that mine the log files and produce reports and trends. Furthermore, these log files can also be used to train anomaly detection systems and feed events into a security event management system. The Session Initiation Protocol does not have a common log format, and as a result, each server supports a distinct log format that makes it unnecessarily complex to produce tools to do trend analysis and security detection. We propose a common log file format for SIP servers that can be used uniformly for proxies, registrars, redirect servers as well as back-to-back user agents. | ||
| << Start < Prev 1 2 3 4 Next > End >> | ||
| Display # Results 1 - 25 of 97 | ||