idnits 2.17.1 draft-ietf-pint-sip-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-23) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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 Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 44 has weird spacing: '... in the c (co...' == Line 120 has weird spacing: '...swerspk on,...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 20, 1997) is 9651 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 11 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force PINT WG 3 Internet Draft Schulzrinne 4 draft-ietf-pint-sip-00.txt Columbia U. 5 November 20, 1997 6 Expires: April 1, 1998 8 SIP for Click-To-Dial-Back and Third-Party Control 10 STATUS OF THIS MEMO 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as ``work in progress''. 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 Distribution of this document is unlimited. 30 1 Introduction 32 SIP can also be used to control calls established by other entities, 33 for example, to have a computer control a PBX or a web server ask an 34 SCP to initiate a call to a standard telephone (''click-to-dial- 35 back''). We refer to the entity initiating the phone call as the 36 controller and the PBX or SCP as the PSTN server. 38 2 Outgoing Call 40 The controller sends an INVITE request to the PSTN server. The SIP 41 request contains information about the caller and the call, e.g., 42 from a web form. The PSTN server may use this information in 43 initiating the call. The telephone number to be called is contained 44 in the c (connection) parameter of the SDP body. For example, if the 45 subscriber with number 415 555 1200 wants to initiate a call through 46 her local PBX to the subscriber at 1-212-555-1234, her SIP client 47 issues the following request to the PBX: 49 INVITE sip://1-212-555-1234@pbx.example.com 50 From: j.doe@example.com 51 Content-type: application/sdp 53 v=0 54 o=user1 53655765 2353687637 IN IP4 128.3.4.5 55 c=PSTN E.164 +1-415-555-1200 56 t=0 0 57 m=audio 0 RTP/AVP 0 59 Camp-on is realized with the SIP Call-Disposition "queue" parameter. 61 3 Answering Incoming Calls 63 If a controller receives a SIP call, it may indicate in its 200 64 response to send the audio to a given telephone number, as indicated 65 in the previous section. Alternatively, it can include the phone 66 number in a redirection response, but then it is assumed that further 67 call control is handled by the phone device, not the controller. It 68 can also reject the call with the standard SIP codes. Call forwarding 69 is handled with standard SIP 30x status codes. 71 accept call 200 72 blind transfer BYE, with new destination 73 forward, no anser 408 74 forward, busy 600 75 forward call 301 or 302, Location contains address 77 4 Placing Calls on Hold 79 The party wishing to place the other party on hold sends an INVITE 80 for the existing call identifier, with an SDP description indicating 81 a zero port number for the media types it currently does not wish to 82 receive. This also allows media-specific hold, e.g., to ask the other 83 side temporarily not to send video. Music-on-hold is implemented by 84 asking an RTSP server to play to the IP address (or phone number) 85 provided in the RTSP SETUP request. 87 5 Call Parking 89 A user can send an INVITE to an existing call id and cause it to 90 move to a new extension. [Alternative: PARK request] 92 6 Call Transfer 93 To transfer an existing call blindly, the controller sends a BYE 94 containing a Location header indicating the phone number the call is 95 to be transferred to. 97 For supervised call transfer, the controller initiates a call to the 98 destination of the call, placing the existing call on hold. It then 99 sends a BYE, as above, for the first call. The PBX can transfer back 100 the call to the first destination if the call transfer fails. 102 7 Configuring the Local PBX 104 A controller can control a PBX by issuing a REGISTER request with 105 call-handling specification. This call-handling specification can be 106 in a number of programming languages and formats, including a simple 107 list of parameters as a text/parameter. Table 1 lists the parameters 108 currently defined. The REGISTER response returns the current 109 configuration. [TBD: Could use GET_PARAMETER and SET_PARAMETER 110 instead.] 112 Examples: 114 autoanswer: on 115 callsparked: 5 116 forward_busy: +1-415-555-1234 117 forward_all: off 119 autoanswer on, off 120 autoanswerspk on, off 121 callsparked integer 123 Table 1: Configuring PBX behavior using SIP 125 Table 2: Parameters