Internet Draft
SIP Working Group Fredrik Thernelius
Bertil Engelholm
Internet Draft Ericsson
<draft-thernelius-sip-firewall-solution-00.txt> July 2000
Category: Informational
SIP Firewall Solution
Status of this Memo
This document is an Internet-Draft and is NOT offered in accordance
with Section 10 of RFC2026, and the author does not provide the IETF
with any rights other than to publish as an Internet-Draft
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.
1. Abstract
This document describes a solution that is able to handle SIP
signaling together with NAT enabled firewalls. The intent is to show
that existing firewalls do not have to be replaced by "SIP enabled"
ones, instead they will only have to be reconfigured slightly.
The main feature of this solution is using MGCP from a session
control proxy to open/close holes in an RTP proxy which then enables
RTP traffic to flow between interconnected networks.
Worth noting is that this solution will not only work for SIP, it
will also work for other protocols, such as H.323 or Real Audio. It
does not even have to be RTP that is passed through the RTP proxy,
though this draft assumes that the RTP stream is accompanied by
RTCP. The solution will work for any protocol that wishes to
open/close ports dynamically in the RTP proxy (maybe it should be
called Forwarding Engine in the general case).
Thernelius, Engelholm [Page 1]
SIP Firewall Solution July 2000
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119 [1].
3. Introduction
This draft proposes a simple solution to the problems that NAT
introduces when it's used together with SIP [2]. By terminating all
multimedia sessions in an RTP proxy on the demilitarized zone (DMZ)
and then from that point relay the RTP packets to the final
destination we do not have to bother with NAT even if the internal
network uses private addresses.
It must be noted that packet-filtering rules have to be added in the
firewall in order to allow UDP packets from both the internal and
the external networks if they are destined for the RTP proxy.
Similarly, packets must be allowed to leave the DMZ if they come
from the RTP proxy. The RTP proxy will require a global IP address
for this solution to work as described in this document.
A SIP proxy controls the RTP proxy by using the media gateway
control protocol (MGCP) [3]. MGCP is a client-server protocol,
documented in RFC 2705. The solution requires that an MGCP call
agent is integrated in the SIP proxy.
The draft "draft-huitema-megaco-mgcp-firewall-00.txt" shows the
signaling needed for implementing this solution. Since only a small
subset of MGCP is needed the development time of this solution is
kept to a minimum.
4 SIP
4.1 General
The Session Initiation Protocol (SIP) is used to setup media
sessions between two or more parties. The session can include e.g.
audio and/or video streams.
A SIP message can look like this:
INVITE sip:watson@boston.bell-tel.com SIP/2.0
Via: SIP/2.0/UDP kton.bell-tel.com
From: A. Bell
To: T. Watson
Call-ID: 3298420296@kton.bell-tel.com
CSeq: 1 INVITE
Subject: Mr. Watson, come here.
Content-Type: application/sdp
Content-Length: ...
Thernelius, Engelholm Expires January 2001 [Page 2]
SIP Firewall Solution July 2000
v=0
o=bell 53655765 2353687637 IN IP4 128.3.4.5
s=Mr. Watson, come here.
c=IN IP4 kton.bell-tel.com
m=audio 3456 RTP/AVP 0 3 4 5
The SIP message contains two parts. A SIP part and a SDP part.
The SIP part basically describes who you want to contact (in the
example watson@boston.bell-tel.com) and from whom the invitation
come from (A.Bell).
The SDP part describes what kind of media stream you want to setup
and to where you want the B-client to setup the media stream (in the
example the A-client want the B-client to setup an RTP audio stream
towards port 3456 at kton.bell-tel.com).If this kind of message is
sent from a client connected to a company network or an ISP network
a few problem will arise if the network is connected through a
firewall towards the rest of internet.
5 Firewall Design
|
| +----------+
+--| |
| | |
| +----------+
EXTERNAL INTERNAL |
| :
| :
| :
oooo | :
ooo ooo |
ooo ooo +-----------+ | +----------+
o o | | | | Agent 1 |
o IP Cloud o--------| Firewall |---+--| |
ooo ooo | | | +----------+
/ ooo ooo +-----------+ |
/ oooo | |
/ DMZ |
/ |
/ | +----------+
+--------+ +--|SIP proxy |
| Agent 2| +----------+ | | |
| | |RTP proxy |---+ +----------+
+--------+ | | |
+----------+
Figure 1. Firewall Design View
Thernelius, Engelholm Expires January 2001 [Page 3]
SIP Firewall Solution July 2000
The design is based on a firewall/router (FW) with three interfaces.
The internal interface connects to all SIP agents inside the
firewall. The external interface connects to the unprotected
external world. The demilitarized zone (DMZ) is a third separate
interface connecting a number of proxies.
For SIP there are two proxies that are interesting, the SIP proxy
and the RTP proxy. The SIP proxy will transfer all SIP communication
between the internal and the external world. In the same way will
the RTP proxy transfer all RTP communication. This means that no SIP
or RTP traffic is allowed to pass through the firewall without first
passing one of the proxies.
It is noted that the architecture described above is not REQUIRED.
Both the RTP proxy and the SIP proxy MAY just as well be co-located
in the firewall box. For simplicity reasons the architecture in
Figure 1 is discussed in this document.
5.1 SIP Proxy
The SIP proxy will take care of all SIP messages that need to be
transferred between the internal and the external interfaces. When
SIP messages are received, the SIP proxy will use them to control
the RTP proxy so that all RTP ports for a multi media session are
opened/closed as they are needed.
In some cases the SIP proxy also have to modify addresses in the SIP
headers so that internal/private information is not send out on the
external side of the firewall. This draft does not attempt to cover
how this should be done.
The SIP proxy will exchange the SDP part of the message to the one
given by the RTP proxy (see below)
5.2 RTP Proxy
The RTP proxy will analyze the SDP part sent by the SIP proxy and
open/close the corresponding ports and then return a new SDP back to
the SIP proxy containing the addresses and ports used by the RTP
proxy for the current session. This new SDP is copied into the SIP
message by the SIP proxy which then forwards it to the correct
receiver.
The RTP proxy will be configured to use a wide range of ports for
the RTP traffic. The firewall will have to let UDP traffic through
if its destination or source address is the RTP proxy.
5.3 MGCP
The Media Gateway Control Protocol (MGCP) is used as a control
protocol between the SIP proxy and the RTP proxy. The SIP proxy have
Thernelius, Engelholm Expires January 2001 [Page 4]
SIP Firewall Solution July 2000
to integrate the client part of the protocol, the Call Agent (CA),
and the RTP proxy will have to implement the server part of the
protocol, the Call Agent Server (CAS). The CAS will use the well-
known MGCP port (2427).
MGCP is convenient to use for this purpose since it also uses SDP as
session description protocol, just as SIP do. In this way the SIP
proxy can just copy the SDP part from SIP messages to the MGCP
commands sent to the RTP proxy.
MGCP is also logical to use due to the fact that the functionality
of the RTP proxy is very similar to that of other media gateways in
the sense that we set up connections through the RTP proxy. In this
case the media gateway happens to have IP on the both sides. The
media gateway will thus work as an IP bridge.
When MGCP is used in the way described in this draft only a subset
of the entire protocol have to be implemented.
MGCP specifies possibility to get traffic statistics from the
gateway (RTP proxy) which means that functionality for charging can
be added.
6 Signal Flows
6.1 Session Setup (internal -> External)
6.1.1 Flow
agent1 SIP proxy RTP proxy agent2
| | | |
| SIP(INVITE) | | |
|----------------->| | |
| SIP(100 Trying) | | |
|<-----------------| | |
| | MGCP (Create Connection#1) | |
| |----------------------------->| |
| | MGCP (200 OK) | |
| |<-----------------------------| |
| | MGCP (Create Connection#2) | |
| |----------------------------->| |
| | MGCP (200 OK) | |
| |<-----------------------------| |
| | SIP (INVITE) | |
| |--------------------------------------------->|
| | SIP (200 OK) | |
| |<---------------------------------------------|
| | MGCP (Modify connection#2) | |
| |----------------------------->| |
| | MGCP (200 OK) | |
| |<-----------------------------| |
| | MGCP (Modify connection#1) | |
Thernelius, Engelholm Expires January 2001 [Page 5]
SIP Firewall Solution July 2000
| |----------------------------->| |
| | MGCP (200 OK) | |
| |<-----------------------------| |
| SIP(200 OK) | | |
|<-----------------| | |
| SIP(ACK) | | |
|----------------->| | |
| | MGCP (Modify connection: sendrecv) |
| |----------------------------->| |
| | MGCP (200 OK) | |
| |<-----------------------------| |
| | SIP (ACK) | |
| |--------------------------------------------->|
| | | |
|<----------------------------------------------->|<------------->|
|<---------- RTP traffic -------------->|<-RTP traffic->|
|<----------------------------------------------->|<------------->|
| | | |
| | | |
Figure 2. SIP and MGCP setup signaling
6.1.2 Description
RTP proxy
+--------+ P1 C1 P2 +---------+ P3 C2 P4 +--------+
| |o---------------o|- - - - -|o-----------------o| |
| agent1 | | R1 | | agent2 |
| |o----- | | -----o| |
+--------+ \ +---------+ / +--------+
\ o /
\ | /
\ | /
\ | /
\ | MGCP /
SIP \ | / SIP
\ | /
\ | /
\ | /
\ | /
\ | /
\ | /
C = Connection o o o
P = Endpoint +---------+
R = Relay | |
|SIP proxy|
| |
+---------+
Figure 3. Signaling between logical entities
Thernelius, Engelholm Expires January 2001 [Page 6]
SIP Firewall Solution July 2000
This is a logical view of what should be done for this traffic case.
The SIP proxy shall order the RTP proxy to setup connections (C1 and
C2) towards the two SIP agents where agent1 is inside the firewall
and agent2 is outside.
Everything starts with agent1 sending a SIP INVITE message to the
outbound SIP proxy:
INVITE sip:UserB@fwp1.wcom.com SIP/2.0
Via: SIP/2.0/UDP here.com:5060
From: TheBigGuy
To: TheLittleGuy
Call-Id: 12345600@here.com
CSeq: 1 INVITE
Contact: TheBigGuy
Content-Type: application/sdp
Content-Length:169
v=0
o=UserA 2890844526 2890844526 IN IP4 here.com
t=0 0
c=IN IP4 10.11.12.13
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 53000 RTP/AVP 32
a=rtpmap:32 MPV/90000
In this example UserA (user agent1) invites UserB (user agent2) to
participate in a session containing one audio stream (on port 49170
at IP address 10.11.12.13) and one MPEG video stream (on port 53000
also at IP address 10.11.12.13).
The SIP proxy will send a MGCP command ordering the RTP proxy to
setup a connection towards agent1 (C1):
CRCX 1432 relay/$@rtpproxy.here.com MGCP 1.0
C: A3F41278B7065249
M: inactive
v=0
o=UserA 2890844526 2890844526 IN IP4 here.com
t=0 0
c=IN IP4 10.11.12.13
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 53000 RTP/AVP 32
a=rtpmap:32 MPV/90000
The SIP proxy orders the RTP proxy to create a connection (CRCX) for
this session. The SDP from the SIP message is copied as it is and
will be analyzed by the Call Agent Server in the RTP proxy. The SIP
proxy has also specified a call id (C: ...) and the connection mode
Thernelius, Engelholm Expires January 2001 [Page 7]
SIP Firewall Solution July 2000
(M: ...). The mode is set to inactive at this stage because we don't
want the RTP proxy to forward any RTP packages yet (no receiver
yet).
The RTP proxy will now analyze the SDP part and create the
corresponding ports, which will be returned as a new SDP part in a
OK message:
200 1432 OK
Z: relay/42@rtpproxy.here.com
I: 32C789
v=0
o=UserA 2890844526 2890844526 IN IP4 here.com
t=0 0
c=IN IP4 200.3.4.5
m=audio 10126 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 10128 RTP/AVP 32
a=rtpmap:32 MPV/90000
The RTP proxy has generated a new IP address (200.3.4.5) and two new
port numbers (10126 and 10128). The RTP proxy actually allocates
four port numbers since each RTP port has a corresponding RTCP port
(10127 and 10129). A connection identity (I: ...) has also been
returned so the SIP proxy can direct orders directly to this
connection later on. The RTP proxy has also return a relay address
(Z: ...) for this connection so the SIP proxy can order the RTP
proxy to relay packages (R1 in the picture) between different
connections.
The SIP proxy will now order the RTP proxy to setup a new connection
(C2) towards agent2:
CRCX 1433 relay/42@rtpproxy.here.com MGCP 1.0
C: A3F41278B7065249
M: inactive
Since the SIP proxy has no information yet about agent2 it cannot
send any SDP information. Since the SIP proxy uses the same call id
and specifies the relay code (42) it received in the last response
from the RTP proxy the RTP proxy will create the corresponding ports
and setup the relay between these ports (R1 between P2 and P3). The
RTP proxy will then return an OK message with the new ports:
200 1433 OK
I: 32C78A
v=0
o=UserA 2890844526 2890844526 IN IP4 here.com
t=0 0
c=IN IP4 200.3.4.5
Thernelius, Engelholm Expires January 2001 [Page 8]
SIP Firewall Solution July 2000
m=audio 10130 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 10132 RTP/AVP 32
a=rtpmap:32 MPV/90000
The SIP proxy can know take the received SDP part and copy it into a
SIP INVITE message and send it to UserB at agent2:
INVITE sip:UserB@there.com SIP/2.0
Via: SIP/2.0/UDP fwp1.wcom.com:5060
Via: SIP/2.0/UDP here.com:5060
Record-Route:
From: TheBigGuy
To: TheLittleGuy
Call-Id: 12345600@here.com
CSeq: 1 INVITE
Contact: TheBigGuy
Content-Type: application/sdp
Content-Length:167
v=0
o=UserA 2890844526 2890844526 IN IP4 here.com
t=0 0
c=IN IP4 200.3.4.5
m=audio 10130 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 10132 RTP/AVP 32
a=rtpmap:32 MPV/90000
Agent2 can now setup communication towards the address and ports
pointed out the RTP proxy. When UserB has decided which media
streams he can/wants to participate in he respond with an OK
message:
SIP/2.0 200 OK
Via: SIP/2.0/UDP fwp1.wcom.com:5060
Via: SIP/2.0/UDP here.com:5060
Record-Route:
From: TheBigGuy
To: TheLittleGuy ;tag=314159
Call-Id: 12345600@here.com
CSeq: 1 INVITE
Contact: TheLittleGuy
Content-Type: application/sdp
Content-Length: 147
v=0
o=UserB 2890844527 2890844527 IN IP4 there.com
t=0 0
c=IN IP4 110.111.112.113
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
Thernelius, Engelholm Expires January 2001 [Page 9]
SIP Firewall Solution July 2000
m=video 0 RTP/AVP 32
In this message agent2 (UserB) says that the audio stream will be
received at port 3456 at IP address 110.111.112.113 but denies the
video stream by setting the port to zero.
The SIP proxy will now order the RTP proxy to modify the connection
towards agent2 using the SDP part received in the SIP message from
agent2:
MDCX 1434 relay/42@rtpproxy.here.com MGCP 1.0
C: A3F41278B7065249
I: 32C78A
M: inactive
v=0
o=UserB 2890844527 2890844527 IN IP4 there.com
t=0 0
c=IN IP4 110.111.112.113
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 0 RTP/AVP 32
The RTP proxy will remove the ports allocated for the video stream
since it will not be used. After that the RTP proxy respond with an
OK message:
200 1434 OK
The SIP proxy now orders the RTP proxy to modify the connection
towards agent1 (UserA):
MDCX 1435 relay/42@rtpproxy.here.com MGCP 1.0
C: A3F41278B7065249
I: 32C789
M: inactive
v=0
o=UserB 2890844527 2890844527 IN IP4 there.com
t=0 0
c=IN IP4 110.111.112.113
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 0 RTP/AVP 32
The RTP proxy modifies this connection according to the new SDP and
responds with an OK message:
200 1435 OK
Thernelius, Engelholm Expires January 2001 [Page 10]
SIP Firewall Solution July 2000
v=0
o=UserB 2890844527 2890844527 IN IP4 there.com
t=0 0
c=IN IP4 200.3.4.5
m=audio 10126 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 0 RTP/AVP 32
This SDP information is copied into the SIP OK message by the SIP
proxy and sent to UserA at agent1:
SIP/2.0 200 OK
Via: SIP/2.0/UDP here.com:5060
From: TheBigGuy
To: TheLittleGuy ;tag=314159
Call-Id: 12345600@here.com
CSeq: 1 INVITE
Contact: TheLittleGuy
Content-Type: application/sdp
Content-Length: 147
v=0
o=UserB 2890844527 2890844527 IN IP4 there.com
t=0 0
c=IN IP4 200.3.4.5
m=audio 10126 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 0 RTP/AVP 32
Agent1 can now configure its RTP ports to communicate with the RTP
proxy and after that send an ACK message back to agent2 via the SIP
proxy:
ACK sip:UserB@fwp1.wcom.com SIP/2.0
Via: SIP/2.0/UDP here.com:5060
Route:
From: TheBigGuy
To: TheLittleGuy ;tag=314159
Call-Id: 12345600@here.com
CSeq: 1 ACK
Content-Length: 0
The SIP proxy now has to order the RTP proxy to open up the RTP
traffic by issuing a new modify command (this could already have
been done when the SIP OK message arrived):
MDCX 1436 relay/42@rtpproxy.here.com MGCP 1.0
C: A3F41278B7065249
M: sendrecv
Thernelius, Engelholm Expires January 2001 [Page 11]
SIP Firewall Solution July 2000
The RTP proxy respond with an OK message after the mode have been
changed:
200 1436 OK
The SIP proxy now forwards the ACK message to agent2:
ACK sip: UserB@there.com SIP/2.0
Via: SIP/2.0/UDP fwp1.wcom.com:5060
Via: SIP/2.0/UDP here.com:5060
From: TheBigGuy
To: TheLittleGuy ;tag=314159
Call-Id: 12345600@here.com
CSeq: 1 ACK
Content-Length: 0
UserA and UserB can now send audio streams to each other through the
RTP proxy. Since all RTP traffic is passing the RTP proxy it means
that the RTP proxy can keep track on how much traffic is passing it
which can be used for e.g. charging. The RTP proxy can also check if
the packages passing is correct and throw away packages that has
some fault in them.
6.2 Session Disconnection (internal -> External)
6.2.1 Flow
agent1 SIP proxy RTP proxy agent2
| | | |
| SIP(BYE) | | |
|----------------->| | |
| | SIP (BYE) | |
| |------------------------------------------->|
| | SIP (200 OK) | |
| |<-------------------------------------------|
| | MGCP (Delete Connection#1) | |
| |----------------------------->| |
| | MGCP (250 OK) | |
| |<-----------------------------| |
| | MGCP (Delete Connection#2) | |
| |----------------------------->| |
| | MGCP (250 OK) | |
| |<-----------------------------| |
| SIP(200 OK) | | |
|<-----------------| | |
| | | |
Figure 4. SIP and MGCP setup signaling
6.2.2 Description
Thernelius, Engelholm Expires January 2001 [Page 12]
SIP Firewall Solution July 2000
RTP proxy
+--------+ P1 C1 P2 +---------+ P3 C2 P4 +--------+
| |o---------------o|- - - - -|o-----------------o| |
| agent1 | | R1 | | agent2 |
| |o----- | | -----o| |
+--------+ \ +---------+ / +--------+
\ o /
\ | /
\ | /
\ | /
\ | MGCP /
SIP \ | / SIP
\ | /
\ | /
\ | /
\ | /
\ | /
\ | /
C = Connection o o o
P = Endpoint +---------+
R = Relay | |
|SIP proxy|
| |
+---------+
Figure 5. Signaling between logical entities
This is a logical view of what should be done for this traffic case.
The SIP proxy shall order the RTP proxy to delete the two
connections (C1 and C2) towards the SIP agents where agent1 is
inside the firewall and agent2 is outside.
Agent1 initiates the disconnection by sending a SIP BYE message to
the SIP proxy:
BYE sip:UserB@fwp1.wcom.com SIP/2.0
Via: SIP/2.0/UDP here.com:5060
Route:
From: TheBigGuy
To: TheLittleGuy
Call-Id: 12345600@here.com
CSeq: 2 BYE
Content-Length:0
The SIP proxy forwards the BYE message to agent2:
BYE sip: UserB@there.com SIP/2.0
Via: SIP/2.0/UDP fwp1.wcom.com:5060
Via: SIP/2.0/UDP here.com:5060
From: TheBigGuy
To: TheLittleGuy ;tag=314159
Thernelius, Engelholm Expires January 2001 [Page 13]
SIP Firewall Solution July 2000
Call-Id: 12345600@here.com
CSeq: 2 BYE
Content-Length: 0
Agent2 confirms the disconnection by returning a OK message to the
SIP proxy:
SIP/2.0 200 OK
Via: SIP/2.0/UDP fwp1.wcom.com:5060
Via: SIP/2.0/UDP here.com:5060
From: TheBigGuy
To: TheLittleGuy ;tag=314159
Call-Id: 12345600@here.com
CSeq: 2 BYE
Content-Length: 0
The SIP proxy now orders the RTP proxy to delete the two connections
used by this session:
DLCX 1437 relay/42@rtpproxy.here.com MGCP 1.0
C: A3F41278B7065249
I: 32C789
DLCX 1438 relay/42@rtpproxy.here.com MGCP 1.0
C: A3F41278B7065249
I: 32C78A
After deleting each connection the RTP proxy respond with an OK
message for each delete command:
250 1437 OK
P: PS=1459, OS=34560, PR=1434, OR=33780, PL=2, JI=7, LA=26
250 1438 OK
P: PS=1434, OS=33780, PR=1459, OR=34560, PL=5, JI=5, LA=26
MGCP specifies a possibility for the gateway (RTP proxy in our case)
to return connection parameters (P: ...) when a connection is
deleted. These parameters basically says how many packets was sent
(PS) and received (PR) and how many octets that was sent (OS) and
received (OR). It is also specified how many packets were lost (PL)
the jitter (JI) and estimated network latency (LA).
8. Security Considerations
Strong authentication and encryption algorithms SHOULD protect the
communication between the SIP proxy and the RTP proxy.
Thernelius, Engelholm Expires January 2001 [Page 14]
SIP Firewall Solution July 2000
RTP proxy: This entity should have all services turned off except
those needed for management.
SIP proxy: This entity should have all services turned off except
those needed for management.
The firewall SHOULD allow communication to and from the RTP proxy
and SIP proxy, which both reside on the DMZ.
The SIP proxy MUST know if a certain SIP message came from the
"inside" or from the "outside". Otherwise it is possible for a user
to be able to open ports through the RTP proxy by answering his/her
own INVITE message with a 200 OK.
9. References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
[2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg,
"SIP:session initiation protocol," Request for Comments
(Proposed Standard) 2543, Internet Engineering Task Force,
Mar. 1999.
[3] M. Arango, A. Dugan, I. Elliott, C. Huitema, S. Pickett, "Media
Gateway Control Protocol Version 1.0", RFC 2705, October 1999.
10. Author's Addresses
Fredrik Thernelius
G÷talandsv„gen 230
Box 1505
125 25 ýlvsj÷
Stockholm, Sweden
Phone: +46-8-727 49 96
Email: fredrik.thernelius@uab.ericsson.se
Bertil Engelholm
G÷talandsv„gen 230
Box 1505
125 25 ýlvsj÷
Stockholm, Sweden
Phone: +46-8-727 3499
Email: bertil.engelholm@uab.ericsson.se
Thernelius, Engelholm Expires January 2001 [Page 15]
SIP Firewall Solution July 2000
11. Full Copyright Statement
"Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its 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 languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Thernelius, Engelholm Expires January 2001 [Page 16]