Internet Draft H. Sinnreich, S. Donovan, D. Rawlins
draft-sinnreich-interdomain-sip-qos-osp-01.txt MCI Worldcom
February 2000 S. Thomas
Category: Informational Transnexus
Interdomain IP Communications with QoS, Authorization and Usage Reporting
1. 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.
2. Abstract
Commercial grade IP telephony requires linkage between call setup,
end-to-end QoS setup, interdomain authorization and accounting. This
draft considers the network model for inter-domain QoS for access and
transit networks, the service models and policy implementation
options. Also, interdomain authorization and accounting may require
the trust services of a clearinghouse, to which the local policy
server may outsource authorization for support for inter-domain
accounting.
The draft defines two options for QoS support for telephony: PSTN-
style "QoS Assured" or Internet-style "QoS Enabled" service.
Implementing the local policy or QoS deployment can also have two
options: The more usual policy "Pull Model" and the policy "Push
Model" that may be advantageous for large IP telephony gateway
deployments. The draft illustrates the various combinations of QoS
service and policy implementation for interdomain QoS with
authorization and accounting.
The inter-process communications between the SIP, SDP, RSVP and OSP
protocol engines is illustrated. Future work for SIP/SDP and other
extensions, QoS metric and policy is outlined to make interdomain QoS
for IP telephony possible.
draft-sinnreich-interdomain-sip-qos-osp-01.txt [Page 1]
Internet Draft Interdomain SIP QOS OSP March 2000
3. Content
1. Status of this memo................................................1
2. Abstract...........................................................1
3. Content............................................................2
4. Introduction.......................................................3
4.1 Background........................................................3
4.2 Purpose...........................................................3
5. Outline............................................................4
5.1 QoS Network Model.................................................4
5.1.1 Access Network Model............................................5
5.1.1.1. Network Elements.............................................6
5.1.1.2 Protocols....................................................8
5.1.1.3 Other QoS Models.............................................9
5.1.1.4 Policy Options Using COPS...................................10
5.1.1.5 Teardown Of QoS..............................................12
5.1.2 Transit Networks...............................................12
5.2 QoS Models for IP Telephony......................................15
5.2.1 Comparison between QoS Assured and QoS Enabled Calls...........15
5.3 SIP, Policy, RSVP and COPS Interworking..........................17
5.3.1 SIP Client Types and Policy Information Base for COPS..........17
6. Inter-Process Overview: SIP, OSP, RSVP, Cops Interworking.........17
6.1 SIP and OSP Interworking ........................................18
6.2 SIP and RSVP Policy Interworking.................................19
6.3 Call Teardown and Timer Expires..................................20
7. Message Exchanges and Inter-Process Overview......................20
7.2 Overview of Call Flow Examples..................................20
7.2.1 QoS Assured Calls..............................................21
7.2.1.1 QoS Assured Push Model - Setup and Session Expires Refresh..21
7.2.1.2 QoS Assured Push Model - Teardown and Session Expires........23
7.2.1.3 QoS Assured Pull Model - Setup..............................25
7.2.1.4 QoS Assured Pull Model Call Teardown.........................29
7.2.2 QoS Enabled Calls..............................................30
7.2.2.1 QoS Enabled Push Model Call Setup...........................32
7.2.2.2 QoS Enabled Push Model Call Teardown.........................33
7.2.2.3 QoS Enabled Pull Model Call Setup............................34
7.2.2.4 QoS Enabled Pull Model - Teardown...........................37
7.3 Generic QoS Usage Reporting to Clearing House....................39
7.4. Detailed Call Flows.............................................39
7.4.1 QoS Assured Push Call Setup....................................39
7.4.2 QoS Assured Push BYE...........................................49
7.4.3 OSP Messages for Usage Indication..............................53
8. Future Work.......................................................54
9. Conclusions.......................................................55
10. Acknowledgements.................................................55
11. References.......................................................55
12. Authors' Addresses...............................................58
draft-sinnreich-interdomain-sip-qos-osp-01.txt [Page 2]
Internet Draft Interdomain SIP QOS OSP March 2000
4. Introduction
There is a widespread belief that commercial IP telephony and other
IP communication services have to provide equal quality of service
(QoS) or better, when compared to digital circuit switched telephony.
This requires end-to-end QoS in corporate IP networks, by Internet
service providers (ISPs) and across the IP backbone that carries
traffic between the networks. QoS requires the usage of network
resources. Network administrators and service providers will make
resources available only if they can be assured that they will be
paid for the usage of resources. Payment is based on the
authorization of the parties participating in the communication and
on reporting the usage of network resources.
QoS delivery in the access networks is determined by local policy for
network usage. SIP servers act as policy enforcement points for SIP
calls. SIP call parameters such as end point addresses, call ID,
time, authorization requests and tokens have to be exchanged with
policy servers and trusted authorization and accounting servers to
install and tear down QoS policy in RSVP enabled routers and 802
style LANs.
As for transit networks, aggregation of RSVP into Differentiated
Services by edge routers is the mechanism to insure QoS.
4.1 Background
Providing IP communications with QoS across the Internet, between
various network operators, requires a common way of usage for call
setup, authorization, and QoS. Though the individual protocols have
been developed in detail, there is at present no reported work on how
to use them together in a consistent way across the Internet.
4.2 Purpose
This document describes the framework for linkage and provides
examples of the sequence of the individual messages of the various
protocols for IP communications with QoS and accounting. The
interchange of parameters between session setup, authorization,
policy, QoS and usage reporting will support quality IP
communications across the Internet, between ISPs, enterprise
networks, and individual clients.
draft-sinnreich-interdomain-sip-qos-osp-01.txt [Page 3]
Internet Draft Interdomain SIP QOS OSP March 2000
+--------------+
+-------|Clearing House|-------+
| +--------------+ |
| |
| |
+--+---+ +----------------+ +---+--+
|Policy| | | |Policy|
+-----+ |Server| | | |Server| +-----+
| SIP | | | | | | | |PSTN |
|Phone|--| SIP | | | | SIP |--| GWY |
+-----+ | Srv | | | | Srv | +-----+
| | | | | |
| Edge |--|Border Border|--| Edge |
|Router| |Router Router| |Router|
+------+ +----------------+ +------+
ISP-1 Transit ISP-2
Network
Fig. 1 Reference model for interdomain QoS support for IP telephony
5. Outline
5.1 QoS Network Model
Fig. 1 shows a simple network model for call setup, QoS, policy,
authorization and payments applicable for various real time IP
communications.
We will pursue this model for the specific application of IP
telephony. The model uses the following terminology:
Access Network: IP network to which users connect directly their
hosts/clients for IP communications or various servers for such
communications. The access network is part of a single
administrative domain, such as Internet Service Providers (ISPs),
corporate networks, government and educational organizations. See
the paragraph 5.1.1 on the Interdomain model for handling of QoS,
policy and the authentication and authorization of IP
communication clients in access networks [SIP-Auth].
draft-sinnreich-interdomain-sip-qos-osp-01.txt [Page 4]
Internet Draft Interdomain SIP QOS OSP March 2000
Transit Network: One or several transit networks may be in between
two or more access networks. Transit networks are sometime also
referred to as backbone networks, though the distinction is
somewhat fuzzy, since a transit network may also act as an access
network. For the model used here, a transit network has no
directly connected hosts for the particular session, be it
telephony or any other type. A transit network in this model has
no knowledge of individual microflows, such as phone calls between
parties connected to adjacent access network.
Service Level Specification (SLS): The machine readable agreement
between the access network provider and transit network provider
with regard to QoS and other features. Present SLS are of static
nature, though there is interest in signaling for dynamic delivery
of QoS between service providers, such as in the case of bandwidth
broker services.
Clearinghouse: Given the large number of access networks belonging
to different administrative domains, it is not possible to have
SLS between all domains on the Internet. Clearinghouses facilitate
the authorization and logging or accounting between domains for
premium services, such as QoS. This does not preclude however some
domains to have direct bilateral agreements, so as not to use any
clearinghouse service when exchanging traffic. The protocols used
in this draft apply equally well for the case of using
clearinghouses or for bilateral agreements. We will use the
examples with clearinghouses, since they render a more complete
image.
Premium Service Models: The notion of accounting for QoS supported
IP communications does not in any way imply that service charges
will be usage based, since this is a business decision left for
service providers. Authorization, logging and accounting for
individual microflows applies equally well for flat rate or usage
based service plans.
5.1.1 Access Network Model
Sophisticated mechanisms have been developed for QoS in private
IP networks, such as:
* Classification of packet flows, depending on the
application,
* Top priority in forwarding of voice packets between
routers.
draft-sinnreich-interdomain-sip-qos-osp-01.txt [Page 5]
Internet Draft Interdomain SIP QOS OSP March 2000
+---------------------+
+-------+ | +------+ |
| SIP |---| |Policy| |
| Phone | | | Serv | |
+-------+ | +-----+ +------+ |
+--------+ +--------+ | | SIP | |
+-----+ | PSTN | | PSTN | | |Proxy| |
|Phone|--| Switch |--| GWY |--| +-----+ +------+ |
+-----+ +--------+ +--------+ | | Edge | |
+--------+ | |Router| |To
|Computer|--| +-----+ +------+ |Transit
+--------+ | |802.3| |Network
+--------+ | | LAN | |--------
|Wireless|--| +-----+ |
| Device | | |
+--------+ +---------------------+
Fig. 2 Access network model for call setup, QoS and policy
Some of these techniques are however of proprietary nature and
therefore not suitable for interdomain operation across the
Internet. Other techniques are:
* Protocols [LSN] on slow links (less than 1 Mb/s) for
class mappings and header compression,
* Subnet Bandwidth Manager (SBM), for control of QoS in
802 style Ethernet LANs [SBM],
* Various protocols for QoS control of frame relay and
ATM layer 2 networks within the framework of the IETF
Integrated Services Architecture [ISSL].
These protocols are however not visible between domains. We
will for this reason mention only one of them, SBM, and
provide some examples for using it. An access network in
our model belongs to a single administrative domain for
delivery of Internet services. The intradomain network
model is shown in Figure 2.
5.1.1.1. Network Elements
Client: An IP phone, computer, mobile device or an IP
telephony gateway (GW) connecting to the Public Switched
Telephony Network (PSTN). The internal structure of the GW
and the master-slave protocols deployed between its
components; gateway controller and the media gateways, such
as MGCP or MEGACO/H.248 are not visible to this model, since
these protocols do not apply for interdomain end-to-end call
setup.
draft-sinnreich-interdomain-sip-qos-osp-01.txt [Page 6]
Internet Draft Interdomain SIP QOS OSP March 2000
SIP Server: The SIP proxy server acts on the behalf of and
provides services to all clients in the access network or
the administrative domain. Clients requesting call setup
have to be first registered with the SIP server, before
obtaining authorization for QoS supported calls. See
[Sparks] for the registration of SIP clients. After
registration with the SIP server, the server may handle all
call requests to/from that client. This does not exclude
however direct client-client call setup without the benefits
of any SIP server. Such direct client-client call setups can
be faster and may be desirable for special services, such as
the equivalent of the hot line. Clients that are not
registered and authorized for direct calling, cannot have
the QoS benefit via the support from the SIP and policy
servers.
Policy Server: In the context of this paper, the policy
server acts to control policy for all QoS usage by all types
of clients. We assume the policy server to be independent of
any particular application, such as telephony, media
applications (radio/TV), games, etc.
The policy server (1) authorizes internal QoS for microflows
and (2) may communicate for telephony with an outside
clearinghouse, or (3) directly with an outside policy server
in the correspondent administrative domain.
Local Router: Any IP router in the path of packets between a
voice client and the edge router connecting to the outside
of the access network. Local routers have to be RSVP enabled
for QoS delivery.
Edge Router: The edge router has some of the most
interesting functions for QoS premium services, since it
acts as gate for QoS support for clients requesting service.
The edge router performs the following functions:
* Acts as policy enforcement point (PEP) under control of
the policy server to accept or reject RSVP requests for
clients,
* Aggregates all RSVP flows into classes of
Differentiated Services (DS), the RSVP DCLASS Objects,
* Provides traffic shaping,
* Communicates with the correspondent border router in
the transit network, so that aggregated DS packet streams
are passed on for transit outside the access network.
* May control adjacent layer two subnets and switches to
implement QoS as signaled by RSVP.
draft-sinnreich-interdomain-sip-qos-osp-01.txt [Page 7]
Internet Draft Interdomain SIP QOS OSP March 2000
Layer 2 Devices: 802 style LANs may implement QoS under RSVP
control. Other layer two networks such as point to points
access links, frame relay and ATM switches may also serve to
implement QoS within the framework of the IETF integrated
services architecture [ISSL].
5.1.1.2 Protocols
Session Initiation Protocol (SIP): To set up telephony calls
and other Internet multimedia sessions [RFC 2543]. Other
signaling protocols, such as H.323 could also be used, but
the message exchange shown in this draft would not apply.
Session Description Protocol (SDP): SDP is used by SIP in
the context of QoS to describe the capabilities of the
client and other properties of the session [SDP-QoS].
Open Settlement Protocol (OSP): Used between policy servers
and clearing house for pricing, usage exchange and
settlements for services [OSP ETSI], [OSP IETF].
Common Open Policy Service (COPS): Used between the policy
server and other network elements to communicate policy
applicable for microflows that have QoS support [ COPS].
Resource Reservation Protocol (RSVP): Signaling protocol to
request QoS from the network. RSVP is an end-to-end
signaling protocol and can be used between corresponding
telephony clients in the respective domains [RSVP].
Differentiated Services (DS): Highly scalable architecture
for Internet transit networks. Scalability is based on
classes of traffic, rather than QoS enabled virtual circuits
[DS].
Subnet Bandwidth Manager (SBM): SBM is used to control
Ethernet switches in 802.1p style networks. SBM is an
essential component for QoS support, but will not be
detailed here any further, since it is not visible in
interdomain message exchanges [SBM].
Other terminology of interest is:
RSVP Aggregation: The edge router or another designated RSVP
aggregator will aggregate the individual RSVP flows into a
Differentiated Services Code Point (DSCP) [RSVP-Aggr].
draft-sinnreich-interdomain-sip-qos-osp-01.txt [Page 8]
Internet Draft Interdomain SIP QOS OSP March 2000
RSVP aggregation can also result in an aggregate RSVP path
to the remote network. The remote edge router or RSVP proxy
in the remote network will deaggregate the individual
microflows. This is of interest for IP telephony, since
header compression can be applied on such aggregate paths,
resulting in a significant enhancement of bandwidth
efficiency. Given the emerging state of this technology, it
will not be pursued in examples in this draft.
Traffic shaping: The edge router has also the function of
traffic shaping, to delay packets within various traffic
streams so as to enforce the service level specification.
Care is required, to avoid the delay for voice packets for
any shaping settings on links such as frame relay between
the access and transit networks.
5.1.1.3 Other QoS Models
We have used the standard end-to-end RSVP approach across
the Internet in this draft, though there are other
approaches that have been proposed or are commercially
available as proprietary implementations. The main non-end-
to-end RSVP approaches known to the authors are:
* Segmented RSVP [DCSGRP], [SEGM-RSVP]
* Border Gateway Routing Protocol [BGRP],
* SIP based path selection in MPLS networks [Gibson],
* Proprietary precedence based on strict priority for
voice.
We believe however that within the limits of present
standards based implementations, end-to-end RSVP in access
networks and Differentiated Services in transit networks can
be optimized and simplified so as to offer valid near term
solutions for real time IP communications.
Some of the alternate approaches to RSVP merit further
investigation and can be useful under various assumptions.
Strict precedence for voice for example facilitates simple
and robust QoS implementation in private IP networks where
policy control and accounting for individual are not
required. Extending strict priority for voice between
different domains across the Internet would however prevent
service providers from exercising policy control and
accounting, and thus would take away the incentive to deploy
QoS in the first place.
draft-sinnreich-interdomain-sip-qos-osp-01.txt [Page 9]
Internet Draft Interdomain SIP QOS OSP March 2000
Furthermore, the model of strict or high priority service
without policy and accounting may be open ended when applied
for high bandwidth applications such as video.
5.1.1.4 Policy Options Using COPS
We will review here the main options for policy
administration in the access network.
Policy Control of Network Elements
The edge router and other local routers in the path of the
SIP client can have
a. Locally provisioned policy, or
b. Outsourced policy to a policy server using COPS.
COPS Policy Control Models
Implementation of policy can be accomplished in several
ways. We will discuss here the policy push and policy pull
models and compare their suitability for SIP based call
setup. The basic sequence of events is explained in this
section and detailed examples are given in section 7.
Push Model
In response to a SIP INVITE, or from any other application
layer request, the policy server pre-installs policy in the
edge and local routers The installation of policy in the
push model is part of the following sequence:
* SIP client sends INVITE to SIP proxy,
* SIP proxy queries the policy server,
* Policy server queries
* Local policy database about the ID and services for
the user,
* Clearinghouse server or policy server in
corresponding network,
* Upon positive acknowledgement, the policy server
installs policy in network elements to accept the RSVP
PATH and RESV requests for the particular flow to the SIP
client.
Outsourcing of the policy decisions of network elements to
the policy server requires a Policy Information Base (PIB)
in the policy server.
draft-sinnreich-interdomain-sip-qos-osp-01.txt [Page 10]
Internet Draft Interdomain SIP QOS OSP March 2000
Pull Model
Network elements initiate a COPS query to the policy server.
The sequence of events is slightly different at the
beginning only:
* Network element receives RSVP PATH or RESV request,
* Network element queries the policy server,
* The policy server queries
* Local database about ID and services for the user,
* Clearinghouse server or policy server in corresponding
network,
* Upon positive acknowledgement, the policy server
confirms policy in network elements to accept RSVP PATH
and RESV requests for the particular flow to the SIP
client.
The query of the policy server by various network elements
represents extra messaging overhead compared to the push
model and may also add extra delay in the setup of QoS.
A comparison of the push and pull approaches is given here:
The Push Approach
* The RSVP local policy reduces the serial delay
encountered with the COPS-RSVP REQUEST/ DECISION exchanges
during RSVP outsourcing policy control to the policy
server,
* It requires new behavior in the RSVP network elements
to accommodate configuration of local decision policy,
* Requires network topology knowledge to determine the
network elements needing the local decision policy.
It may be preferable to use the push model for QoS setup in
order to reduce the messaging overhead and the resulting QoS
setup delay increase. The push model offers the lowest
possible call setup delay, but requires protocol work and
its implementation in the network.
The push approach makes sense in compact, but high
performing networks, such as found in service provider
centers locating IP telephony gateways. Configuration of the
topology to optimize performance is doable in such
environments.
draft-sinnreich-interdomain-sip-qos-osp-01.txt [Page 11]
Internet Draft Interdomain SIP QOS OSP March 2000
The Pull Approach
* Introduces additional messaging resulting from the RSVP
edge router outsourcing policy control to the policy
server.
* Does not require any additional protocol work. It uses
existing COPS [COPS] and RSVP [RSVP] protocols.
* Does not require knowledge of network topology.
The pull approach is therefore preferable for faster time to
market for QoS and also for lower development and deployment
costs in the network.
The pull approach may be more convenient for large corporate
networks with a complex topology, where avoidance of
configuration is a high priority.
5.1.1.5 Teardown Of QoS
The SIP session ends when a BYE message is received or when
the Session Timer expires.
* The SIP proxy server will send an DRQ OSP request to
the policy server,
* The policy server
* Informs the clearing house about session duration for
accounting,
* De-installs the policy for the session in the network
elements with a COPS decision (DEC) remove (REM)
command,
* The edge router sends
* RESVTEAR command to the SIP client,
* PATHTEAR command to the upstream network elements.
5.1.2 Transit Networks
Real-time interactive applications have end-to-end performance
requirements that are more exacting than applications that have
been the dominant Internet traffic sources to date. Though the
end-to-end performance requirements for emerging applications
are not yet thoroughly understood and quantified, there is
strong reason to believe that the incorporation of QoS controls
that can match network performance to a range of application
requirements will fuel diversity in emerging applications and
extend the utility of the Internet protocol suite.
draft-sinnreich-interdomain-sip-qos-osp-01.txt [Page 12]
Internet Draft Interdomain SIP QOS OSP March 2000
One of the difficulties in adding QoS controls is to be able to
implement them so the mechanisms have scaling properties that
are suitable to high-capacity infrastructure with resources
being shared by enormous numbers of simultaneous traffic flows.
To this end, hierarchy can be incorporated into the IP QoS
model to great advantage when used in conjunction with traffic
engineering principals. Use of hierarchy in the QoS model is
motivated by the difficulty of installing and maintaining per-
microflow state in any device that processes highly aggregated
traffic. Fortunately the statistical properties of highly
aggregated traffic flows generally makes the maintenance of
per-microflow state unnecessary to provide adequate end-to-end
performance, even for applications such as telephony. Though
individual networks may vary greatly, generally where the
following conditions hold, a "static" allocation of resource
per traffic class is sufficient to give a high statistical
assurance of adequate end-to-end service:
* A large number of micro-flows sharing resources during
periods of peak load,
* No single micro-flows large enough to utilize a large
percentage of a potentially congested resource,
* The total amount of traffic in the network receiving
priority over best-effort traffic is relatively low.
These characteristics can be expected to apply to large
Internet backbones as they deploy this QoS model.
A useful reminder is that QoS does not create bandwidth.
Rather, premium services prioritize the delivery of certain
IP packets at the expense of packets belonging to best
effort traffic. In case of heavy traffic, packets tagged
with "coach class" best effort traffic (no special tags
required), will suffer from degraded network performance.
Service providers will assure either enough network capacity
or limit the subscription levels, so that even best effort
traffic is an acceptable service for applications that are
not real time sensitive, such as ftp, mail or web browsing.
We will list here only some features of transit networks of
interest to this draft
* For scalability reasons, transit networks have to be
unaware of individual microflows and the associated RSVP
messages and processing. RSVP is tunneled through transit
networks.
draft-sinnreich-interdomain-sip-qos-osp-01.txt [Page 13]
Internet Draft Interdomain SIP QOS OSP March 2000
* Transit networks are not visible to end users, except
when end-to-end QoS cannot be provided. The access network
does not need to understand what QoS mechanism operates in
the transit network and vice versa; the only common
element between them is the service level specification.
* Transit networks are protected from theft of premium
QoS service by border routers facing the access networks.
* The egress border router in Fig. 1 can be a point of
congestion, if traffic to a destination access network
exceeds the physical capacity of the access link. We are
not aware of a deterministic solution to this problem,
though it can be addressed by proper capacity
provisioning.
Service Level Specification: In the context of this draft,
the SLS specifies the Differentiated Services Code Points
(DSCPs) for various classes of traffic passing the transit
network. Present SLSs are of static nature, though there is
recent interest in dynamic SLS supported by signaled QoS for
traffic at the ingress and egress points of transit
networks.
Border Routers: The transit network is protected as
mentioned against theft of service and of possible denial of
service attacks by border routers facing edge routers in the
adjacent access network (Fig. 1). Traffic between edge
routers and border routers is protected by physical security
of the data link. The border router polices the ingress
traffic from the edge router in the access network and in
case of excess, out of profile traffic, remarks the DS
packets as best effort traffic. Out of profile packets can
be dropped in case of congestion.
Certain service models allow the edge router and border
router functions to be placed into a single physical unit.
In this case the transit network service provider has
control over the traffic admission policy at the ingress
into the transit network.
draft-sinnreich-interdomain-sip-qos-osp-01.txt [Page 14]
Internet Draft Interdomain SIP QOS OSP March 2000
5.2 QoS Models for IP Telephony
We consider here three main classes of service for IP telephony:
* Best effort packet delivery: Such service may be acceptable
in high bandwidth networks during non-peak traffic times. Best
effort service may however be unsatisfactory on slow access
links (less than 1-2 Mb/s) when voice packets may be delayed due
to other types of long data packets.
* QoS Assured: The telephone call will complete only after all
the network resources required for a specified QoS are assured
by such means as a successful RSVP reservation end-to-end.
* QoS Enabled: When only partial or no QoS is available, the
caller could receive messages, such as: "Sorry, we cannot
guarantee complete quality for this call, <reason code>, would
you like to continue anyway?" Reasons to inform the customer
could be:
- No end-to-end guarantee quality of service, or
- Temporary high traffic.
The application in the IP telephony device must be prepared to
respond appropriately while the session is in progress. The RSVP
state in the network may not be terminated only with a SIP BYE,
but also by the session timer or by the application when it senses
no more media flow. This has consequences for accounting of the
call.
5.2.1 Comparison between QoS Assured and QoS Enabled Calls
Both the QoS Assured and QoS Enabled models provide a QoS
mechanism for the session based on RSVP. They differ in that
the QoS Assured integrates the RSVP policy control into the SIP
session establishment.
Both models:
* Provide end to end QoS,
* Introduce a new outsourcing COPS client type to support
policy coordination with the clearinghouse for authorization
and usage reporting,
* Require aggregation to be scalable for transit networks.
The QoS Assured model:
* Ensures that acceptable QoS is available prior to the call
proceeding,
draft-sinnreich-interdomain-sip-qos-osp-01.txt [Page 15]
Internet Draft Interdomain SIP QOS OSP March 2000
* Ensures the RSVP QoS teardown is coordinated with the SIP
session teardown,
* Introduces RSVP messages into the call setup and
subsequently introduces additional delay into the session
setup,
* Requires an additional COPS REQUEST message type for
exchanging media description information to the policy
server.
The QoS Enabled model:
* Permits call setup to proceed but may result in the
initial portion of the session being impacted by impairments
from not having QoS such as voice clipping and distortion,
* Does not coordinate the SIP session termination with RSVP
teardown.
Overall, the trade-off between the two models is control versus
call setup delay and protocol impact.
* The QoS Assured model provides tight SIP initiated QoS
control at the cost of higher session setup delay and
additional protocol development.
* The QoS Enabled model provides QoS for the session without
delays to the setup. However, there may be voice clipping at
the beginning of the call. At the end of the call, the media
stream could still have access to RSVP established QoS after
the SIP session has terminated.
There are intermediate models between the extremes of QoS
assured and QoS enabled that are shown in section 7. We will
however discuss and provide examples the extreme different
cases so as to highlight the differences.
Without the SIP triggering of the policy in the policy server,
it is not possible to control resource usage on a per port
basis. The only policy that could be put into the policy
server would be to allow all packets from a device, independent
of port/application. A device could therefore use elevated QoS
resources when using the non well-known ports that are used by
RTP. This may not present a problem in enterprise networks
where call usage is neither restricted nor recorded, but is not
acceptable in ISP networks where usage is recorded and may be
restricted.
At this point in time, the authors of this draft are themselves
divided as which model, one of the extremes - QoS Assured/QoS
Enabled, or some intermediate make more sense to be the default
QoS IP telephony service.
draft-sinnreich-interdomain-sip-qos-osp-01.txt [Page 16]
Internet Draft Interdomain SIP QOS OSP March 2000
5.3 SIP, Policy, RSVP and COPS Interworking
5.3.1 SIP Client Types and Policy Information Base for COPS
The inter-domain QoS policy requires three potential additions
to COPS.
The first addition is to support AAA functions. Each of the
inter-domain examples presented in this document contains a
COPS exchange between the SIP server and policy server for
authorization and accounting information. The PDP resolves the
request using a clearinghouse. This type of messaging requires
a new COPS client type that uses the policy outsourcing
approach.
Secondly, the Assured Model and push approach require a new
COPS client type to define the media and QoS information
exchanged between the SIP server and policy server. This COPS
client type supports an outsourcing REQUEST LDP/Assured to
exchange the media description information.
The third COPS inter-domain addition is a new Policy
Information Base module that defines the RSVP local decision
policy. This PIB module uses the existing COPS-Provisioning
protocol to configure the local decision policy into the edge
routers.
COPS is designed to accommodate additional client types and
Policy Information Base modules, so these inter-domain
additions do not require a change to the current
implementations of the protocol.
6. Inter-Process Overview: SIP, OSP, RSVP, Cops Interworking
The coordination policy for the clearinghouse authorization, QoS, SIP
session establishment and usage reporting is accomplished by the
interworking of the SIP, RSVP, OSP and COPS protocols. The
authorization information is passed in the COPS exchanges between the
SIP server and policy server. It then is exchanged via OSP with the
clearinghouse.
The media descriptions can be exchanged between the SIP server and
policy server using COPS. The policy server then coordinates RSVP QoS
policy using COPS with the network elements. Usage information at the
end of the call is exchanged between the policy server and
clearinghouse using OSP and is based on collection of QoS usage
information via COPS.
draft-sinnreich-interdomain-sip-qos-osp-01.txt [Page 17]
Internet Draft Interdomain SIP QOS OSP March 2000
The QoS can be indicated in the Session Description Protocol (SDP)
part of the SIP message as described in [SDP-SIP].
6.1 SIP and OSP Interworking
A SIP server can outsource an AAA request REQ OSP to a policy
server, which in turn can outsource it to another server, such as
a clearinghouse server using OSP. The parameters passed between
the processes are illustrated here.
Calling party requests authorization:
From SIP to OSP to authorize a call, REQ OSP to <AuthReq>
- SIP Call ID,
- Called Number,
- Calling Number.
Decision from OSP to SIP, <AuthRsp> to DEC
- Called Number (in case there is a number translation in the
OSP server),
- Authorization Token.
Called party requests authorization:
The called party has received an INVITE message that contains an
authorization token from a server with which it has a trust
relationship. This token will be used for usage reporting to the
trusted server, to prove that it was an authorized call.
From SIP to OSP to authorize an incoming call, REQ OSP to OSP
<AuthReq>
- SIP Call ID,
- Called Number,
- Calling Number,
- Authorization Token.
Usage Indication:
Calling and called parties request de-installation of QoS policy
from the respective local policy servers. This event triggers
usage reporting to the OSP server and receipt of usage report. The
parameters passed to the policy server in the DRQ OSP. The OSP
<UsageInd> parameters are
- Duration of Call,
- Called Number (if not cached from REQ),
draft-sinnreich-interdomain-sip-qos-osp-01.txt [Page 18]
Internet Draft Interdomain SIP QOS OSP March 2000
- Calling Number (if not cached from REQ),
- SIP Call ID (if not cached from REQ),
- Authorization Token.
6.2 SIP and RSVP Policy Interworking
In the Assured Model, the Sip server outsources QoS policy to the
policy server with a REQ Assured /LDP. The REQ contains the media
description information. In the pull approach, the media and QoS
is referenced during the RSVP signaling to ensure that the flow
correlates to the one approved during the SIP Session
Establishment. The correlation is done via the QoS information in
the SDP message carried by SIP. In the push approach, the media
and QoS information is provisioned into the edge router(s)
associated with the flow.
An overview of the parameters passed between these processes is
described here.
SIP server retains the caller media information from the INVITE
and receives callee media information in the SIP 183 message.
From SIP to policy server, REQ Assured/LDP coveys the data:
- SIP Call ID,
- caller media address /QoS,
- callee media address /QoS.
The decision returned is returned from the policy server to the
SIP server.
The policy server retains the media information for the call id
and uses it to approve outsourced QoS policy or to provision RSVP
Local Decision Policy.
The push approach, whether for the QoS Assured Push Model or QoS
Enabled Push Model, requires a Policy Information Base (PIB)
defining the RSVP Local Decision Policy rules for the flow. This
information is provisioned (pushed) using the existing COPS-PR
protocol. The local decision policy for the flow includes data
such as:
* Access Control Entry (ACE), source and destination address of
the calller and callee flows,
* Caller/callee token rates, token bucket sizes, peak rate,
* Caller/callee service name,
* Caller/callee Rspec rate and slack.
draft-sinnreich-interdomain-sip-qos-osp-01.txt [Page 19]
Internet Draft Interdomain SIP QOS OSP March 2000
6.3 Call Teardown and Timer Expires
We have seen that call setup has two prominent models: QoS Assured
and QoS Enabled.
Call teardown has also two prominent models: Default and the SIP
Session Timer Expires.
Many behavior models can be developed based on combining the
above. Setting the SIP Session Timer allows for example to
establish a pre-determined duration for the call.
7. Message Exchanges and Inter-Process Overview
The message exchanges for the protocols listed above are well
documented and understood when each is used in isolation. This is not
the case when using them all together. We will exemplify here the
inter-process dependencies when these protocols are used together for
inter-domain IP communications. Call flows without QoS have been
published and [SIP-CALL-FLOWS], [SIP-SERVICES] and [VOICE MAIL] and
we use here similar call flows, but have added the QoS , COPS and OSP
related messages.
The sequence in the message exchanges is not arbitrary. The
parameters communicated in a previous message are used in the
subsequent message. For example, the origination and destination URLs
in the initial INVITE message are used for authorizing the call. The
authorization token is then used to establish/install policy in the
network, etc.
We will assume that before initiating a call, both the SIP client and
the user have been authenticated. Client and user authentication for
SIP initiated IP communications are described in [SIP-AUTH] and will
not be repeated here.
7.2 Overview of Call Flow Examples
An overview of the call flow options for the various models is
given in table 1. Figures 3-12 provide examples of interest. Other
call flows may meet the needs of various types of services, but we
believe the illustrated exampled to provide some guidance on the
basic options. Usage indication is provided by OSP messages at the
end of the call [OSP-ETSI], [OSP-IETF].
draft-sinnreich-interdomain-sip-qos-osp-01.txt [Page 20]
Internet Draft Interdomain SIP QOS OSP March 2000
QoS Assured QoS Enabled
Call Setup Push Fig. 3 Fig. 7
Pull Fig. 5 Fig. 10
Call Teardown Push Fig. 4 Fig. 8, 9
Pull Fig. 6 Fig. 11
Usage Indication Fig. 12
Table 1 Overview of push/pull policy models and QoS options
7.2.1 QoS Assured Calls
The Assured QoS example represents a SIP initiated and
controlled QoS policy. The integration of the QoS signaling
with the SIP signaling by the application provides feedback
during call setup on whether the media streams receive the
requested QoS. The SIP application is able to react according
to this feedback received during call setup. This integration
also provides a mechanism for SIP to dynamically initiate
policy control for the call by providing call specific data
such as the media description to the policy server. This
information is used by the policy server to administer the
enforcement of media stream access to QoS. The information is
also used later for SIP initiated RSVP state removal. After
call establishment, the re-negotiation of QoS can be
accomplished by following the same mechanism as used for call
set-up.
This QoS Assured approach introduces additional messaging which
extends the call setup period. The integration of RSVP and SIP
has some impact to the SIP protocol and the SIP application
client. It also requires definition of the new COPS client type
for the SIP QoS assured call setup.
7.2.1.1 QoS Assured Push Model - Setup and Session Expires
Refresh
The following call flow illustrates the Assured Push Model
which integrates the RSVP with the SIP signaling and
provisions RSVP local decision policy into the network
element a priori of the RSVP messaging for the flow. RSVP
session setup for the two directions appear in the diagram
as in sequence, but they are really proceeding independently
in each domain.
draft-sinnreich-interdomain-sip-qos-osp-01.txt [Page 21]
Internet Draft Interdomain SIP QOS OSP March 2000
+-----+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
| SIP | |SIP| |POL| | R | |CH | | R | |POL| |SIP| |GWY|
|Phone| | 1 | | 1 | | 1 | | | | 2 | | 2 | | 2 | | |
+-----+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
| 1 | | | | | | | |
|INVITE | 2 | | | | | | |
|------>|REQ OSP 3 | | | | |
| |----->| <AuthReq> | | | | |
| | |------------>| | | | |
| | | 4 | | | | |
| | | <AuthReq> | | | | |
| | 5 |<------------| | | | |
| | DEC | | 6 | | | |
| |<-----| | INVITE | | | 7 |
| |---------------------------------------->|INVITE|
| | | | | | | |----->|
| | | | | | | 9 REQ| 8 |
| | | | | | 10 |Assure| 183 |
| | | | | | DEC | /LDP |<-----|
| | | | | | LDP |<-----| |
| | | | | |<-----| | |
| | | | | | 11 | | |
| | | | | | RPT | 12 | |
| | | | | |----->| DEC | |
| | | | 13 183 | |----->| |
| |<----------------------------------------| |
| |14 REQ| | | | | | |
| |Assure| 15 | | | | | |
| | /LDP | DEC | | | | | |
| |----->| LDP | | | | | |
| | |----->| | | | | |
| | 17 |16 RPT| | | | | |
| 18 | DEC |<-----| | | | | |
| 183 |<-----| | | | | | |
|<------| | | | | | | |
- continue call setup -
Fig.3 QoS Assured Call setup - push model
draft-sinnreich-interdomain-sip-qos-osp-01.txt [Page 22]
Internet Draft Interdomain SIP QOS OSP March 2000
+-----+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
| SIP | |SIP| |POL| | R | |CH | | R | |POL| |SIP| |GWY|
|Phone| | 1 | | 1 | | 1 | | | | 2 | | 2 | | 2 | | |
+-----+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
| | | | | | | | |
| 19 PATH/SBM | 20 PATH | 21 PATH/SBM |
|====================>|------------>|===================>|
| | | | | | | | |
| 24 RESV/SBM | 23 RESV | 22 RESV/SBM |
|<====================|<------------|<===================|
| | | | | | | | |
| 25 RESV-CONF/SBM |26 RESV-CONF | 27 RESV-CONF/SBM |
|====================>|------------>|===================>|
| | | | | | | | |
| 30 PATH/SBM | 29 PATH | 28 PATH/SBM |
|<====================|<------------|<===================|
| | | | | | | | |
| 31 RESV/SBM | 34 RESV | 33 RESV/SBM |
|====================>|------------>|===================>|
| | | | | | | | |
| 36 RESV-CONF/SBM |35 RESV-CONF | 34 RESV-CONF/SBM |
|<====================|<------------|<===================|
| | | | | | | | 37 |
| | | | | | | | 180 |
| 39 | | 38 180 | | | |<-----|
| 180 |<----------------------------------------| 40 |
|<------| | | | | | |200 OK|
| 42 | | 41 200 OK | | |<-----|
| 200 OK|<----------------------------------------| |
|<------| | | | | | | |
|43 ACK | | | | | | | |
|------>| | | 44 ACK | | | |
| |---------------------------------------->|45 ACK|
| |----->|
| Hello! (RTP established both ways) | |
|<======================================================>|
Figure 3.a QoS Assured push setup and completing the call
7.2.1.2 QoS Assured Push Model - Teardown and Session Expires
QoS removal is signaled by SIP and RSVP mechanisms. The SIP
teardown mechanisms include
1) the user agent application issuing a BYE to end the
session (reference Fig. 4 QoS assured push BYE) or,
2) BYE cannot be provided due to some failure. In this
case the session timer in the SIP proxy will terminate tha
call [Timer].
draft-sinnreich-interdomain-sip-qos-osp-01.txt [Page 23]
Internet Draft Interdomain SIP QOS OSP March 2000
In the QoS Assured Push Model, the policy server initiates
removal of the local decision policy from the router during
a SIP initiated session teardown.
+-----+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
| SIP | |SIP| |POL| | R | |CH | | R | |POL| |SIP| |GWY|
|Phone| | 1 | | 1 | | 1 | | | | 2 | | 2 | | 2 | | |
+-----+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
| | | | | | | | |
| | | | Good Bye! | | | |
|<======================================================>|
| BYE | | | | | | | |
|------>| | | BYE | | | |
| |---------------------------------------->| |
| |DRQ OSP | | | | | |
| |----->| | | | | | |
| | DRQ | | | | | | |
| |As/LDP| DEC | | | | | |
| |----->|REM LDP | | | | |
| | |----->| | | | | |
| | | RPT | | | | | |
| | |<-----| | | | | |
| RESVTEAR/SBM | | | | | |
|<====================| PATHTEAR | | | |
| | | |------------>| PATHTEAR/SBM| |
| | | | | |===================>|
| | | | | | | | BYE |
| | | | | | | DRQ |----->|
| | | | | | DEC |As/LDP| |
| | | | | |REM LDP<-----| |
| | | | | |<-----| | |
| | | | | | RPT | | |
| | | | | |----->| | |
| | | | | | | | |
| | | PATHTEAR | RESVTEAR/SBM |
| PATHTEAR/SBM |<-------------------|===================>|
|<=============| | | | | |200 OK|
| | | | 200 OK | | |<-----|
|200 OK |<----------------------------------------| |
|<------| | | | | | | |
Fig. 4 QoS Assured push BYE with background usage update
De-installation of polcy is not dependent on the PATHTEAR
message, but is triggered by the BYE message or by the
session timer in the respective SIP server.
draft-sinnreich-interdomain-sip-qos-osp-01.txt [Page 24]
Internet Draft Interdomain SIP QOS OSP March 2000
7.2.1.3 QoS Assured Pull Model - Setup
The QoS Assured Pull Model coordinates the QoS policy with
the SIP signaling during the call setup. Initially, the
Clearinghouse policy is determined for the call. Then, the
SIP media access and feature information is dynamically
relayed to the policy server in the COPS REQUEST Assured.
Finally, the QoS resource policy is outsourced by the RSVP
edge router during the RSVP signaling phase using COPS.
+-----+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
| SIP | |SIP| |POL| | R | |CH | | R | |POL| |SIP| |GWY|
|Phone| | 1 | | 1 | | 1 | | | | 2 | | 2 | | 2 | | |
+-----+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
| 1 | | | | | | | |
|INVITE | 2 | | | | | | |
|------>|REQ OSP 3 | | | | |
| |----->| <AuthReq> | | | | |
| | |------------>| | | | |
| | | 4 | | | | |
| | | <AuthRsp> | | | | |
| | 5 |<------------| | | | |
| | DEC | | 6 | | | |
| |<-----| | INVITE | | | 7 |
| |---------------------------------------->|INVITE|
| | | | | | | |----->|
| | | | | | | | 8 |
| | | | | | |9 REQ | 183 |
| | | | | | |Assure|<-----|
| | | | | | |<-----| |
| | | | | | |10 DEC| |
| | | | 11 183 | |----->| |
| |<----------------------------------------| |
| |12 REQ| | | | | | |
| |Assure| | | | | | |
| |----->| | | | | | |
| |13 DEC| | | | | | |
| |<-----| | | | | | |
|14 183 | | | | | | | |
|<------| | | | | | | |
- continue call setup -
Fig.5 QoS Assured call setup - pull model
draft-sinnreich-interdomain-sip-qos-osp-01.txt [Page 25]
Internet Draft Interdomain SIP QOS OSP March 2000
- call setup continued -
+-----+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
| SIP | |SIP| |POL| | R | |CH | | R | |POL| |SIP| |GWY|
|Phone| | 1 | | 1 | | 1 | | | | 2 | | 2 | | 2 | | |
+-----+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
| 15 PATH/SBM | | | | | |
|====================>| | | | | |
| | |16 REQ| | | | | |
| | | PATH | | | | | |
| | |<-----| | | | | |
| | |17 DEC| 18 PATH |19 REQ| | |
| | |----->|------------>| PATH | | |
| | | | | |----->| | |
| | | | | |20 DEC| | |
| | | | | |<-----| | |
| | | | | | 21 PATH/SBM |
| | | | | |===================>|
| | | | | | 22 RESV/SBM |
| | | | | |<===================|
| | | | | |23 REQ| | |
| | | | | | RESV | | |
| | | | | |----->| | |
| | | | | |24 DEC| | |
| | | | | |<-----| | |
| | | | | |25 RPT| | |
| | |27 REQ| 26 RESV |----->| | |
| | | RESV |<------------| | | |
| | |<-----| | | | | |
| | |28 DEC| | | | | |
| | |----->| | | | | |
| | |29 RPT| | | | | |
| | |<-----| | | | | |
| 30 RESV/SBM | | | | | | |
|<====================| | | | | |
| 31 RESV-CONF/SBM |32 RESV-CONF | 33 RESV-CONF/SBM |
|====================>|------------>|===================>|
- continue call flow -
Fig.5a QoS Assured pull - call setup
draft-sinnreich-interdomain-sip-qos-osp-01.txt [Page 26]
Internet Draft Interdomain SIP QOS OSP March 2000
- call setup continued -
+-----+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
| SIP | |SIP| |POL| | R | |CH | | R | |POL| |SIP| |GWY|
|Phone| | 1 | | 1 | | 1 | | | | 2 | | 2 | | 2 | | |
+-----+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
| | | | 34 PATH/SBM |
|<====================| | |<===================|
| | | | | |35 REQ| | |
| | | | | | PATH | | |
| | | | | |----->| | |
| | |38 REQ| 37 PATH |36 DEC| | |
| | | PATH |<------------|<-----| | |
| | |<-----| | | | | |
| | |39 DEC| | | | | |
| | |----->| | | | | |
| 40 PATH/SBM | | | | | | |
|<====================| | | | | |
| 41 RESV/SBM | | | | | | |
|====================>| | | | | |
| | |42 REQ| | | | | |
| | | RESV | | | | | |
| | |<-----| | | | | |
| | |43 DEC| | | | | |
| | |----->| | | | | |
| | |44 RPT| | | | | |
| | |<-----| 45 RESV | | | |
| | | |------------>|46 REQ| | |
| | | | | | RESV | | |
| | | | | |----->| | |
| | | | | |47 DEC| | |
| | | | | |<-----| | |
| | | | | |48 RPT| | |
| | | | | |----->| | |
| | | | | | | 49 RESV/SBM |
| | | | | |===================>|
| 52 RESV-CONF/SBM |51 RESV-CONF | 50 RESV-CONF/SBM |
|<====================|<------------|<===================|
- continue call flow -
Figure 5.b QoS Assured pull - completing the call setup
draft-sinnreich-interdomain-sip-qos-osp-01.txt [Page 27]
Internet Draft Interdomain SIP QOS OSP March 2000
- call setup continued -
+-----+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
| SIP | |SIP| |POL| | R | |CH | | R | |POL| |SIP| |GWY|
|Phone| | 1 | | 1 | | 1 | | | | 2 | | 2 | | 2 | | |
+-----+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
| | | | | | | | |
| | | | | | | |53 180|
| | | | | | | |<-----|
| | | | 54 180 | | | |
| |<----------------------------------------| |
|55 180 | | | | | | | |
|<------| | | | | | |56 200|
| | | | | | | | OK |
| | | | 57 200 OK | | |<-----|
|58 200 |<----------------------------------------| |
| OK | | | | | | | |
|<------| | | | | | | |
|59 ACK | | | | | | | |
|------>| | | 60 ACK | | | |
| |---------------------------------------->|61 ACK|
| | | | | | | |----->|
| Hello! (RTP established both way) | |
|<======================================================>|
Figure 5.c QoS Assured pull - completing the call setup
draft-sinnreich-interdomain-sip-qos-osp-01.txt [Page 28]
Internet Draft Interdomain SIP QOS OSP March 2000
7.2.1.4 QoS Assured Pull Model Call Teardown
In the QoS Assured Session Pull Model, when session teardown
is initiated by SIP, the removal of the associated RSVP
flows is accomplished by the policy server issuing decisions
to remove the installed Path and Resv State associated with
the flow. The RSVP state that is removed is determined by
the policy state information created based on the SIP
initiated COPS REQUEST Assured.
+-----+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
| SIP | |SIP| |POL| | R | |CH | | R | |POL| |SIP| |GWY|
|Phone| | 1 | | 1 | | 1 | | | | 2 | | 2 | | 2 | | |
+-----+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
| | | | | | | | |
| | | | Good Bye! | | | |
|<======================================================>|
| BYE | | | | | | | |
|------>| | | BYE | | | |
| |---------------------------------------->| |
| |DRQ OSP | | | | | BYE |
| |----->| | | | | |----->|
| | | | | | | DRQ | |
| | DRQ | DEC | | | DEC |<-----| |
| |----->|REM (PATH) | |REM (PATH) | |
| | |----->| | |<-----| | |
| | | DEC | | | DEC | | |
| | |REM (RESV) | |REM (RESV) | |
| | |----->| | |<-----| | |
| RESVTEAR/SBM | | | | | |
|<====================| PATHTEAR | | | |
| | | |------------>| PATHTEAR/SBM| |
| | | | | |===================>|
| | | | | | RESVTEAR/SBM| |
| | | | | |===================>|
| | | | RESVTEAR | | | |
| | | |<------------| | | |
| PATHTEAR/SBM | | | | | |
|<====================| | | | | |
| | | | | | | |200 OK|
| | | | 200 OK | | |<-----|
|200 OK |<----------------------------------------| |
|<------| | | | | | | |
Figure 6 - QoS Assured Pull BYE
draft-sinnreich-interdomain-sip-qos-osp-01.txt [Page 29]
Internet Draft Interdomain SIP QOS OSP March 2000
7.2.2 QoS Enabled Calls
In the QoS Enabled Model, the QoS is determined
independently from SIP session establishment. The SIP
session is not delayed to ascertain the QoS for the call.
The QoS request is evaluated after establishment of the SIP
session. There is no sharing of session information between
SIP and RSVP protocols. The QoS is controlled by information
contained in the RSVP signaled and the pre-provisioned
policy rules. There is no additional delay in call setup is
introduced by the model as experienced with the QoS Assured
Model. However, the initial moments of the session may
experience best effort side-effects such as voice clipping
until the RSVP signaling is completed or that QoS is
established at all for the call.
draft-sinnreich-interdomain-sip-qos-osp-01.txt [Page 30]
Internet Draft Interdomain SIP QOS OSP March 2000
+-----+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
| SIP | |SIP| |POL| | R | |CH | | R | |POL| |SIP| |GWY|
|Phone| | 1 | | 1 | | 1 | | | | 2 | | 2 | | 2 | | |
+-----+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
| 1 | | | | | | | |
|INVITE | 2 | | | | | | |
|------>|REQ OSP 3 | | | | |
| |----->| <AuthReq> | | | | |
| | |------------>| | | | |
| | | 4 | | | | |
| | | <AuthRsp> | | | | |
| | 5 |<------------| | | | |
| | DEC | | 6 | | | |
| |<-----| | INVITE | | | 7 |
| |---------------------------------------->|INVITE|
| | | | | | | |----->|
| | | | | | | | 8 |
| | | | | | 10 | 9 REQ| 183 |
| | | | | | DEC | /LDP |<-----|
| | | | | | LDP |<-----| |
| | | | | |<-----| | |
| | | | | | 11 | | |
| | | | | | RPT | 12 | |
| | | | | |----->| DEC | |
| | | | 13 183 | |----->| |
| |<----------------------------------------| |
| |14 REQ| 15 | | | | | |
| | /LDP | DEC | | | | | |
| |----->| LDP | | | | | |
| | |----->| | | | | |
| | 17 |16 RPT| | | | | |
| 18 | DEC |<-----| | | | | |
| 183 |<-----| | | | | | |
|<------| | | | | | | |
| 21 | | | | | | | 19 |
| 180 | | | 20 180 | | | 180 |
|<------|<----------------------------------------|<-----|
| 24 | | | | | | | 22 |
| 200 OK| | |23 200 OK | | |200 OK|
|<------|<----------------------------------------|<-----|
|25 ACK | | | 26 ACK | | |27 ACK|
|------>|---------------------------------------->|----->|
| | Hello! (RTP established both way) | |
|<======================================================>|
- continue call setup -
Figure 7 QoS Enabled Call setup - push model
draft-sinnreich-interdomain-sip-qos-osp-01.txt [Page 31]
Internet Draft Interdomain SIP QOS OSP March 2000
- call setup continued -
+-----+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
| SIP | |SIP| |POL| | R | |CH | | R | |POL| |SIP| |GWY|
|Phone| | 1 | | 1 | | 1 | | | | 2 | | 2 | | 2 | | |
+-----+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
| | | | | | | | |
| 28 PATH/SBM | 29 PATH | 30 PATH/SBM |
|====================>|------------>|===================>|
| | | | | | | | |
| 33 RESV/SBM | 32 RESV | 31 RESV/SBM |
|<====================|<------------|<===================|
| | | | | | | | |
| 34 RESV-CONF/SBM |35 RESV-CONF | 36 RESV-CONF/SBM |
|====================>|------------>|===================>|
| | | | | | | | |
| 39 PATH/SBM | 38 PATH | 37 PATH/SBM |
|<====================|<------------|<===================|
| | | | | | | | |
| 40 RESV/SBM | 41 RESV | 42 RESV/SBM |
|====================>|------------>|===================>|
| | | | | | | | |
| 45 RESV-CONF/SBM |44 RESV-CONF | 43RESV-CONF/SBM |
|<====================|<------------|<===================|
Figure 7.a QoS Assured push setup and completing the call
7.2.2.1 QoS Enabled Push Model Call Setup
For purposes of comparison, message sequence flows of a Push
approach to the QoS Enabled Model are included below. The
QoS Enabled Provision Model introduces QoS policy
interdependency between SIP and RSVP. The QoS is determined
during the SIP session setup and likewise, the QoS removal
is initiated during SIP session termination.
draft-sinnreich-interdomain-sip-qos-osp-01.txt [Page 32]
Internet Draft Interdomain SIP QOS OSP March 2000
7.2.2.2 QoS Enabled Push Model Call Teardown
The call termination call flow and RSVP teardown are shown
in Fig. 8 and Fig. 9 respectively. Both processes are
triggered by a client using BYE or by the session time the
policy server, independent of one another.
+-----+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
| SIP | |SIP| |POL| | R | |CH | | R | |POL| |SIP| |GWY|
|Phone| | 1 | | 1 | | 1 | | | | 2 | | 2 | | 2 | | |
+-----+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
| | | | | | | | |
| | | | Good Bye! | | | |
|<======================================================>|
| BYE | | | | | | | |
|------>| | | BYE | | | |
| |---------------------------------------->| BYE |
| |DRQ OSP | | | | |----->|
| |----->| | | | DRQ LDP| |
| |DRQ LDP | | | |<-----| |
| |----->| | | DEC REM| | |
| | |DEC REM | | LDP | | |
| | | LDP | | |<-----| | |
| | |----->| | | RPT | | |
| | | RPT | | |----->| | |
| | |<-----| | | | | |
|200 OK | | | 200 OK | | |200 OK|
|<------|<----------------------------------------|<-----|
| RESVTEAR/SBM | | | | | |
|<====================| | | | | |
| | | | PATHTEAR | | | |
| | | |------------>| PATHTEAR/SBM |
| | | | | |===================>|
| | | | | | RESVTEAR/SBM |
| | | | PATHTEAR |===================>|
| PATHTEAR/SBM |<------------| | | |
|<====================| | | | | |
Fig. 8 QoS Enabled push BYE with background usage update
draft-sinnreich-interdomain-sip-qos-osp-01.txt [Page 33]
Internet Draft Interdomain SIP QOS OSP March 2000
+-----+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
| SIP | |SIP| |POL| | R | |CH | | R | |POL| |SIP| |GWY|
|Phone| | 1 | | 1 | | 1 | | | | 2 | | 2 | | 2 | | |
+-----+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
| | | | | | | | |
| PATHTEAR/SBM | | | | | |
|====================>| | | | | |
| | | | PATHTEAR | | | |
| | | |------------>| PATHTEAR/SBM| |
| | RPT (LDP | |===================>|
| | | tear)| | RPT (LDP | |
| | |<-----| | | tear)| | |
| | DEC REM| | |----->| | |
| | | LDP | | DEC REM| | |
| | |----->| | | LDP | | |
| | | RPT | | |<-----| | |
| | |<-----| | | RPT | | |
| DEC REM| | | |----->| | |
| | LDP | | | | |DEC REM |
| |<-----| | | | | LDP | |
| | | | | | |----->| |
Fig. 9 QoS Enabled push RSVP TEAR with background usage update
7.2.2.3 QoS Enabled Pull Model Call Setup
Below in Figure 10, the QoS Enabled pull model call setup is
shown and the independence of the QoS signaling from SIP
signaling is illustrated. QoS is determined independently
from SIP session establishment. The QoS request is evaluated
after establishment of the SIP session. There is no sharing
of session information between SIP and RSVP protocols. QoS
is controlled by information contained in the RSVP signaled
and the pre-provisioned policy rules.
draft-sinnreich-interdomain-sip-qos-osp-01.txt [Page 34]
Internet Draft Interdomain SIP QOS OSP March 2000
+-----+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
| SIP | |SIP| |POL| | R | |CH | | R | |POL| |SIP| |GWY|
|Phone| | 1 | | 1 | | 1 | | | | 2 | | 2 | | 2 | | |
+-----+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
| 1 | | | | | | | |
|INVITE | 2 | | | | | | |
|------>|REQ OSP 3 | | | | |
| |----->| <AuthReq> | | | | |
| | |------------>| | | | |
| | | 4 | | | | |
| | | <AuthRsp> | | | | |
| | 5 |<------------| | | | |
| | DEC | | 6 | | | |
| |<-----| | INVITE | | | 7 |
| |---------------------------------------->|INVITE|
| | | | | | | |----->|
| 10 | | | | | | | 8 |
| 180 | | | 9 180 | | | 180 |
|<------|<----------------------------------------|<-----|
| 13 | | | | | | | 11 |
|200 OK | | | 12 200 OK | | |200 OK|
|<------|<----------------------------------------|<-----|
| 14 | | | | | | | 16 |
| ACK | | | 15 ACK | | | ACK |
|------>|---------------------------------------->|----->|
- continue QoS setup -
Fig.10 QoS Enabled pull - call setup
draft-sinnreich-interdomain-sip-qos-osp-01.txt [Page 35]
Internet Draft Interdomain SIP QOS OSP March 2000
- call setup continued -
+-----+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
| SIP | |SIP| |POL| | R | |CH | | R | |POL| |SIP| |GWY|
|Phone| | 1 | | 1 | | 1 | | | | 2 | | 2 | | 2 | | |
+-----+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
| 17 PATH/SBM | | | | | |
|====================>| | | | | |
| | |18 REQ| | | | | |
| | | PATH | | | | | |
| | |<-----| | | | | |
| | |19 DEC| 20 PATH |21 REQ| | |
| | |----->|------------>| PATH | | |
| | | | | |----->| | |
| | | | | |22 DEC| | |
| | | | | |<-----| | |
| | | | | | 23 PATH/SBM |
| | | | | |===================>|
| | | | | | 24 RESV/SBM |
| | | | | |<===================|
| | | | | |25 REQ| | |
| | | | | | RESV | | |
| | | | | |----->| | |
| | | | | |26 DEC| | |
| | | | | |<-----| | |
| | | | | |27 RPT| | |
| | |29 REQ| 28 RESV |----->| | |
| | | RESV |<------------| | | |
| | |<-----| | | | | |
| | |30 DEC| | | | | |
| | |----->| | | | | |
| | |31 RPT| | | | | |
| | |<-----| | | | | |
| 32 RESV/SBM | | | | | | |
|<====================| | | | | |
| 33 RESV-CONF/SBM |34 RESV-CONF | 35 RESV-CONF/SBM |
|====================>|------------>|===================>|
- continue QOS setup -
Fig.10a QoS Enabled pull - QoS setup
draft-sinnreich-interdomain-sip-qos-osp-01.txt [Page 36]
Internet Draft Interdomain SIP QOS OSP March 2000
- continue QoS Assured pull QoS setup (Direction 2)
+-----+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
| SIP | |SIP| |POL| | R | |CH | | R | |POL| |SIP| |GWY|
|Phone| | 1 | | 1 | | 1 | | | | 2 | | 2 | | 2 | | |
+-----+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
| | | | | | 36 PATH/SBM |
| | | | | |<===================|
| | | | | |37 REQ| | |
| | | | | | PATH | | |
| | | | | |----->| | |
| | |40 REQ| 39 PATH |38 DEC| | |
| | | PATH |<------------|<-----| | |
| | |<-----| | | | | |
| | |41 DEC| | | | | |
| | |----->| | | | | |
| 42 PATH/SBM | | | | | | |
|<====================| | | | | |
| 43 RESV/SBM | | | | | | |
|====================>| | | | | |
| | |44 REQ| | | | | |
| | | RESV | | | | | |
| | |<-----| | | | | |
| | |45 DEC| | | | | |
| | |----->| | | | | |
| | |46 RPT| | | | | |
| | |<-----| 47 RESV | | | |
| | | |------------>|48 REQ| | |
| | | | | | RESV | | |
| | | | | |----->| | |
| | | | | |49 DEC| | |
| | | | | |<-----| | |
| | | | | |50 RPT| | |
| | | | | |----->| | |
| | | | | | | 51 RESV/SBM |
| | | | | |===================>|
| 54 RESV-CONF/SBM |53 RESV-CONF | 52 RESV-CONF/SBM |
|<====================|<------------|<===================|
Figure 10.b continued QoS Enabled pull QoS setup completion
7.2.2.4 QoS Enabled Pull Model - Teardown
Similar to the QoS Assured Session Teardown, QoS removal is
signaled by either SIP or RSVP mechanisms. Unlike the QoS
Assured model, there is no interdependency between SIP
session removal and RSVP flow removal. The removal of QoS
for media stream is handled independently from the SIP
session.
draft-sinnreich-interdomain-sip-qos-osp-01.txt [Page 37]
Internet Draft Interdomain SIP QOS OSP March 2000
+-----+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
| SIP | |SIP| |POL| | R | |CH | | R | |POL| |SIP| |GWY|
|Phone| | 1 | | 1 | | 1 | | | | 2 | | 2 | | 2 | | |
+-----+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
| | | | | | | | |
| | | | Good Bye! | | | |
|<======================================================>|
| BYE | | | | | | | |
|------>| | | BYE | | | |
| |---------------------------------------->| BYE |
| |DRQ OSP | | | | |----->|
| |----->| | | | | | |
|200 OK | | | 200 OK | | |200 OK|
|<------|<----------------------------------------|<-----|
| | | | | | | | |
| | | | | | | | |
| PATHTEAR/SBM | | | | | |
|====================>| | | | | |
| | | DRQ | | | | | |
| | |(path)| | | | | |
| | |<-----| PATHTEAR | | | |
| | | |------------>| PATHTEAR/SBM| |
| | | DRQ | | |===================>|
| | |(resv)| | | DRQ | | |
| | |<-----| | |(path)| | |
| | | | | |----->| | |
| | | | | | DRQ | | |
| | | | | |(resv)| | |
| | | | | |----->| | |
| | | | | | | | |
| | | | | | PATHTEAR/SBM |
| | | | PATHTEAR |<===================|
| PATHTEAR/SBM |<------------| | | |
|<====================| | | DRQ | | |
| | | DRQ | | |(path)| | |
| | |(path)| | |----->| | |
| | |<-----| | | | | |
| | | | | | DRQ | | |
| | | DRQ | | |(resv)| | |
| | |(resv)| | |----->| | |
| | |<-----| | | | | |
Fig. 11 QoS Enabled pull RSVP TEAR with background usage update
draft-sinnreich-interdomain-sip-qos-osp-01.txt [Page 38]
Internet Draft Interdomain SIP QOS OSP March 2000
7.3 Generic QoS Usage Reporting to Clearing House
1. Usage is reported by POL1 server to clearing house server,
2. Usage report is confirmed to POL1,
3. Usage is reported by POL2 server to clearing house server,
4. Usage report is confirmed to POL2.
+---+ +---+ +---+ +---+ +---+
|POL| | R | |CH | | R | |POL|
| 1 | | 1 | | | | 2 | | 2 |
+---+ +---+ +---+ +---+ +---+
| | | | |
| | | | |
|1 <UsageInd> | | |
|------------>|3 <UsageInd> |
| | |<------------|
|2 <UsageCnf> | | |
|<------------| | |
| | |4 <UsageCnf> |
| | |------------>|
Fig. 12 OSP usage indication
7.4. Detailed Call Flows
We provide here examples of messages by using the same numbers as
in the call flow diagrams for call setup. A number of optional
messages are shown here that are not shown in the diagrams. The
optional messages are of the type "Trying" and serve to report
call progress to the client of the caller.
7.4.1 QoS Assured Push Call Setup
See Figure 3.
Msg. Protocol
1 SIP
INVITE sip:+1-972-555-5555@sip.domain2.com;user=phone SIP/2.0
Via: SIP/2.0/UDP phone1.domain1.com:5060
From: Henry Sinnreich <henry.sinnreich@phone1.domain1.com>
To: <sip:+1972-555-5555@sip.domain2.com;user=phone>
Callid: 123456@domain1.com
Cseq: 1 INVITE
Contact: phone1.domain1.com
...
SDP
QOS required
draft-sinnreich-interdomain-sip-qos-osp-01.txt [Page 39]
Internet Draft Interdomain SIP QOS OSP March 2000
2 COPS
REQ OSP =
(Common Header, Client Handle, Context, ClientSI: OSP)
Client Handle = "123456@domain1.com"
Context = "Incoming & Outgoing", "OSP"
ClientSI: OSP = (Called Number, Calling Number)
Called Number = "To: <sip:+1972-555-5555@sip.domain2.com;user=phone>"
Calling Number = "From: Henry Sinnreich
henry.sinnreich@phone1.domain1.com"
3 OSP
<AuthReq>
<?xml version=1.0?>
<Message messageId="123454321" random="12345678">
<AuthorizationRequest componentId="9876567890">
<Timestamp>
1999-10-24T17:03:00Z
</Timestamp>
<CallId encoding="base64">
YT64VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756t
</CallId>
<SourceInfo type="henry.sinnreich@phone1.domain1.com">
</SourceInfo>
<DestinationInfo type="e164">
1-972-555-5555
</DestinationInfo>
<Service/>
<MaximumDestinations>
5
</MaximumDestinations>
</AuthorizationRequest>
</Message> <AuthReq/>
4 OSP
<AuthRsp>
<?xml version=1.0?>
<Message messageId="123454321" random="12345678">
<AuthorizationResponse componentId="9876567890">
<Timestamp>
1999-10-24T17:03:01Z
</Timestamp>
<Status>
<Code>
200
</Code>
<Description>
success
</Description>
draft-sinnreich-interdomain-sip-qos-osp-01.txt [Page 40]
Internet Draft Interdomain SIP QOS OSP March 2000
</Status>
<TransactionId>
67890987
</TransactionId>
<Destination>
<DestinationSignalAddress>
[172.16.1.2]:112
</DestinationSignalAddress>
<Token encoding="base64">
YT64VqpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756t
HGTrfvbnjn8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfH
6ghyHhHUujpfyF47GhIGfHfYT64VQbnj
</Token>
<ValidAfter>
1999-04-24T17:01:01Z
</ValidAfter>
<ValidUntil>
1998-04-24T17:11:01Z
</ValidUntil>
<CallId encoding="base64">
YT64VqpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756t
</CallId>
<UsageDetail>
<Service/>
<Amount>
24
</Amount>
<Increment>
3600
</Increment>
<Unit>
s
</Unit>
</UsageDetail>
</Destination>
</AuthorizationResponse>
</Message>
<AuthRsp>
5 COPS
DEC = (Common Header, Client Handle, Context,
Decision Flag,Decision: ClientSI Data: OSP)
Client Handle = "123456@domain1.com"
Context = "Incoming & Outgoing"
Decision Flag = "Install"
Decision: ClientSI Data: OSP = (Called Number, Authorization Token)
Called Number = "To: <sip:+1972-555-5555@sip.domain2.com;user=phone>"
draft-sinnreich-interdomain-sip-qos-osp-01.txt [Page 41]
Internet Draft Interdomain SIP QOS OSP March 2000
Authorization Token = "<Token encoding="base64">
YT64VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756t
HGTrfvbnjn8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfH
6ghyHhHUujpfyF47GhIGfHfYT64VQbnj
</Token>"
Opt. SIP
SIP/2.0 100 Trying
Via: SIP/2.0/UDP phone1.domain1.com:5060
From: Henry Sinnreich <henry.sinnreich@phone1.domain1.com>
To: <sip:+1972-555-5555@sip.domain2.com;user=phone>
Callid: 123456@domain1.com
Cseq: 1 INVITE
6 SIP
INVITE sip:+1-972-555-5555@sip.domain2.com;user=phone SIP/2.0
Via: SIP/2.0/UDP sip.domain1.com:5060
Via: SIP/2.0/UDP phone1.domain1.com:5060
From: Henry Sinnreich <henry.sinnreich@phone1.domain1.com>
To: <sip:+1972-555-5555@sip.domain2.com;user=phone>
Callid: 123456@domain1.com
Cseq: 1 INVITE
Contact: phone1.domain1.com
Record-Route: sip.domain1.com
...
SDP
QOS required
7 SIP
INVITE sip:+1-972-555-5555@sip.domain2.com;user=phone SIP/2.0
Via: SIP/2.0/UDP sip.domain2.com:5060
Via: SIP/2.0/UDP sip.domain1.com:5060
Via: SIP/2.0/UDP phone1.domain1.com:5060
From: Henry Sinnreich <henry.sinnreich@phone1.domain1.com>
To: <sip:+1972-555-5555@sip.domain2.com;user=phone>
Callid: 123456@domain1.com
Cseq: 1 INVITE
Contact: phone1.domain1.com
Record-Route: sip.domain1.com
...
SDP
QOS required
draft-sinnreich-interdomain-sip-qos-osp-01.txt [Page 42]
Internet Draft Interdomain SIP QOS OSP March 2000
8 SIP
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP sip.domain2.com:5060
Via: SIP/2.0/UDP sip.domain1.com:5060
Via: SIP/2.0/UDP phone1.domain1.com:5060
From: Henry Sinnreich <henry.sinnreich@phone1.domain1.com>
To: <sip:+1972-555-5555@sip.domain2.com;user=phone>;tag=134159
Callid: 123456@domain1.com
Cseq: 1 INVITE
...
SDP
QOS required
9 COPS
REQ AssuredLDP=
(Common Header, Client Handle, Context, ClientSI: ConfigLocalPolicy)
Client Handle = "123456@domain1.com"
Context = "Configuration Request" ,"ConfigLocalDecisionPolicy"
ClientSI: ConfigLocalDecisionPolicy = ( Caller Media Address, Caller
Media
Port, Caller SDP info, Callee Media Address, Callee Media Port , Callee
SDP
info )
10 COPS
DEC =
(Common Header, Client Handle) (Decision) | (Error)
Client Handle = "R1001"
Decision = (Context, Decision Flag, Named Decision Data: Config Local
DecisionPolicy)
Context = "Configuration Request", "ConfigLocalDecisionPolicy"
Decision Flag = "Install"
Named Decision Data: (Binding Count, PRID, BPD)
Binding Count = 1
PRID = "1.2.3.4"
BPD = (Ace of Caller flow, Caller Token rate, Caller Peak rate, Caller
Token Bucket Size, Caller Min Policed Unit, Caller Max Packet Size,
Caller Reservation Style, Caller DSCLASS, Caller POLICY)
| (Ace of Callee flow, Callee Token rate, Callee Peak rate, Callee
Token Bucket Size, Callee Min Policed Unit, Callee Max Packet Size,
Callee Reservation Style, Callee DSCLASS, Callee POLICY ))
draft-sinnreich-interdomain-sip-qos-osp-01.txt [Page 43]
Internet Draft Interdomain SIP QOS OSP March 2000
11 COPS
RPT =
(Common Header, Client Handle, Report-Type, ClientSI: ConfigRPT)
Client Handle = "PEP1001
Report-Type = "Installed"
ClientSI = (PRID)
PRID = "1.2.3.4"
12 COPS
DEC =
(Common Header, Client Handle, Context, Decision Flags)
Client Handle = "123456@domain1.com"
Context = "Incoming&Outgoing","ConfigLocalDecisionPolicy"
Decision Flag = "Install"
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP sip.domain2.com:5060
Via: SIP/2.0/UDP sip.domain1.com:5060
Via: SIP/2.0/UDP phone1.domain1.com:5060
From: Henry Sinnreich <henry.sinnreich@phone1.domain1.com>
To: <sip:+1972-555-5555@sip.domain2.com;user=phone>;tag=134159
Callid: 123456@domain1.com
Cseq: 1 INVITE
...
SDP
QOS required
14 COPS
REQ
AssuredLDP= (Common Header, Client Handle, Context, ClientSI:
ConfigLocalPolicy)
Client Handle = "123456@domain1.com"
Context = "Configuration Request" ,"ConfigLocalDecisionPolicy"
ClientSI: ConfigLocalDecisionPolicy = ( Caller Media Address, Caller
Media Port, Caller SDP info, Callee Media Address, Callee Media Port ,
Callee SDP info )
draft-sinnreich-interdomain-sip-qos-osp-01.txt [Page 44]
Internet Draft Interdomain SIP QOS OSP March 2000
15 COPS
DEC =
(Common Header, Client Handle) (Decision) | (Error)
Client Handle = "R1001"
Decision = (Context, Decision Flag, Named Decision Data: Config Local
DecisionPolicy)
Context = "Configuration Request", "ConfigLocalDecisionPolicy"
Decision Flag = "Install"
Named Decision Data: (Binding Count, PRID, BPD)
Binding Count = 1
PRID = "1.2.3.4"
BPD = (Ace of Caller flow, Caller Token rate, Caller Peak rate, Caller
Token Bucket Size, Caller Min Policed Unit, Caller Max Packet Size,
Caller Reservation Style, Caller DSCLASS, Caller POLICY)
| (Ace of Callee flow, Callee Token rate, Callee Peak rate, Callee
Token Bucket Size, Callee Min Policed Unit, Callee Max Packet Size,
Callee Reservation Style, Callee DSCLASS, Callee POLICY ))
16 COPS
RPT =
(Common Header, Client Handle, Report-Type, ClientSI: ConfigRPT)
Client Handle = "PEP1001
Report-Type = "Installed"
ClientSI = (PRID)
PRID = "1.2.3.4"
17 COPS
DEC =
(Common Header, Client Handle, Context, Decision Flags)
Client Handle = "123456@domain1.com"
Context = "Incoming&Outgoing","ConfigLocalDecisionPolicy"
Decision Flag = "Install"
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP sip.domain2.com:5060
Via: SIP/2.0/UDP sip.domain1.com:5060
Via: SIP/2.0/UDP phone1.domain1.com:5060
From: Henry Sinnreich <henry.sinnreich@phone1.domain1.com>
To: <sip:+1972-555-5555@sip.domain2.com;user=phone>;tag=134159
Callid: 123456@domain1.com
Cseq: 1 INVITE
...
SDP
QOS required
draft-sinnreich-interdomain-sip-qos-osp-01.txt [Page 45]
Internet Draft Interdomain SIP QOS OSP March 2000
19 RSVP
PATH =
(Common Header, [INTEGRITY], SESSION, RSVP_HOP, TIME_VALUES, [
(POLICY_DATA) +], [sender descriptor]
Sender descriptor = (SENDER_TEMPLATE,SENDER_TSPEC, [ADSPEC] )
Note: Messages 19 - 31 are for Caller to Callee flow.
20 RSVP
See Message 19.
21 RSVP
See Message 19.
22 RSVP
RESV =
( Common Header, [INTEGRITY], SESSION, RSVP_HOP, TIME_VALUES,
[RESV_CONFIRM], [SCOPE] , [(POLICY_DATA) + ] STYLE, flow descriptor
list)
23 RSVP
See Message 22.
24 RSVP
See Message 22.
25 RSVP
RESV-CONF =
(Common Header, [INTEGRITY], SESSION, ERROR_SPEC, RESV_CONFIRM, STYLE,
flow descriptor list )
26 RSVP
See Message 25.
27 RSVP
See Message 25.
28 RSVP
See Message 19.
Note: Messages 32 - 40 are for the Callee to Caller Flow.
29 RSVP
See Message 19.
30 RSVP
See Message 19.
31 RSVP
See Message 22.
32 RSVP
See Message 22.
33 RSVP
See Message 22.
34 RSVP
See Message 25.
35 RSVP
See Message 25.
draft-sinnreich-interdomain-sip-qos-osp-01.txt [Page 46]
Internet Draft Interdomain SIP QOS OSP March 2000
36 RSVP
See Message 25.
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP sip.domain2.com:5060
Via: SIP/2.0/UDP sip.domain1.com:5060
Via: SIP/2.0/UDP phone1.domain1.com:5060
From: Henry Sinnreich <henry.sinnreich@phone1.domain1.com>
To: <sip:+1972-555-5555@sip.domain2.com;user=phone>;tag=134159
Callid: 123456@domain1.com
Cseq: 1 INVITE
...
SDP(Optional)
SIP/2.0 183 Ringing
Via: SIP/2.0/UDP sip.domain2.com:5060
Via: SIP/2.0/UDP sip.domain1.com:5060
Via: SIP/2.0/UDP phone1.domain1.com:5060
From: Henry Sinnreich <henry.sinnreich@phone1.domain1.com>
To: <sip:+1972-555-5555@sip.domain2.com;user=phone>;tag=134159
Callid: 123456@domain1.com
Cseq: 1 INVITE
...
SDP(Optional)
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP sip.domain2.com:5060
Via: SIP/2.0/UDP sip.domain1.com:5060
Via: SIP/2.0/UDP phone1.domain1.com:5060
From: Henry Sinnreich <henry.sinnreich@phone1.domain1.com>
To: <sip:+1972-555-5555@sip.domain2.com;user=phone>;tag=134159
Callid: 123456@domain1.com
Cseq: 1 INVITE
...
SDP(Optional)
SIP/2.0 200 OK
Via: SIP/2.0/UDP sip.domain2.com:5060
Via: SIP/2.0/UDP sip.domain1.com:5060
Via: SIP/2.0/UDP phone1.domain1.com:5060
From: Henry Sinnreich <henry.sinnreich@phone1.domain1.com>
To: <sip:+1972-555-5555@sip.domain1.com;user=phone>;tag=134159
draft-sinnreich-interdomain-sip-qos-osp-01.txt [Page 47]
Internet Draft Interdomain SIP QOS OSP March 2000
Callid: 123456@domain1.com
Cseq: 1 INVITE
Contact: 972gw.domain2.com
Record-Route: sip.domain1.com, sip.domain2.com
...
SDP (Optional)
SIP/2.0 200 OK
Via: SIP/2.0/UDP sip.domain1.com:5060
Via: SIP/2.0/UDP phone1.domain1.com:5060
From: Henry Sinnreich <henry.sinnreich@phone1.domain1.com>
To: <sip:+1972-555-5555@sip.domain2.com;user=phone>;tag=134159
Callid: 123456@domain1.com
Cseq: 1 INVITE
Contact: 972gw.domain2.com
Record-Route: sip.domain1.com, sip.domain2.com
...
SDP (Optional)
SIP/2.0 200 OK
Via: SIP/2.0/UDP phone1.domain1.com:5060
From: Henry Sinnreich <henry.sinnreich@phone1.domain1.com>
To: <sip:+1972-555-5555@sip.domain2.com;user=phone>;tag=134159
Callid: 123456@domain1.com
Cseq: 1 INVITE
Contact: 972gw.domain2.com
Record-Route: sip.domain1.com, sip.domain2.com
...
SDP (Optional)
ACK sip.domain1.com SIP/2.0
Via: SIP/2.0/UDP phone1.domain1.com:5060
From: Henry Sinnreich <henry.sinnreich@phone1.domain1.com>
To: <sip:+1972-555-5555@sip.domain2.com;user=phone>;tag=134159
Callid: 123456@domain1.com
Cseq: 1 INVITE
Route: sip.domain2.com, gw972.domain2.com
...
SDP (Optional)
draft-sinnreich-interdomain-sip-qos-osp-01.txt [Page 48]
Internet Draft Interdomain SIP QOS OSP March 2000
ACK sip.domain2.com SIP/2.0
Via: SIP/2.0/UDP sip.domain1.com:5060
Via: SIP/2.0/UDP phone1.domain1.com:5060
From: Henry Sinnreich <henry.sinnreich@phone1.domain1.com>
To: <sip:+1972-555-5555@sip.domain2.com;user=phone>;tag=134159
Callid: 123456@domain1.com
Cseq: 1 INVITE
Route: gw972.domain2.com
...
SDP (Optional)
ACK gw972.domain2.com SIP/2.0
Via: SIP/2.0/UDP sip.domain2.com:5060
Via: SIP/2.0/UDP sip.domain1.com:5060
Via: SIP/2.0/UDP phone1.domain1.com:5060
From: Henry Sinnreich <henry.sinnreich@phone1.domain1.com>
To: <sip:+1972-555-5555@sip.domain2.com;user=phone>;tag=134159
Callid: 123456@domain1.com
Cseq: 1 INVITE
...
SDP (Optional)
7.4.2 QoS Assured Push BYE
See Fig. 4.
The usage information is updated in the background. Note that
several messages could be occurring concurrently. For example,
Message 10 BYE, could be processing concurrently with message 3
DRQ.
Msg. Protocol
1 SIP
BYE sip.domain1.com SIP/2.0
Via: SIP/2.0/UDP phone1.domain1.com:5060
From: Henry Sinnreich <henry.sinnreich@phone1.domain1.com>
To: <sip:+1972-555-5555@sip.domain1.com;user=phone>;tag=134159
Callid: 123456@domain1.com
Cseq: 1 INVITE
Route: sip.domain2.com, gw972.domain2.com
draft-sinnreich-interdomain-sip-qos-osp-01.txt [Page 49]
Internet Draft Interdomain SIP QOS OSP March 2000
2 SIP
BYE sip.domain2.com SIP/2.0
Via: SIP/2.0/UDP sip.domain1.com:5060
Via: SIP/2.0/UDP phone1.domain1.com:5060
From: Henry Sinnreich <henry.sinnreich@phone1.domain1.com>
To: <sip:+1972-555-5555@sip.domain2.com;user=phone>;tag=134159
Callid: 123456@domain1.com
Cseq: 1 INVITE
Route: gw972.domain2.com
3 COPS
DRQ OSP = (Common Header, Client Handle)
4 COPS
DRQ AsuredLDP = (Common Header, Client Handle)
5 COPS
DEC = (Common Header, Client Handle, Decision)
Client Handle = "R1001"
Decision = (Context, Decision Flag, Named Decision Data: Remove Local
DecisionPolicy)
Context = "Configuration Request"
Decision Flag = "Remove"
Named Decision Data: (Binding Count, PRID)
Binding Count = 1
PRID = 1.2.3.4
6 COPS
RPT = (Common Header, Client Handle, Report-Type, ClientSI: UsageRPT)
Client Handle = "PEP1001
Report-Type = "Installed"
ClientSI = (PRID, Usage)
PRID = "1.2.3.4"
Usage = Timestamp, Packet Count, QoS Usage Level
7 RSVP
RESVTEAR = ( Common Header, [INTEGRITY], SESSION, RSVP_HOP, [SCOPE]
STYLE, flow descriptor list)
8 RSVP
PATHTEAR = (Common Header, [INTEGRITY], SESSION, RSVP_HOP, [sender
descriptor]
draft-sinnreich-interdomain-sip-qos-osp-01.txt [Page 50]
Internet Draft Interdomain SIP QOS OSP March 2000
9 RSVP
PATHTEAR = (Common Header, [INTEGRITY], SESSION, RSVP_HOP, [sender
descriptor]
Note: Message 7 - 9 are for the caller to callee flow.
BYE gw972.domain2.com SIP/2.0
Via: SIP/2.0/UDP sip.domain2.com:5060
Via: SIP/2.0/UDP sip.domain1.com:5060
Via: SIP/2.0/UDP phone1.domain1.com:5060
From: Henry Sinnreich <henry.sinnreich@phone1.domain1.com>
To: <sip:+1972-555- 555@sip.domain2.com;user=phone>;tag=134159
Callid: 123456@domain1.com
Cseq: 1 INVITE
11 COPS
DRQ AsuredLDP = (Common Header, Client Handle)
12 COPS
DEC = (Common Header, Client Handle, Decision)
Client Handle = "R1001"
Decision = (Context, Decision Flag, Named Decision Data: Remove Local
DecisionPolicy)
Context = "Configuration Request"
Decision Flag = "Remove"
Named Decision Data: (Binding Count, PRID)
Binding Count = 1
PRID = 1.2.3.4
13 COPS
RPT = (Common Header, Client Handle, Report-Type, ClientSI: UsageRPT)
Client Handle = "PEP1001
Report-Type = "Installed"
ClientSI = (PRID, Usage)
PRID = "1.2.3.4"
Usage = Timestamp, Packet Count, QoS Usage Level
14 RSVP
RESVTEAR = ( Common Header, [INTEGRITY], SESSION, RSVP_HOP, [SCOPE]
STYLE, flow descriptor list)
draft-sinnreich-interdomain-sip-qos-osp-01.txt [Page 51]
Internet Draft Interdomain SIP QOS OSP March 2000
15 RSVP
PATHTEAR = (Common Header, [INTEGRITY], SESSION, RSVP_HOP, [sender
descriptor]
16 RSVP
PATHTEAR = (Common Header, [INTEGRITY], SESSION, RSVP_HOP, [sender
descriptor]
Note: Message 14 - 16 are for the callee to caller flow.
SIP/2.0 200 OK
Via: SIP/2.0/UDP sip.domain1.com:5060
Via: SIP/2.0/UDP phone1.domain1.com:5060
From: Henry Sinnreich <henry.sinnreich@phone1.domain1.com>
To: <sip:+1972-555-5555@sip.domain2.com;user=phone>;tag=134159
Callid: 123456@domain1.com
Cseq: 1 INVITE
SIP/2.0 200 OK
Via: SIP/2.0/UDP phone1.domain1.com:5060
From: Henry Sinnreich <henry.sinnreich@phone1.domain1.com>
To: <sip:+1972-555-5555@sip.domain2.com;user=phone>;tag=134159
Callid: 123456@domain1.com
Cseq: 1 INVITE
SIP/2.0 200 OK
Via: SIP/2.0/UDP sip.domain2.com:5060
Via: SIP/2.0/UDP sip.domain1.com:5060
Via: SIP/2.0/UDP phone1.domain1.com:5060
From: Henry Sinnreich <henry.sinnreich@phone1.domain1.com>
To: <sip:+1972-555-5555@sip.domain1.com;user=phone>;tag=134159
Callid: 123456@domain1.com
Cseq: 1 INVITE
draft-sinnreich-interdomain-sip-qos-osp-01.txt [Page 52]
Internet Draft Interdomain SIP QOS OSP March 2000
7.4.3 OSP Messages for Usage Indication
The OSP message numbers correspond to those in Figure 12.
1 OSP
<UsageInd>
<?xml version=1.0?>
<Message messageId="123454321" random="12345678">
<UsageIndication componentId="13579990">
<Timestamp>
1999-10-24T22:03:00Z
</Timestamp>
<Role>
source
</Role>
<TransactionId>
67890987
</TransactionId>
<CallId encoding="base64">
YT64VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756t
</CallId>
<SourceInfo type="e164">
81458811202
</SourceInfo>
<DestinationInfo type="e164">
4766841360
</DestinationInfo>
<DestinationAlternate type="transport">
[10.0.1.2]:112
</DestinationAlternate>
<UsageDetail>
<Service/>
<Amount>
10
</Amount>
<Increment>
60
</Increment>
<Unit>
s
</Unit>
</UsageDetail>
</UsageIndication>
</Message>
<UsageInd/>
draft-sinnreich-interdomain-sip-qos-osp-01.txt [Page 53]
Internet Draft Interdomain SIP QOS OSP March 2000
2 OSP
<UsageCnf>
<?xml version=1.0?>
<Message messageId="123454321" random="12345678">
<UsageConfirmation componentId="13579990">
<Timestamp>
1999-10-24T22:44:00Z
</Timestamp>
<Status>
<Code>
201
</Code>
<Description>
new usage information created
</Description>
</Status>
</UsageConfirmation>
</Message>
<UsageCnf/>
8. Future Work
The analysis in this draft points to several areas of future work:
For the MMUSIC Working Group:
* SDP extensions for type of QoS to signal the flavors,
Assured, enabled, other, Type of the local policy model - push or
pull, End-to-end versus access network only qualifier,
For the SIP Working Group:
* New SIP type 4xx failure messages related to QoS,
* SIP and OSP interworking.
For other working groups:
* A new COPS client type to support SIP and RSVP coordination,
* A new COPS client type to support the OSP functions,
* Policy Information Base (PIB) for provisioning RSVP local
decision policy,
* Interdomain QoS rate metrics for telephony, based on RFC 2063
[TFM],
* Classes of traffic, such as priority voice, in both access and
transit networks, so as to completely eliminate QoS policy
implementation at the microflow level.
* Policy control in transit networks to distinguish strict
priority voice traffic,
* QoS specifics in the policy framework architecture.
draft-sinnreich-interdomain-sip-qos-osp-01.txt [Page 54]
Internet Draft Interdomain SIP QOS OSP March 2000
9. Conclusions
End-to-end QoS for commercial grade QoS has several service options
and policy implementation models. Message sequences and parameter
exchanges between various protocols, such as SIP/SDP, COPS, RSVP and
OSP have to be standardized and the missing protocol extensions have
to be defined.
10. Acknowledgements
We would like to thank Richard Wilder from MCI WorldCom for
discussions and guidance on the approach to handling large traffic
amounts in transit networks. Denise Caballero-McCann, Tom Redman,
Azhar Sayeed, and David Oran from Cisco Systems for pointing out
implementation options for QoS and last but not least Wilhelm
Wimmreuter from Siemens Public Networks for useful critique and for
driving us to seek the most simple approach in the spirit of the
Internet architecture.
11. References
[ISSL] RFC 2688: Integrated Services Mappings for Low Speed Networks
by S. Jackowski, D. Putzolu, E. Crawley, B. Davie, September 1999.
ftp://ftp.isi.edu/in-notes/rfc2688.txt
[Sparks] Providing for Multiple-Proxy Authentication of a SIP Request
by R. Sparks. Internet-Draft, April 2000. http://ietf.org/internet-
drafts/draft-sparks-sip-multiproxy-auth-00.txt
[SBM] Raj Javatkar, Don Hoffman, Yoram Bernet, Fred Baker, Michael
Speer: SBM (Subnet Bandwidth Manager): A Protocol for RSVP-based
Admission Control over IEEE 802-style networks. Work in progress,
January 2000. http://ietf.org/internet-drafts/draft-ietf-issll-
is802-sbm-10.txt
[ISSL] IETF Documents of the Working Group for Integrated Services
over Specific Link Layers. http://www.ietf.org/html.charters/issll-
charter.html
[IRSVP] RFC 2210, The Use of RSVP with IETF Integrated Services by J.
Wroclawski, September 1997. ftp://ftp.isi.edu/in-notes/rfc2210.txt
[DS] RFC 2475, An Architecture for Differentiated Services by S.
Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and W. Weiss.
December 1998. ftp://ftp.isi.edu/in-notes/rfc2475.txt
[SIP] RFC 2543 , SIP: Session Initiation Protocol by M. Handley, H.
Schulzrinne, E. Schooler and J. Rosenberg. ftp://ftp.isi.edu/in-
notes/rfc2543.txt
draft-sinnreich-interdomain-sip-qos-osp-01.txt [Page 55]
Internet Draft Interdomain SIP QOS OSP March 2000
[SDP-SIP] Establishing QoS and Security Preconditions for SDP
Sessions by J. Rosenberg, H. Schulzrinne, S. Donovan. Internet-Draft,
work in progress, January 1999. http://ietf.org/internet-
drafts/draft-ietf-mmusic-sdp-qos-00.txt
[OSP-ETSI]] European Telecommunications Standards Institute.
"Telecommunications and Internet Protocol Harmonization Over Networks
(TIPHON); Inter-domain pricing, authorization, and usage exchange".
Technical Specification 101 321 version 1.4.2, December 1998.
[OSP-IETF] Stephen Thomas, R. Brennan, B. Anton, D. Oran: "The
application/osp-token MIME type. IETF draft, April 1999. Work in
Progress. http://ietf.org/internet-drafts/draft-thomas-mime-osp-
token-00.txt
[COPS] RFC 2748: The COPS (Common Open Policy Service) Protocol by
D. Durham, J.Boyle, R. Cohen, S. Herzog, R. Rajan and A. Sastry.
http://www.rfc-editor.org/rfc/rfc2748.txt
[RSVP-DS] Y. Bernet, R. Yavatkar, P. Ford, F. Baker, L. Zhang, M.
Speer, R. Braden, B. Davie, J. Wroclawski, and E. Felstaine, "A
Framework For Integrated Services Operation Over Diffserv Networks".
Internet-Draft, September 1999. http://ietf.org/internet-
drafts/draft-ietf-issll-diffserv-rsvp-03.txt
[RSVP-Aggr] F. Baker, C. Iturralde, F. Le Faucheur, B. Davis,
"Aggregation of RSVP for Ipv4 and Opv6 Reservations", Internet-Draft,
December 1999. http://www.ietf.org/internet-drafts/draft-ietf-issll-
rsvp-aggr-01.txt
[DCSGROUP] W. Marshall, E. Miller, B. Beser, D. Oran, J. Pickens, P.
Lalwaney, J. Felows, , D. Evans, K. Kelly, and F. Andreasen,
Integration of Resource Management and Call Signaling for IP
Telephony. Internet-Draft, October 1999. http://ietf.org/internet-
drafts/draft-dcsgroup-sip-resource-00.txt
[SEGM-RSVP] H. Schulzrinne, J. Rosenberg, J. Lennox, "Interaction of
Call Setup and Resource Reservation Protocols in Internet Telephony".
Unpublished paper, June 1999.
http://www.cs.columbia.edu/~hgs/tmp/resource.pdf
[BGRP] P. Pan, E. Hahne, H. Schulzrinne, "BGRP: A Framework for
Scalable Resource Reservation", January 2000.
http://ietf.org/internet-drafts/draft-pan-bgrp-framework-00.txt
[GIBSON] M. Gibson, J. Crowcroft, "Use of SIP for the Reservation of
QoS guaranteed Paths", Internet Draft, October 1999.
http://ietf.org/internet-drafts/draft-gibson-sip-qos-resv-00.txt
draft-sinnreich-interdomain-sip-qos-osp-01.txt [Page 56]
Internet Draft Interdomain SIP QOS OSP March 2000
[SIP-Auth] R. Sparks "Providing for Multiple-Proxy Authentication of
a SIP Request", Internet-Draft, October 1999.
http://ietf.org/internet-drafts/draft-sparks-sip-multiproxy-
auth-00.txt
[SIP-Call-Flows] A. Johnston, S. Donovan, R. Sparks, C. Cunningham,
K. Summers "SIP Telephony Call Flow Examples", Internet Draft,
October 1999. http://search.ietf.org/internet-drafts/draft-johnston-
sip-call-flows-00.txt
[SIP-Services] SIP Telephony Service Examples With Call Flows by R.
Sparks, C. Cunningham, A. Johnston and K. Summers. Internet-Draft,
work in progress, October 1999. http://search.ietf.org/internet-
drafts/draft-sparks-sip-service-examples-00.txt
[Voice Mail] B. Campbell, R. Sparks, "Control of Service Context
using SIP Request-URI", Internet Draft, January 2000.
http://search.ietf.org/internet-drafts/draft-campbell-sip-service-
control-00.txt
[TFM] RFC 2063, Traffic Flow Measurement: Architecture by N.
Brownlee, C. Mills and G. Ruth. January 1997. ftp://ftp.isi.edu/in-
notes/rfc2063.txt
[Timer] S. Donovan, "SIP Session Timer", Internet-Draft, October
1999. http://ietf.org/internet-drafts/draft-ietf-mmusic-sip-session-
timer-02.txt
draft-sinnreich-interdomain-sip-qos-osp-01.txt [Page 57]
Internet Draft Interdomain SIP QOS OSP March 2000
12. Authors' Addresses
Henry Sinnreich
MCI WorldCom
400 International Parkway
Richardson, Texas 75081
e-mail: henry.sinnreich@wcom.com
Steve Donovan
MCI WorldCom
901 International Parkway
Richardson, Texas 75081
e-mail: steven.r.donovan@wcom.com
Diana Rawlins
MCI WorldCom
901 International Parkway
Richardson, Texas 75081
e-mail: diana.rawlins@wcom.com
Stephen Thomas
TransNexus
430 Tenth Street NW
Suite N-204
Atlanta, Georgia
e-mail: stephen.thomas@transnexus.com
draft-sinnreich-interdomain-sip-qos-osp-01.txt [Page 58]
Internet Draft Interdomain SIP QOS OSP March 2000
"Copyright (C) The Internet Society (2000). 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 implmentation 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."
draft-sinnreich-interdomain-sip-qos-osp-01.txt [Page 59]