One document matched: draft-petrie-sipping-xfer-issues-00.txt
SIPPING D. Petrie
Internet-Draft Pingtel Corp.
Expires: April 17, 2004 October 18, 2003
SIP Transfer Issues
draft-petrie-sipping-xfer-issues-00.txt
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
Transfer features in SIP have been enabled via the REFER method and
Replaces header. These constructs have been around for a while now
with stable definitions for how they work. However, there appear to
be a small set of edge cases and requirements that are not yet
satisfied. This draft attempts to define some of those cases and
requirements. This is intended to spark discussion to whether these
are legitimate requirements on which further standards work is
appropriate.
Petrie Expires April 17, 2004 [Page 1]
Internet-Draft SIP Transfer Issues October 2003
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Definitions of Transfer Terminology . . . . . . . . . . . . 3
1.2 Requirements Terminology . . . . . . . . . . . . . . . . . . 3
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Consultative Transfer to Lost Target . . . . . . . . . . . . 4
2.2 Consultative Transfer User Experience . . . . . . . . . . . 5
2.2.1 Consultative Call Prompting . . . . . . . . . . . . . . . . 5
2.2.2 Consultative Turned Blind Double Ring . . . . . . . . . . . 6
2.3 Gateway Issues . . . . . . . . . . . . . . . . . . . . . . . 6
2.3.1 Coerce Gateway Hairpins to the Same Gateway . . . . . . . . 6
2.3.2 Consultative Turned Blind Gateway Glare . . . . . . . . . . 7
2.4 Common Implementation Issues . . . . . . . . . . . . . . . . 8
2.4.1 Consultative with Single Line UA . . . . . . . . . . . . . . 8
2.4.2 Consultative Turned Blind Cancel Issues . . . . . . . . . . 8
3. Solutions and Directions to Consider . . . . . . . . . . . . 9
3.1 Use of Option Tokens . . . . . . . . . . . . . . . . . . . . 9
3.2 New Header for Related Dialog . . . . . . . . . . . . . . . 9
3.3 Transfer on the TDM Side of Gateways . . . . . . . . . . . . 10
3.4 Transfer on the TDM Side of Gateways . . . . . . . . . . . . 10
3.5 New Header for Actors . . . . . . . . . . . . . . . . . . . 11
3.6 Use a Target URI . . . . . . . . . . . . . . . . . . . . . . 11
3.7 Disallow Transition from Consultative to Blind Transfer . . 11
3.8 Continue Ringing after CANCEL of Consult . . . . . . . . . . 12
4. Security Considerations . . . . . . . . . . . . . . . . . . 12
References . . . . . . . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . 13
A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . 14
Petrie Expires April 17, 2004 [Page 2]
Internet-Draft SIP Transfer Issues October 2003
1. Introduction
Transfer features in SIP [RFC3261] can be accomplished using the
primitives based upon the REFER method [RFC3515] and the Replaces
header [I-D.ietf-sip-replaces] as described in
[I-D.ietf-sipping-cc-transfer]. Further examples of the signaling
involved in transfer are demonstrated in
[I-D.ietf-sipping-service-examples]. There are a few problems which
come up in the field that are not obviously solvable by these
constructs. In this draft some of the requirements and problems are
described so that they can be categorized as: solved by existing
protocol, implementation issues, desirable to solve with new
protocol, or not a requirement desirable to solve. Also an attempt
was made to propose some directions that can be pursued in fulfilling
these requirements.
1.1 Definitions of Transfer Terminology
transferor - the user agent initiating the transfer.
transferee - the user agent to be transferred to the third party.
transfer target - the third party to which the transferee is to be
connected.
original call - the dialog between the transferor and the transferee
which is setup before initiating the transfer.
consultative call - the dialog between the transferor and the
transfer target which is setup before completing the transfer.
target call - the dialog between the transferee and the transfer
target which is the final outcome of the transfer.
1.2 Requirements Terminology
Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and
"MAY" that appear in this document are to be interpreted as described
in RFC 2119[RFC2119].
2. Requirements
The following define requirements, problems and issues seen in
current transfer implementations. Some of these simply reflect the
need for a better understanding of how transfer
[I-D.ietf-sipping-cc-transfer], REFER [RFC3515] and replaces
[I-D.ietf-sip-replaces] should be used. Others may require new
application of existing protocol constructs. Some may require new
Petrie Expires April 17, 2004 [Page 3]
Internet-Draft SIP Transfer Issues October 2003
protocol constructs.
2.1 Consultative Transfer to Lost Target
In many cases of general call setup, the routing functions that
determine how to route a SIP request to a target user agent are not
static. The routing may be influenced by the time of day, dialog
state on the target, availability of the call agent, etc. For this
reason, SIP requests sent to the same address of record will not
necessarily be routed to the same target user agent. This causes a
problem for consultative transfer. The consultative INVITE is sent
and the dialog is setup with the transfer target prime (TT'). When
the consultation is complete the transferor (TC) sends a REFER to the
transferee (TE). The transferee in turn sends an INVITE with
Replaces to the transfer target (TT). The INVITE with Replaces does
not land on the correct transfer target prime (TT') where the dialog
in the Replaces header matches. The transfer target (TT) then
according to [I-D.ietf-sip-replaces] sends a 481 and thus the
transfer fails. What is really needed is a globally routable means
for the transferor to address the correct target TT' in the Refer-To
header of the REFER (which is used as the URI for the INVITE with
Replaces).
For a more concrete example (See Figure 1) assume that the transfer
target (TT) is forwarding calls when busy to TT'. When the
consultative INVITE gets to the transfer target it is redirected via
a 302 to TT'. Note that a proxy (P) is inserted below to illustrate
that the transferor (TC) may have no way of knowing that the
consultative call was forwarded from TT to TT'.
Petrie Expires April 17, 2004 [Page 4]
Internet-Draft SIP Transfer Issues October 2003
TC TE P TT TT'
<=talking=>
---I(hold)--->
<---100,200---
-----ACK----->
(busy)
--------I(consult)------->
-I(consult)->
<----302-----
-----ACK---->
-------I(consult)--------->
<-------100,180,200--------
<-------100,180,200-------
-----------------------ACK------------------------->
<================(consultation)====================>
(not busy)
----REFER--->
<----202-----
-I(replaces)->
-I(replaces)->
<-----481-----
<----481-----
-----ACK---->
<---N(503)---
-----200---->
Consultative Transfer to the Wrong Target
Figure 1
2.2 Consultative Transfer User Experience
The following set of issues and requirements relate to undesirable
user experiences in consultative transfer scenarios.
2.2.1 Consultative Call Prompting
Currently when a transfer target receives a consultative call it
looks like any other independent INVITE. The user agent cannot give
the user any sort of hint that this is related to a transfer or that
it is a consultation. At best a user answering the consultative call
is presented with the caller ID of the transferor. It would be
desirable to improve this user experience. For example it might be
better to be able to provide the user on the transfer target with
Petrie Expires April 17, 2004 [Page 5]
Internet-Draft SIP Transfer Issues October 2003
information of the form: "Incoming consultation from: <transferor ID>
with intent to transfer: <transferee ID>". The transferee Id is not
present in the consultative INVITE.
2.2.2 Consultative Turned Blind Double Ring
In the consultative turned blind case the transfer controller
initiates a consultative INVITE to the transfer target, sends a
CANCEL and then a REFER (to the transferee) to perform the blind
transfer. This sometimes creates an awkward experience on the
transfer target. The consultative INVITE comes in and rings for a
short period of time. Then that call is CANCELed. Afterwards the
transferee receives the REFERred INVITE and starts ringing again.
The transfer target hears the phone ring twice and may see two
different caller Ids. It is probably not desirable to change the
signaling approach (i.e. INVITE, CANCEL, REFER) at this point.
However if the transfer target user agent were given more hints as to
what was going on, it could potentially hide the double ring and
changing caller Ids.
2.3 Gateway Issues
The following set of requirements relate to SIP signaling gateways
(PSTN and others).
2.3.1 Coerce Gateway Hairpins to the Same Gateway
To illustrate how a hairpin situation can occur in transfer, consider
this example. The original call dialog is setup with the transferee
residing on the TDM side of a SIP gateway. The transferor is a SIP
phone purely in the IP space. The transfer target is on the TDM side
of a SIP gateway as well. After completing the transfer, (regardless
of consultative or blind) the transferee is in a call with the
transfer target (both on the TDM side of a gateway). It is often
desirable to remove the gateway(s) out of the loop. This is likely
to only be possible if both legs of the target call are on the same
gateway. With both legs on the same gateway, it may be able to
invoke the analogous transfer on the TDM side. Then the target call
would not involve the gateway.
Gateway ports can be expensive or limited resources. It is therefore
desirable to keep their utilization to a minimum. For example, in a
hybrid situation a SIP to PSTN gateway may be used to extend the life
of a TDM switch that is at its maximum for line and trunk cards. The
last few valuable trunk cards are used to glue in the gateway with
the desire of using SIP (proxy, etc.) to get a higher density of
utilization from the trunk lines. A hairpin through the gateway
consumes two ports that could be switched in the TDM switch, freeing
Petrie Expires April 17, 2004 [Page 6]
Internet-Draft SIP Transfer Issues October 2003
both gateway ports. This is easier to accomplish if the hairpin is
on the same T1. It is certainly very difficult to accomplish if the
hairpin is across two different gateways. Even if the hairpin cannot
be eliminated by being pushed to the other side of the gateway, there
are other scenarios where coercing the two legs of a hairpin onto the
same gateway is very desirable for network traffic optimization (e.g.
avoiding the traffic in and out over two limited WAN connections if
the gateways are at different sites.).
So the problem is how to give the proxy enough information so that it
knows to route the call to the same gateway. With a simple single
call that hairpins, the incoming and outgoing leg have the same
dialog. The proxy should have enough information to optimize the
routing.
In the consultative transfer scenario, it is desirable to coerce the
consultative INVITE out the same gateway as the original call to be
transferred. However there is no way to relate the consultation with
the original call. In the consultative case the target call INVITE
includes the Replaces header which contains dialog information that
can be used to relate it to the consultation. However there is no
information that relates the target call to the original.
In the blind transfer scenario, it is desirable to coerce the target
call onto the same gateway as the original call. However the same
problem exists in that the target dialog cannot be related to the
original dialog.
In either transfer scenario, it may be desirable to push the transfer
operation onto the non-SIP side of the gateway. Presumably this is
not possible unless all of the legs go out the same gateway. If the
gateway supports more than one truck group, it might also be
necessary to get all of the legs on the same trunk group in order to
perform the transfer on the non-SIP side of the gateway.
2.3.2 Consultative Turned Blind Gateway Glare
In the consultative transfer case turned blind, there is a glare-like
problem. The transferor initiates the consultation INVITE, the user
gets impatient and hangs up, transitioning this to a blind transfer.
The transfer target on the gateway (connected through a TDM switch to
a single line or dumb analog phone) rings. The user answers the
phone just after the CANCEL is received by the transfer target. The
REFER and INVITE for the target call are sent. The transferee
attempts to setup the call on the TDM side, but gets either a busy or
lands in the users voicemail as the user has the handset in hand and
off hook.
Petrie Expires April 17, 2004 [Page 7]
Internet-Draft SIP Transfer Issues October 2003
In this scenario the simplest requirement, might be to disallow
consultative transfer. An alternative requirement might be to
disallow the transition from consultative to blind transfer. Either
way the transferor needs to know ahead of time what the transfer
target can and cannot do.
2.4 Common Implementation Issues
The following are mostly implementation oversights or
misunderstandings that are commonly seen in the field and at SIPit
events. These are just a few examples. Transfer is very complicated
and too few implementations get it right or are robust. The
robustness problem is probably largely due to the number of points of
failure. In the consultative case there are three dialogs among
three user agents and it takes 8 or more transactions to complete it
all. Each transaction can fail for various reasons, etc.
[Should these be here at all? Is it worth writing these up into a
more expanded list in the next revision?]
2.4.1 Consultative with Single Line UA
Some SIP user agents only support blind transfer. This may be
because the user agent only supports a single dialog or line or it
may simply be a business decision. The problem is that this is not
typically discovered until the INVITE with Replaces header is sent.
This is probably more a best current practices issue rather than a
protocol issue. If in the consultative INVITE, the transferor
includes a Requires header with the "replaces" token in the value AND
the transfer target correctly observes the Requires header, this
would not be a problem. The transferor would get a 420 Bad Extension
response. It could then try a blind transfer using REFER.
2.4.2 Consultative Turned Blind Cancel Issues
Two common mistakes are made when a consultative transfer transitions
to a blind transfer. Some implementations of the transferor do not
send a CANCEL. They try to use Replaces to replace the early dialog.
This is documented in Replaces [I-D.ietf-sip-replaces] as not
supported because it just does not work. You cannot reliably replace
a dialog on the user agent server side because (due to forking )it is
a moving target.
The other common mistake is to not wait for the outcome of the
CANCEL. The transferor MUST CANCEL the consultative INVITE, wait for
the CANCEL to succeed, then send the REFER without Replaces. If the
CANCEL fails (as the dialog was setup with a 200 response), the
transferor can then send the REFER with Replaces as the consultative
Petrie Expires April 17, 2004 [Page 8]
Internet-Draft SIP Transfer Issues October 2003
call is no longer an early dialog.
3. Solutions and Directions to Consider
This section contains some initial thoughts on ways to resolve the
requirements in Section 2.
The following are at least preliminary approaches to resolving the
requirements identified in this draft. They are mostly independent
and can be used separately or all together. These solutions are not
intended to be complete. The descriptions are here for discussion on
how to proceed.
3.1 Use of Option Tokens
Applicable to: Section 2.2.2, Section 2.3.1, Section 2.3.2, Section
2.4.1
In the consultative INVITE, the transferor MUST put the replaces
token in the Requires header. In common practice this is often not
done. Even if it was used in practice, it is probably not sufficient
to completely solve the double ring (see Section 2.2.2) and gateway
glare (see Section 2.3.2) problems. It will allow a gateway or user
agent acting as the role of transfer target to say "I do not want to
perform a consultative transfer".
Often the only problem or limitation is the troublesome transition
from consultative to blind transfer. To avoid restricting the use of
a pure consultative transfer, one could instead restrict the use of
the transition from consultative to blind. This can be accomplished
by creating a new options token consult2blind. The transferor MUST
put this token in the Requires header if it allows the user to back
out of the consultation and transition to a blind transfer.
3.2 New Header for Related Dialog
Applicable to: Section 2.2.2, Section 2.2.1, Section 2.3.1
Create a new header 'Related' to generally relate a request to
another dialog. Create tokens for that header that define the type
of relationship between the message containing the Related header and
the referenced dialog. The syntax specifies a dialog similar to the
Replaces [I-D.ietf-sip-replaces] syntax. However the Related header
specifies a relationship as opposed to a specific operation as the
Replaces header does. In addition the relationship is abstract for
the header and specified by the relationship token.
Petrie Expires April 17, 2004 [Page 9]
Internet-Draft SIP Transfer Issues October 2003
"Related" HCOLON relation SEMI dialog-param *(SEMI generic-param)
relation = ("consult" / token)
dialog-param = callid SEMI to-param SEMI from-param
to-param = to-tag / early-flag
tfrom-param = from-tag / early-flag
to-tag = "to-tag" EQUAL token
from-tag = "from-tag" EQUAL token
early-flag = "early-only"
Example:
Related: consult; 8719100197@10.1.1.123; to-tag=98748; from-tag=99173
In the context of transfer this can be used to relate the
consultative INVITE request with the original dialog between the
transferor and the transferee. This is useful to the transfer
target's user agent. The consultative INVITE should contain the
Related header with the consult token and the dialog information of
the original call. In the gateway context it is useful to the
location server in deciding which gateway to route the request to.
The location server can use the dialog package
[I-D.ietf-sipping-dialog-package] or any maintained call state to
find which gateway is currently servicing the original call and
attempt to use the same gateway for the consultation and target
calls. This also has the side effect of specifying that this INVITE
is a consultation.
3.3 Transfer on the TDM Side of Gateways
A proposal exists for conveying trunk group information
[I-D.ietf-iptel-trunk-group]. This may be useful in helping to get
all of the legs in the transfer on to the same gateway and trunk
group.
3.4 Transfer on the TDM Side of Gateways
By putting all of the TDM legs of the transfer parties on the same
gateway and providing the gateway with the ability to disallow
consultative transfer, it should be possible to perform the transfer
on the TDM side. The consultative dialog can be disallowed by the
gateway as described in Section 3.1. All of the transfer dialogs can
be associated by the gateway as described in Section 3.2. This also
gives the gateway enough information to selectively decide when to
disallow consultative transfer (i.e. if it knows it has one leg of
the original call related to the consultation). This also assumes
the gateway location service has dialog state awareness of the
original transfer dialog and can route the consultation to the same
gateway. If the gateway uses more than one trunk group it may be
Petrie Expires April 17, 2004 [Page 10]
Internet-Draft SIP Transfer Issues October 2003
necessary to apply [I-D.ietf-iptel-trunk-group] as well to get all of
the TDM legs of the transfer out the same trunk group.
3.5 New Header for Actors
Applicable to: Section 2.2.2, Section 2.2.1
Create a new header to relate address of records outside of a dialog.
Create named tokens to label the type of relationship of the AOR to
this dialog or transaction. This could be thought of as a general
purpose Referred-By header [I-D.ietf-sip-referredby]. This is useful
in the consultative INVITE request to allow the transferor to say
this consultation is with regards to transferring the given AOR who
is the transferee.
"Actor" HCOLON acttoken SEMI name-addr *(SEMI generic-param)
acttoken = "transferee" / token
Example:
Actor: transferee; Joe Transferee<sip:joe@example.com>
This syntax could be combined with that in Section 3.2. However
they seem more broadly applicable to other SIP features if they are
useable independently.
3.6 Use a Target URI
Applicable to: Section 2.1
Create a transfer target URI analogous to the Conference URI in
[I-D.ietf-sipping-cc-conferencing]. This URI needs to be globally
routable such that the transferor and the transferee (potentially in
different domains) can both reach the transfer target via the URI.
The URI must be unique to the consultative dialog residing on the
transfer target. It cannot be the same for other dialogs (early or
established) created as a result of the consultation.
3.7 Disallow Transition from Consultative to Blind Transfer
Applicable to: Section 2.2.2, Section 2.3.2
A more drastic approach to the problems associated with transitioning
from consultative to blind transfer would be to simply disallow it
completely. This would require that the transferor hang on to and
complete the consultation dialog until it was setup or failed. This
might make it impossible for some user agents to do consultative
transfer due to limitations of having only one active dialog at a
Petrie Expires April 17, 2004 [Page 11]
Internet-Draft SIP Transfer Issues October 2003
time. This solution does not seem very desirable from a market
requirements and end user expectations perspective.
3.8 Continue Ringing after CANCEL of Consult
Applicable to: Section 2.2.2, Section 2.3.2
An implementation approach to solving some problems on the transfer
target caused by the transition from consultative to blind transfer
is to hold on to the resources on the far end a little longer. That
is, on a phone user agent, hold on to the ringer resource a little
longer (e.g. 5 seconds) in the hopes that the blind transfer will
come in that can be associated with the CANCELed consultation. If it
does, then the blind transfer INVITE gets the ringer resource -
covering up the audio artifact that the consultation was CANCELed.
In the case where a PSTN gateway is the transfer target, it could
hold on to the PSTN resource in an analogous way to the ringer on the
phone.
4. Security Considerations
TBD
References
[I-D.ietf-iptel-trunk-group]
Gurbani, V., "Representing trunk groups in sip/tel Uniform
Resource Identifiers (URIs)",
draft-ietf-iptel-trunk-group-00 (work in progress),
November 2002.
[I-D.ietf-sip-referredby]
Sparks, R., "The SIP Referred-By Mechanism",
draft-ietf-sip-referredby-03 (work in progress), August
2003.
[I-D.ietf-sip-replaces]
Biggs, B., Dean, R. and R. Mahy, "The Session Inititation
Protocol (SIP) 'Replaces' Header",
draft-ietf-sip-replaces-04 (work in progress), August
2003.
[I-D.ietf-sipping-cc-conferencing]
Johnston, A. and O. Levin, "Session Initiation Protocol
Call Control - Conferencing for User Agents",
draft-ietf-sipping-cc-conferencing-01 (work in progress),
July 2003.
Petrie Expires April 17, 2004 [Page 12]
Internet-Draft SIP Transfer Issues October 2003
[I-D.ietf-sipping-cc-transfer]
Sparks, R. and A. Johnston, "Session Initiation Protocol
Call Control - Transfer",
draft-ietf-sipping-cc-transfer-01 (work in progress),
February 2003.
[I-D.ietf-sipping-dialog-package]
Rosenberg, J. and H. Schulzrinne, "An INVITE Inititiated
Dialog Event Package for the Session Initiation Protocol
(SIP", draft-ietf-sipping-dialog-package-02 (work in
progress), July 2003.
[I-D.ietf-sipping-service-examples]
Johnston, A. and R. Sparks, "Session Initiation Protocol
Service Examples", draft-ietf-sipping-service-examples-05
(work in progress), September 2003.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors",
RFC 2223, October 1997.
[RFC3261] 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.
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003.
Author's Address
Daniel Petrie
Pingtel Corp.
400 W. Cummings Park
Suite 2200
Woburn, MA 02476
US
Phone: "Dan Petrie (+1 781 970 0111)"<sip:dpetrie@pingtel.com>
EMail: dpetrie@pingtel.com
URI: http://www.pingtel.com/
Appendix A. Acknowledgments
Petrie Expires April 17, 2004 [Page 13]
Internet-Draft SIP Transfer Issues 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.
The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
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.
Petrie Expires April 17, 2004 [Page 14]
Internet-Draft SIP Transfer Issues October 2003
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
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Petrie Expires April 17, 2004 [Page 15]
| PAFTECH AB 2003-2026 | 2026-04-23 20:21:01 |