Network Working Group C. Jennings
Internet-Draft Cisco Systems
Expires: January 12, 2006 July 11, 2005
Conventions for Voicemail URIs in SIP
draft-jennings-sip-voicemail-uri-04
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 January 12, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
The SIP protocol is often used to initiate connections to voicemail
or unified messaging systems. This specification describes a
convention for forming SIP Service URIs that request particular
services from unified messaging systems.
Jennings Expires January 12, 2006 [Page 1]
Internet-Draft SIP Voicemail URI July 2005
Table of Contents
1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Mechanism (UAS and Proxy) . . . . . . . . . . . . . . . . . 4
3.1 Target . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2 Cause . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3 Retrieving Messages . . . . . . . . . . . . . . . . . . . 5
4. Interaction with History . . . . . . . . . . . . . . . . . . 5
5. Limitations of Voicemail URI . . . . . . . . . . . . . . . . 5
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1 Proxy Forwards No Answer to Voicemail . . . . . . . . . . 6
6.2 Zero Configuration UM System . . . . . . . . . . . . . . . 8
6.3 TDM Voice Mail Connected via a Gateway . . . . . . . . . . 9
6.4 Call Coverage . . . . . . . . . . . . . . . . . . . . . . 9
7. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8. PSTN Mapping . . . . . . . . . . . . . . . . . . . . . . . . 10
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 11
10. Security Considerations . . . . . . . . . . . . . . . . . . 11
10.1 Integrity Protection of Forwarding in SIP . . . . . . . 12
10.2 Privacy Related Issues on the Second Call Leg . . . . . 13
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 14
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
12.1 Normative References . . . . . . . . . . . . . . . . . . 14
12.2 Informative References . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . 16
Jennings Expires January 12, 2006 [Page 2]
Internet-Draft SIP Voicemail URI July 2005
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. Users often
use SIP to initiate communications with them. When a SIP call is
routed to a UM, it is necessary that the UM be able to obtain 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 and
possible reasons for the type of service desired from the UM. This
includes knowing the type of media (voice or IM, for example). Many
voice mail systems provide different greetings depending whether the
call went to voicemail because 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
could get it to work; however, this approach is unrealistic for
achieving interoperability among call control, gateways, and unified
messaging systems from different vendors. This specification
describes a convention for describing this mailbox and service
information in the SIP URI so that vendors and operators can build
interoperable systems.
The work in the History Info [9] draft can be used in similar
systems. It is more comprehensive and covers a much wider set of
requirements. A key difference from this system is that History
allows the UM to look at the history of the call and decide on the
best treatment 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 voicemail
systems or to 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 PSTN GW both the subscriber's mailbox identifier
(which typically looks like a phone number) and the address of the
voicemail system in the TDM network (again a phone number).
One topic that causes some confusion in the requirements has to do
Jennings Expires January 12, 2006 [Page 3]
Internet-Draft SIP Voicemail URI July 2005
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 which it has been redirected. In general,
the original target is used to find the voice mail box. The target
that most recently redirected is not as useful for voicemail 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 a 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
specify which mailbox to use. One problem is that the call control
proxies cannot modify the To header, and the UACs 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. 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 has been
sent 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 retargeting
and indicates the desired service. The target mailbox can be put in
the user part of the URI and is also put in a target URI parameter,
while the reason is put in the URI cause 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;cause=486
3.1 Target
The target parameter indicates the mailbox to use. In many cases the
Jennings Expires January 12, 2006 [Page 4]
Internet-Draft SIP Voicemail URI July 2005
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 Cause
The URI cause parameter is used to indicate the service that the UAS
receiving the message should perform. It corresponds to the SIP
Status-Code that results in the desired service being requested. A
mapping between some common services and reason codes are:
+------------------------------+-----------------+
| Service | Cause Parameter |
+------------------------------+-----------------+
| Busy | 486 |
| No answer | 408 |
| Unconditional | 302 |
| Deflect | 487 |
| No Contacts/Failure of UA | 410 |
+------------------------------+-----------------+
3.3 Retrieving Messages
The UM system MAY use the fact that the From header is the same as
the URI target as a hint that the user wishes to retrieve messages.
4. 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 if it is present and
using that to handle the call. It is reasonable to have systems in
which both the information in this specification and the History
information are included and one or both are used.
5. 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 in which the proxy is not configured with information about the
UM system or 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 information about the call
Jennings Expires January 12, 2006 [Page 5]
Internet-Draft SIP Voicemail URI July 2005
that allows it to decide what to do. For example, if a call to the
help desk got forwarded first to Alice, then to Bob, and then finally
to the helpdesk UM system, the UM system might want to leave a copy
of the message in the primary help desk mailbox 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 Alice, Bob, and their
supervisor to let them know that no one is staffing 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 such a scenario.
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 has already been tried".
Some systems have expressed the requirement that the UAC understand
when the call is re-targeted and get updated information about where
it was targeted to as the call proceeds. This work does not address
this requirement - History does, as does the option of just sending a
1xx class message with a Reason header[7].
The mechanism in this specification do not address any billing issues
associated with forwarded calls. This is a separate problem.
The limitations discussed in this section are addressed by the
History[9] work.
6. Examples
6.1 Proxy Forwards 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 to note is the URI in message F4.
Jennings Expires January 12, 2006 [Page 6]
Internet-Draft SIP Voicemail URI July 2005
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
Jennings Expires January 12, 2006 [Page 7]
Internet-Draft SIP Voicemail URI July 2005
F4: INVITE proxy.example.com -> um.example.com
INVITE sip:bob@um.example.com;target=bob;cause=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*
6.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 which the recorded message is to be sent.
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 [8] URI play parameter specifies where the greeting to
play can be fetched from.
F4: INVITE proxy.example.com -> um.example.com
INVITE
sip:bob@um.example.com;target=mailto:bob%40example.com;cause=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*
Jennings Expires January 12, 2006 [Page 8]
Internet-Draft SIP Voicemail URI July 2005
In addition, if the proxy wished to indicate a VXML script that the
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
6.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=tel:+1-555-555-1002;cause=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*
6.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.
The key item in this flow is that the invite to Alice and Bob looks
like
Jennings Expires January 12, 2006 [Page 9]
Internet-Draft SIP Voicemail URI July 2005
INVITE sip:bob@um.example.com;target=helpdesk;cause=302 SIP/2.0
7. Syntax
This specification updates the ABNF in Section 25 of RFC 3261 [3] to
add the target-param to the uri-parameter as shown below.
uri-parameter = transport-param / user-param /
method-param / ttl-param / maddr-param /
lr-param / other-param /
target-param / cause-param
target-param = "target" EQUAL pvalue
cause-param = "cause" EQUAL Status-Code
It is worth noting that the ABNF requires some characters to be
escaped if they occur in the value of the target parameters. For
example, the "@" character needs to be escaped.
8. PSTN Mapping
The mapping to the PSTN protocols is important both for gateways that
connect the IP network to existing TDM equipment, such as PBXs and
voicemail systems, and for gateways that 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
voicemail 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 same Trust Domain (defined in RFC
3325 [5]), and the Spec(T) includes compliance with this
specification, 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 map
the target information into the redirecting party information, but
doing so is not in violation of this specification.
Jennings Expires January 12, 2006 [Page 10]
Internet-Draft SIP Voicemail URI July 2005
The following SHOULD be used as the mapping between reason parameters
and ISUP/ISDN redirect reason codes:
+-----------+----------------------------------------+--------------+
| ISUP or | PSTN Reason | URI Cause |
| 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 one unless additional
information is available.
9. IANA Considerations
This specification adds a new value to the IANA registration in the
"SIP/SIPS URI Parameters" sub-registry at
http://www.iana.org/assignments/sip-parameters as defined in [6].
Parameter Name Predefined Values Reference
____________________________________________
target No [RFCAAAA]
cause Yes [RFCAAAA]
[Note to IANA: Please replace AAAA with the RFC number of this
specification.
10. Security Considerations
This draft discusses transactions involving at least three parties,
which increases the complexity of the privacy issues.
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. These new
parameters tell the UM what service the proxy wishes to have
performed. Just as any message sent from the proxy to the UM needs
to be integrity protected, these messages need to be integrity
protected to stop attackers from, for example, causing a voicemail
Jennings Expires January 12, 2006 [Page 11]
Internet-Draft SIP Voicemail URI July 2005
meant for a company's CEO to go to an attacker's mailbox. RFC 3261
provides a TLS mechanism suitable for performing this integrity
protection.
The signaling from the Proxy to the UM will reveal who is calling
whom and possibly some information about a user's presence based on
whether the call was answered or sent to voicemail. 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.
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 [10] 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 that all hops
between the Proxy and UM be trusted, which is the case in many
deployment scenarios.
10.1 Integrity Protection of Forwarding in SIP
The forwarding of a call in SIP brings up a very strange trust issue.
Consider the normal case when A calls B and the call gets forwarded
to C by a network element in B's domain, and then C answers the call.
A has called B but ended up talking to C. This scenario may be hard
to separate from a man in the middle attack.
There are two possible solutions. One is that B sends back
information to A saying don't call me, call C and signs it as B. The
problem is that this solution involves revealing that B has forwarded
to C, which B often may not want to do. 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, even
more importantly, does not want to reveal that they are not in the
office.
The other possible solution 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 SIPS 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 diverted to an attacker.
Any redirection of a call to an attacker's mailbox is serious. It is
Jennings Expires January 12, 2006 [Page 12]
Internet-Draft SIP Voicemail URI July 2005
trivial for an attacker to make its mailbox seem very much like the
real mailbox and forward the messages to the real mailbox so that the
fact that the messages have been intercepted or even tampered with
escapes detection.
10.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 and 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 forwarding Proxy to induce it not to reveal
that information. The call should go through an anonymizer service
that provides session or user level privacy (as described in RFC 3323
[4]) service before going to C. It is not hard to figure out how to
meet this requirement, but it is unclear why anyone would want this
service.
The scenario in which B wants to make sure that C does not see that
the call was to B is easier to deal with 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 hard to imagine 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, when she tries to call Bill. 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
initiated 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 is present. Clearly
some people are fairly dubious about the need for this, but never
mind: let's look at how it is solved.
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 in which the mechanisms
Jennings Expires January 12, 2006 [Page 13]
Internet-Draft SIP Voicemail URI July 2005
in this specification are being used in conjunction with RFC 3325,
and the UM and the Proxy are both in the trust domain. In this
limited case, the problem that B does not want to 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.
11. Acknowledgments
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. Lyndsay Campbell helped catch mistakes. I would
like to thank them very much for this assistance, and I would also
like to acknowledge Rohan Mahy's help and encouragement with respect
to this subject.
12. References
12.1 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 the Session Initiation Protocol (SIP) for Asserted Identity
within Trusted Networks", RFC 3325, November 2002.
[6] Camarillo, G., "The Internet Assigned Number Authority (IANA)
Uniform Resource Identifier (URI) Parameter Registry for the
Session Initiation Protocol (SIP)", BCP 99, RFC 3969,
December 2004.
[7] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason Header
Field for the Session Initiation Protocol (SIP)", RFC 3326,
December 2002.
Jennings Expires January 12, 2006 [Page 14]
Internet-Draft SIP Voicemail URI July 2005
12.2 Informative References
[8] Burger, E., "Basic Network Media Services with SIP",
draft-burger-sipping-netann-11 (work in progress),
February 2005.
[9] Barnes, M., "An Extension to the Session Initiation Protocol
for Request History Information",
draft-ietf-sip-history-info-06 (work in progress),
January 2005.
[10] Ono, K. and S. Tachimoto, "End-to-middle security in the
Session Initiation Protocol(SIP)",
draft-ono-sipping-end2middle-security-04 (work in progress),
February 2005.
Author's Address
Cullen Jennings
Cisco Systems
170 West Tasman Drive
Mailstop SJC-21/2
San Jose, CA 95134
USA
Phone: +1 408 421-9990
Email: fluffy@cisco.com
Jennings Expires January 12, 2006 [Page 15]
Internet-Draft SIP Voicemail URI July 2005
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Jennings Expires January 12, 2006 [Page 16]
