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

As some of you may have noticed my Blog was down for a while … (almost a month)

This had to do with some construction work on the attic of my house …

This is done now and I spoiled myself with a small mini server room .. where this webserver is running on.

I am going to replace my blog very soon to the servers of my ISP… but untill that happens it will still run in my server room at home.

I will be writing more articles soon … but first I need to pass my CCIE VOICE …

This is a small explanation about Interdigit Timeout.
Interdigit timeout is called T302 within CUCM.

To change the interdigit timeout value go to
System => Service Parameters
Select the CUCM server and the “Cisco CallManager” Service.
Once there do search with “CTRL-F” to open up the find window in your browser.
Then search for “302″
This will bring you down to the “T302 Timer” settings field.
Enter the desired value in milliseconds and then click “Save”.
When you are done restart the CCM service.

Navigate to Cisco Unified Serviceabillity
Tools => Control Center – Feature Services
Now select the server then click the radio button for Cisco CallManager and click on “Restart”.

From CUCM in regards to the T302 timer:

T302 Timer :
This parameter specifies an interdigit timer for sending the SETUP ACK message. The timer restarts each time Cisco CallManager receives a digit.
When this timer expires, CUCM routes the dialed digits. For exact timer definitions, refer to the Q.931 specification.
This is a required field.
Default: 15000
Minimum: 3000
Maximum: 75000

All Units are in msec.

I’ve come to the bluprint topic regarding MGCP…

This is how MGCP basically works.

A Media Gateway (MG) contains “simple” endpoints,

This endpoints can be:
– analog voice-ports (FXS/FXO)
- digital (T1-PRI/T1-CAS) voice trunks

The call Intelligence of these endpoints are provided by 1of the following:
– a Media Gateway Controller (MGC)
- Call Agent (CA)
- CUCM

There is a Master/Slave relationship between the MGC/CA and the MG.

In order to make everything work the MGCP sends messages over IP/UDP between the MGC and the MG.
The Voice traffic is also carried over IP/UDP.

MGCP messages have 8 commands or messages that are sent accross between MGC and the MG:

1) RQNT – NotificationRequest: CallManager can issue a NotificationRequest command to a
gateway, instructing the gateway to watch for specific events such as hook actions or Dual-Tone
Multifrequency (DTMF) tones on a specified endpoint. RQNT is also used to request a gateway
to apply a specific signal to endpoint (i.e. dial tone, ringback, etc).

2) NTFY – Notify: The gateway uses the Notify command to inform the CallManager when the
requested events occur.

3) CRCX – CreateConnection: CallManager uses the CreateConnection command to create a
connection that terminates in an endpoint inside the gateway.

4) MDCX – ModifyConnection: CallManager uses the ModifyConnection command to change
the parameters associated to a previously established connection.

5) DLCX – DeleteConnection: CallManager uses the DeleteConnection command to delete an
existing connection. The DeleteConnection command may also be used by a gateway to
indicate that a connection can no longer be sustained.

6) AUEP – AuditEndpoint: CallManager uses the AuditEndpoint commands to audit the status of
an endpoint associated with it.

7) AUCX – AuditConnection: CallManager uses the AuditConnection commands to audit the
status of any connection associated with it.

8 ) RSIP – RestartInProgress: The gateway uses the RestartInProgress command to notify the
CallManager that the gateway, or a group of endpoints managed by the gateway, is being taken
out of service or is being placed back in service.

There are three types of restart:
- Restart – endpoint in service
- Graceful – wait until call clearing
- Forced – endpoint out of service.

It is important to remember that this protocol is used for control purposes only. No voice data is transmitted through the MGCP protocol itself. All the voice data transfer occurs directly between the phone and the gateway. This diagram explains these relationships:

The Cisco 7960 IP phones in this example use the Skinny Call Control Protocol (SCCP) to communicate with the Cisco CallManager. The actual voice data is transferred through Real-time Transport Protocol (RTP) directly between the two devices. MGCP is used by the Cisco CallManager only to control the gateway.

This diagram below describes how Cisco CallManager registers voice gateways in its database with use of MGCP. The acknowledgment (ACK) commands are standard TCP acknowledgements of the received command:

This below diagram shows a sample FXS call flow (dialing and connection):

I believe it’s very important to know this because there could be OEQ’s on this topic!

I just added a new cheat sheet on my Cheat Sheet page.

This sheet are the basic ports that the CUCM is using to communicate with voice gateways and phones…

Have fun with it!

I just bumped into a nice youtube video about Cisco Unified Survivable Remote Site Telephony Video …
Thank god they included subtitles with this movie …

I have to warn you tough … it’s a bit annoying how this lady pronounce SRST…

Have fun watching it!

I’ve come to the part that I need to gather a lot of information on the CCIE voice blueprint specifics.
This in order to pass the OEQ part of the exam …
This is what I am using to study:

I am thinking of buying the INE CCIE Voice Core Knowledge Simulation package for $99 but I first need to know how big the pool is of questions they are offering.

I also created my own set of questions that is based in the content that can be found in the SRND guides…

When I have the feeling rhat I know enough to pass the OEQ part I am going to review the Cisco Networkers (Live) 2009 CCIE Voice Techtorial PDF.

There is also a very important document from Cisco with the ports that are used for the voice applications … I am sure that I don’t need to memmorize all the ports from the document. It;s important to read trough it and I highlighted the importand ports that I REALLY should know for the OEQ training…
You can download the document here –> Cisco Unified Callmanager TCP and UDP Port Usage (234)

I hope this is enough …

Based on the Cisco CCIE Worldwide Statistics website and the website of  Antonio Soares’ stats page I created some cool charts.

Here you go and have fun!

Last 5 years

2006

2007

2008

2009

2010

As I was telling you in my previous blog article Cisco Pagent is a set of tools…
Well what kind of tools and what can you do with these tools exactly?

Sit back and prepare yourself for some nice intel.

Pagent Tools

Traffic Generation, Count and Capture

• TGN—create and send packets
• PKTS—capture, fast-count, and display packets
• Template Compiler—language for defining packet formats
• Pagent Classic—create, send, capture, fast-count and display packets

IOS-Based Scripting

• SRE (Stimulus Response Engine)—respond to an event
• Router-Based Tcl—Tcl interpreter in privileged exec mode

Verified Traffic

• RVT/CVT (Router Verified Traffic/Control Verified Traffic)—generates and verifies traffic on a simulated network
• IVT/TCP and IVT/UDP—IOS Classic-based load-generation tools
• NQR (Network Quality Reporter)—A simple IOS-based tool that measures end-to-end network delay, jitter, packet drop, and out-of-sequence packets

Session Emulators

• TCP Session Emulator—generates TCP traffic
• HTTP Session Emulator—generates HTTP traffic
• FTP Session Emulator—generates FTP traffic

Large Network Emulators

• LNE-BGP, LNE-IGRP, LNE-EIGRP, LNE-OSPF, LNE-ISIS, LNE-RIP, LNE-LDP
• emulate routers that advertise large router networks

Modify Traffic

• PMOD (Passthru MODify)—allows a Pagent router to be inserted into a test network
• CSYN (Clock Synch)—assists the Network Time Protocol (NTP) to synchronize clocks between two or more Pagent routers

Client Emulators

• ICE (IGMP Client Emulator)—emulates the behavior of a multicast client (receiver) in a multicast network
• DHCP Client Emulator—emulates DHCP client devices and each client gets an IP address allocated by the DHCP server Related Tool—NVT

NVT (Network Verification Tool)

• web browser-based GUI interface to the Pagent tools

Traffic Generation, Count and Capture

Traffic Generation, Count and CaptureTGN—Used to define and send packets on any combination of supported interfaces on arouter. The program has predefined templates to support the definition of specific packettypes. Packet lengths and the data in any header field can be set to constant, random orincrementing values. Packet definitions can be imported from the PKTS program capturebuffer.

PKTS—Used to capture and display incoming and/or outgoing packets from anycombination of interfaces on a router. It can fast-count packets, that is, it can count anddiscard packets at higher rates than IOS counters can support. PKTS supports the creationof filters that allow selective counting, capture or display.
Template Compiler—Provides a convenient, high-level language for defining packetformats. It adds new definitions to the Pagent tools TGN and PKTS at run time and allows
TGN traffic streams and PKTS filters to be defined using the new formats. It allows thedefinitions of multiple display methods that can be used to decode and display packets.

Pagent Classic—Pagent Classic is the original Cisco router and IOS based network traffictransmission and validation tool. It runs on any Cisco router and allows the user to defineand transmit virtually any packet in hex (including corrupted packets) on any interfacesupported by the hosting platform. It also allows the capture and hex display of packets onany interface. Its functionality has been superseded by the TGN and PKTS programs.

IOS-Based Scripting

SRE (Stimulus Response Engine)—An IOS-based scripting language for networking
applications. SRE scripts can be used to receive, manipulate, modify, and send packets, to
test and simulate protocol stacks.

Router-Based Tcl—Use of the TCL language allows you to develop scripts that will run
autonomously on the router, to define new router commands command options, run
automated tests, or define Pagent packet response procedures.

Verified Traffic

RVT/CVT (Router Verified Traffic/Control Verified Traffic)—Router Verified Traffic
(RVT) and Control Verified Traffic (CVT) are used together to test bridges and routers.
CVT can automatically create numerous traffic streams between many Pagent router
interfaces, for many different LAN media and network protocols. RVT can create modest
levels of verified traffic where every packet sent through the test network is validated for
correct sequence, data integrity, and length. RVT can also create fast-unverified traffic.

IVT/TCP and IVT/UDP—IOS Classic-based load generation tools. The TCP and UDP
tools generate traffic between one or more routers using the socket interface provided by
IOS. Traffic is specified in terms of one or more data streams between specific network
addresses, or endpoints. By default, the primary endpoint of each data stream sends
messages and the secondary endpoint echoes the messages back to the primary.

NQR (Network Quality Reporter)—NQR is an IOS-based program in the Pagent test tool
set, introduced in Pagent 3.7. It is a simple tool that measures end-to-end network delay,
jitter, packet drop, and out-of-sequence packets. Packets are sent from an NQR router into a
network, which is configured to route the packets back into one of the interfaces of the
NQR router. NQR processes the returned packets and calculates the necessary statistics.

Session Emulators

TCP Session Emulator—Generates TCP traffic. The tool provides configurable features
that enable a user to emulate various TCP application dialogs between a TCP client and a
TCP server. It emulates multiple hosts establishing thousands of TCP connections. All these
TCP sessions are short-lived, which is very typical for web or email traffic.

HTTP Session Emulator—Generates HTTP traffic. It emulates multiple HTTP clients
establishing HTTP connections to a HTTP server. It generates all kinds of HTTP traffic,
including all kinds of HTTP requests and HTTP responses.

FTP Session Emulator—FTPSE is a TCP application for transferring files. The FTPSE
Client Emulator generates real FTP traffic and emulates FTP client sessions which must talk
to a real FTP server. Currently FTPSE only supports the client side in passive mode

Large Network Emulators

LNE-BGP, LNE-IGRP, LNE-EIGRP, LNE-OSPF, LNE-ISIS, LNE-RIP,
LNE-LDP—LNE is comprised of seven programs to support six routing protocols. LNE is
used to emulate routers that advertise large router networks. It can emulate hundreds of
routers to emulate multiple peers to a router under test. To stress the router under test, LNE
can flap entire LNE routers, routes advertised by the LNE routers or route attributes.

PMOD—PMOD allows a Pagent router to be inserted into a test network so test traffic
passes through the router and then allows the traffic packets to be modified. Depending on
PMOD filters and configurations, the tool can selectively drop, alter, delay or timestamp
packets. It also allows test packets to act as triggers and can recalculate test packet IP, TCP
and UDP checksums.

CSYN—CSYN assists the Network Time Protocol (NTP) to synchronize clocks between
two or more Pagent routers by confirming how closely the routers are synchronized. CSYN
causes multiple Pagent routers to display their time simultaneously so you can determine
how closely their clocks are set.

Client Emulators

ICE (IGMP Client Emulator)—ICE is used to emulate the behavior of a multicast client
(receiver) in a multicast network. The multicast clients utilize Internet Group Management
Protocol (IGMP) to interact with the router on the same subnet. TGN or IVT/UDP is used to
inject multicast traffic with different multicast group addresses.

DCE (DHCP Client Emulator)—DCE emulates DHCP client devices and each client gets
an IP address allocated by the DHCP server. It keeps track of IP address lease time and
responds upon lease expiration. It also provides all DHCP packet statistics as well as the
client’s DHCP state..

NVT

NVT is a web-based application with a graphical user interface front end to the Pagent
tools. It’s a network verification tool, used in a laboratory environment, to test:

• new hardware and network designs
• new software features
• upgrades

before deployment into the production network.

NVT emulates a busy network environment by:

• generating multiprotocol traffic
• verified data traffic
• routing protocol updates

NVT includes a set of pre-defined configurable fields, (i.e., standardized templates), in which you can create your own test scenarios:

• each template (as task) represents an individual test case
• profiles are a collection of tasks, and other profiles, grouped together to be
• executed serially or in parallel
• profiles are used to organize test scenarios

NVT monitors test performance by querying the network devices. Types of tasks include
a traffic generator, a traffic analyzer, session emulator, and routing protocol emulators, as
well as device queries.

Today I am going to tell you guys something about 2 tools that was developed by Cisco (or at least developed for Cisco)

Before I am telling anything about these tools I need to say cannot provide any of these tools and I will not provide any information on how you can get these tools.

The first tool is called IOU.
The second tool (that exist of a set of around 16 tools) is called Pagent.

IOU which basically means “IOS on Unix” is a tool that can simulate multiple router instances.

Pagent is based on the Cisco IOS (Internetwork Operating System), and developed within Cisco. The test tools are included in special IOS Pagent images.

IOU
IOS on Unix is a fully working version of IOS that runs as a user mode UNIX (Solaris) process. IOU is build as a native Solaris image and runs just like any other program on Solaris. IOU supports all platform independent protocols and features. It is possible to connect multiple copies of IOU trough the network to form some kind of virtual network.
This way you can build a bigger network using multiple Sun Ultrasparc machines.
There is also a version that runs on OSX (Mac) but I don’t know much about this version. It’s probably the same as the Solaris version but especially for Mac.
What is also nice to know is that there are IOU images available with the Pagent software build in.
Nowdays there is a programs like Dynamips, Dynagen and GNS3 doing the same IOU is doing.
Cisco employees (engineers) are using IOU to test complex designs and features in order to support large customers.

Pagent
The primary function of the Pagent tool set is to provide cost effective test tools to the Cisco community. This tool is NOT available for the public and requires a serial number based on the hardware serial number. There are some cracked versions available out there on torrent websites but this will not be the scope of this blog.

Since the tools are based on production hardware and the IOS operating system, the tools are not able to test the datalink level. They cannot affect frame checksums, preambles, inter frame gap times, or inject hardware failures.
There are limitations to the rates that Pagent tools can transmit and receive packets. Due to the processing power of the main CPU, not all IOS based devices are able to transmit packets at full media rates.

The Pagent programs are best used for testing layer 3 protocols and above. That is, emulating routing
protocols, multicast, TCP sessions, HTTP sessions. Pagent images have a security scheme to prevent illegal distribution outside Cisco. When an router is loaded with a Pagent image for the first time, it presents a machine Id that must be converted to a license key. Once the license key is entered in the router, it is saved in the configuration so it is not required on subsequent downloads.

Pagent tools
• TGN (Traffic Generator) is used to define and send packets on any combination of supported
interfaces on a router. The program has predefined templates to support the definition of specific
packet types. Packet lengths and the data in any header field can be set to constant, incrementing
or random values. Packet definitions can be imported from the PKTS program capture buffer.
• PKTS (Packet Count and Capture) can capture and display incoming and/or outgoing packets from
any combination of interfaces on a router. It can fast-count packets, that is, it can count and discard
packets at higher rates than IOS counters can support. PKTS supports the creation of filters that
allow selective counting, capture or display
• Template Compiler provides a convenient high-level language for defining packet formats. It adds
new packet definitions to the Pagent tool set (TGN and PKTS) at run time and allows TGN traffic
streams and PKTS filters to be defined using the new formats. It allows the definition of multiple
display methods that can be used to decode and display packets.
• Router Verified Traffic (RVT) and Control Verified Traffic (CVT) are used together to test bridges
and routers. CVT can automatically create numerous traffic streams between many Pagent router
interfaces, for many different LAN media and network protocols. RVT can create modest levels of
verified traffic where every packet sent through the test network is validated for correct sequence,
data integrity, and length. RVT can also create fast-unverified traffic.
• PMOD (Passthru Modify) allows a Pagent router to be inserted into a test network so test traffic
passes through the router and then allows the traffic packets to be modified. Depending on PMOD
filters and configurations, the tool can selectively drop, alter, delay or timestamp packets. It also
allows test packets to act as triggers and can recalculate test packet IP, TCP and UDP checksums.
• TCP Session Emulator (TCPSE) is a tool for generating TCP traffic. The tool provides configurable
features that enable a user to emulate various TCP application dialogs between a TCP client and a TCP server. It emulates multiple hosts establishing thousands of TCP connections. All these TCP sessions are short-lived, which is very typical for web or email traffic.
• HTTP Session Emulator (HTTPSE) is a tool for generating HTTP traffic. It emulates multiple
HTTP clients establishing HTTP connections to a HTTP server. It generates all kinds of HTTP
traffic, including all kinds of HTTP requests and HTTP responses.
• FTP Session Emulator (FTPSE) is a TCP application for transferring files. The FTPSE Client
Emulator generates real FTP traffic and emulates FTP client sessions, which must talk to a real
FTP server. Currently FTPSE only supports the client side in passive mode.
• Large Network Emulators (LNE) is comprised of six programs to support six routing protocols:
BGP, OSPF, ISIS, EIGPR, IGRP and RIP. LNE is used to emulate routers that advertise large router
networks. It can emulate hundreds of routers to emulate multiple peers to a router under test. To
stress the router under test, LNE can flap entire LNE routers, routes advertised by the LNE routers
or route attributes.
• NQR) is , a tool to measure end-to-end network delay, jitter, packet drop, and out-of-sequence packets.

Next time I am going to go deeper into the pagent tools and I am going to give examples how LNE, TGEN, PKTS and much more is working.