Internet-Draft Daniele Giordano
Category: Best Common Practice
20 August 2008
Expires: 11 Febbruary 2009
Call on hold for telephony applications of SIP protocol
draft-giordano-sip-call-hold-revision-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
Many RFCs and Internet Drafts describe call on hold methods adopted
in SIP signaling protocol. The actual implementation may not always
be ideal for telephony applications (reasons are explained below).
This draft proposes a revision of call on hold method for SIP
protocol.
Giordano [Page 1]
Internet-Draft Call on hold for telephony applications of SIP protocol
Table of Contents
1. Conventions Used In This Document . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The actual implementation . . . . . . . . . . . . . . . . . . . 3
4. New Implementation and Operations . . . . . . . . . . . . . . . 4
4.1 Example of Holding process. . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . . . . 7
Giordano [Page 2]
Internet-Draft Call on hold for telephony applications of SIP protocol
1. Conventions Used In This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Introduction
Many RFCs and Internet Drafts describe call on hold methods adopted
in SIP signaling protocol. The actual implementation may not always
be ideal for telephony applications (reasons are explained below).
This draft proposes a revision of actual call on hold method for
SIP protocol used in telephony applications.
3. The actual implementation
The actual implementations of call on hold method are described in
many documents.
[RFC2543] paragraph B.5 "Putting Media Streams on Hold" establishes:
If a party in a call wants to put the other party "on hold", i.e.,
request that it temporarily stops sending one or more media streams,
a party re-invites the other by sending an INVITE request with a
modified session description. The session description is the same as
in the original invitation (or response), but the "c" destination
addresses for the media streams to be put on hold are set to zero
(0.0.0.0).
[RFC3264] paragraph 8.4 "Putting a Unicast Media Stream on Hold"
establishes:
Typically, when a user "presses" hold, the agent will generate an
offer with all streams in the SDP indicating a direction of sendonly,
and it will also locally mute, so that no media is sent to the far
end, and no media is played out.
[RFC3725] paragraph 5 "Recommendations" establishes:
... Several of these flows use a "black hole" connection address of
0.0.0.0. This is an IPv4 address with the property that packets sent
to it will never leave the host which sent them; they are just
discarded. ... In most cases, including the recommended flows, user A
will hear silence while the call to B completes. This may not always
be ideal. It can be remedied by connecting the caller to a
music-on-hold source while the call to B occurs.
Giordano [Page 3]
Internet-Draft Call on hold for telephony applications of SIP protocol
[RFC3725] paragraph 7 "Continued Processing" establishes:
.... In particular, the version number in the SDP will need to be
changed by the controller in certain cases. If the controller should
issue an SDP offer on its own (for example, to place a call on hold),
it will need to increment the version number in the SDP offer.
[draft-ietf-sipping-sip-offeranswer] paragraph 5.3 "Hold and Resume
of media" establishes:
...If UA2 has previously been "placed on hold" by UA1, via receipt of
"a=sendonly", then it may initiate its own hold by sending a new
offer containing "a=sendonly" to UA1. Upon receipt of that, UA1 will
answer with "a=inactive" because that is the only valid answer that
reflects its desire not to receive media.
[draft-ietf-sip-service-examples] gives examples of hold methods in
various SIP services like call hold, consultation hold, attended
transfer, etc.
How explained in all these documents hold is unidirectional in nature
so a UA that places the other party on hold will stop sending media.
The result is silence on the holded side until the transferred-to
answers the call or the holder resume that.
This is not ideal. An alternative is the use of a music on hold
source but it's not a mandatory component in a SIP environment.
4. New Implementation and Operations
When a UA receives a SIP message which places the call on hold and no
music on hold sources are available It MUST play an holding tone
locally in according to the regional phone line parameters.
When the place on hold state is modified (e.g. the call is resumed)
the UA MUST stop the holding tone.
4.1 Example of Holding process
In this example setup and tear down messages are omitted and It
assumes that the call is already established. Dashed lines (---)
represent control messages while double dashed lines (===) represent
media paths between network elements.
Giordano [Page 4]
Internet-Draft Call on hold for telephony applications of SIP protocol
Alice Proxy Bob
| | |
| Both way RTP Established |
|<=============================>|
| |INVITE(hold) |
|INVITE(hold) |<-------------|
|<---------------| |
| 200 OK | |
|--------------->| 200 OK |
| |------------->|
| | ACK |
| ACK |<-------------|
|<---------------| |
| | |
| No RTP Sent! |
| | |
---------------- | |
| play holding | | |
| tone | | |
---------------- | |
| | |
| | |
| | |
| | |
| | INVITE |
| INVITE |<-------------|
|<---------------| |
| 200 OK | |
|--------------->| 200 OK |
| |------------->|
| | ACK |
| ACK |<-------------|
|<---------------| |
| | |
---------------- | |
| stop holding | | |
| tone | | |
---------------- | |
| | |
| Both way RTP Established |
|<=============================>|
| | |
In this scenario, Alice and Bob are talking, then Bob places the
call on hold. No RTP packets are sent and no music on hold sources
are available. Alice's UA play the holding tone locally.
Giordano [Page 5]
Internet-Draft Call on hold for telephony applications of SIP protocol
5. Security Considerations
This document is not directly concerned with security.
6. IANA Considerations
None.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
7.2. Informative References
[RFC2543] M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg
"SIP: Session Initiation Protocol", RFC2543, March 1999.
[RFC3264] J. Rosenberg, H. Schulzrinne, "An Offer/Answer Model with
the Session Description Protocol (SDP)", RFC3264, June 2002.
[RFC3725] J. Rosenberg, J. Peterson, H. Schulzrinne, G. Camarillo
"Best Current Practices for Third Party Call Control (3pcc) in the
Session Initiation Protocol (SIP)", RFC3725, BCP85, April 2004.
[draft-ietf-sipping-sip-offeranswer] T. Sawada, P. Kyzivat, "SIP
(Session Initiation Protocol) Usage of the Offer/Answer Model",
October 2007.
[draft-ietf-sip-service-examples] A. Johnston, R. Sparks,
C. Cunningham, S. Donovan, K. Summers, "Session Initiation
Protocol Service Examples", July 2007.
Giordano [Page 6]
Internet-Draft Call on hold for telephony applications of SIP protocol
Author's Address
Giordano Daniele
Email: d.giordano@fastpiu.it
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein 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 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Giordano Expires 11 Feb 2009 [Page 7]