idnits 2.17.1 draft-ietf-l2tpext-v92-moh-05.txt: Skipping this file; it looks like a tombstone file to me. -------------------------------------------------------------------------------- 1 A new Request for Comments is now available in online RFC libraries. 3 RFC 3573 5 Title: Signalling of Modem-On-Hold status 6 in Layer 2 Tunneling Protocol (L2TP) 7 Author(s): I. Goyret 8 Status: Standards Track 9 Date: July 2003 10 Mailbox: igoyret@lucent.com 11 Pages: 13 12 Characters: 22758 13 Updates/Obsoletes/SeeAlso: None 15 I-D Tag: draft-ietf-l2tpext-v92-moh-05.txt 17 URL: ftp://ftp.rfc-editor.org/in-notes/rfc3573.txt 19 The Layer 2 Tunneling Protocol (L2TP) defines a mechanism for 20 tunneling Point-to-Point Protocol (PPP) sessions. It is common for 21 these PPP sessions to be established using modems connected over the 22 public switched telephone network. 24 One of the standards governing modem operation defines procedures 25 that enable a client modem to put the call on hold and later, re- 26 establish the modem link with minimal delay and without having to 27 redial. While the modem call is on hold, the client phone line can 28 be used to place or receive other calls. 30 The L2TP base protocol does not provide any means to signal these 31 events from the L2TP Access Controller (LAC), where the modem is 32 physically connected, to the L2TP Network Server (LNS), where the PPP 33 session is handled. 35 This document describes a method to let the LNS know when a client 36 modem connected to a LAC has placed the call on hold. 38 This document is a product of the Layer Two Tunneling Protocol 39 Extensions Working Group of the IETF. 41 This is now a Proposed Standard Protocol. 43 This document specifies an Internet standards track protocol for 44 the Internet community, and requests discussion and suggestions 45 for improvements. Please refer to the current edition of the 46 "Internet Official Protocol Standards" (STD 1) for the 47 standardization state and status of this protocol. Distribution 48 of this memo is unlimited. 50 This announcement is sent to the IETF list and the RFC-DIST list. 51 Requests to be added to or deleted from the IETF distribution list 52 should be sent to IETF-REQUEST@IETF.ORG. Requests to be 53 added to or deleted from the RFC-DIST distribution list should 54 be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. 56 Details on obtaining RFCs via FTP or EMAIL may be obtained by sending 57 an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body 58 help: ways_to_get_rfcs. For example: 60 To: rfc-info@RFC-EDITOR.ORG 61 Subject: getting rfcs 63 help: ways_to_get_rfcs 65 Requests for special distribution should be addressed to either the 66 author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless 67 specifically noted otherwise on the RFC itself, all RFCs are for 68 unlimited distribution.echo 69 Submissions for Requests for Comments should be sent to 70 RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC 71 Authors, for further information.