Skinny inspection enables voice communication between two Skinny clients by using the Cisco CallManager. The Cisco CallManager uses the TCP port 200 to provide services to Skinny clients. A Skinny client connects to the primary Cisco CallManager by establishing a TCP connection and if available, connects to a secondary Cisco CallManager. After the TCP connection is established, the Skinny client registers with the primary Cisco CallManager, which will be used as the controlling Cisco CallManager until it reboots or a keepalive failure occurs. Thus, the TCP connection between the Skinny client and the Cisco CallManager exists forever and is used to establish calls coming to or from the client. If a TCP connection fails, the secondary Cisco CallManager is used. All data channels established with the initial Cisco CallManager remain active and will be closed after the call ends.

The Skinny protocol inspects the locally generated or terminated Skinny control channels and opens or closes pinholes for media channels that originate from or are destined to the firewall. Pinholes are ports that are opened through a firewall to allow an application controlled access to a protected network. The Skinny traffic that passes through and locally generated or terminated Skinny traffic is treated in the same way at the firewall.

The table below lists the set of messages that are necessary for the data sessions to open and close. Skinny inspection will examine the data sessions that are deemed for opening and closing the access list pinholes.

When two phones register with the CME running on Cisco IOS firewall, two control channels terminated on the CME box. These two control channels are TCP connections and are inspected by the Firewall Skinny module. When pinholes are opened for the media traffic, a total of four pre-gen sessions are created, two for each control session.

With the flow-through mode of operation of CME, the four pregenerated sessions are converted to two active sessions. The same number of active sessions is retained because there are two media sessions, one from each phone terminating on CME.

With the flow-around mode of operation of CME, the CME is bypassed as there is a direct connection between the two phones. In this mode, there are two possible scenarios:

• When both phones are on the same side of the CME, there is no exchange of media packets between the two phones. However, exchange of media packets is possible with pass-through traffic. In this case, the pre-gen sessions will timeout because the media traffic will not reach the router itself.
• When both phones are located on either side of the CME, the media traffic goes through the CME box. The four pre-gen sessions that are created are converted to one active session. Instead of creating four pre-gen sessions, only two pre-gen sessions are created. These two pre-gen sessions are converted to one active session when you see the media traffic.

In typical deployments, both Cisco IOS firewall and Network Address Translator (NAT) will be running on the same router. When CME is also running, typically in the case of an Integrated Services Router (ISR), some complexities and limitations exist.

• If two Skinny phones are registered to CME that is on the Cisco IOS firewall with NAT. When Phone 1 attempts to communicate with Phone 2, the IP and port (mostly private IP) of Phone 1 will be exchanged with Phone 2 over the already established TCP connection.
• If NAT is configured on the outside interface to translate all the private addresses to the router's global address. Some private addresses are exchanged over a TCP connection between the router and the remote phone. If NAT is able to translate the addresses in such flows where one endpoint is the router itself, then NAT and CME running on the same box will not cause any problems. If not, the following scenarios are possible:
• In flow-through mode of operation, the voice data channels, Real-time Transport Protocol (RTP) stream over User Datagram Protocol (UDP), from Phone 1 and Phone 2, both terminate on CME. So, there will be one RTP over UDP connection from Phone 1 to the CME and a second from Phone 2 to the CME. The CME relays the voice data over the two channels. In this case, there should not be any problem with NAT running on the CME box, as the connection is terminated on the router from Phone 2 and the address used for that connection is the global address of the router.
• In flow-around mode of operation, there is a direct connection (RTP over UDP) between Phone1 and Phone 2 for carrying voice data traffic. If NAT does not translate the private IP of Phone 1, then the voice data channel will not be established successfully because the private IP of Phone 1 is shared in the control channel. In such a scenario, the running of CME with NAT breaks down.

A new registry is created in the Skinny local media traffic path. This path differs from the regular switching path code, where all the controlling and pass-through media traffic is inspected. The Skinny module sends the locally generated traffic using the "fastsend" application program interface (API) which does not put the packet in the regular switching path, but sends it directly (to Layer 2 drivers). This new registry resets the timeouts for the media channels and also reports the number of Skinny media sessions that are established such as the output of show commands.

Note

The above API is used to update the Firewall sessions when the media channel is active. Firewall will not attempt to protect the CME box based on the nonexistence of pregen. Therefore, the firewall will not drop media packets for which there is no pre-gen/active session. The MTP module in CME protects itself by dropping the packets that do not match the source IP and source port numbers.

1.    enable

2.    configure terminal

3.    parameter-map type inspect parameter-map-name

4.    alert {on | off}

5.    audit-trail {on | off}

6.    class-map type inspect protocol-name [match-any| match-all] class-map-name

7.    policy-map type inspect policy-map-name

8.    class type inspect class-map-name

9.    zone security name

10.    zone security name

11.    exit

12.    zone-pair security zone-pair-name {source source-zone-name| self} destination [self | destination-zone-name]

13.    service-policy type inspect policy-map-name

14.    interface type number

15.    zone-member security zone-name