rfc3351
draft-ietf-sip-guidelines
draft-moyer-sip-appliances-framework
draft-ietf-sip-state
draft-beck-sipping-svc-charging-req
rfc3351
draft-ietf-sip-guidelines
draft-moyer-sip-appliances-framework
draft-ietf-sip-state
draft-beck-sipping-svc-charging-req
rfc3351.txt  | User Requirements for the Session Initiation Protocol (SIP) in Support of Deaf, Hard of Hearing and Speech-impaired Individuals |
| Author(s) | N. Charlton, M. Gasson, G. Gybels, M. Spanner, A. van Wijk |
| Organization | ietf |
| State | informational |
| Size | 33894 bytes |
| Abstract | This document presents a set of Session Initiation Protocol (SIP) user requirements that support communications for deaf, hard of hearing and speech-impaired individuals. These user requirements address the current difficulties of deaf, hard of hearing and speech-impaired individuals in using communications facilities, while acknowledging the multi-functional potential of SIP-based communications. A number of issues related to these user requirements are further raised in this document. Also included are some real world scenarios and some technical requirements to show the robustness of these requirements on a concept-level. |
| draft-ietf-sip-guidelines-06.txt | Guidelines for Authors of Extensions to the Session Initiation Protocol (SIP) |
| Author(s) | Jonathan Rosenberg |
| Organization | ietf |
| Working group | sip |
| State | unknown |
| Date | 2002-11-08 |
| Size | 52938 bytes |
| Abstract | The Session Initiation Protocol (SIP) is a flexible, yet simple tool for establishing interactive connections across the Internet. Part of this flexibility is the ease with which it can be extended. In order to facilitate effective and interoperable extensions to SIP, some guidelines need to be followed when developing SIP extensions. This document outlines a set of such guidelines for authors of SIP extensions. Table of Contents 1 Terminology ......................................... 3 2 Introduction ........................................ 3 3 Should I define a SIP Extension? ................... 3 3.1 SIP's Solution Space ................................ 4 3.2 SIP Architectural Model ............................. 6 4 Issues to be Addressed .............................. 8 4.1 Backwards Compatibility ............................. 8 4.2 Security ............................................ 10 4.3 Terminology ......................................... 10 4.4 Syntactic Issues .................................... 11 4.5 Semantics, Semantics, Semantics ..................... 13 4.6 Examples Section .................................... 14 4.7 Overview Section .................................... 14 4.8 IANA Considerations Section ......................... 15 4.9 Document Naming Conventions ......................... 15 4.10 Additional Considerations for New Methods ........... 16 4.11 Additional Considerations for New Header Fields or Header Field Parameters ........................................ 17 4.12 Additional Considerations for New Body Types ........ 17 5 Interactions with SIP Features ...................... 18 6 Security Considerations ............................. 18 7 IANA Considerations ................................. 19 8 Acknowledgements .................................... 19 9 Authors Addresses ................................... 19 10 Normative References ................................ 19 11 Informative References .............................. 20 |
| draft-moyer-sip-appliances-framework-03.txt
|
| draft-ietf-sip-state-03.txt
|
| draft-beck-sipping-svc-charging-req-01.txt | SIP endpoint service charging requirements |
| Author(s) | Wolfgang Beck |
| Organization | ietf |
| State | unknown |
| Date | 2002-12-20 |
| Size | 23105 bytes |
| Abstract | Today, a SIP user wanting to charge for a service needs to establish an agreement with all prospective callers. This administrative overhead can be avoided if caller and callee can prove the duration and existence of a call in case of a dispute. The draft describes requirements for protocols and SIP extensions that can be used to implement such functionality. |