Iwan Hoogendoorn

Hi Guys,

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

Hi,

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.

Hi,

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!

Hi,

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!

Hi,

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!

Hi,

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 …

Hi,

I proudly present the first cheatsheet that I made.

you can find it on the cheatsheet page.

Have fun and if you have any requests, remarks or questions just send me a mail.

Iwan Hoogendoorn

Hi,

Today I managed to get CME working on a GNS3/Dynamips router.
The steps that I followed:

- Create a new GNS3 Project
- Get the IOS version “c3725-adventerprisek9_ivs-mz.124-15.T6.bin”
- Get the CME files “cme-full-4.3.0.0.tar”
- Create a new 3700 router
- Edit the properties and change the PCMCI disk0 space to 99MB

- Create a cloud with a breakout to your real network with the Ethernet NIO interface

- When that is done connect 1 of the router interfaces to the NIO Cloud interface

- Start the Router
- Assign an IP address to the routers interface (the one that is connected to the NIO/LAN breakout interface) and if neccesary also put in a default gateway.
- Set up an TFTP server where you will put the “cme-full-4.3.0.0.tar” file on
- Make sure you can ping the TFTP server from the router (so that the TFTP server is accesable from the router)
- Do a “erase flash:” on the router
- Do a “format flash:” on the router in order to create a DOS filesystem
- Issue the follwing command

(X = TFTP server IP address or DNS name)
- From this moment on all files will be extractes into the routers flash.
- Before you can start you need to issue the following commands on the router

When this is done you can access the CME trough the browser with http://router-ip/telephony-service.html

Iwan Hoogendoorn

Hi,

After my twitter post this morning on Cisco Phone migrations a few people asked me to write a blog post on this…

When you do the CCIE voice lab you need to work with SCCP and SIP endpoints.
The best and fastest option is to just let all your phones register with SCCP by default.
For this you need to turn on auto registration, and set the auto registration protocol to SCCP.

To turn on auto registration you need to go to System –> Cisco Unified CM Group Configuration

You will see the following section and all you need to do is check the box.

To set the auto registration protocol you need to go to System –> Enterprise Parameters

Here you need to set the auto registration protocol on SCCP.

Don’t forget to have the TFTP service running on the CUCM you are using for registration!

When a Cisco phone is registered as SCCP endpoint you will see it in the device list (Device –>Phone)

Now we will have 1 of 2 phones that we will migrate to SIP.

The steps to do the migration are:
1) Create a new phone (SIP) template
2) Use the Bulk Administration Tool to migrate the phone(s) to an SIP image

Create a new phone (SIP) template:

- Go to Bulk Administration –> Phones –> Phone Template
- Click on “Add New”
- Select the phone type you want to create the template for and click on next
- Select the SIP protocol and click on next
- You will see a bunch of options and change the options that are mandatory.
- When done click on “Save”

Use the Bulk Administration Tool to migrate the phone(s) to an SIP image:

- Go to Bulk Administration –> Phones –> Migrate Phones –> SCCP to SIP
- Select the phone(s) you want to migrate from SCCP to SIP
- Select the option “Run Immediately”
- And click in “Submit”

When this is all done you should see your phone resetting itself and it will upgrade to the SIP image.
Make sure you put the auto registration protocol to SIP on the System –> Enterprise Parameters page so your newly migrated phone(s) can register automatically with the SIP protocol.

When everything is done as described above you will have your phone(s) successfully registered with the SIP image.

When you want to go back to SCCP the procedure will be a bit different.

1) Delete the phone(s) on the “Device –> Phone” page
2) Set the auto registration protocol to SCCP on the System –> Enterprise Parameters
3) Restart your phone by unplugging the power cable of your phone(s)
4) Wait 10 seconds and put the power cable back in and wait

Your phone(s) should now boot and upgrade (or migrate) itself to the SCCP image.
When it does not work the first time just try it the second time …

Hi,

There are 2 new blogs available on how I am getting allong with the CCIE Voice study.

    Iwan’s Voice Quest: Part 2 & Iwan’s Voice Quest: Part 3

Have fun reading this … I am writing a new article today on my adventure with upgrading an Cisco 7960 with pre-historic SIP software on it.

Bye for now!

Iwan Hoogendoorn