The Evolved Packet Core (EPC model)

By Frédéric Firmin, 3GPP MCC

This article looks at the Evolved Packet Core (EPC), the core network of the LTE system, giving an overview of the architecture of the core network, describing some of its key elements.
The EPC is the latest evolution of the 3GPP core network architecture.
In GSM, the architecture relies on circuit-switching (CS). This means that circuits are established between the calling and called parties throughout the telecommunication network (radio, core network of the mobile operator, fixed network). This circuit-switching mode can be seen as an evolution of the "two cans and a string". In GSM, all services are transported over circuit-switches telephony principally, but short messages (SMS) and some data is also seen.

In GPRS, packet-switching (PS) is added to the circuit-switching. With this technology, data is transported in packets without the establishment of dedicated circuits. This offers more flexibility and efficiency. In GPRS, the circuits still transport voice and SMS (in most cases). Therefore, the core network is composed of two domains: circuit and packet.
In UMTS (3G), this dual-domain concept is kept on the core network side. Some network elements have evolved but the concept remains very similar.
When designing the evolution of the 3G system, the 3GPP community decided to use IP (Internet Protocol) as the key protocol to transport all services. It was therefore agreed that the EPC would not have a circuit-switched domain anymore and that the EPC should be an evolution of the packet-switched architecture used in GPRS/UMTS.
This decision had consequences on the architecture itself but also on the way that the services were provided. Traditional use of circuits to carry voice and short messages needed to be replaced by IP-based solutions in the long term.

Architecture of the EPC

EPC was first introduced by 3GPP in Release 8 of the standard.
It was decided to have a "flat architecture". The idea is to handle the payload (the data traffic) efficiently from performance and costs perspective. Few network nodes are involved in the handling of the traffic and protocol conversion is avoided.
It was also decided to separate the user data (also known as the user plane) and the signalling (also know as the control plane) to make the scaling independent. Thanks to this functional split, the operators can dimension and adapt their network easily.
Figure 2 shows a very basic architecture of the EPS when the User Equipment (UE) is connected to the EPC over E-UTRAN (LTE access network). The Evolved NodeB (eNodeB) is the base station for LTE radio. In this figure, the EPC is composed of four network elements: the Serving Gateway (Serving GW), the PDN Gateway (PDN GW), the MME and the HSS. The EPC is connected to the external networks, which can include the IP Multimedia Core Network Subsystem (IMS).

HSS
Basically, the HSS (for Home Subscriber Server) is a database that contains user-related and subscriber-related information. It also provides support functions in mobility management, call and session setup, user authentication and access authorization.
It is based on the pre-3GPP Release 4 - Home Location Register (HLR) and Authentication Centre (AuC).
Serving GW
The gateways (Serving GW and PDN GW) deal with the user plane. They transport the IP data traffic between the User Equipment (UE) and the external networks.
The Serving GW is the point of interconnect between the radio-side and the EPC. As its name indicates, this gateway serves the UE by routing the incoming and outgoing IP packets.
It is the anchor point for the intra-LTE mobility (i.e. in case of handover between eNodeBs) and between LTE and other 3GPP accesses.
It is logically connected to the other gateway, the PDN GW.
PDN GW
The PDN GW is the point of interconnect between the EPC and the external IP networks. These networks are called PDN (Packet Data Network), hence the name. The PDN GW routes packets to and from the PDNs.
The PDN GW also performs various functions such as IP address / IP prefix allocation or policy control and charging.
3GPP specifies these gateways independently but in practice they may be combined in a single "box" by network vendors.
MME
The MME (for Mobility Management Entity) deals with the control plane. It handles the signalling related to mobility and security for E-UTRAN access.
The MME is responsible for the tracking and the paging of UE in idle-mode. It is the termination point of the Non-Access Stratum (NAS).

Support of multiple access technologies

As seen in figure 2, the UE can reach the EPC using E-UTRAN however this is not the only access technology supported.
3GPP specified support of multiple access technologies and also the handover between these accesses. The idea was to bring convergence using a unique core network providing various IP-based services over multiple access technologies.
Existing 3GPP radio access networks are supported. 3GPP specifications define how the interworking is achieved between an E-UTRAN (LTE and LTE-Advanced), GERAN (radio access network of GSM/GPRS) and UTRAN (radio access network of UMTS-based technologies WCDMA and HSPA).
The EPS also allows non-3GPP technologies to interconnect the UE and the EPC. Non-3GPP means that these accesses were not specified in the 3GPP. These technologies includes e.g. WiMAX, cdma2000®, WLAN or fixed networks.
Non-3GPP accesses can be split into two categories: the "trusted" ones and the "untrusted":

• Trusted non-3GPP accesses can interact directly with the EPC.
• Untrusted non-3GPP accesses interwork with the EPC via a network entity called the ePDG (for Evolved Packet Data Gateway). The main role of the ePDG is to provide security mechanisms such as IPsec tunnelling of connections with the UE over an untrusted non-3GPP access.

3GPP does not specify which non-3GPP technologies should be considered trusted or untrusted. This decision is made by the operator.

Upgrading Cisco Router IOS

Today I upgraded the flash and system RAM in my Cisco 2651XM router.

Before upgrading the router memory, I had this in place:

C2600 platform with 65536 Kbytes of main memory

16384K bytes of processor board System flash (Read/Write)

I bought 64 MB extra main memory and 16 MB extra flash memory. When I opened up the router, the insides looked like this diagram:

I had a single 64 MB DRAM DIMM in the "Primary memory" slot with one free. I had no memory in the "System-code SIMM (Flash memory)" slot, since the 2651XM must ship with 16 MB on the motherboard. Once I snapped in the extra memory, my router recognized it without any trouble, as will be seen later.

I also decided to upgrade from a 12.2 release to 12.3. My old IOS was 12.2(11)T10, which corresponded to the c2600-ik9s-mz.122-11.T10.bin image. The 'show flash' command showed this after the memory upgrades:

gill#sh flash

System flash directory:
File  Length   Name/status
  1   14962584  c2600-ik9s-mz.122-11.T10.bin
[14962648 bytes used, 18591784 available, 33554432 total]
32768K bytes of processor board System flash (Read/Write)

First I searched for a suitable IOS from the Cisco IOS Feature Navigator and Upgrade Planner tools. I located a version of IOS which offered NetFlow and SSH v2 in the 12.3 train, 12.3(4)T4 (image c2600-a3jk9s-mz.123-4.T4.bin). I downloaded it to a TFTP server on the same network as the router, into the TFTP server's /tftpboot directory.

I did not make a copy of the existing router flash image as I already had it elsewhere for safekeeping.

Next I copied my startup-config to the TFTP server:

gill#copy startup-config tftp://172.27.20.5/gill-startup-config
Address or name of remote host [172.27.20.5]?
Destination filename [gill-startup-config]?
!!
2200 bytes copied in 0.072 secs (30556 bytes/sec)

Now I was ready to copy my new flash image to the router:

gill#copy tftp flash
Address or name of remote host []? 172.27.20.5
Source filename []? c2600-a3jk9s-mz.123-4.T4.bin
Destination filename [c2600-a3jk9s-mz.123-4.T4.bin]?
Accessing tftp://172.27.20.5/c2600-a3jk9s-mz.123-4.T4.bin...
Erase flash: before copying? [confirm]
Erasing the flash filesystem will remove all files! Continue? [confirm]
Erasing device... eeeeeeeeeeeeeeee
...edited...
Erase of flash: complete
Loading c2600-a3jk9s-mz.123-4.T4.bin from 172.27.20.5 (via FastEthernet0/1):!!!!
!!!
...edited...
[OK - 24299960 bytes]
Verifying checksum...  OK (0x5193)
24299960 bytes copied in 182.832 secs (132909 bytes/sec)

Next I checked to see if it was loaded:

gill#sh flash

System flash directory:
File  Length   Name/status
  1   24299960  c2600-a3jk9s-mz.123-4.T4.bin
[24300024 bytes used, 8730120 available, 33030144 total]
32768K bytes of processor board System flash (Read/Write)

This looked fine, so I changed the system boot parameters to use the new image, copied the running-config to startup-config, and reloaded the router:

gill#conf term
Enter configuration commands, one per line.  End with CNTL/Z.
gill(config)#no boot system flash c2600-ik9s-mz.122-11.T10.bin
gill(config)#boot system flash  c2600-a3jk9s-mz.123-4.T4.bin
gill(config)#exit
gill#
01:21:28: %SYS-5-CONFIG_I: Configured from console by console
gill#copy running-config startup-config
Destination filename [startup-config]?
Building configuration...
[OK]
gill#reload
Proceed with reload? [confirm]

01:22:32: %SYS-5-RELOAD: Reload requested by console.

I then watched the router come up:

System Bootstrap, Version 12.2(7r) [cmong 7r], RELEASE SOFTWARE (fc1)
Copyright (c) 2002 by cisco Systems, Inc.
C2600 platform with 131072 Kbytes of main memory

program load complete, entry point: 0x80008000, size: 0x172c840
Self decompressing the image : ###########
...edited...
############ [OK]

Smart Init is enabled
smart init is sizing iomem
  ID            MEMORY_REQ                 TYPE
00036F          0X00103980 C2651XM Dual Fast Ethernet
                0X000F3BB0 public buffer pools
                0X00211000 public particle pools
TOTAL:          0X00408530

If any of the above Memory Requirements are
"UNKNOWN", you may be using an unsupported
configuration or there is a software problem and
system operation may be compromised.
Rounded IOMEM up to: 5Mb.
Using 3 percent iomem. [5Mb/128Mb]
...edited...
program load complete, entry point: 0x80008000, size: 0x172c840
Self decompressing the image : ###########
...edited...
############ [OK]

Smart Init is enabled
smart init is sizing iomem
  ID            MEMORY_REQ                 TYPE
00036F          0X00103980 C2651XM Dual Fast Ethernet
                0X000F3BB0 public buffer pools
                0X00211000 public particle pools
TOTAL:          0X00408530

If any of the above Memory Requirements are
"UNKNOWN", you may be using an unsupported
configuration or there is a software problem and
system operation may be compromised.
Rounded IOMEM up to: 5Mb.
Using 3 percent iomem. [5Mb/128Mb]
...edited...
Cisco IOS Software, C2600 Software (C2600-A3JK9S-M), Version 12.3(4)T4, 
 RELEASE SOFTWARE (fc2)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2004 by Cisco Systems, Inc.
Compiled Thu 11-Mar-04 19:57 by eaarmas
Image text-base: 0x80008098, data-base: 0x8243BC1C
...edited...
Cisco 2651XM (MPC860P) processor (revision 0x100) with 125952K/5120K bytes of me
mory.
Processor board ID JAE071601DV (2514262155)
M860 processor: part number 5, mask 2
2 FastEthernet interfaces
32K bytes of NVRAM.
32768K bytes of processor board System flash (Read/Write)

Press RETURN to get started!

*Mar  1 00:00:04.695: %LINEPROTO-5-UPDOWN: Line protocol on Interface VoIP-Null0,
 changed state to up
*Mar  1 00:00:15.280: %LINK-3-UPDOWN: Interface FastEthernet0/0,
 changed state to up
*Mar  1 00:00:15.280: %LINK-3-UPDOWN: Interface FastEthernet0/1,
 changed state to up
00:00:16: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0,
 changed state to up
00:00:16: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1,
 changed state to up
00:00:18: %SYS-5-CONFIG_I: Configured from memory by console
00:00:19: %SYS-5-RESTART: System restarted --

Cisco IOS Software, C2600 Software (C2600-A3JK9S-M), Version 12.3(4)T4,  RELEASE
 SOFTWARE (fc2)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2004 by Cisco Systems, Inc.
Compiled Thu 11-Mar-04 19:57 by eaarmas
00:00:19: %SNMP-5-COLDSTART: SNMP agent on host gill is undergoing a cold start
00:00:19: %NTP-6-RESTART: NTP process starts
00:00:20: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0,
 changed state to down
00:00:20: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1,
 changed state to down
00:00:21: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1,
 changed state to up
00:00:27: %DHCP-6-ADDRESS_ASSIGN: Interface FastEthernet0/0 assigned DHCP address edited,
 mask 255.255.254.0, hostname gill
00:00:30: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0,
 changed state to up
00:00:33: %NTP-5-PEERSYNC: NTP synced to peer 204.152.184.72
00:00:33: %NTP-6-PEERREACH: Peer 204.152.184.72 is reachable

Everything looks fine, including the time setting via NTP. I also looked again at the flash and then the filesystem:

gill>enable
Password:
gill#sh flash detailed

System flash directory:
File  Length   Name/status
        addr      fcksum  ccksum
  1   24299960  c2600-a3jk9s-mz.123-4.T4.bin
        0x40      0x5193  0x5193
[24300024 bytes used, 8730120 available, 33030144 total]
32768K bytes of processor board System flash (Read/Write)
gill#show file systems
File Systems:

     Size(b)     Free(b)      Type  Flags  Prefixes
           -           -    opaque     rw   system:
       29688       26383     nvram     rw   nvram:
           -           -    opaque     rw   null:
           -           -    opaque     ro   xmodem:
           -           -    opaque     ro   ymodem:
           -           -   network     rw   tftp:
*   33030144     8730120     flash     rw   flash:
           -           -   network     rw   pram:
           -           -   network     rw   rcp:
           -           -   network     rw   scp:
           -           -   network     ro   http:
           -           -   network     rw   ftp:
           -           -   network     ro   https:
           -           -    opaque     ro   cns:

My upgrade was complete!

Posted by Richard Bejtlich

How to run topologies in GNS3 without hitting %100 utilization

How to get Good Idle-PC Value in GNS3

One of the most difficult problems new users have to come to grips with when starting out with GNS3 is the concept of an Idle-PC.
Get it right, and you will have a great GNS3 experience. Try to ignore it, and you will be forever miserable.
Here is my tedious and time consuming method of finding a good idle-pc value.
REPEAT FOR EVERY DIFFERENT IOS IMAGE YOU WISH TO RUN ON YOUR SYSTEM:
Step 1:
Windows: Open the windows task manager and sort by %CPU
Linux: Open a console window and enter the command top
Mac OS X: Open a terminal window and enter the command top -o cpu
Keep this window visible for the entire process

Step 2:

In GNS3, start a new topology with 1 router ONLY
Start the router
Open the console. When when the router is fully up, configure the following:

line con 0
exec-timeout 0

NOTE: While writing this post, I observed this step alone dropped the CPU usage from 98% to 1% on a Windows 7 install (running in a VM on OS X)

Step 3:

Back at your task manager or console window:
Take note of the amount of CPU being chewed by dynamips

Step 4:

In GNS3, right-click on the router and choose idle-pc
If NO values appear marked with *, try again
When you find a value marked with a *, WRITE IT DOWN
If MULTIPLE values appear with *, WRITE THEM ALL DOWN (in a column)
… then choose one of them

Step 5:

Check the CPU utilisation for dynamips in the task manager or console window.
Estimate the average CPU consumption for dynamips over say 15-20 seconds
WRITE IT DOWN next to the Idle-pc value you wrote down in step 4
If you have an idle-pc vlaue that shows less than 10-15% CPU, you may want to go to step 6,
Else, go back to step 4

Step 6:

Now that you have a good idle-pc, you need to know how to use it well.
Firstly, check that GNS3 has recorded you best value against the image you are using
That’s in:
Edit->IOS Images and Hypervisors
Select the image you are using and check the IDLE PCs value
Now GNS3 will automatically use that value in any NEW topologies you create.

Step 7:

If you have any saved topologies (ie .net files) that have used this IOS, open the .net file and replace the idle-pc value found there with your new “good” idle-pc value.

Step 8:

Record the results you found (IOS & idle-pc values) in a spreadsheet and keep it!
Now go back to Step 1 and repeat for the next IOS image you use

General Tips for keeping CPU under control

Always use the same image for ALL routers in your topology if possible.
This means using the same router model as well. If this is not possible, use the same image for all routers of the same model.
ALWAYS set the exec-timeout 0 under line con 0
In GNS 0.7.3 and later, you can set a base config for each IOS image under Edit->IOS Images and Hypervisors. Make sure the base config has the exec-timeout 0 under line con 0

Reference: http://www.gns3.net/phpBB/topic2873.html

FACETIME_ANALYSIS

NAT traversal for the SIP protocol

By Diana Cionoiu;

NAT stands for Network Address Translation. It's the technology which allows most people to have more than one computer in their home and still use a single IP address. Most of the time, a router with NAT support gets data packets from the internal network (with internal IP addresses) and sends them to Internet, changing the internal IP address of each packet to the external one.

What's RTP?

RTP stands for Real-Time Transport Protocol. Its purpose is to pass voice data between a caller and the called. The problem is that when you call someone using the RTP protocol, you need to know his IP address and port. This makes RTP quite inconvenient when used alone, since the parts have no way to find one another. This is why people invented SIP.

What's SIP?

SIP (Session Initiation Protocol) looks in syntax like HTTP, human readable text. Its purpose is to help the caller find the IP address and port of the called. It also helps the negotiation of the media types and formats. For example, when you have a PC at home and you want to call your friend from Romania using Free World Dialup (which uses the SIP protocol):

SIP sends an INVITE packet with the caller IP address and port for RTP to the FWD server, and from there, FWD forwards the call to the intended destination. The called accepts the call and sends his own IP address and port for RTP back.

SIP + NAT, an unsolvable problem?

The problem with SIP and NAT is not actually a SIP problem, but the RTP problem. SIP announces the RTP address and port, but if the client is behind NAT, it announces the client's RTP port, which can be different from the port the NAT allocates externally.

Even if a lot of SIP implementations and carriers are based on the fact that NAT will always try to allocate the same port, that assumption is false. In a production environment, you can't tell grandma that she can't talk with her grandson because some router has allocated another number.

If you are a carrier, the solution is simple because you proxy all the data, anyway. The solution is to use a SIP Session Border Controller. The SIP SBC normally stays in front of the internal SIP network of the carrier, solving the NAT traversal problem and protecting the SIP network.

The solution for NAT traversal in this case is to use some tricks.
The first trick is to keep open the hole in the NAT from the SIP client to the server. This is normally done by making all SIP clients use a two byte packet which is sent more often than 30 seconds. Some routers remove apparently unused NAT mappings after 30 seconds; GNU/Linux typically does this after three minutes.
The second trick is one we've used for our project YATE, to figure out the RTP IP and port from the first packet that arrives on the local RTP IP and port of the server, and to use it instead of using the RTP IP and address declared in SDP. This trick solves the NAT traversal problem, no matter how many NATs the client is traversing. However, the main disadvantage is that, in some cases, the client will not receive early media (since at that point, it sends out no voice packets) and it will not hear the ringing.
If you are not a carrier and you are trying to make a peer-to-peer call and both sides are behind the NAT, you must use an external SIP proxy or gateway to pass the SIP between the two points, hoping that the NATs will open the proper ports, one to another, for the RTP connection. However, there is no ultimate solution for that. Two proposed solutions are STUN and ICE, but every solution that currently exists can get in your way sometimes. Skype has found a very simple and nice solution for this problem: They use the Skype clients that are not behind NAT to proxy all the data for clients that are behind NAT.

This solution, technically speaking, is very good. However, there are some moral and political reasons not to use Skype. One of them is that if you are a Skype client outside the NAT, you don't know whose data is passing through your computer. Another is that it is using your bandwidth; after all, someone has to pay one way or another for Internet bandwidth necessary to proxy the voice stream.
My personal hope is that in the near future, most SIP implementations will use the two tricks used by YATE. Skype will probably be around for a long time for home users, but enterprise seems to move slowly to VoIP providers. With a lot of work and a little bit of luck, they will become at least as reliable as PSTN providers, since the technology is better.

Facetime Analysis

This blog article is based on the blog article that was written by FryGuy.
This article will explain what is happening on the low level when a Facetime call is made between 2 x iPhone 4 devices.
FryGuy tested facetime and enabled packet capturing in his ASA to see what is actually happening on the network when you make a simple facetime call.
ASA packet capturing is explained HERE.

iPhone 4 #1 = IP Private – 192.168.0.128
iPhone 4 #1 = IP NAT – 216.164.100.100
iPhone 4 #2 = IP Private 192.168.2.106
iPhone 4 #2 = IP NAT – 72.81.200.200

Apple Video Servers = 17.155.5.251 / 17.155.5.252 / 17.155.4.14
Note: NATs change to protect the guilty
1.  The call is first initiated via regular Celluar networks.  In the contact list you will see an icon called FaceTime.

2.  The phones then communicate to a server at Apple (17.155.5.251 is what he saw).  Communication is sourced from port 16402 via UDP initially and then looks to dynamically allocate ports for communication (16385 and 16386 are what appeared on his end).

1 0.000000 192.168.0.128 17.155.5.251 UDP Source port: 16402 Destination port: connected
2 0.431054 17.155.5.251 192.168.0.128 UDP Source port: connected Destination port: 16402
3 0.715713 192.168.0.128 17.155.5.251 UDP Source port: 51136 Destination port: connected
4 0.716064 192.168.0.128 17.155.5.251 UDP Source port: 51136 Destination port: 16385
5 0.717147 192.168.0.128 17.155.5.252 UDP Source port: 51136 Destination port: 16386
6 0.958285 17.155.5.252 192.168.0.128 UDP Source port: 16386 Destination port: 51136
7 0.960329 17.155.5.251 192.168.0.128 UDP Source port: 16385 Destination port: 51136
8 0.960588 17.155.5.251 192.168.0.128 UDP Source port: connected Destination port: 51136
9 1.016402 192.168.0.128 216.164.100.100 UDP Source port: 51136 Destination port: 52585
10 1.018172 192.168.0.128 216.164.100.100 UDP Source port: 51136 Destination port: 52585

3. The phone then negotiates an HTTPS connection to the servers at Apple for the setup and communication. There also seems to be some communication to other servers (in this case  RCN 208.59.216.10) – and they are FryGuys cable provider.

11 1.019912 192.168.0.128 17.155.4.14 TCP 50697 > https [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2 TSV=469580285 TSER=0
12 1.020140 192.168.0.128 216.164.100.100 UDP Source port: 51136 Destination port: 52585
13 1.298294 17.155.4.14 192.168.0.128 TCP https > 50697 [SYN, ACK] Seq=0 Ack=1 Win=8190 Len=0 MSS=1360 WS=4
14 1.318312 192.168.0.128 17.155.4.14 TCP 50697 > https [ACK] Seq=1 Ack=1 Win=131920 Len=0
15 1.321211 192.168.0.128 17.155.4.14 TLSv1 Client Hello
16 1.645657 192.168.0.128 17.155.5.251 UDP Source port: 51136 Destination port: connected
17 1.645978 192.168.0.128 17.155.5.251 UDP Source port: 51136 Destination port: 16385
18 1.646130 192.168.0.128 17.155.5.252 UDP Source port: 51136 Destination port: 16386
19 1.662234 192.168.0.128 208.59.216.10 TCP 50698 > http [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2 TSV=469580291 TSER=0
20 1.730834 17.155.4.14 192.168.0.128 TCP [TCP segment of a reassembled PDU]
21 1.731963 17.155.4.14 192.168.0.128 TLSv1 Server Hello, Certificate, Server Hello Done
22 1.808298 208.59.216.10 192.168.0.128 TCP http > 50698 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1380 TSV=941715237 TSER=469580291 WS=1
23 1.832208 192.168.0.128 17.155.4.14 TCP 50697 > https [ACK] Seq=160 Ack=1361 Win=130560 Len=0
24 1.834588 192.168.0.128 17.155.4.14 TCP 50697 > https [ACK] Seq=160 Ack=2490 Win=130788 Len=0
25 1.834954 192.168.0.128 208.59.216.10 TCP 50698 > http [ACK] Seq=1 Ack=1 Win=131328 Len=0 TSV=469580293 TSER=941715237
26 1.836526 192.168.0.128 208.59.216.10 HTTP GET /WebObjects/VCInit.woa/wa/getBag?ix=1 HTTP/1.1
27 1.881018 17.155.5.252 192.168.0.128 UDP Source port: 16386 Destination port: 51136
28 1.882147 17.155.5.251 192.168.0.128 UDP Source port: connected Destination port: 51136
29 1.883124 17.155.5.251 192.168.0.128 UDP Source port: 16385 Destination port: 51136
30 1.884207 192.168.0.128 216.164.100.100 UDP Source port: 51136 Destination port: 52585
31 1.886053 192.168.0.128 216.164.100.100 UDP Source port: 51136 Destination port: 52585
32 1.886343 192.168.0.128 216.164.100.100 UDP Source port: 51136 Destination port: 52585
33 1.930729 192.168.0.128 17.155.4.14 TLSv1 Client Key Exchange
34 1.930835 192.168.0.128 17.155.4.14 TLSv1 Change Cipher Spec
35 1.931583 192.168.0.128 17.155.4.14 TLSv1 Encrypted Handshake Message
36 2.190008 208.59.216.10 192.168.0.128 TCP http > 50698 [ACK] Seq=1 Ack=229 Win=6432 Len=0 TSV=941715619 TSER=469580293
37 2.190313 208.59.216.10 192.168.0.128 TCP [TCP segment of a reassembled PDU]
38 2.191366 208.59.216.10 192.168.0.128 TCP [TCP segment of a reassembled PDU]
39 2.192312 208.59.216.10 192.168.0.128 HTTP/XML HTTP/1.1 200 OK
40 2.242678 192.168.0.128 208.59.216.10 TCP 50698 > http [ACK] Seq=229 Ack=2737 Win=128592 Len=0 TSV=469580297 TSER=941715619
41 2.243014 192.168.0.128 208.59.216.10 TCP 50698 > http [ACK] Seq=229 Ack=3506 Win=127820 Len=0 TSV=469580297 TSER=941715619
42 2.393275 17.155.4.14 192.168.0.128 TCP https > 50697 [ACK] Seq=2490 Ack=299 Win=35216 Len=0
43 2.393305 17.155.4.14 192.168.0.128 TCP https > 50697 [ACK] Seq=2490 Ack=305 Win=35216 Len=0
44 2.393351 17.155.4.14 192.168.0.128 TCP https > 50697 [ACK] Seq=2490 Ack=342 Win=35184 Len=0
45 2.394633 17.155.4.14 192.168.0.128 TLSv1 Change Cipher Spec, Encrypted Handshake Message
46 2.448112 192.168.0.128 17.155.4.14 TCP 50697 > https [ACK] Seq=342 Ack=2533 Win=131876 Len=0
47 2.449760 192.168.0.128 17.155.4.14 TLSv1 Application Data
48 2.450325 192.168.0.128 17.155.4.14 TLSv1 Application Data
49 2.511448 192.168.0.128 17.155.5.251 UDP Source port: 51136 Destination port: connected
50 2.512608 192.168.0.128 17.155.5.251 UDP Source port: 51136 Destination port: 16385
51 2.512776 192.168.0.128 17.155.5.252 UDP Source port: 51136 Destination port: 16386
52 2.905644 17.155.5.252 192.168.0.128 UDP Source port: 16386 Destination port: 51136
53 2.905690 17.155.4.14 192.168.0.128 TCP https > 50697 [ACK] Seq=2533 Ack=966 Win=34560 Len=0
54 2.905782 17.155.4.14 192.168.0.128 TCP https > 50697 [ACK] Seq=2533 Ack=1453 Win=34064 Len=0
55 2.906896 17.155.5.251 192.168.0.128 UDP Source port: 16385 Destination port: 51136
56 2.907536 17.155.5.251 192.168.0.128 UDP Source port: connected Destination port: 51136
57 2.923466 17.155.4.14 192.168.0.128 TLSv1 Application Data
58 2.923924 17.155.4.14 192.168.0.128 TLSv1 Application Data
59 3.060254 192.168.0.128 216.164.100.100 UDP Source port: 51136 Destination port: 52585
60 3.060422 192.168.0.128 216.164.100.100 UDP Source port: 51136 Destination port: 52585
61 3.062146 192.168.0.128 17.155.4.14 TCP 50697 > https [ACK] Seq=1453 Ack=2894 Win=131556 Len=0
62 3.062451 192.168.0.128 17.155.4.14 TCP 50697 > https [ACK] Seq=1453 Ack=3240 Win=131212 Len=0
63 3.062741 192.168.0.128 199.7.52.190 TCP 50699 > http [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2 TSV=469580305 TSER=0
64 3.063122 192.168.0.128 216.164.100.100 UDP Source port: 51136 Destination port: 52585
65 3.532458 199.7.52.190 192.168.0.128 TCP http > 50699 [SYN, ACK] Seq=0 Ack=1 Win=8190 Len=0 MSS=1380
66 3.571122 192.168.0.128 199.7.52.190 TCP 50699 > http [ACK] Seq=1 Ack=1 Win=65535 Len=0
67 3.579117 192.168.0.128 199.7.52.190 HTTP GET /EVIntl2006.cer HTTP/1.1
68 3.690690 192.168.0.128 17.155.4.14 TLSv1 Encrypted Alert
69 3.692505 192.168.0.128 17.155.5.251 UDP Source port: 51136 Destination port: connected
70 3.696701 192.168.0.128 17.155.4.14 TCP 50697 > https [FIN, ACK] Seq=1476 Ack=3240 Win=131920 Len=0
71 3.697007 192.168.0.128 208.59.216.10 TCP 50698 > http [FIN, ACK] Seq=229 Ack=3506 Win=131328 Len=0 TSV=469580312 TSER=941715619
72 3.697388 192.168.0.128 17.155.5.251 UDP Source port: 51136 Destination port: 16385
73 3.697617 192.168.0.128 17.155.5.252 UDP Source port: 51136 Destination port: 16386
74 3.809626 199.7.52.190 192.168.0.128 TCP [TCP segment of a reassembled PDU]
75 3.810572 199.7.52.190 192.168.0.128 HTTP HTTP/1.0 200 OK (text/plain)
76 3.881720 192.168.0.128 199.7.52.190 TCP 50699 > http [ACK] Seq=154 Ack=1865 Win=65535 Len=0
77 3.890585 192.168.0.128 199.7.52.190 TCP 50699 > http [FIN, ACK] Seq=154 Ack=1865 Win=65535 Len=0
78 3.952258 208.59.216.10 192.168.0.128 TCP http > 50698 [FIN, ACK] Seq=3506 Ack=230 Win=6432 Len=0 TSV=941717381 TSER=469580312
79 3.954256 192.168.0.128 208.59.216.10 TCP 50698 > http [ACK] Seq=230 Ack=3507 Win=131328 Len=0 TSV=469580314 TSER=941717381
80 4.007781 17.155.4.14 192.168.0.128 TCP https > 50697 [ACK] Seq=3240 Ack=1476 Win=40928 Len=0
81 4.007965 17.155.4.14 192.168.0.128 TCP https > 50697 [FIN, ACK] Seq=3240 Ack=1477 Win=40928 Len=0
82 4.009155 17.155.5.251 192.168.0.128 UDP Source port: 16385 Destination port: 51136
83 4.009170 17.155.5.251 192.168.0.128 UDP Source port: connected Destination port: 51136
84 4.009948 192.168.0.128 17.155.4.14 TCP 50697 > https [FIN, ACK] Seq=1476 Ack=3240 Win=131920 Len=0
85 4.014495 192.168.0.128 17.155.4.14 TCP 50697 > https [ACK] Seq=1477 Ack=3241 Win=131920 Len=0
86 4.019866 192.168.0.128 216.164.100.100 UDP Source port: 51136 Destination port: 52585
87 4.023955 17.155.5.252 192.168.0.128 UDP Source port: 16386 Destination port: 51136
88 4.025984 192.168.0.128 216.164.100.100 UDP Source port: 51136 Destination port: 52585
89 4.034971 192.168.0.128 216.164.100.100 UDP Source port: 51136 Destination port: 52585
90 4.504292 199.7.52.190 192.168.0.128 TCP http > 50699 [ACK] Seq=1865 Ack=155 Win=8190 Len=0
91 4.671800 192.168.0.128 17.155.5.251 UDP Source port: 51136 Destination port: connected
92 4.672167 192.168.0.128 17.155.5.251 UDP Source port: 51136 Destination port: 16385
93 4.672411 192.168.0.128 17.155.5.252 UDP Source port: 51136 Destination port: 16386
94 5.139092 17.155.5.252 192.168.0.128 UDP Source port: 16386 Destination port: 51136
95 5.140068 17.155.5.251 192.168.0.128 UDP Source port: 16385 Destination port: 51136
96 5.140129 17.155.5.251 192.168.0.128 UDP Source port: connected Destination port: 51136
97 5.210011 192.168.0.128 216.164.100.100 UDP Source port: 51136 Destination port: 52585
98 5.215809 192.168.0.128 216.164.100.100 UDP Source port: 51136 Destination port: 52585
99 5.216068 192.168.0.128 216.164.100.100 UDP Source port: 51136 Destination port: 52585
100 5.715774 192.168.0.128 17.155.5.251 UDP Source port: 51136 Destination port: 16385
101 6.054578 17.155.5.251 192.168.0.128 UDP Source port: 16385 Destination port: 51136

4. After Client (iPhone) and server negotiation you start to see Stun requests via the private IPs, after they fail you see them from the Public IP NAT ranges. They success via the Public peering at that point.

102 8.258196 192.168.0.128 192.168.2.106 STUN2 Binding Request
103 8.286606 192.168.0.128 192.168.2.106 STUN2 Binding Request
104 8.303893 192.168.0.128 72.81.200.200 STUN2 Binding Request
105 8.313353 192.168.0.128 192.168.2.106 STUN2 Binding Request
106 8.313582 72.81.200.200 192.168.0.128 STUN2 Binding Request
107 8.316909 192.168.0.128 72.81.200.200 STUN2 Binding Success Response
108 8.333677 192.168.0.128 72.81.200.200 STUN2 Binding Request
109 8.344419 72.81.200.200 192.168.0.128 STUN2 Binding Request
110 8.350980 192.168.0.128 72.81.200.200 STUN2 Binding Success Response
111 8.360852 192.168.0.128 72.81.200.200 STUN2 Binding Request
112 8.374294 72.81.200.200 192.168.0.128 STUN2 Binding Request
113 8.376750 192.168.0.128 72.81.200.200 STUN2 Binding Success Response
114 8.467002 192.168.0.128 192.168.2.106 STUN2 Binding Request
115 8.496083 192.168.0.128 192.168.2.106 STUN2 Binding Request
116 8.528156 72.81.200.200 192.168.0.128 STUN2 Binding Request
117 8.530139 192.168.0.128 72.81.200.200 STUN2 Binding Request
118 8.530765 192.168.0.128 72.81.200.200 STUN2 Binding Success Response
119 8.553316 72.81.200.200 192.168.0.128 STUN2 Binding Request
120 8.555467 192.168.0.128 72.81.200.200 STUN2 Binding Request
121 8.556032 192.168.0.128 72.81.200.200 STUN2 Binding Success Response
122 8.626234 72.81.200.200 192.168.0.128 STUN2 Binding Success Response
123 8.629896 72.81.200.200 192.168.0.128 STUN2 Binding Success Response

5. A SIP call is then initiated between the phones for the video portion of the call

124 8.730361 192.168.0.128 72.81.200.200 SIP/SDP Request: INVITE sip:user@72.81.200.200:50925, with session description
125 8.748746 72.81.200.200 192.168.0.128 STUN2 Binding Success Response
126 8.771618 192.168.0.128 192.168.2.106 STUN2 Binding Request
127 8.797557 192.168.0.128 192.168.2.106 STUN2 Binding Request
128 8.925571 72.81.200.200 192.168.0.128 STUN2 Binding Success Response
129 8.927723 72.81.200.200 192.168.0.128 STUN2 Binding Success Response
130 9.232700 192.168.0.128 72.81.200.200 SIP/SDP Request: INVITE sip:user@72.81.200.200:50925, with session description
131 9.258562 192.168.0.128 192.168.2.106 STUN2 Binding Request
132 9.262926 72.81.200.200 192.168.0.128 SIP Status: 100 Trying
133 9.268831 72.81.200.200 192.168.0.128 SIP Status: 180 Ringing
134 9.296692 192.168.0.128 192.168.2.106 STUN2 Binding Request
135 9.320586 72.81.200.200 192.168.0.128 SIP/SDP Status: 200 OK, with session description
136 9.326857 192.168.0.128 72.81.200.200 SIP Request: ACK sip:user@72.81.200.200:50925
137 9.334699 192.168.0.128 72.81.200.200 SIP Request: MESSAGE sip:user@72.81.200.200:50925
138 9.688477 72.81.200.200 192.168.0.128 SIP/SDP Status: 200 OK, with session description
139 9.716567 192.168.0.128 72.81.200.200 SIP Request: ACK sip:user@72.81.200.200:50925
140 9.834542 192.168.0.128 72.81.200.200 SIP Request: MESSAGE sip:user@72.81.200.200:50925
141 10.216053 72.81.200.200 192.168.0.128 SIP Status: 200 OK
142 10.230152 192.168.0.128 72.81.200.200 SIP Request: MESSAGE sip:user@72.81.200.200:50925
143 10.442848 72.81.200.200 192.168.0.128 SIP Status: 200 OK
144 10.491689 72.81.200.200 192.168.0.128 SIP Status: 200 OK
145 10.727812 192.168.0.128 72.81.200.200 SIP Request: MESSAGE sip:user@72.81.200.200:50925
146 11.229984 192.168.0.128 72.81.200.200 SIP Request: MESSAGE sip:user@72.81.200.200:50925
147 11.318007 72.81.200.200 192.168.0.128 SIP Status: 200 OK
148 11.367565 192.168.0.128 72.81.200.200 SIP Request: MESSAGE sip:user@72.81.200.200:50925
149 11.618986 72.81.200.200 192.168.0.128 SIP Status: 200 OK
150 11.866691 192.168.0.128 72.81.200.200 SIP Request: MESSAGE sip:user@72.81.200.200:50925
151 11.998932 192.168.0.128 72.81.200.200 UDP Source port: 16402 Destination port: 50925
152 12.035444 72.81.200.200 192.168.0.128 SIP Status: 200 OK
153 12.063916 192.168.0.128 72.81.200.200 UDP Source port: 16402 Destination port: 50925
154 12.129174 192.168.0.128 72.81.200.200 UDP Source port: 16402 Destination port: 50925
155 12.180258 192.168.0.128 72.81.200.200 UDP Source port: 16402 Destination port: 50925
156 12.183416 192.168.0.128 72.81.200.200 UDP Source port: 16402 Destination port: 50925
157 12.187093 72.81.200.200 192.168.0.128 SIP Status: 200 OK
158 12.195043 192.168.0.128 72.81.200.200 UDP Source port: 16402 Destination port: 50925
159 12.200932 72.81.200.200 192.168.0.128 SIP Request: BYE sip:user@192.168.0.128:16402
160 12.206181 192.168.0.128 72.81.200.200 SIP Status: 200 OK

6. So in the end, this is a Video SIP call

VPN's: IPSec vs. SSL

From Tony Bradley, CISSP-ISSAP, former About.com Guide

In years gone by if a remote office needed to connect with a central computer or network at company headquarters it meant installing dedicated leased lines between the locations. These dedicated leased lines provided relatively fast and secure communications between the sites, but they were very costly. To accommodate mobile users companies would have to set up dedicated dial-in remote access servers (RAS). The RAS would have a modem, or many modems, and the company would have to have a phone line running to each modem. The mobile users could connect to the network this way, but the speed was painstakingly slow and made it difficult to do much productive work.
With the advent of the Internet much of that has changed. If a web of servers and network connections already exists, interconnecting computers around the globe, then why should a company spend money and create administrative headaches by implementing dedicated leased lines and dial-in modem banks. Why not just use the Internet?
Well, the first challenge is that you need to be able to choose who gets to see what information. If you simply open up the whole network to the Internet it would be virtually impossible to implement an effective means of keeping unauthorized users from gaining access to the corporate network. Companies spend tons of money to build firewalls and other network security measures aimed specifically at ensuring that nobody from the public Internet can get into the internal network.
How do you reconcile wanting to block the public Internet from accessing the internal network with wanting your remote users to utilize the public Internet as a means of connecting to the internal network? You implement a Virtual Private Network (VPN). A VPN creates a virtual “tunnel” connecting the two endpoints. The traffic within the VPN tunnel is encrypted so that other users of the public Internet can not readily view intercepted communications.
By implementing a VPN, a company can provide access to the internal private network to clients around the world at any location with access to the public Internet. It erases the administrative and financial headaches associated with a traditional leased line wide-area network (WAN) and allows remote and mobile users to be more productive. Best of all, if properly implemented, it does so without impacting the security and integrity of the computer systems and data on the private company network.
Traditional VPN’s rely on IPSec (Internet Protocol Security) to tunnel between the two endpoints. IPSec works on the Network Layer of the OSI Model- securing all data that travels between the two endpoints without an association to any specific application. When connected on an IPSec VPN the client computer is “virtually” a full member of the corporate network- able to see and potentially access the entire network.

The majority of IPSec VPN solutions require third-party hardware and / or software. In order to access an IPSec VPN, the workstation or device in question must have an IPSec client software application installed. This is both a pro and a con.
The pro is that it provides an extra layer of security if the client machine is required not only to be running the right VPN client software to connect to your IPSec VPN, but also must have it properly configured. These are additional hurdles that an unauthorized user would have to get over before gaining access to your network.
The con is that it can be a financial burden to maintain the licenses for the client software and a nightmare for tech support to install and configure the client software on all remote machines- especially if they can’t be on site physically to configure the software themselves.
It is this con which is generally touted as one of the largest pros for the rival SSL (Secure Sockets Layer) VPN solutions. SSL is a common protocol and most web browsers have SSL capabilities built in. Therefore almost every computer in the world is already equipped with the necessary “client software” to connect to an SSL VPN.
Another pro of SSL VPN’s is that they allow more precise access control. First of all they provide tunnels to specific applications rather than to the entire corporate LAN. So, users on SSL VPN connections can only access the applications that they are configured to access rather than the whole network. Second, it is easier to provide different access rights to different users and have more granular control over user access.
A con of SSL VPN’s though is that you are accessing the application(s) through a web browser which means that they really only work for web-based applications. It is possible to web-enable other applications so that they can be accessed through SSL VPN’s, however doing so adds to the complexity of the solution and eliminates some of the pros.
Having direct access only to the web-enabled SSL applications also means that users don’t have access to network resources such as printers or centralized storage and are unable to use the VPN for file sharing or file backups.
SSL VPN’s have been gaining in prevalence and popularity; however they are not the right solution for every instance. Likewise, IPSec VPN’s are not suited for every instance either. Vendors are continuing to develop ways to expand the functionality of the SSL VPN and it is a technology that you should watch closely if you are in the market for a secure remote networking solution. For now, it is important to carefully consider the needs of your remote users and weigh the pros and cons of each solution to determine what works best for you.