Real Networks RDT Mode

Three channels

- Control connection (TCP)

- UDP data (simplex UDP)

- UDP resend (simplex UDP) Outbound connections

- If outbound traffic is allowed, open inbound port for UDP data

- If outbound traffic is not allowed, open inbound port for UDP data and open outbound port UDP resend

Inbound connections

- If outbound traffic is allowed, open inbound port for UDP resend

- If outbound traffic is not allowed, open outbound port for UDP data and open inbound port UDP resend

Server

Client

Server

TCP: Control

Setup transport5 x-real-rdt/udp client_port = 3057 server_port = 5000

UDP: Data

UDP: Resend

©2000, Cisco Systems,

In RealNetworks' RDT mode, the following three channels are used by RTSP:

■ TCP control channel—Standard TCP connection initiated from the client to the server.

■ UDP data channel—Simplex (unidirectional) UDP session used for media delivery using the standard UDP packet format from the server to the client.

■ UDP resend—Simplex (unidirectional) UDP session used for the client to request that the server resend lost data packets.

For RealNetworks' RDT mode RTSP traffic, the PIX Firewall will behave in the following manner:

■ Outbound connections

< If outbound UDP traffic is implicitly allowed, and after the client and the server negotiate the transport mode and the ports to use for the session, the PIX Firewall opens a temporary inbound conduit for the UDP data channel from the server.

< If outbound UDP traffic is not implicitly allowed, and after the client and the server negotiate the transport mode and the ports to use for the session, the PIX Firewall opens a temporary inbound conduit for the UDP data channel from the server and a temporary outbound conduit for the UDP resend channel from the client.

■ Inbound connections

< If a conduit exists allowing inbound connections to an RTSP server, and if all outbound UDP traffic is implicitly allowed, the PIX Firewall opens a temporary outbound conduit for the UDP data channel from the server.

< If a conduit exists allowing inbound connections to an RTSP server, and if all outbound TCP traffic is not implicitly allowed, the PIX Firewall opens temporary conduits for the UDP data and UDP resend channels from the server and client, respectively.

RTSPFixup Configuration

pixfirewall (config)#

fixup protocol rtsp port[-port]

• Defines ports for RTSP connections

- No RTSP fixup is enabled by default. RFC2326 port is 554.

- RTSP dynamically opens UDP connections as required by the RTSP transport.

- PAT and dual NAT are not currently supported.

- UDP transport modes are disallowed.

- TCP transport modes are allowed (TCP connection rules apply).

pixfirewall(config)# fixup protocol rtsp 554 pixfirewall(config)# fixup protocol rtsp 8554-8574 pixfirewall(config)# no fixup protocol rtsp

CSPFA 1.01—5-17

By default, the PIX Firewall does not inspect any ports for RTSP connections. To enable the PIX Firewall to inspect specific ports for RTSP traffic, such as the standard port 554, use the fixup protocol rtsp command.

The fixup protocol rtsp command causes the PIX Firewall to dynamically create conduits for RTSP UDP channels for RTSP traffic on the indicated port.

Use the no form of the command to disable the inspection of traffic on the indicated port for RTSP connections. If the fixup protocol sqlnet command is not enabled for a given port, then neither outbound or inbound RTSP will work properly on that port.

Using the no fixup protocol rtsp command without any arguments causes the PIX Firewall to clear all previous fixup protocol rtsp assignments.

The syntax of the fixup protocol rtsp command is as follows:

fixup protocol rtsp port[-port]

no fixup protocol rtsp port[-port]

fixup protocol rtsp port[-port]

no fixup protocol rtsp port[-port]

Argument

Description

port[-port\

Single port or port range that the PIX Firewall will inspect for RTSP connections.

H.323

• Real-time multimedia communications delivery specification

- Uses two TCP and several UDP sessions for a single "call"

• Supported H.323 versions

• Supported applications

- Cisco Multimedia Conference

• H.323 protocols and standards

- H.225-Registration,

Admission, and Status (RAS)

Manager

- Microsoft NetMeeting

- Intel Video Phone

- H.225-Call Signaling

- CUseeMe Networks

- H.245-Control Signaling

• MeetingPoint

- TPKT Header

• CUseeMe Pro

- Q.931 Messages

- VocalTec

- Abstract Syntax Notation (ASN.1) (PIX Firewall 5.2)

• Internet Phone

• Gatekeeper

H.323 is more complicated than other traditional protocols because it uses two TCP connections and several UDP sessions for a single "call." (Only one of the TCP connections goes to a well-known port; all the other ports are negotiated and are temporary.) Furthermore, the content of the streams is far more difficult for firewalls to understand than existing protocols because H.323 encodes packets using Abstract Syntax Notation, or ASN.l.

Other protocols and standards supported within H.323 are as follows:

■ H.225-Registration, Admission, and Status (RAS)

■ H.225-Call Signaling

■ H.245-Control Signaling

0 0

Post a comment