Internet DRAFT - draft-bjorkner-spirits-vsua
draft-bjorkner-spirits-vsua
Internet Engineering Task Force J.Bjorkner,
S.Nyckelgard
Internet Draft Hotsip,
Telia
Document: draft-bjorkner-spirits-vsua-00.txt July 2000
A SPIRITS solution based on virtual SIP user agents
STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
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.
Abstract
This document discusses events occurring in a telephony network that
could be useful for call related services created in an Internet
environment. It also shows one possible implementation of a SPIRITS
protocol based on Session Initiation Protocol (SIP) [2]. The SPIRITS
working group has not yet done any protocol decisions, so this draft
is written for informative purpose showing that the introduction of
virtual SIP user agents (SIP UAs) in a SPIRITS client makes it
possible to realize the services described in the pre-spirits
implementations document [3].
The advantage of introducing SIP UAs in the SPIRITS client is that a
SPIRITS proxy and a SPIRITS server then also could be used by any
other voice network that natively speaks SIP, for example wireless
3G networks and voice over IP networks. This would also allow the
PSTN network to utilize the services created for those networks.
The document is not focused on how these services are subscribed for
within the telephony network, since there is several appropriate
methods to do this from an end users perspective, from calling the
customer service to submit a web form. The action taken after this
subscription is dependent of the voice network attached to the
J.Bjorkner,S.Nyckelgard [1]
Internet Draft vsua July 2000
SPIRITS client. This document has the focus on the Internet specific
parts of the protocol, which should be voice network independent.
1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119 [2].
2. Introduction
This document describes a solution to the problem where an event in
a telephony network needs to trigger a service that will operate on
a particular data within the telephony network associated with the
event. The solution described makes it possible to distribute this
service logic out from the telephony network to a host on an IP
network, or in fact also to a host on the Internet.
The solution is coherent with the architecture developed within the
SPIRITS working group and proposes a solution based on SIP (Session
Initiation Protocol) [2]. There are two reasons to use SIP as a
foundation for the SPIRITS protocol: By using SIP will it be
possible for SIP speaking voice networks to utilize the SPIRITS
services; SIP is designed for Internet use with respect to scaling
and security and contains necessary placeholders for information
related to voice calls.
The solution described fits in to the SPIRITS architecture defined
by the SPIRITS working group shown in Figure 1. The interfaces
defined with this solution are B and C. The interface D is not
described in this document, since it is dependent on the signaling
protocols used in the underlying network. The D interface only
affects the SPIRITS client implementation according to this proposal
and leaves the interfaces B and C unaffected.
If one would like to use the already existing service protocols
defined for PSTN to talk to IP based hosts, then these protocols can
be tunneled as they are by using the protocols defined in the IETF
SIGTRAN working group. Those protocols are however not designed for
an Internet environment with respect to trust relations and
transport conditions, so therefore could it be useful to map
functionality from these protocols to something more Internet
friendly. Another disadvantage with this method is that these
protocols exist in different national flavors in different countries
and even in some cases differs among the networks owned by a single
operator. On the Internet exists no flavors of a standard, and it is
important that a SPIRITS server could work together with several
operators in different countries, without having to install special
software to make it work. These problems are solved by a protocol
mapping as described in this document.
J.Bjorkner,S.Nyckelgard [2]
Internet Draft vsua July 2000
+-----------+
| SPIRITS |
| Server |
+-----+-----+
| B
+-----------+
| SPIRITS |
| Proxy |
+-----+-----+
| C
+-----------+
| SPIRITS |
| Client |
+-----+-----+
| D
+-----------+
| Voice net |
| service |
| function |
+-----------+
Figure 1.
The basic idea with this proposal is to show that it is possible to
create a solution which make the PSTN phones to appear as if they
were SIP phones to the SPIRITS server. The motivation for this is
that there will soon be a large number of innovative services that
will be deployed for SIP networks. If a PSTN could behave as a SIP
networks from a signaling point of view, it could easily make use of
these services. Another rationale to use telephony services
implemented in SIP is that SIP will be the signaling protocol used
for the all IP 3G wireless networks.
The functions provided by service protocols used in an IN
environment in today's PSTN networks differs depending on which
version and flavor of the IN protocol that is used. Instead of
focusing on the particular functions and the naming of the functions
within the different IN protocols, a set of general functions of
interest for a SPIRITS service are defined and explained in the next
section.
The set of general functions is a subset of capabilities of the
current IN protocols. They provide a balanced tradeoff between
complexity and functionality. Having this signaling protocol
agnostic view ensures that no PSTN specific behavior is built into
the SPIRITS protocol, which is essential in order to make SPIRITS
useful also for other voice networks than PSTN.
3. Telephony events that could trigger a SPIRITS server
J.Bjorkner,S.Nyckelgard [3]
Internet Draft vsua July 2000
This section lists events occurring in a voice network that could
trigger a request from the voice network to a SPIRITS server. It
also outlines the information that is passed between the SPIRITS
client and the SPIRITS server. Parameters and formats are subjects
for a follow-up draft.
The events are divided into three different categories: call
origination, call termination and non-call related.
C->S: denotes information passed from the SPIRITS Client to the
SPIRITS server. S->C: denotes information passed in the opposite
direction.
3.1 Call origination events
3.1.1 Event O1 (Call initiation)
C->S: call identifier, calling party address, called party address,
dialed address,
S->C: response code, call identifier, [calling party address,
called party address, dialed address]
This event is triggered when a user has filled out a complete
address (i.e. dialed a number) but before a route has been selected
for the call.
A normal response from the SPIRITS server carries the same parameter
fields as the query but the SPIRITS server may have changed any data
field(s) except 'call identifier'. The returned data is used for
routing the call in the voice network.
An alternative response may indicate to the SPIRITS client to
complete the call as dialed or to reject the call.
Services possible to create with this event are e.g. Call Barring,
Speed Dialing, VPN services, Number Portability etc.
This event maps to a SIP Invite request.
3.2 Call termination events
3.2.1 Event T1 (Call received)
C->S: call identifier, calling party address, called party address,
dialed address,
S->C: response code, call identifier, [calling party address,
called party address, dialed address]
This event is triggered when a call is received at the switch
servicing the callee, before the phone starts ringing.
J.Bjorkner,S.Nyckelgard [4]
Internet Draft vsua July 2000
The response from the SPIRITS server may indicate to the SPIRITS
client to make the callee's phone ring, to redirect the call to
another destination or to reject the call.
Services possible to create with this event are: Conditional
Redirection, Call Filtering, Internet Call Waiting, Internet Caller
Identification, etc.
This event maps to a SIP invite request.
3.3 Call progress informative events
3.3.1 Event I1 (Call failed)
C->S: call identifier, calling party address, called party address,
dialed address, reason of failure
S->C:
This event is sent if a call for some reason failed to be set up.
This event maps to a SIP 503 Service Unavailable response.
3.3.2 Event I2 (Callee busy)
C->S: call identifier, calling party address, called party address,
dialed address
S->C:--
This event is sent if the called party is busy due to an ongoing
phone call.
This event maps to a SIP 486 Busy Here response.
3.3.3 Event I3 (Call rejected)
C->S: call identifier, calling party address, called party address,
dialed address, reason of rejection
S->C:--
This event is sent if the called party rejects an incoming call for
some reason.
This event maps to a SIP 603 Decline response.
3.3.4 Event I4 (Call terminated)
J.Bjorkner,S.Nyckelgard [5]
Internet Draft vsua July 2000
C->S: call identifier, calling party address, called party address,
dialed address
S->C:--
This event is sent if any of the calling parties terminates the call
by hanging up.
This event maps to a SIP Bye request.
3.4 Non call related events
3.4.1 Event N1 (User logged on)
C->S: user id
S->C: --
This event is sent when a user logs on to his phone, i.e. turns on
his cell phone.
This information is useful for intelligent routing services.
This event maps to a SIP Register request.
3.4.1 Event N2 (User logged off)
C->S: user id
S->C: --
This event is sent when a user logs off from his phone, i.e. turns
off his cell phone.
This information is useful for intelligent routing services.
This event maps to a SIP Register request.
3.4.1 Event N3 (Position changed)
C->S: user id, spatial location
S->C: --
This event is sent when a user updates his position in the network.
His geographical coordinates for his current position are sent
within the event.
This information is useful for intelligent call routing services.
Note. It is probably good to have the option to send this event
slightly before an event that might have use of the information,
J.Bjorkner,S.Nyckelgard [6]
Internet Draft vsua July 2000
instead of constantly sending these messages when an user is moving
around.
This event maps to a SIP Register request.
4. Architecture
Since telephony calls usually involves two ore more parties is it
proposed that the SPIRITS client actually consists of two logical
entities representing the calling and called party. These entities
could be viewed as virtual phones, or virtual users.
Those entities are called user agents (UA) throughout this document.
The user agent representing the calling party is named user agent A
(UAA), and the UA representing the called party is named user agent
B (UAB). Depending on if the SPIRITS client is residing in the
originating end of the network or terminating end of the network are
these named originating or terminating user agents (OUA, TUA).
The idea is that when a call is to be set up from a user subscribing
to a SPIRITS service is a UAA corresponding to the calling party
created within the SPIRITS client. At the same time is a UAB set up
to represent the called party. An event is sent from the UAA to the
SPIRITS proxy, which could modify the call setup information before
it is sent to the UAB. The SPIRITS proxy will then remain within the
signaling path between the UAA and the UAB throughout the call to
receive call related events.
The advantage with this setup is that the UAA and UAB don't have to
reside within the same SPIRITS client for the services residing in
the SPIRITS proxy to work. The same SPIRITS proxy could then serve
voice networks of a more distributed nature.
Some services, for example Internet Call Waiting, requires some end
user interaction. In this case will the SPIRITS proxy forward the
incoming event to the SPIRITS server for user notification. If a
response is not received from this server within a certain amount of
time could the proxy process the message according to some pre-
defined logic.
The most complex scenario is when a user who has an originating
SPIRITS service is calling a user who has a terminating SPIRITS
service. In this case will the call informative events pass flow
through two SPIRITS servers as shown in Figure 2.
J.Bjorkner,S.Nyckelgard [7]
Internet Draft vsua July 2000
+----------------+ +----------------+
| SPIRITS proxy | | SPIRITS proxy |
+----------------+ +----------------+
| | | |
/|\ | /|\ |
| \|/ | \|/
| | | |
+-+----+--+----+-- +-+----+--+----+-+
| |OUAA| |OUAB| | | |TUAA| |TUAB| |
| +----+ +----+ | | +----+ +----+ |
| SPIRITS Client | | SPIRITS client |
+----------------+ +----------------+
| |
0---0 +-----------+ +-----------+ 0---0
/_\-->-| Exec. Syst|------------->-------|Exec. Syst.|-->-/_\
+-----------+ +-----------+
Orig. Side Term. Side
Figure 2.
5. Transport protocol
This document proposes to use SIP as a transport protocol for the
SPIRITS messages. One reason for this is that it designed to work in
an environment consisting of the entities described in the SPIRTIS
architecture. As the next section will show could SIP be used as it
is without any new extensions to be able to create the services
described in the pre-SPIRITS implementations document [3].
Instead needs the behavior it the entities be specified, and the
encoding of the necessary information to be transported from the
SPIRITS client to the SPIRITS proxy and servers.
6. System components
This section gives a description of the components necessary to
create a SPIRITS service and their behavior.
6.1 Executive system
This is the logic in the voice network responsible for setting up a
call, in a PSTN network is this corresponding to a switch. The
executive system is required to report all events occurring in the
J.Bjorkner,S.Nyckelgard [8]
Internet Draft vsua July 2000
telephony network necessary to create SPIRITS services to the
SPIRITS client. The executive system has the knowledge that a user
is subscribing to a SPIRITS service and is invoking a SPIRITS client
for all inbound and outbound calls for this user.
6.2 SPIRITS Client
The SPIRITS client is the bridge between the voice network's service
function and the SPIRITS services created in an IP environment. The
SPIRITS client have a default behavior on inbound calls that
triggers it to send out requests to a SPIRITS proxy on the IP
network. Its handling of the call is determined from the responses
of these requests. Therefore is there no need for the SPIRITS client
to have any knowledge of the service executed in the IP network.
The SPIRITS client could be viewed of having two sides, one inbound
side and one outbound. An inbound call to a user having a SPIRITS
service is associated with the inbound side of the client and that
UA, the UAA. Depending of the type of service could the SPIRITS
client stay involved in the signaling path for the rest of the call.
In this case is an outbound UA, UAB, associated with the connected
address.
In the case of a service that wants to stay within the signaling
path is the invite message forwarded to the UAB, with a request URI
containing the number to connect the inbound call leg with. The
address of UAB is carried in the route: header of the initial Invite
request.
6.2.1 SPIRITS Client UA Outbound Requests
The UAA sends a SIP Invite to the SPIRITS proxy. The request URI
contains the dialed inbound number, the from: field the calling
party's number and the to: field the originally dialed number. The
to: field could differ from the request URI if any redirection had
occurred in the voice network. The UAA also inserts a route: header
indicating the address of the UAB associated with this call.
The UAA or UAB sends a BYE request when an active call associated to
the client is terminated to the proxy.
6.2.2 SPIRITS Client UA Inbound Requests
When a SIP Invite is received by the UAB makes the SPIRITS client
the executive system to create an outbound call leg to the telephone
number in the request URI. The progress of setting up this call leg
is reported back to the SPIRITS proxy with appropriate provisional
responses. When the called party on this leg answers the phone is a
200 OK sent back through the proxy to the UAA. If the Invite
contained a record-route header would all further requests be sent
according to these routes. By this could a SPIRITS proxy ask to
receive the BYE message sent when the call is terminated.
J.Bjorkner,S.Nyckelgard [9]
Internet Draft vsua July 2000
If the Invite message contains a replaces: header would the SPIRITS
client tear down any ongoing call leg towards the telephone number
and call ID indicated in this header. The replaces header is
introduced in the SIP Call Control Services draft [4].
When a Bye request is received by any UA is the call leg associated
with this UA terminated by a signal from the SPIRITS client to the
executive system.
6.2.3 SPIRITS Client responses
A number of different SIP responses could be received to the invite
sent by the UAA. The action to these responses is described below.
200 OK, indicates that the SPIRITS client should signal down to the
executive system to connect inbound call leg with the call leg
corresponding to the UAS. The SPIRITS client will stay associated
with the call until it ends.
302 Moved Temporarily, the SPIRITS client tells the executive system
to redirect the incoming call to the telephone number in the
contact: field of the response. The SPIRITS client is released from
the call.
404 Not found, indicates that the SPIRITS client should signal down
to the executive system to connect the call to the telephone number
of the inbound call. The SPIRITS client is released from the call.
603 Decline, tell the executive system to reject the inbound call.
The SPIRITS client is released from the call.
6.3 SPIRITS proxy
The SPIRITS proxy is the entity that implements the SPIRITS
services. The behavior is similar to a SIP redirect/proxy server
since it performs some action based on the request URI of an
incoming request and either responds back or forwards the invite to
the next hop server. In the case of a SPIRITS proxy would the next
hop server always be the UAB since the UAA always inserts a route
header containing its address.
If there is need for user interaction would the proxy know if a user
is online by the register messages sent from the user to the proxy.
In this case could a request be sent to the user before the incoming
request is forwarded or responded to.
7. Call flows
This section shows how the services described in the pre spirits
implementations document could be realized according to the proposed
solution. The target services according to the SPIRITS charter are:
Internet Call Waiting, Internet Caller Identification and Internet
Call Forwarding. The SPIRITS protocol should not be hard wired to
J.Bjorkner,S.Nyckelgard [10]
Internet Draft vsua July 2000
just fit these services, the protocol is a useful tool for people
implementing services in a SPIRITS proxy or SPIRITS server.
These examples show the involved message transactions. It needs to
be defined how to encode the information to be transported within
the messages.
7.1 Internet Call Waiting
Internet Call Waiting (ICW) is an example of a terminating service
which is executed when the call signaling is reaching the executive
telephone system responsible for the called party. Since ICW is just
involved during the call setup phase is there no need for the
SPIRITS server to be involved in the signaling path after the call
has been established.
The following steps are invoked in the service execution.
1. The inbound call setup signaling is received at the receiving
executive system. This system associates the called number with a
SPIRITS customer and invokes a SPIRITS client. This invocation is
out of scope for this working group, and is dependent on the
signaling mechanisms used in the voice network.
2. The SPIRITS client creates an UAA and UAB which will be used to
control the call setup in the voice network.
3. The UAC send a SIP Invite message to the SPIRITS Proxy. If a user
is online would he have sent a SIP Register to the SPIRITS proxy
that contained the IP host he is running his ICW software on. In
this case would the proxy forward the Invite message to the ICW
client (SPIRITS server). If he were not registered with the SPIRITS
proxy would the proxy respond with a 404 Not Found message to the
UAA. This would cause the SPIRITS client to signal back to the
executive system to continue the call setup with the dialed number.
4. If the user were online would he receive an Invite message. This
invite message contains the calling party's number in the from:
field that could be used for caller identification. The ICW software
(SPIRITS server) would show a window telling the user that there is
an incoming call. He could then have the option to reject, accept or
redirect the call to another number. In the case of rejection would
the SPIRITS server return a 603 Decline response to the proxy. This
would cause the proxy to respond with the same message to the UAA.
If the call is accepted is the Invite forwarded to the UAA contained
in the route: header. This invite will contain a replaces: header to
indicate that the ongoing call should be terminated. The call ID for
this ongoing were fetched by the SPIRITS proxy during the call setup
of this ongoing call. In this case would the UAB cause the executive
system to disconnect any connected voice calls for this user and
after that connect the inbound call that was accepted. If the user
whishes to redirect the call to any other answering place, for
example a soft phone on his PC or a cell phone would a 302 Moved
Temporarily be returned with the phone number to redirect to in the
J.Bjorkner,S.Nyckelgard [11]
Internet Draft vsua July 2000
contact: field of the answer. This would cause the executive system
to set up the inbound call to this telephone number.
5. When a response is received at the UAA is action taken according
to above. This would cause the call to be connected and make a phone
to start ringing.
7.2 Internet Caller Identification
The Internet Caller Identification (ICI) service is a somewhat
simplified version of Internet Call Waiting. The message flow is the
same as for that service, except that the UAC immediately connects
the call. The Invite message sent out from the UAA would be received
by the ICI software that a user have registered with the SPIRITS
proxy. This message would cause a window to pop up which displays
the name and number of the calling party. This information is
fetched from the from: field of the Invite message.
7.3 Internet Call Authorization
This is an example of a more advanced call barring service which is
an originating service. The idea is that a user can set up rules
which regulates which number that can be dialed or not. This set of
rules is stored in the SPIRITS server. If a number is dialed that is
blocked by the rule set could the SPIRITS server alert the user that
this is the case, and ask for an authorization code. This would
cause a software to pop up a window asking for the code. If the
right code were entered would the call setup continue.
The message flow for this service is as follows:
1. All outbound calls for a user be detected by the executive
system. The dialed number would be sent to the SPIRITS client that
creates an UAA for this call.
2. An Invite message is sent to the SPIRITS proxy. This proxy
contains an access control list of the numbers that this user is
allowed to call. If there is a granted number is a 200 OK sent back
to the UAA. If it is a number that is not permitted to call is the
action dependent of if the user is running his ICA application or
not. If the user were not logged on would the proxy return a 603
Decline to the UAA.
3. If the user is logged on, i.e. have registered with the proxy is
the Invite forwarded to the application. In normal SIP scenarios is
the client authenticating himself for the server, i.e.
authentication is necessary to send a request. In this scenario is
the opposite necessary, authentication is necessary to send a
response. This could be done by inserting an WWW-authenticate
header containing a challenge in the Invite message sent from the
proxy. This would cause a window to pop up asking for an
authorization code and also displaying the dialed from and to
numbers. From this code is a response calculated and returned in a
authentication header in a 200 OK response back to the proxy. The
J.Bjorkner,S.Nyckelgard [12]
Internet Draft vsua July 2000
proxy checks whether this was a valid authentication, and if it was
the case forwards the Invite to the UAB to set up the call.
Otherwise is a 603 Decline returned to the UAA.
7.4 Internet Call Distribution
This is an example of how an automatic call distribution service
could be built on top of the tools described in this document. A
call distribution service is a service that selects a termination
number depending on some built in logic, independent of the dialed
number. The service is a terminating service. This service is also
involved during the whole call setup and the call itself since it
needs to know if a call was successfully set up and when a call
ends. The steps involved during a call invoking such a service is
described below.
1. An inbound call is received by the executive system in the voice
network. The executive system has the knowledge that this dialed
number has an associated SPIRITS service.
2. The executive system invokes the SPIRITS client and provides it
with the called and calling party number.
3. The SPIRITS client creates a UAA and UAB. The UAA is associated
with in inbound call leg to the executive system. The UAB will be
the entity responsible to create an outbound call leg from the
executive system towards a recipient of the call. The recipient is
of the call determined by the SPIRITS proxy according to some built
in logic. These two user agents could be viewed as mirrors of the
phones involved during the call.
4. The UAA sends an Invite message to the SPIRITS proxy. The dialed
number is inserted in a tel: URL in the request URI of the message.
The proxy looks performs its logic based on the values of for
example the request URI and the from: field. Based on this
information is a new termination number determined which is inserted
in the request URI of the invite message before it is forwarded.
Since the SPIRITS client needs to get this information to the UAB,
is a route header containing the address of the UAB inserted in the
Invite message sent to the SPIRITS proxy. This will force the proxy
to forward the Invite to the UAB. The proxy also inserts a record-
route header in the Invite message before it is forwarded, to ensure
that all further requests is sent through the proxy.
5. The UAB receives the Invite message. The request URI contains the
number to be called. The UAB uses this number and makes the
executive system to contact this number. The executive system sends
back status information to the SPIRITS client regarding the call
setup progress. These messages are mapped to appropriate SIP
provisional responses and are sent back from the UAB via the proxy
to the UAA. If the call setup fails or takes too long time could the
proxy send a Cancel to the UAB to terminate the call setup attempt,
and send a new Invite to the UAB with a new number to try. By this
could call forward on no answer be created.
J.Bjorkner,S.Nyckelgard [13]
Internet Draft vsua July 2000
6. When the executive system reports back to the SPIRITS client that
the intended destination has been reached is a 200 OK sent back from
the UAB through the proxy to the UAA. When this is received by the
UAA will the SPIRITS client report down to the executive system that
the call should be connected
7. When the calling party hangs up will a BYE message be sent from
either the UAs, through the proxy, to the other UA. This is useful
if the service in the proxy needs this to free up some resources or
create some statistics.
From the view of the proxy is this call setup looking like any call
setup between two SIP endpoints. This has the advantage that the
same service proxy could be used for both a SIP network and a
SPIRITS enabled telephony network. The SPIRITS client is performing
basically the same task as a PINT server is doing. The PINT server
is creating two call legs in the PSTN and ties them together. In
this case we already have one of the legs, and creates another which
then is tied together with the first one.
8. Security Considerations
Since the transactions occurring between the SPIRITS client and
SPIRITS proxy contain sensitive data is it recommended that hop-to-
hop encryption or a secure transport layer be used for this
communication. These mechanisms are described in section 13 of [2].
9. References
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
2 Handley, M., et al., "SIP: Session Initiation Protocol", RFC
2543, March 1999
3 Lu, H., et al., "Pre-Spirits Implementations of PSTN-initiated
Services", IETF Internet Draft draft-ietf-spirits-
implementations-00.txt, May 2000
4 Schulzrinne,H., Rosenberg,J., "SIP Call Control Services (draft
1)",IETF Internet Draft draft-ietf-mmusic-sip-cc-01.txt, June
1999, www.cs.columbia.edu/~jdrosen
10. Acknowledgments
11. Author's Addresses
J.Bjorkner,S.Nyckelgard [14]
Internet Draft vsua July 2000
Jorgen Bjorkner
Hotsip AB
Barnhusgatan 16
SE-111 23 Stockholm
Sweden
Phone: +46 70 666 23 26
Email: Jorgen.Bjorkner@Hotsip.com
Soren Nyckelgard
Telia Research AB
SE-123 86 Farsta
Sweden
Phone: +46 31 89 77 71
Email: Soren.M.Nyckelgard@telia.se
J.Bjorkner,S.Nyckelgard [15]
Internet Draft vsua July 2000
Full Copyright Statement
"Copyright (C) The Internet Society (date). 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
J.Bjorkner,S.Nyckelgard [16]
