SIP D. Worley
Internet-Draft Nortel
Expires: March 1, 2009 August 28, 2008
Session Initiation Protocol Service Example -- Music on Hold
draft-worley-service-example-02
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.
This Internet-Draft will expire on March 1, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Worley Expires March 1, 2009 [Page 1]
Internet-Draft Music on Hold August 2008
Abstract
The "music on hold" feature is one of the most desired features of
telephone systems in the business environment. "Music on hold" is
where, when one party to a call has the call "on hold", that party's
telephone provides an audio stream (often music) to be heard by the
other party. Architectural features of SIP make it difficult to
implement music-on-hold in a way that is fully compliant with the
standards. The implementation of music-on-hold described in this
document is fully effective and standards-compliant, but is simpler
than the methods previously documented.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Technique . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Placing a Call on Hold and Providing an External Media
Stream . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Taking a Call off Hold and Terminating the External
Media Stream . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Example Message Flow . . . . . . . . . . . . . . . . . . . 6
2.4. Re-INVITE and UPDATE from the Remote UA . . . . . . . . . 14
2.5. INVITE with Replaces . . . . . . . . . . . . . . . . . . . 15
2.6. Re-INVITE and UPDATE from the Music-On-Hold Source . . . . 15
2.7. Payload Type Numbers . . . . . . . . . . . . . . . . . . . 15
3. Advantages . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4. Security Considerations . . . . . . . . . . . . . . . . . . . 18
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
6. Revision History . . . . . . . . . . . . . . . . . . . . . . . 20
6.1. Changes from draft-worley-service-example-00 to
draft-worley-service-example-01 . . . . . . . . . . . . . 20
6.2. Changes from draft-worley-service-example-01 to
draft-worley-service-example-02 . . . . . . . . . . . . . 20
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.1. Normative References . . . . . . . . . . . . . . . . . . . 21
7.2. Informative References . . . . . . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . . . 23
Worley Expires March 1, 2009 [Page 2]
Internet-Draft Music on Hold August 2008
1. Introduction
Within SIP[1]-based systems, it is desirable to be able to provide
features that are similar to those provided by traditional telephony
systems. A frequently requested feature is "music on hold": The
music-on-hold feature is where, when one party to a call has the call
"on hold", that party's telephone provides an audio stream (often
music) to be heard by the other party.
Architectural features of SIP make it difficult to implement music-
on-hold in a way that is fully compliant with the standards. The
purpose of this document is to describe a method that is reasonably
simple yet fully effective and standards-compliant.
Worley Expires March 1, 2009 [Page 3]
Internet-Draft Music on Hold August 2008
2. Technique
The essence of the technique is that when the executing UA (the
user's UA) performs a re-INVITE of the remote UA to establish the
hold state, it provides no SDP[3] offer[2][11], thus compelling the
remote UA to provide an SDP offer. The executing UA then extracts
the offer SDP from the remote UA's 2xx response, and uses that as the
offer SDP in a new INVITE to the external media source. The external
media source is thus directed to provide media directly to the remote
UA. The media source's answer SDP is returned to the remote UA in
the ACK to the re-INVITE.
2.1. Placing a Call on Hold and Providing an External Media Stream
1. The executing user instructs the executing UA to put the dialog
on-hold.
2. The executing UA sends a re-INVITE without SDP to the remote UA,
which forces the remote UA to provide an SDP offer in its 2xx
response. The Contact header of the re-INVITE includes the
'+sip.rendering="no"' field parameter to indicate that it is
putting the call on hold.[6]
3. The remote UA sends a 2xx to the re-INVITE, and includes an SDP
offer giving its own listening address/port. If the remote UA
understands the sip.rendering feature parameter, the offer may
indicate that it will not send media by specifying the media
directionalities as "recvonly" (the reverse of "on-hold") or
perhaps "inactive". But the remote UA may offer to send media.
4. The executing UA uses this offer to derive the offer SDP of an
initial INVITE that it sends to the configured music-on-hold
(MOH) source. The SDP in this request is largely copied from the
SDP returned by the remote UA in the previous step, particularly
regarding the provided listening address/port and payload type
numbers. But the media directionalities are restricted to
"recvonly" or "inactive" as appropriate. The executing UA may
want or need to change the o= line. In addition, some a=rtpmap
lines may need to be added to control the assignment of RTP
payload type numbers.[Section 2.7]
5. The MOH source sends a 2xx response to the INVITE, which contains
an SDP answer that should include its media source address as its
listening address/port. This SDP must necessarily[2] specify
"sendonly" or "inactive" as the directionality for all media
streams. (Although this address/port should receive no RTP, by
convention UAs use their declared RTP listening ports as their
RTP source ports as well. The answer SDP will reach the remote
Worley Expires March 1, 2009 [Page 4]
Internet-Draft Music on Hold August 2008
UA, thus informing it of the address/port from which the MOH
media will come, and presumably preventing the remote UA from
ignoring the MOH media as SPIT. This functionality requires the
SDP answer to contain the sending address/port in the c= line,
even though the MOH source does not receive RTP.)
6. The executing UA sends this SDP answer as its SDP answer in the
ACK for the re-INVITE to the remote UA. The o= line in the
answer must be modified to be within the sequence of o= lines
previously generated by the executing UA in the dialog. Any
dynamic payload type number assignments that have been created in
the answer must be recorded in the state of the original dialog.
7. Due to the sip.rendering feature parameter in the Contact of the
re-INVITE and the media directionality in the SDP answer
contained in the ACK, the on-hold state of the dialog is
established (at the executing end).
8. After this point, the MOH source generates RTP containing the
music-on-hold media, and sends it directly to the listening
address/port of the remote UA. The executing UA maintains two
dialogs (one to the remote UA, one to the MOH source), but does
not see or handle the MOH RTP.
2.2. Taking a Call off Hold and Terminating the External Media Stream
1. The executing user instructs the executing UA to take the dialog
off-hold.
2. The executing UA sends a re-INVITE to the remote UA with SDP that
requests to receive media. The Contact header of the re-INVITE
does not include the '+sip.rendering="no"' field parameter. (It
may contain a sip.rendering field parameter with value "yes" or
"unknown", or it may omit the field parameter.) Thus this INVITE
removes the on-hold state of the dialog (at the executing end).
(Note that the version in o= line of the offered SDP must account
for the SDP versions that were passed through from the MOH
source, and that any payload type numbers that were assigned in
SDP provided by the MOH source must be respected.)
3. When the remote UA sends a 2xx response to the re-INVITE, the
executing UA sends a BYE request in the dialog to the MOH source.
4. After this point, the MOH source does not generate RTP and
ordinary RTP flow is re-established in the original dialog.
Worley Expires March 1, 2009 [Page 5]
Internet-Draft Music on Hold August 2008
2.3. Example Message Flow
This section shows a message flow which is an example of this
technique. The scenario is: Alice establishes a call with Bob. Bob
then places the call on hold, with music-on-hold provided from an
external source. Bob then takes the call off hold.
Note that this is just one possible message flow that illustrates
this technique; numerous variations on these operations are allowed
by the applicable standards.
Alice Bob Music Source
Alice establishes the call:
| | |
| INVITE F1 | |
|--------------->| |
| 180 Ringing F2 | |
|<---------------| |
| 200 OK F3 | |
|<---------------| |
| ACK F4 | |
|--------------->| |
| RTP | |
|<==============>| |
| | |
Bob places Alice on hold, compelling Alice's UA to provide SDP:
| | |
| INVITE F5 | |
| (no SDP) | |
|<---------------| |
| 200 OK F6 | |
| (SDP offer) | |
|--------------->| |
| | |
Bob's UA initiates music-on-hold:
| | |
| | INVITE F7 |
| | (SDP offer, |
| | rev. hold) |
| |------------->|
| | 200 OK F8 |
| | (SDP answer, |
Worley Expires March 1, 2009 [Page 6]
Internet-Draft Music on Hold August 2008
| | hold) |
| |<-------------|
| | ACK F9 |
| |------------->|
| | |
Bob's UA provides an SDP answer containing the address/port
of the Music Source:
| | |
| ACK F10 | |
| (SDP answer, | |
| hold | |
|<---------------| |
| no RTP | |
| | |
| Music-on-hold RTP |
|<==============================|
| | |
The music on hold is active.
Bob takes Alice off hold:
| | |
| INVITE F11 | |
| (SDP offer) | |
|<---------------| |
| 200 OK F12 | |
| (SDP answer) | |
|--------------->| |
| ACK F13 | |
|<---------------| |
| | BYE F14 |
| |------------->|
| | 200 F15 |
| |<-------------|
| RTP | |
|<==============>| |
| | |
The normal media session between Alice and Bob is resumed.
Message Details
/* Alice calls Bob. */
F1 INVITE Alice -> Bob
Worley Expires March 1, 2009 [Page 7]
Internet-Draft Music on Hold August 2008
INVITE sips:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/TLS atlanta.example.com:5061
;branch=z9hG4bK74bf9
Max-Forwards: 70
From: Alice <sips:alice@atlanta.example.com>;tag=1234567
To: Bob <sips:bob@biloxi.example.com>
Call-ID: 12345600@atlanta.example.com
CSeq: 1 INVITE
Contact: <sips:a8342043f@atlanta.example.com;gr>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, gruu
Content-Type: application/sdp
Content-Length: [omitted]
v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s=
c=IN IP4 atlanta.example.com
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
F2 180 Ringing Bob -> Alice
SIP/2.0 180 Ringing
Via: SIP/2.0/TLS atlanta.example.com:5061
;branch=z9hG4bK74bf9
;received=192.0.2.103
From: Alice <sips:alice@atlanta.example.com>;tag=1234567
To: Bob <sips:bob@biloxi.example.com>;tag=23431
Call-ID: 12345600@atlanta.example.com
CSeq: 1 INVITE
Contact: <sips:bob@biloxi.example.com>
Content-Length: 0
F3 200 OK Bob -> Alice
SIP/2.0 200 OK
Via: SIP/2.0/TLS atlanta.example.com:5061
;branch=z9hG4bK74bf9
;received=192.0.2.103
From: Alice <sips:alice@atlanta.example.com>;tag=1234567
To: Bob <sips:bob@biloxi.example.com>;tag=23431
Call-ID: 12345600@atlanta.example.com
CSeq: 1 INVITE
Contact: <sips:bob@biloxi.example.com>
Worley Expires March 1, 2009 [Page 8]
Internet-Draft Music on Hold August 2008
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Content-Type: application/sdp
Content-Length: [omitted]
v=0
o=bob 2890844527 2890844527 IN IP4 biloxi.example.com
s=
c=IN IP4 biloxi.example.com
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
F4 ACK Alice -> Bob
ACK sips:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/TLS atlanta.example.com:5061
;branch=z9hG4bK74bfd
Max-Forwards: 70
From: Alice <sips:alice@atlanta.example.com>;tag=1234567
To: Bob <sips:bob@biloxi.example.com>;tag=23431
Call-ID: 12345600@atlanta.example.com
CSeq: 1 ACK
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Content-Length: 0
/* Bob places Alice on hold. */
/* The re-INVITE contains no SDP, thus compelling Alice's UA
to provide an offer. */
F5 INVITE Bob -> Alice
INVITE sips:a8342043f@atlanta.example.com;gr SIP/2.0
Via: SIP/2.0/TLS biloxi.example.com:5061
;branch=z9hG4bK874bk
To: Alice <sips:alice@atlanta.example.com>;tag=1234567
From: Bob <sips:bob@biloxi.example.com>;tag=23431
Call-ID: 12345600@atlanta.example.com
CSeq: 712 INVITE
Contact: <sips:bob@biloxi.example.com>;+sip.rendering="no"
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Content-Length: 0
Worley Expires March 1, 2009 [Page 9]
Internet-Draft Music on Hold August 2008
/* Alice's UA provides an SDP offer.
Since it does not know that it is being put on hold,
the offer is the same as the original offer and describes
bidirectional media. */
F6 200 OK Alice -> Bob
SIP/2.0 200 OK
Via: SIP/2.0/TLS biloxi.example.com:5061
;branch=z9hG4bK874bk
;received=192.0.2.105
To: Alice <sips:alice@atlanta.example.com>;tag=1234567
From: Bob <sips:bob@biloxi.example.com>;tag=23431
Call-ID: 12345600@atlanta.example.com
CSeq: 712 INVITE
Contact: <sips:a8342043f@atlanta.example.com;gr>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, gruu
Content-Type: application/sdp
Content-Length: [omitted]
v=0
o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
s=
c=IN IP4 atlanta.example.com
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=active
/* Bob's UA initiates music-on-hold. */
/* This INVITE contains Alice's offer, but with the media
direction set to "reverse hold", receive-only. */
F7 INVITE Bob -> Music Source
INVITE sips:music@source.example.com SIP/2.0
Via: SIP/2.0/TLS biloxi.example.com:5061
;branch=z9hG4bKnashds9
Max-Forwards: 70
From: Bob <sips:bob@biloxi.example.com>;tag=02134
To: Music Source <sips:music@source.example.com>
Call-ID: 4802029847@biloxi.example.com
CSeq: 1 INVITE
Contact: <sips:bob@biloxi.example.com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Worley Expires March 1, 2009 [Page 10]
Internet-Draft Music on Hold August 2008
Supported: replaces, gruu
Content-Type: application/sdp
Content-Length: [omitted]
v=0
o=bob 2890844534 2890844534 IN IP4 atlanta.example.com
s=
c=IN IP4 atlanta.example.com
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=recvonly
F8 200 OK Music Source -> Bob
SIP/2.0 200 OK
Via: SIP/2.0/TLS biloxi.example.com:5061
;branch=z9hG4bKnashds9
;received=192.0.2.105
From: Bob <sips:bob@biloxi.example.com>;tag=02134
To: Music Source <sips:music@source.example.com>;tag=56323
Call-ID: 4802029847@biloxi.example.com
Contact: <sips:music@source.example.com>
CSeq: 1 INVITE
Content-Length: [omitted]
v=0
o=MusicSource 2890844576 2890844576 IN IP4 source.example.com
s=
c=IN IP4 source.example.com
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=sendonly
F9 ACK Bob -> Music Source
ACK sips:music@source.example.com SIP/2.0
Via: SIP/2.0/TLS source.example.com:5061
;branch=z9hG4bK74bT6
From: Bob <sips:bob@biloxi.example.com>;tag=02134
To: Music Source <sips:music@source.example.com>;tag=56323
Max-Forwards: 70
Call-ID: 4802029847@biloxi.example.com
CSeq: 1 ACK
Content-Length: 0
Worley Expires March 1, 2009 [Page 11]
Internet-Draft Music on Hold August 2008
/* Bob's UA now sends the ACK that completes the re-INVITE
to Alice and completes the SDP offer/answer.
The ACK contains the SDP received from the Music Source,
and thus contains the address/port from which the Music Source
will send media. */
F10 ACK Bob -> Alice
ACK sips:a8342043f@atlanta.example.com;gr SIP/2.0
Via: SIP/2.0/TLS biloxi.example.com:5061
;branch=z9hG4bKq874b
To: Alice <sips:alice@atlanta.example.com>;tag=1234567
From: Bob <sips:bob@biloxi.example.com>;tag=23431
Call-ID: 12345600@atlanta.example.com
CSeq: 712 ACK
Contact: <sips:bob@biloxi.example.com>;+sip.rendering="no"
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Content-Length: [omitted]
v=0
o=bob 2890844527 2890844528 IN IP4 biloxi.example.com
s=
c=IN IP4 source.example.com
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=sendonly
/* Bob picks up the call by sending a re-INVITE to Alice. */
F11 INVITE Bob -> Alice
INVITE sips:a8342043f@atlanta.example.com;gr SIP/2.0
Via: SIP/2.0/TLS biloxi.example.com:5061
;branch=z9hG4bK874bk
To: Alice <sips:alice@atlanta.example.com>;tag=1234567
From: Bob <sips:bob@biloxi.example.com>;tag=23431
Call-ID: 12345600@atlanta.example.com
CSeq: 713 INVITE
Contact: <sips:bob@biloxi.example.com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Content-Type: application/sdp
Content-Length: [omitted]
v=0
o=bob 2890844527 2890844529 IN IP4 biloxi.example.com
Worley Expires March 1, 2009 [Page 12]
Internet-Draft Music on Hold August 2008
s=
c=IN IP4 biloxi.example.com
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
F12 200 OK Alice -> Bob
SIP/2.0 200 OK
Via: SIP/2.0/TLS biloxi.example.com:5061
;branch=z9hG4bK874bk
;received=192.0.2.105
To: Alice <sips:alice@atlanta.example.com>;tag=1234567
From: Bob <sips:bob@biloxi.example.com>;tag=23431
Call-ID: 12345600@atlanta.example.com
CSeq: 713 INVITE
Contact: <sips:a8342043f@atlanta.example.com;gr>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, gruu
Content-Type: application/sdp
Content-Length: [omitted]
v=0
o=alice 2890844526 2890844527 IN IP4 atlanta.example.com
s=
c=IN IP4 atlanta.example.com
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
F13 ACK Bob -> Alice
ACK sips:a8342043f@atlanta.example.com;gr SIP/2.0
Via: SIP/2.0/TLS biloxi.example.com:5061
;branch=z9hG4bKq874b
To: Alice <sips:alice@atlanta.example.com>;tag=1234567
From: Bob <sips:bob@biloxi.example.com>;tag=23431
Call-ID: 12345600@atlanta.example.com
CSeq: 713 ACK
Contact: <sips:bob@biloxi.example.com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Content-Length: 0
F14 BYE Bob -> Music Source
Worley Expires March 1, 2009 [Page 13]
Internet-Draft Music on Hold August 2008
BYE sips:music@source.example.com SIP/2.0
Via: SIP/2.0/TLS biloxi.example.com:5061
;branch=z9hG4bK74rf
Max-Forwards: 70
From: Bob <sips:bob@biloxi.example.com>;tag=02134
To: Music Source <sips:music@source.example.com>;tag=56323
Call-ID: 4802029847@biloxi.example.com
CSeq: 2 BYE
Contact: <sips:bob@biloxi.example.com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, gruu
Content-Length: [omitted]
F15 200 OK Music Source -> Alice
SIP/2.0 200 OK
Via: SIP/2.0/TLS atlanta.example.com:5061
;branch=z9hG4bK74rf
;received=192.0.2.103
From: Bob <sips:bob@biloxi.example.com>;tag=02134
To: Music Source <sips:music@source.example.com>;tag=56323
Call-ID: 4802029847@biloxi.example.com
CSeq: 2 BYE
Content-Length: 0
/* Normal media session between Alice and Bob is resumed */
2.4. Re-INVITE and UPDATE from the Remote UA
While the call is on-hold, the remote UA can send a request to modify
the SDP or the feature parameters of its Contact header. This can be
done with either an INVITE or UPDATE method, both of which have much
the same effect in regard to MOH.
A common reason for a re-INVITE will be when the remote UA desires to
put the dialog on hold on its end. And because of the need to
support this case, an implementation must process INVITEs and UPDATEs
during the on-hold state as described below.
The executing UA handles these requests by echoing requests and
responses: an incoming request from the remote UA causes the
executing UA to send a similar request to the MOH source and an
incoming response from the MOH source causes the executing UA to send
a similar response to the remote UA. In all cases, SDP offers or
answers that are received are added as bodies to the stimulated
request or response to the other UA.
Worley Expires March 1, 2009 [Page 14]
Internet-Draft Music on Hold August 2008
The passed-through SDP will usually need its o= line modified. The
directionality attributes may need to be restricted. In regard to
payload type numbers, since the mapping has already been established
within the MOH dialog, a=rtpmap lines need not be added.
2.5. INVITE with Replaces
The executing UA must be prepared to receive INVITE requests with a
Replaces headers that replaces the original dialog, and similarly it
must be prepared to receive REFER requests within the dialog. The
SDP within the new dialog is negotiated by being passed through to
the MOH source within a new dialog with the MOH source. The SDP
offer or answer can be passed to the MOH source with only
modification to the o= line and directionality attributes.
In some cases, the previous dialog with the MOH source can be reused,
but only if the executing UA presents the first offer within the new
dialog, as otherwise there is no way to force the RTP payload types
that have been used previously in the MOH dialog to be mapped to the
correct codecs in the new dialog.
2.6. Re-INVITE and UPDATE from the Music-On-Hold Source
It is possible for the MOH source to send an INVITE or UPDATE
request, and the executing UA can support doing so in similar manner
as requests from the remote UA. However, if the MOH source is within
the same administrative domain as the executing UA, the executing UA
may have knowledge that the MOH source will not (or need not) make
such requests, and so can respond to any such request with a failure
response, avoiding the need to pass the request through.
However, in an environment in which ICE[8] is supported, the MOH
source may need to send requests as part of ICE negotiation[9] with
the remote UA. Hence, in environments that support ICE, the
executing UA must be able to pass through requests from the MOH
source as well as requests from the remote UA.
Again, as SDP is passed through, its o= line will need to be
modified. In some cases, the directionality attributes will need to
be restricted.
2.7. Payload Type Numbers
In this technique, the MOH source generates an SDP answer that the
executing UA presents to the remote UA as an answer within the
original dialog. In basic functionality, this presents no problem,
because [2] (section 6.1, at the very end) specifies that the payload
type numbers used in either direction of RTP are the ones specified
Worley Expires March 1, 2009 [Page 15]
Internet-Draft Music on Hold August 2008
in the SDP sent by the recipient of the RTP, which in this case is
the remote UA, which composed the offer.
But strict compliance to [2] (section 8.3.2) requires that payload
type numbers used in the SDP answer may duplicate the payload type
numbers used in any offers and answers previously used in the dialog
only if the payload type numbers represent the same media format
(codec) as they did previously. However, the MOH source has no
knowledge of the payload type numbers previously used in the original
dialog, and it may accidentally specify a media format for a
previously used payload type number in its answer (or in a
subsequently generated INVITE or UPDATE). This would cause no
problem with media decoding, as it cannot send any format that was
not in the remote UA's offer, but it would violate [2].
We can prevent this problem by utilizing the requirement itself to
control the behavior of the MOH source: When the executing UA is
composing the INVITE to the MOH source, it compiles a list of all the
(dynamically-assigned) payload type numbers which have been used in
the original dialog but which are not mapped to a media format in the
offer SDP. (The executing UA must be maintaining a list of all
previously used payload type numbers anyway, in order to comply with
[2].) Then, for each of these payload type numbers, it inserts
session-level or media-level (as appropriate) a=rtpmap lines
specifying the payload type number and the media format that it has
been used for. Because of the reuse rule, the MOH source cannot
propose those payload type numbers for any other media format.
However, once the payload type numbers have been defined within the
MOH dialog, the executing UA need not insert additional a=rtpmap
lines in later SDP that is passed through.
Worley Expires March 1, 2009 [Page 16]
Internet-Draft Music on Hold August 2008
3. Advantages
This technique for providing music-on-hold has advantages over other
methods now in use:
1. The original dialog is not transferred to another UA, so the
"remote endpoint URI" displayed by the remote endpoint's user
interface and dialog event package[6] does not change during the
call.[4]
2. The music-on-hold media are sent directly from the music-on-hold
source to the remote UA, rather than being relayed through the
executing UA.
3. The remote UA sees, in the incoming SDP, the address/port that
the MOH source will send MOH media from, thus allowing it to
render the media, even if it is filtering incoming media based on
originating address as a SPIT preventative.
4. The technique requires relatively simple manipulation of SDP, and
in particular: (1) does not require a SIP agent to modify
unrelated SDP to be acceptable to be sent within an already
established sequence of SDP (a problem with [5]), and (2) does
not require converting an SDP answer into an SDP offer (which was
a problem with the -00 version of this document, as well as with
[5]).
5. It strictly complies with the payload type number rules.[2]
Worley Expires March 1, 2009 [Page 17]
Internet-Draft Music on Hold August 2008
4. Security Considerations
Some UAs filter incoming media based on the address of origin in
order to avoid SPIT. The technique described in this document
ensures that any UA that should render MOH media will be informed of
the source address of the media via the SDP that it receives. This
should allow such UAs to filter without interfering with MOH
operation.
Worley Expires March 1, 2009 [Page 18]
Internet-Draft Music on Hold August 2008
5. Acknowledgments
The original version of this proposal was derived from [5] and the
similar implementation of MOH in the Snom UA. Significant
improvements to the sequence of operations, allowing improvements to
the SDP handling, were suggested by Venkatesh[7].
John Elwell[9] pointed out the need for the executing UA to pass
through re-INVITEs/UPDATEs in order to allow ICE negotiation.
Paul Kyzivat[10] pointed out the difficulties regarding re-use of
payload type numbers.
Worley Expires March 1, 2009 [Page 19]
Internet-Draft Music on Hold August 2008
6. Revision History
6.1. Changes from draft-worley-service-example-00 to
draft-worley-service-example-01
Removed the original "Example Message Flow" and promoted the
"Alternative Example Message Flow" to replace it because of a number
of flaws that were described in the discussion of -00 on the SIPPING
mailing list.
Described the use of the sip.rendering feature parameter to indicate
on-hold status.
6.2. Changes from draft-worley-service-example-01 to
draft-worley-service-example-02
Added discussion of passing though re-INVITEs and UPDATEs.
Added discussion of payload type numbers.
Added Acknowledgments section.
Worley Expires March 1, 2009 [Page 20]
Internet-Draft Music on Hold August 2008
7. References
7.1. Normative References
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[2] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
the Session Description Protocol (SDP)", RFC 3264, June 2002.
[3] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
7.2. Informative References
[4] Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and K.
Summers, "Session Initiation Protocol Service Examples",
I-D draft-ietf-sipping-service-examples-13, July 2007.
[5] Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and K.
Summers, "Session Initiation Protocol Service Examples",
I-D draft-ietf-sipping-service-examples-11, October 2006.
[6] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE-
Initiated Dialog Event Package for the Session Initiation
Protocol (SIP)", RFC 4235, November 2005.
[7] Venkatesh, "Subject: Re: [Sipping] I-D
ACTION:draft-ietf-sipping-service-examples-11.txt", IETF
Sipping mailing list msg12180, October 2006.
[8] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A
Protocol for Network Address Translator (NAT) Traversal for
Offer/Answer Protocols", I-D draft-ietf-mmusic-ice-19,
October 2007.
[9] Elwell, J., "Subject: [Sipping] RE: I-D
Action:draft-worley-service-example-00.txt", IETF Sipping
mailing list msg14678, November 2007.
[10] Kyzivat, P., "Subject: Re: [Sipping] I-D
ACTION:draft-ietf-sipping-service-examples-11.txt", IETF
Sipping mailing list msg12181, October 2006.
[11] Sawada, T. and P. Kyzivat, "SIP (Session Initiation Protocol)
Usage of the Offer/Answer Model",
I-D draft-ietf-sipping-sip-offeranswer-04, October 2007.
Worley Expires March 1, 2009 [Page 21]
Internet-Draft Music on Hold August 2008
Author's Address
Dale R. Worley
Nortel Networks Corp.
600 Technology Park Dr.
Billerica, MA 01821
US
Email: dworley@nortel.com
URI: http://www.nortel.com
Worley Expires March 1, 2009 [Page 22]
Internet-Draft Music on Hold August 2008
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).
Worley Expires March 1, 2009 [Page 23]