SIP WG C. Jennings
Internet-Draft Cisco Systems
Expires: April 17, 2004 October 18, 2003
SIP Conventions for Voicemail URIs
draft-jennings-sip-voicemail-uri-00
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 April 17, 2004.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
SIP systems are often used to initiate connections to voicemail or
unified messaging systems. This document describes a convention for
forming SIP Request URIs that request particular services from
unified messaging systems.
This work is being discussed on the sip@ietf.org mailing list.
Jennings Expires April 17, 2004 [Page 1]
Internet-Draft SIP Voicemail URI October 2003
Table of Contents
1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Mechanism (UAS and Proxy) . . . . . . . . . . . . . . . . . 4
3.1 Target . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2 Reason Parameter . . . . . . . . . . . . . . . . . . . . . . 5
3.3 Retrieving Messages . . . . . . . . . . . . . . . . . . . . 5
4. Interaction with Netann and App-Interaction . . . . . . . . 5
5. Interaction with History . . . . . . . . . . . . . . . . . . 5
6. Limitations of Voicemail URI . . . . . . . . . . . . . . . . 6
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1 Proxy Forward No Answer to Voicemail . . . . . . . . . . . . 6
7.2 Zero Configuration UM System . . . . . . . . . . . . . . . . 8
7.3 TDM Voice Mail Connected via a Gateway . . . . . . . . . . . 9
7.4 Call Coverage . . . . . . . . . . . . . . . . . . . . . . . 9
8. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9. PSTN Mapping . . . . . . . . . . . . . . . . . . . . . . . . 10
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 11
11. Security Considerations . . . . . . . . . . . . . . . . . . 11
11.1 Integrity Protection of Forwarding in SIP . . . . . . . . . 12
11.2 Privacy Related Issues on the Second Call Leg . . . . . . . 13
12. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 14
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
Normative References . . . . . . . . . . . . . . . . . . . . 14
Informative References . . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . 16
Jennings Expires April 17, 2004 [Page 2]
Internet-Draft SIP Voicemail URI October 2003
1. Conventions
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 RFC-2119 [1].
2. Introduction
Unified messaging systems (UM) have developed out of traditional
voice mail systems. They can be used for storing and interacting with
voice, video, faxes, email and instant messaging, and users often use
SIP to initiate communications with them. When a SIP call is routed
to a UM, there is a requirement for the UM to be able to figure out
several bits of information from the call so that it can deliver the
desired services. The UM needs to know what mailbox should be used
for the context of this call and possible reasons about what type of
service is desired. This includes knowing the type of media (voice or
IM for example). Many voice mail systems provide different greetings
depending whether the reason the call was sent to voicemail was that
the user was busy or because the user did not answer. All of this
information can be delivered in existing SIP signaling from the call
control that retargets the call to the UM, but there are no
standardized conventions for describing how the desired mailbox and
service requested are expressed. It would be possible for every
vendor to make this configurable so that any site can get it to work;
however, this is not a very realistic view of achieving
interoperability among call control, gateways, and unified messaging
systems from different vendors. These requirements and more are
described in the History Requirements [9]. This document describes a
convention for describing this mailbox and service information in the
SIP URI so that vendors and operators can build interoperable
systems. It meets some but not all of the requirements in [9].
The work in the draft-History Hisotry Info [10] draft can be used in
similar systems. It is more comprehensive and covers a much wider set
of requirements. A key difference between this work and the work that
uses UM systems, is that history allows the UM to look at the history
of the call and decided on what the best treatment is for the call.
This work requires the call control system to know something about
the history of the call and specifically ask the UM to invoke a
particular service.
If there were no need to interoperate with TDM based voice mail
systems or allow TDM systems to use VoIP unified messaging systems,
this problem would be a little easier. The problem that is introduced
in the VoIP to TDM case is as follows. The SIP system needs to tell a
GW to the PSTN both the subscribers' mailbox identifier (which
typically looks like a phone number) and the address of the voicemail
Jennings Expires April 17, 2004 [Page 3]
Internet-Draft SIP Voicemail URI October 2003
system in the TDM network (again a phone number).
One topic that causes some confusion in the requirements for this has
to do with the fact that the related PSTN mechanism can carry two
addresses. These correspond to the original target of the call and
the most recent target to redirect the call. In general, the original
target is used to find the voice mail box. The target that most
recently redirected is not as useful for voice mail but is very
useful for billing. It is often used to bill the most recent portion
of the call leg. This work addresses only the requirements for UM
system, and billing is completely out of scope. The History draft is
much more extensive and covers more cases that might be useful for
billing, but this work does not.
The question has been asked why the To header cannot be used to
understand which mailbox to use. One of the problems with this is
that the call control proxies cannot modify the To header, and the
UAC often set it incorrectly because they do not have information
about the subscribers in the domain they are trying to call. This
happens because the routing of the call often translates the URI
multiple times before it results in an identifier for the desired
user that is valid in the namespace that the UM system understands.
Another set of requirements that this mechanism can deal with is the
call coverage naming issues. The problem is when Bill calls the 800
number that sends him to the helpdesk, the proxy may first fork the
call to Alice (who works at the help desk), and then if Alice does
not answer in a few seconds fork the call on to Bob (who also works
at the helpdesk). Both Alice and Bob would like to be informed that
the call was to the help desk before they answer the call. If neither
answers, the call may get sent to the help desk's voice mailbox, not
Bob's or Alice's.
3. Mechanism (UAS and Proxy)
The mechanism works by encoding the information for the desired
service in the SIP URI that is sent to the UM system. Two chunks of
information are encoded, the first being the target mailbox to use
and the second being the SIP error code that caused this retarget and
indicates the desired service. The target mailbox can be put in the
userpart of the URI and is also put in a target URI parameter while
the reason is put in a URI parameter. For example, if the proxy
wished to use Alice's mailbox because her phone was busy, the URI
sent to the UM system could be something like:
sip:alice@um.example.com;target=alice;reason=486
Jennings Expires April 17, 2004 [Page 4]
Internet-Draft SIP Voicemail URI October 2003
3.1 Target
The target parameter indicates the mailbox to use. In many cases the
user portion of the SIP URI could be set to the same value but it
does not have to be. For example in the case of a voice mail system
on the PSTN, the user portion will contain the phone number of the
voice mail system while the target will contain the phone number of
the subscriber's mailbox.
3.2 Reason Parameter
A new URI parameter, reason, is defined to indicates the service that
the UAS receiving the message should perform. It is a number code and
corresponds to the SIP Status-Code that would result in the desired
service being requested. A mapping between some common services and
reason codes are:
+------------------------------+------------------+
| Service | Reason Parameter |
+------------------------------+------------------+
| Busy | 486 |
| No answer | 408 |
| Unconditional | 302 |
| Deflect | 487 |
| No Contacts/Failure of UA | 410 |
+------------------------------+------------------+
3.3 Retrieving Messages
The UM can use the fact that the From header is the same as the URI
target as a hint that the user wishes to retrieve messages. In
addition a reason code of 200 can also be used as a hint to retrieve
messages.
4. Interaction with Netann and App-Interaction
This approach is designed to interact well with the netann mechanism.
A netann parameter[8] can be used to indicate exactly which initial
prompt to play. In addition the App-Interaction work[11] can be used
to indicate a VXML script that the UM should use.
5. Interaction with History
The History mechanism[9] provides considerably more information that
is useful for a UM system. This work does not stop a UM system from
taking advantage of the History information and using that to handle
the call.
Jennings Expires April 17, 2004 [Page 5]
Internet-Draft SIP Voicemail URI October 2003
6. Limitations of Voicemail URI
This system requires the proxy that is requesting the service to
understand what are valid targets on the UM system. For practical
purposes this means that the approach is unlikely to work in many
cases where the proxy is not configured with information about the UM
system or if the proxy is not in the same administrative domain.
This system requires the call control proxy to know what it wants the
UM to do instead of giving the UM system the information about the
call that allows the UM system to decide what to do. For example, if
a call to the help desk got forwarded first to Alice, then to Bob,
then finally to the helpdesk UM system, the UM system may want to
leave a copy of the message in the primary help desk mail box and
also leave a copy in Alice's mailbox since she was the primary person
at the helpdesk. In addition the UM system might want to page both
Alice and Bob and their supervisor to let them know that no one is
manning the help desk. This system does not provide enough
information to the UM system about what happened to the call to meet
the needs of a scenario such as the one above.
This system only works when the service the call control wants
applied is fairly simple. For example it does not allow the proxy to
express information like "Do not offer to connect to the target's
colleague because that address was already tried".
Some systems have expressed requirements for the UAC to understand
when the call is re-targeted and get updated information about where
it was targeted too as the call proceeds. This work does not address
that - History does, as does the option of just sending a 1xx class
message with a Reason header[7].
The mechanism in this document does not address any billing issues
associated with forwarded calls. This is a separate problem.
These limitations are addressed by the History work.
7. Examples
7.1 Proxy Forward No Answer to Voicemail
In this example, Alice calls Bob. Bob's proxy runs a timer and
determines that Bob has not answered his phone, and the proxy
forwards the call to Bob's voicemail. Alice's phone is at 192.168.0.1
while Bob's phone is at 192.168.0.2. The important things is the URI
in message F4.
Jennings Expires April 17, 2004 [Page 6]
Internet-Draft SIP Voicemail URI October 2003
F1: INVITE 192.168.0.1 -> proxy.example.com
INVITE sip:15555551002@example.com;user=phone SIP/2.0
Via: SIP/2.0/TCP 192.168.0.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:5551001@example.com>;tag=9fxced76sl
To: sip:15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:x123456x@192.168.0.1;transport=tcp>
Content-Type: application/sdp
Content-Length: *Body length goes here*
* SDP goes here*
F2: INVITE proxy.example.com -> 192.168.0.2
INVITE sip:line1@192.168.0.2 SIP/2.0
Via: SIP/2.0/TCP 192.168.1.4:5060;branch=z9hG4bK-ik80k7g-1
Via: SIP/2.0/TCP 192.168.0.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:5551001@example.com>;tag=9fxced76sl
To: sip:15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:x123456x@192.168.0.1;transport=tcp>
Content-Type: application/sdp
Content-Length: *Body length goes here*
* SDP goes here*
F3: 486 192.168.0.2 -> proxy.example.com
SIP/2.0 486 Busy Here
Via: SIP/2.0/TCP 192.168.1.4:5060;branch=z9hG4bK-ik80k7g-1
Via: SIP/2.0/TCP 192.168.0.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:5551001@example.com>;tag=9fxced76sl
To: sip:15555551002@example.com;user=phone;tag=09xde23d80
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Contact: <sip:x654321x@192.168.0.2;transport=tcp>
Content-Length: 0
F4: INVITE proxy.example.com -> um.example.com
Jennings Expires April 17, 2004 [Page 7]
Internet-Draft SIP Voicemail URI October 2003
INVITE sip:bob@um.example.com;target=bob;reason=486 SIP/2.0
Via: SIP/2.0/TCP 192.168.1.4:5060;branch=z9hG4bK-ik80k7g-2
Via: SIP/2.0/TCP 192.168.0.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:5551001@example.com>;tag=9fxced76sl
To: sip:15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:x123456x@192.168.0.1;transport=tcp>
Content-Type: application/sdp
Content-Length: *Body length goes here*
* SDP goes here*
7.2 Zero Configuration UM System
In this example, the UM system has no configuration information
specific to any user. The proxy is configured to pass a URI that
provides the prompt to play and an email address in the user portion
of the URI to send the recorded message to.
The call flow is the same as in the previous example except that the
URI in F4 changes to specify the user part as Bob's email address,
and the netann URI play parameter specifies where the greeting to
play can be fetched.
F4: INVITE proxy.example.com -> um.example.com
INVITE
sip:bob@um.example.com;target=mailto:bob@example.com;reason=486;\
play=http://www.example.com/bob/busy.way
SIP/2.0
Via: SIP/2.0/TCP 192.168.1.4:5060;branch=z9hG4bK-ik80k7g-2
Via: SIP/2.0/TCP 192.168.0.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:5551001@example.com>;tag=9fxced76sl
To: sip:15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:x123456x@192.168.0.1;transport=tcp>
Content-Type: application/sdp
Content-Length: *Body length goes here*
* SDP goes here*
In addition, if the proxy wished to indicate a VXML script that the
Jennings Expires April 17, 2004 [Page 8]
Internet-Draft SIP Voicemail URI October 2003
UM should execute, it could add a parameter to the URI in the above
message that looked like
voicexml=http://www.example.com/bob/busy.vxml or add an header that
looked like
App-Info: "Voicemail"
<http://www.example.com/bob/busy.vxml>;id=app4323!um.example.com
7.3 TDM Voice Mail Connected via a Gateway
In this example, the voicemail system has a TDM interconnect to a
gateway to the VoIP system. Bob's mailbox is +1 555 555-1002 while
the address of the voicemail system on the TDM network is +1 555
555-2000.
The call flow is the same as in the previous example except for the
URI in F4.
F4: INVITE proxy.example.com -> gw.example.com
INVITE sip:+1-555-555-2000@um.example.com;user=phone;\
target=+1-555-555-1002;reason=486
SIP/2.0
Via: SIP/2.0/TCP 192.168.1.4:5060;branch=z9hG4bK-ik80k7g-2
Via: SIP/2.0/TCP 192.168.0.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:5551001@example.com>;tag=9fxced76sl
To: sip:15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:x123456x@192.168.0.1;transport=tcp>
Content-Type: application/sdp
Content-Length: *Body length goes here*
* SDP goes here*
7.4 Call Coverage
In this example a user on the PSTN calls a 800 number. The GW sends
this to the proxy which recognizes that the helpdesk is the target.
Alice and Bob are staffing the help desk and are tried sequentially
but neither answers so the call is forwarded to the helpdesk's voice
mail.
Jennings Expires April 17, 2004 [Page 9]
Internet-Draft SIP Voicemail URI October 2003
Still need to do this. Key item here is that the invite to Alice and
Bob looks like
sip:bob@um.example.com;target=helpdesk;reason=xxx
8. Syntax
This document updates the BNF in Section 25 of RFC 3261 [3] to add a
reason-param and target-param to the uri-parameter and define a
reason-param as shown below.
uri-parameter = transport-param / user-param /
method-param / ttl-param / maddr-param /
lr-param /
target-param/ reason-param/ other-param
reason-param = "reason=" Status-Code
target-param = "target=" pvalue
9. PSTN Mapping
The mapping to PSTN protocol is important both for gateways that
connect the IP network to existing TDM equipment, such as PBX's and
voice mail systems, and also when gateways connect the IP network to
the PSTN network. Both ISDN and ISUP have signaling for this
information that can be treated as roughly equivalent for the
purposes here.
The user portion of the URI SHOULD be used as the address of the
voice mail system on the PSTN, while the target SHOULD be mapped to
the original redirecting party on the PSTN side.
If the gateway and Proxy are in the sameRFC 3325 [5] Trust Domain and
the Spec(T) includes compliance with this document and the Spec(T)
asserts that the Proxy will do screening (whatever that means), then
the gateway MAY claim it is screened; otherwise it SHOULD NOT assert
that the diversion information is screened.
This draft says nothing about what to put into the redirecting
numbers, as that has billing implications outside the scope of this
work. The requirements here will work fine if the redirecting number
is not set on the PSTN side. It is not recommended that the GW decide
also to map the target information into the redirecting party
information, but doing so is not in violation of this document.
Jennings Expires April 17, 2004 [Page 10]
Internet-Draft SIP Voicemail URI October 2003
The following SHOULD be used as the mapping between reason parameters
and ISUP/ISDN redirect reason codes:
+-----------+----------------------------------------+--------------+
| ISUP or | PSTN Reason | SIP Reason |
| ISDN | | Parameter |
+-----------+----------------------------------------+--------------+
| 0000 | Unknown | 300 |
| 0001 | Call forwarding busy or called DTE | 486 |
| | busy | |
| 0010 | Call forwarding no reply | 408 |
| 1111 | Call forwarding unconditional or | 302 |
| | systematic call redirection | |
| 1010 | Call deflection or call forwarding by | 487 |
| | the called DTE | |
| 1001 | Call forwarding DTE out of order | 410 |
+-----------+----------------------------------------+--------------+
The redirection counters SHOULD be set to 1 unless additional
information is available.
10. IANA Considerations
This document adds two new values to the IANA registration in the
sub-registry at http://www.iana.org/assignments/sip-parameters as
defined in [6].
Parameter Name Reference
reason RFC XXXX
target RFC XXXX
Note to RFC Editor - replace XXXX with the RFC number of this
document.
11. Security Considerations
This draft inherently discusses transactions involving at least 3
parties. This makes the privacy issues somewhat more complex.
The new URI parameters defined in this draft are generally sent from
a Proxy or call control system to a unified messaging (UM) system or
gateway to the PSTN, and then to a voicemail system. This tells the
UM what service the proxy wishes to be performed. Just as any message
sent from the proxy to the UM needs to be integrity protected, these
need to be integrity protected. This stops attackers from doing
things like causing a voice mail meant for the CEO of the company to
go to an attacker's mailbox. RFC 3261 provides TLS and IPSEC
Jennings Expires April 17, 2004 [Page 11]
Internet-Draft SIP Voicemail URI October 2003
mechanisms suitable for protecting against this.
The signaling from the Proxy to the UM will reveal who is calling
whom and possibly some information about the presence of a user based
on whether a call got sent to voice mail instead of being answered.
This information can be protected by encrypting the SIP traffic
between the Proxy and UM. Again, RFC 3261 contains mechanisms for
accomplishing this using TLS and IPSEC.
The S/MIME based mechanisms in RFC 3261 will generally not be
applicable for protecting this information because they are meant for
end to end issues and this is primarily a middle to end scenario.
Ongoing work on middle to end [12] may allow S/MIME based schemes to
be used for protecting this information. These schemes would allow
the information to be hidden and integrity protected if there was
another administrative domain between the Proxy and UM. The current
scheme is based on hop by hop security and requires all hops between
the Proxy and UM to be trusted, which is the case in many deployment
scenarios.
11.1 Integrity Protection of Forwarding in SIP
Forwarding of a call in SIP brings up a very strange trust issue.
Consider the normal case of when A calls B, and then the call gets
forwarded by a network element in the domain of B to C, and then C
answers the call. A called B but ended up talking to C. This may be
hard to separate from some man in the middle attack.
There are two possible solutions for this. One is that B sends back
information to A saying don't call me, call C and signs it as B. The
problem with this is that it reveals the fact that B has forwarded to
C and often B does not want to do this. For example, B may be a work
phone that has been forwarded to a mobile or home phone. The user
does not want to reveal their mobile or home phone number but worse
yet does not want to even reveal that they are not in the office but
working from home.
The other possible solution for this is that A needs to trust B only
to forward to a trusted identity. This requires a hop by hop
transitive trust such that each hop will only send to a trusted next
hop and each hop will only do things that the user at that hop
desired. This solution is enforced in SIP using the SIP URI and TLS
based hop by hop security. It protects from an off axis attack but if
one of the hops is not trustworthy, the call may be subverted to a
connect to an attacker.
Any redirection of a call to an attacker's mailbox is a very serious
issue. It is trivial for the attacker to make the mailbox seem very
Jennings Expires April 17, 2004 [Page 12]
Internet-Draft SIP Voicemail URI October 2003
much like the real mailbox and forward the message to the real
mailbox so that the fact that the messages have been intercepted or
even tampered with is not detected.
11.2 Privacy Related Issues on the Second Call Leg
When A calls B and gets redirected to C, occasionally people say
there is a requirement for the call leg from B to C to be anonymous.
This is not the PSTN: there is no call leg from B to C; instead there
is a VoIP session between A and C. If A had put a To header
containing B in the initial invite message, unless something special
is done about it, C will see that To header. If the person who
answers phone C says "I think you dialed the wrong number, who were
you trying to reach?" A will probably specify B.
If A does not want C to see that the call was to B, A needs a special
relationship with the Proxy that does the forwarding so that it will
not reveal that information, and the call should go through an
anonymizer service that provides session or user level privacy (as
desccibed in RFC 3323 [4]) service before going to C. It's not hard
to figure out how to meet this requirement, but it is difficult to
figure out why anyone would want this service.
If B wants to make sure that C does not see that the call was to B,
it is easier but a bit weird. The usual argument is Bill wants to
forward his phone to Monica but does not want Monica to find out his
phone number. It is a little weird that Monica would want to accept
all Bill's calls without knowing how to call Bill to complain. The
only person Monica will be able to complain to is Hillary who tried
to call Bill. Clearly I'm somewhat dubious about the need for this,
but never mind: let's look at how it is solved. Several popular web
portals will send SMS alert message about things like stock prices
and weather to mobile phone users today. Some of these contain no
information about the account on the web portal that imitated them,
making it nearly impossible for the mobile phone owner to stop them.
This anonymous message forwarding has turned out to be a really bad
idea even where no malice was intended.
In the general case, the proxy needs to route the call through an
Anonymization Service and everything will be cleaned up. Any
Anonymization service that performs the "Privacy: Header" Service in
RFC 3323 [5] MUST remove the reason and target URI parameters from
the URI. RFC 3325 already makes it pretty clear you would need to
clean up this sort of information.
There is a specialized case of some interest where the mechanism in
this document is being used in conjunction with RFC 3325 and the UM
and the Proxy are both in the trust domain. It this limited case, the
Jennings Expires April 17, 2004 [Page 13]
Internet-Draft SIP Voicemail URI October 2003
problem that B does not want reveal their address to C can be solved
by ensuring that the target parameter URI should never be in a
message that is forwarded outside the trust domain. If it is passed
to a PSTN device in the trust domain, the appropriate privacy flag
needs to be set in the ISUP or ISDN signaling.
12. Open Issues
Parameters could be in the user portion of the host part. For most
things this is probably wrong. An argument could be made for the
target parameter.
How much do we need to define the hint that is used to indicate the
user is trying to retrieve messages?
Should we create new codes to go in the reason parameter or reuse the
SIP codes?
Should we use the Reason header instead of making a reason parameter?
This seems to overload the Reason header and may amount to trying to
put two semantically different bits of information into one header.
13. Acknowledgements
Mary Barnes, Dean Willis, and Steve Levy have spent significant time
with me helping me understand the requirements and pros and cons of
various approaches. I would like to thank them very much for this,
and since this is an acknowledgements section I would also like to
acknowledge Rohan's help with the various documents on this subject
and his encouragement to work on a solution that brings some
consensus to this topic
Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[3] 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.
[4] Peterson, J., "A Privacy Mechanism for the Session Initiation
Protocol (SIP)", RFC 3323, November 2002.
[5] Jennings, C., Peterson, J. and M. Watson, "Private Extensions to
Jennings Expires April 17, 2004 [Page 14]
Internet-Draft SIP Voicemail URI October 2003
the Session Initiation Protocol (SIP) for Asserted Identity
within Trusted Networks", RFC 3325, November 2002.
[6] Camarillo, G., "The Internet Assigned Number Authority Universal
Resource Identifier Parameter Registry for the Session
Initiation Protocol", draft-ietf-sip-uri-parameter-reg-00 (work
in progress), August 2003.
Informative References
[7] Schulzrinne, H., Oran, D. and G. Camarillo, "The Reason Header
Field for the Session Initiation Protocol (SIP)", RFC 3326,
December 2002.
[8] Burger, E., "Basic Network Media Services with SIP",
draft-burger-sipping-netann-07 (work in progress), September
2003.
[9] Barnes, M., "SIP Generic Request History Capability
Requirements", draft-ietf-sipping-req-history-04 (work in
progress), June 2003.
[10] Barnes, M., "An Extension to the Session Initiation Protocol
for Request History Information",
draft-ietf-sip-history-info-00 (work in progress), June 2003.
[11] Jennings, C., "SIP Support for Application Initiation",
draft-jennings-sip-app-info-01 (work in progress), July 2003.
[12] Ono, K. and S. Tachimoto, "End-to-middle security in the
Session Initiation Protocol(SIP)",
draft-ono-sipping-end2middle-security-00 (work in progress),
June 2003.
Author's Address
Cullen Jennings
Cisco Systems
170 West Tasman Drive
Mailstop SJC-21/3
San Jose, CA 95134
USA
Phone: +1 408 527-9132
EMail: fluffy@cisco.com
Jennings Expires April 17, 2004 [Page 15]
Internet-Draft SIP Voicemail URI October 2003
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Jennings Expires April 17, 2004 [Page 16]
Internet-Draft SIP Voicemail URI October 2003
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Jennings Expires April 17, 2004 [Page 17]