Manual
Table Of Contents
- Preface
- Introduction
- Process Summary
- Prerequisites
- Run the Service Setup Wizard
- VCS System Configuration
- Routing Configuration
- Pre-search Transforms
- Search Rules
- Task 8: Configuring Transforms
- Task 9: Configuring Local Zone Search Rules
- Task 10: Configuring the Traversal Zone
- Neighboring Between VCS Clusters
- Task 11: Configuring Traversal Zone Search Rules
- Task 12: Configuring the DNS Zone
- Task 13: Configuring DNS Zone Search Rules
- Task 14: Configuring External (Unknown) IP Address Routing
- Endpoint Registration
- System Checks
- Maintenance Routine
- Optional Configuration Tasks
- Appendix 1: Configuration Details
- Appendix 2: DNS Records
- Appendix 3: Firewall and NAT Settings
- Appendix 4: Advanced Network Deployments
- Obtaining Documentation and Submitting a Service Request
- Cisco Legal Information
- Cisco Trademark
SIP INVITE Arriving at Endpoint B - Static NAT Mode Enabled
Packet header:
Source IP: 64.100.0.10
Destination IP: 64.100.0.20
SIP payload:
INVITE sip: 64.100.0.20 SIP/2.0
Via: SIP/2.0/TLS 10.0.10.2:5061
Via: SIP/2.0/TLS 10.0.20.3:55938
Call-ID: 20ec9fd084eb3dd2@127.0.0.1
CSeq: 100 INVITE
Contact: <sip:EndpointA@10.0.20.3:55938;transport=tls>
From: "Endpoint A" <sip:EndpointA@cisco.com>;tag=9a42af
To: <sip: 64.100.0.20>
Max-Forwards: 70
Content-Type: application/sdp
Content-Length: 2825
v=0
s=-
c=IN IP4 64.100.0.10
b=AS:2048
…
…
…
With static NAT enabled on LAN2 of the VCS Expressway, the c-line of the SIP INVITE has now been rewritten to
c=IN IP4 64.100.0.10, and this means that when endpoint B sends outbound RTP media to endpoint A, this will be
sent to IP address 64.100.0.10, the public NAT address of the NAT router, which is 1:1 NATed to the LAN2 IP address
of the VCS Expressway, 10.0.10.2. As RTP media from endpoint B arrives at the NAT router with a destination IP
address of 64.100.0.10, the NAT router will forward these packets to the VCS Expressway at 10.0.10.2 and two-way
media is achieved.
What About Routers/Firewalls with SIP/H.323 ALG?
Some routers and firewalls have SIP and H.323 ALG capabilities. ALG is also referred to as Fixup, Inspection,
Application Awareness, Stateful Packet Inspection, Deep Packet Inspection and so forth. This means that the
router/firewall is able to identify SIP and H.323 traffic as it passes through and inspect, and in some cases modify, the
payload of the SIP and H.323 messages. The purpose of modifying the payload is to help the H.323 or SIP application
from which the message originated to traverse NAT, i.e. to perform a similar process to what the VCS Expressway
does.
The challenge with router/firewall-based SIP and H.323 ALGs is that these were originally intended to aid relatively
basic H.323 and SIP applications to traverse NAT, and these applications had, for the most part, very basic
functionality and often only supported audio.
Over the years, many H.323 and SIP implementations have become more complex, supporting multiple video streams
and application sharing (H.239, BFCP), encryption/security features (H.235, DES/AES), firewall traversal (Assent,
H.460) and other extensions of the SIP and H.323 standards.
For a router/firewall to properly perform ALG functions for SIP and H.323 traffic, it is therefore of utmost importance
that the router/firewall understands and properly interprets the full content of the payload it is inspecting. Since
H.323 and SIP are standards/recommendations which are in constant development, it is not likely that the
router/firewall will meet these requirements, resulting in unexpected behavior when using H.323 and SIP applications
in combination with such routers/firewalls.
There are also scenarios where the router/firewall normally will not be able to inspect the traffic at all, for example
when using SIP over TLS, where the communication is end-to-end secure and encrypted as it passes through the
router/firewall.
69
Cisco VCS Expressway and VCS Control - Basic Configuration Deployment Guide
Appendix 4: Advanced Network Deployments