Параметры sipp следующие:

sipp -rtp_echo -mi 172.16.хх.хх -sn uac 192.168.хх.хх -d 2000
-s 100 -rp 2000 -r 5 -i 172.16.хх.хх -l 1

Сервер с Asterisk: 2,66 QuadCore 2 гига, HP DL120G5 X3330.

# uname -a
 Linux elastix.ххх.local 2.6.18-92.1.22.el5 #1
 SMP Tue Dec 16 12:03:43 EST 2008 i686 i686 i386 GNU/Linux

Тест проводился в два этапа. На первом этапе сервер загружался звонками приблизительно с 18.30 до 0.00. Прошло около 2 млн. звонков.

Загрузка памяти:

Видно, что загрузка памяти за время теста постоянно росла, после снятия звонковой нагрузки память осталась в том же состоянии до 10 утра, после чего видно, что память освободилась.

Второй тест проводился на следующий день. Где-то с 12.30 на средней загрузке, с 18.10 нагрузку резко увеличил. В срок с 18.10 по 4.00 утра прошло около 4х млн. звонков. На следующий день память освободилась в исходное состояние.

Отчёт sipp:

 --------------------------- Statistics Screen ------- [1-9]: Change Screen --
 Start Time             | 2009-09-10   11:13:13:164    1252566793.164587
 Last Reset Time        | 2009-09-11   04:00:00:081    1252627200.081742
 Current Time           | 2009-09-11   04:00:00:973    1252627200.973702
 -----------------------+---------------------------+--------------------------
 Counter Name           | Periodic value            | Cumulative value
 -----------------------+---------------------------+--------------------------
 Elapsed Time           | 00:00:00:891              | 16:46:47:809
 Call Rate              |  109.989 cps              |   69.101 cps
 -----------------------+---------------------------+--------------------------
 Incoming call created  |        0                  |        0
 OutGoing call created  |       98                  |  4174217
 Total Call created     |                           |  4174217
 Current Call           |      226                  |
 -----------------------+---------------------------+--------------------------
 Successful call        |       98                  |  4173045
 Failed call            |        0                  |      946
 -----------------------+---------------------------+--------------------------
 Response Time 1        | 00:00:00:025              | 00:00:00:028
 Call Length            | 00:00:02:053              | 00:00:02:057
 ------------------------------ Test Terminated --------------------------------

Для full-mesh сети создаем необходимое количество VLC и задаем маппинг.

Задаем минимальную конфигурацию маршрутизаторов. Для полносвязной сети используем адреса серийных интерфейсов из одной подсети.

R1#sh run
!
interface Serial0/0
 ip address 192.168.1.1 255.255.255.0
 encapsulation frame-relay
 clock rate 2000000
end
!
R1

Аналогично настраиваем два оставшихся маршрутизатора. Проверяем коннективити:

R1#ping 192.168.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/78/152 ms

R1#ping 192.168.1.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/94/200 ms
R1#

R2#ping 192.168.1.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 40/74/132 ms
R2#

Посмотрим на детали соединения:

R1#
R1#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

C    192.168.1.0/24 is directly connected, Serial0/0
R1#
R1#sh frame-relay pvc

PVC Statistics for interface Serial0/0 (Frame Relay DTE)

              Active     Inactive      Deleted       Static
  Local          2            0            0            0
  Switched       0            0            0            0
  Unused         0            0            0            0

DLCI = 102, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0

  input pkts 18            output pkts 17           in bytes 1662
  out bytes 1628           dropped pkts 0           in pkts dropped 0
  out pkts dropped 0                out bytes dropped 0
  in FECN pkts 0           in BECN pkts 0           out FECN pkts 0
  out BECN pkts 0          in DE pkts 0             out DE pkts 0
  out bcast pkts 2         out bcast bytes 68
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
  pvc create time 00:38:34, last time pvc status changed 00:37:34

DLCI = 103, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0

  input pkts 8             output pkts 7            in bytes 622
  out bytes 588            dropped pkts 0           in pkts dropped 0
  out pkts dropped 0                out bytes dropped 0
  in FECN pkts 0           in BECN pkts 0           out FECN pkts 0
  out BECN pkts 0          in DE pkts 0             out DE pkts 0
  out bcast pkts 2         out bcast bytes 68
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
  pvc create time 00:38:35, last time pvc status changed 00:37:35
R1#
R1#sh frame-relay map
Serial0/0 (up): ip 192.168.1.2 dlci 102(0x66,0x1860), dynamic,
              broadcast,
              CISCO, status defined, active
Serial0/0 (up): ip 192.168.1.3 dlci 103(0x67,0x1870), dynamic,
              broadcast,
              CISCO, status defined, active
R1#

Настроим статический маппинг:

R1#sh run int s0/0
!
interface Serial0/0
 ip address 192.168.1.1 255.255.255.0
 encapsulation frame-relay
 clock rate 2000000
 frame-relay map ip 192.168.1.3 103 broadcast
 frame-relay map ip 192.168.1.2 102 broadcast
 no frame-relay inverse-arp
end
R1#

R2#sh run int s0/0
!
interface Serial0/0
 ip address 192.168.1.2 255.255.255.0
 encapsulation frame-relay
 clock rate 2000000
 frame-relay map ip 192.168.1.3 103 broadcast
 frame-relay map ip 192.168.1.1 101 broadcast
 no frame-relay inverse-arp
end
R2#

R3#sh run int s0/0
!
interface Serial0/0
 ip address 192.168.1.3 255.255.255.0
 encapsulation frame-relay
 clock rate 2000000
 frame-relay map ip 192.168.1.2 102 broadcast
 frame-relay map ip 192.168.1.1 101 broadcast
 no frame-relay inverse-arp
end

R3#

Пингом проверяем коннективити, все должно работать.

Топология PPP лабы

Делаем начальные настройки – прописываем хостнеймы (внимательно отнеситесь к этому пункту, хостнеймы роутеров используются при ppp аутентификации) и адреса интерфейсов. Проверяем коннективити и переходим к собственно кофигурированию PPP:

R1#sh run
hostname R1
!
username R2 password password
!
interface Serial0/0
 ip address 192.168.0.1 255.255.255.0
 encapsulation ppp
 ppp authentication chap
end

R2#sh run
hostname R2
!
username R1 password password
!
interface Serial0/0
 ip address 192.168.0.2 255.255.255.0
 encapsulation ppp
 ppp authentication chap
end

Обратите внимание, по умолчанию роутер использует для идентификации себя собственный hostname. Однако, это поведение можно переопределить командой ppp chap hostname.

Чтобы проследить Challenge Handshake протокола CHAP включаем отладку и дёргаем интерфейс на другом роутере:

R1#debug ppp authentication
PPP authentication debugging is on
R1#terminal monitor

R2(config)#int s0/0
R2(config-if)#shut
R2(config-if)#no shut

R1#
*Mar  1 01:30:55.723: Se0/0 PPP: Authorization required
*Mar  1 01:30:55.819: Se0/0 CHAP: O CHALLENGE id 4 len 23 from "R1"
*Mar  1 01:30:55.823: Se0/0 CHAP: I CHALLENGE id 3 len 23 from "R2"
*Mar  1 01:30:55.843: Se0/0 CHAP: Using hostname from unknown source
*Mar  1 01:30:55.847: Se0/0 CHAP: Using password from AAA
*Mar  1 01:30:55.847: Se0/0 CHAP: O RESPONSE id 3 len 23 from "R1"
*Mar  1 01:30:55.995: Se0/0 CHAP: I RESPONSE id 4 len 23 from "R2"
*Mar  1 01:30:56.015: Se0/0 PPP: Sent CHAP LOGIN Request
*Mar  1 01:30:56.015: Se0/0 CHAP: I SUCCESS id 3 len 4
*Mar  1 01:30:56.031: Se0/0 PPP: Received LOGIN Response PASS
*Mar  1 01:30:56.039: Se0/0 PPP: Sent LCP AUTHOR Request
*Mar  1 01:30:56.043: Se0/0 PPP: Sent IPCP AUTHOR Request
*Mar  1 01:30:56.087: Se0/0 LCP: Received AAA AUTHOR Response PASS
*Mar  1 01:30:56.095: Se0/0 IPCP: Received AAA AUTHOR Response PASS
*Mar  1 01:30:56.095: Se0/0 CHAP: O SUCCESS id 4 len 4
*Mar  1 01:30:56.107: Se0/0 PPP: Sent CDPCP AUTHOR Request
*Mar  1 01:30:56.127: Se0/0 CDPCP: Received AAA AUTHOR Response PASS
*Mar  1 01:30:56.259: Se0/0 PPP: Sent IPCP AUTHOR Request
R1#

Процесс установления PPP соединения можно посмотреть командой debug ppp negotiation:

Без аутентификации:

R1#
*Mar  1 01:53:25.623: Se0/0 LCP: I CONFREQ [Open] id 7 len 10
*Mar  1 01:53:25.627: Se0/0 LCP:    MagicNumber 0x0973CA73 (0x05060973CA73)
*Mar  1 01:53:25.635: Se0/0 CDPCP: State is Closed
*Mar  1 01:53:25.635: Se0/0 IPCP: State is Closed
*Mar  1 01:53:25.643: Se0/0 PPP: Phase is TERMINATING
*Mar  1 01:53:25.647: Se0/0 PPP: Phase is ESTABLISHING
*Mar  1 01:53:25.651: Se0/0 LCP: O CONFREQ [Open] id 23 len 10
*Mar  1 01:53:25.655: Se0/0 LCP:    MagicNumber 0x0873D4DE (0x05060873D4DE)
*Mar  1 01:53:25.659: Se0/0 LCP: O CONFACK [Open] id 7 len 10
*Mar  1 01:53:25.659: Se0/0 LCP:    MagicNumber 0x0973CA73 (0x05060973CA73)
*Mar  1 01:53:25.671: Se0/0 IPCP: Remove route to 192.168.0.2
*Mar  1 01:53:25.683: Se0/0 LCP: I CONFACK [ACKsent] id 23 len 10
*Mar  1 01:53:25.683: Se0/0 LCP:    MagicNumber 0x0873D4DE (0x05060873D4DE)
*Mar  1 01:53:25.687: Se0/0 LCP: State is Open
*Mar  1 01:53:25.691: Se0/0 PPP: Phase is FORWARDING, Attempting Forward
*Mar  1 01:53:25.703: Se0/0 PPP: Phase is ESTABLISHING, Finish LCP
*Mar  1 01:53:25.711: Se0/0 PPP: Phase is UP
*Mar  1 01:53:25.715: Se0/0 IPCP: O CONFREQ [Closed] id 1 len 10
*Mar  1 01:53:25.715: Se0/0 IPCP:    Address 192.168.0.1 (0x0306C0A80001)
*Mar  1 01:53:25.719: Se0/0 CDPCP: O CONFREQ [Closed] id 1 len 4
*Mar  1 01:53:25.723: Se0/0 PPP: Process pending ncp packets
*Mar  1 01:53:25.731: Se0/0 IPCP: I CONFREQ [REQsent] id 1 len 10
*Mar  1 01:53:25.735: Se0/0 IPCP:    Address 192.168.0.2 (0x0306C0A80002)
*Mar  1 01:53:25.739: Se0/0 IPCP: O CONFACK [REQsent] id 1 len 10
*Mar  1 01:53:25.743: Se0/0 IPCP:    Address 192.168.0.2 (0x0306C0A80002)
*Mar  1 01:53:25.755: Se0/0 CDPCP: I CONFREQ [REQsent] id 1 len 4
*Mar  1 01:53:25.759: Se0/0 CDPCP: O CONFACK [REQsent] id 1 len 4
*Mar  1 01:53:25.787: Se0/0 IPCP: I CONFACK [ACKsent] id 1 len 10
*Mar  1 01:53:25.791: Se0/0 IPCP:    Address 192.168.0.1 (0x0306C0A80001)
*Mar  1 01:53:25.795: Se0/0 IPCP: State is Open
*Mar  1 01:53:25.919: Se0/0 CDPCP: I CONFACK [ACKsent] id 1 len 4
*Mar  1 01:53:25.923: Se0/0 CDPCP: State is Open
*Mar  1 01:53:25.939: Se0/0 IPCP: Install route to 192.168.0.2
R1#

С chap-аутентификацией:

R1#
*Mar  1 01:55:10.647: Se0/0 LCP: I CONFREQ [Open] id 10 len 15
*Mar  1 01:55:10.651: Se0/0 LCP:    AuthProto CHAP (0x0305C22305)
*Mar  1 01:55:10.655: Se0/0 LCP:    MagicNumber 0x0975646E (0x05060975646E)
*Mar  1 01:55:10.659: Se0/0 CDPCP: State is Closed
*Mar  1 01:55:10.663: Se0/0 IPCP: State is Closed
*Mar  1 01:55:10.671: Se0/0 PPP: Phase is TERMINATING
*Mar  1 01:55:10.671: Se0/0 PPP: Phase is ESTABLISHING
*Mar  1 01:55:10.679: Se0/0 LCP: O CONFREQ [Open] id 26 len 15
*Mar  1 01:55:10.679: Se0/0 LCP:    AuthProto CHAP (0x0305C22305)
*Mar  1 01:55:10.683: Se0/0 LCP:    MagicNumber 0x08756F22 (0x050608756F22)
*Mar  1 01:55:10.687: Se0/0 LCP: O CONFACK [Open] id 10 len 15
*Mar  1 01:55:10.687: Se0/0 LCP:    AuthProto CHAP (0x0305C22305)
*Mar  1 01:55:10.691: Se0/0 LCP:    MagicNumber 0x0975646E (0x05060975646E)
*Mar  1 01:55:10.703: Se0/0 IPCP: Remove route to 192.168.0.2
*Mar  1 01:55:10.727: Se0/0 LCP: I CONFACK [ACKsent] id 26 len 15
*Mar  1 01:55:10.727: Se0/0 LCP:    AuthProto CHAP (0x0305C22305)
*Mar  1 01:55:10.731: Se0/0 LCP:    MagicNumber 0x08756F22 (0x050608756F22)
*Mar  1 01:55:10.735: Se0/0 LCP: State is Open
*Mar  1 01:55:10.735: Se0/0 PPP: Phase is AUTHENTICATING, by both
*Mar  1 01:55:10.739: Se0/0 CHAP: O CHALLENGE id 8 len 23 from "R1"
*Mar  1 01:55:10.743: Se0/0 CHAP: I CHALLENGE id 6 len 23 from "R2"
*Mar  1 01:55:10.787: Se0/0 CHAP: Using hostname from unknown source
*Mar  1 01:55:10.791: Se0/0 CHAP: Using password from AAA
*Mar  1 01:55:10.795: Se0/0 CHAP: O RESPONSE id 6 len 23 from "R1"
*Mar  1 01:55:10.811: Se0/0 CHAP: I RESPONSE id 8 len 23 from "R2"
*Mar  1 01:55:10.815: Se0/0 PPP: Phase is FORWARDING, Attempting Forward
*Mar  1 01:55:10.839: Se0/0 PPP: Phase is AUTHENTICATING, Unauthenticated User
*Mar  1 01:55:10.859: Se0/0 PPP: Phase is FORWARDING, Attempting Forward
*Mar  1 01:55:10.863: Se0/0 CHAP: I SUCCESS id 6 len 4
*Mar  1 01:55:10.875: Se0/0 PPP: Phase is AUTHENTICATING, Authenticated User
*Mar  1 01:55:10.899: Se0/0 CHAP: O SUCCESS id 8 len 4
*Mar  1 01:55:10.903: Se0/0 PPP: Phase is UP
*Mar  1 01:55:10.911: Se0/0 IPCP: O CONFREQ [Closed] id 1 len 10
*Mar  1 01:55:10.911: Se0/0 IPCP:    Address 192.168.0.1 (0x0306C0A80001)
*Mar  1 01:55:10.919: Se0/0 PPP: Process pending ncp packets
*Mar  1 01:55:10.927: Se0/0 IPCP: I CONFREQ [REQsent] id 1 len 10
*Mar  1 01:55:10.931: Se0/0 IPCP:    Address 192.168.0.2 (0x0306C0A80002)
*Mar  1 01:55:10.931: Se0/0 AAA/AUTHOR/IPCP: Start.  Her address 192.168.0.2, we want 0.0.0.0
*Mar  1 01:55:10.955: Se0/0 AAA/AUTHOR/IPCP: Reject 192.168.0.2, using 0.0.0.0
*Mar  1 01:55:10.959: Se0/0 AAA/AUTHOR/IPCP: Done.  Her address 192.168.0.2, we want 0.0.0.0
*Mar  1 01:55:10.963: Se0/0 IPCP: O CONFACK [REQsent] id 1 len 10
*Mar  1 01:55:10.967: Se0/0 IPCP:    Address 192.168.0.2 (0x0306C0A80002)
*Mar  1 01:55:10.971: Se0/0 IPCP: I CONFACK [ACKsent] id 1 len 10
*Mar  1 01:55:10.975: Se0/0 IPCP:    Address 192.168.0.1 (0x0306C0A80001)
*Mar  1 01:55:10.979: Se0/0 IPCP: State is Open
*Mar  1 01:55:10.987: Se0/0 CDPCP: O CONFREQ [Closed] id 1 len 4
*Mar  1 01:55:10.991: Se0/0 CDPCP: I CONFREQ [REQsent] id 1 len 4
*Mar  1 01:55:10.995: Se0/0 CDPCP: O CONFACK [REQsent] id 1 len 4
*Mar  1 01:55:11.011: Se0/0 IPCP: Install route to 192.168.0.2
*Mar  1 01:55:11.035: Se0/0 CDPCP: I CONFACK [ACKsent] id 1 len 4
*Mar  1 01:55:11.039: Se0/0 CDPCP: State is Open
R1#

Посмотрим на состояния интерфейса при успешной и несостоявшейся аутентификации.

При состоявшейся аутентификации:

R1#sh int s0/0
Serial0/0 is up, line protocol is up
  Hardware is GT96K Serial
  Internet address is 192.168.0.1/24
  MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation PPP, LCP Open
  Open: IPCP, CDPCP, loopback not set
R1#

Гасим интерфейс на R2. Через несколько секунд получаем следующий вывод (при включенном debug ppp negotiation):

R1#
*Mar  1 02:05:19.127: Se0/0 PPP: Missed 5 keepalives, taking LCP down
*Mar  1 02:05:19.135: Se0/0 PPP: Sending Acct Event[Down] id[5]
*Mar  1 02:05:19.135: Se0/0 LCP: State is Closed
*Mar  1 02:05:19.139: Se0/0 PPP: Phase is DOWN
*Mar  1 02:05:19.143: Se0/0 CDPCP: State is Closed
*Mar  1 02:05:19.143: Se0/0 IPCP: State is Closed
*Mar  1 02:05:19.175: Se0/0 PPP: Phase is ESTABLISHING, Passive Open
*Mar  1 02:05:19.179: Se0/0 LCP: State is Listen
*Mar  1 02:05:19.187: Se0/0 IPCP: Remove route to 192.168.0.2
*Mar  1 02:05:20.151: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0, changed state to down
*Mar  1 02:05:21.143: Se0/0 LCP: Timeout: State Listen
*Mar  1 02:05:21.147: Se0/0 LCP: O CONFREQ [Listen] id 27 len 15
*Mar  1 02:05:21.151: Se0/0 LCP:    AuthProto CHAP (0x0305C22305)
*Mar  1 02:05:21.155: Se0/0 LCP:    MagicNumber 0x087EBFCF (0x0506087EBFCF)
*Mar  1 02:05:21.175: Se0/0 PPP: Outbound cdp packet dropped
*Mar  1 02:05:23.163: Se0/0 LCP: Timeout: State REQsent
*Mar  1 02:05:23.163: Se0/0 LCP: O CONFREQ [REQsent] id 28 len 15
*Mar  1 02:05:23.167: Se0/0 LCP:    AuthProto CHAP (0x0305C22305)
*Mar  1 02:05:23.171: Se0/0 LCP:    MagicNumber 0x087EBFCF (0x0506087EBFCF)
*Mar  1 02:05:25.175: Se0/0 LCP: Timeout: State REQsent
*Mar  1 02:05:25.179: Se0/0 LCP: O CONFREQ [REQsent] id 29 len 15
*Mar  1 02:05:25.183: Se0/0 LCP:    AuthProto CHAP (0x0305C22305)
*Mar  1 02:05:25.183: Se0/0 LCP:    MagicNumber 0x087EBFCF (0x0506087EBFCF)
*Mar  1 02:05:27.191: Se0/0 LCP: Timeout: State REQsent
R1#
R1#sh int s0/0
Serial0/0 is up, line protocol is down
  Hardware is GT96K Serial
  Internet address is 192.168.0.1/24
  MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation PPP, LCP REQsent, loopback not set

Включаем интерфейс на R2 и меняем username на wrong_hostname (я просто удалил запись username R1… и добавил на интерфейсе s0/0 строчку ppp chap hostname wrong_hostname)

R1#
*Mar  1 02:16:42.875: Se0/0 PPP: Authorization required
*Mar  1 02:16:42.899: Se0/0 CHAP: O CHALLENGE id 10 len 23 from "R1"
*Mar  1 02:16:42.907: Se0/0 CHAP: I CHALLENGE id 8 len 25 from "wrong_hostname"
*Mar  1 02:16:42.915: Se0/0 CHAP: I RESPONSE id 10 len 25 from "wrong_hostname"
*Mar  1 02:16:42.931: Se0/0 PPP: Sent CHAP LOGIN Request
*Mar  1 02:16:42.939: Se0/0 CHAP: Unable to authenticate for peer
*Mar  1 02:16:43.867: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0, changed state to down
*Mar  1 02:16:44.951: Se0/0 PPP: Authorization required
*Mar  1 02:16:47.075: Se0/0 CHAP: O CHALLENGE id 11 len 23 from "R1"
*Mar  1 02:16:47.127: Se0/0 CHAP: I CHALLENGE id 9 len 25 from "asdf"
*Mar  1 02:16:47.135: Se0/0 CHAP: I RESPONSE id 11 len 25 from "asdf"
*Mar  1 02:16:47.147: Se0/0 PPP: Sent CHAP LOGIN Request
*Mar  1 02:16:47.159: Se0/0 CHAP: Unable to authenticate for peer
R1#
R1#sh int s0/0
Serial0/0 is up, line protocol is down
  Hardware is GT96K Serial
  Internet address is 192.168.0.1/24
  MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation PPP, LCP REQsent, loopback not set
R1#

Так как CHAP суть подфункция протокола LCP то при неверном согласовании параметров аутентификации мы наблюдаем падение второго уровня на интерфейсе.

Дополнительно:

• Understanding debug ppp negotiation Output

• Заходим в File / New Project
• В диалоговом окне оставляем галочки Export router configuration files и Keep working directory files
• Жмем ОК

Либо делаем так:

Выбираем New Project, выбираем имя для проекта, жмем OK, после чего соглашаемся применить настройки проекта к текущей топологии.

Меню Call Routing/Call Park:

Здесь указываем диапазон парковочных номеров, в цискиной нотации регулярных выражений:

Call Park Number/Range allowed characters are numeric (0-9), X, close square bracket (]), open square bracket ([), dash (-), asterisk (*), carat (^), pound (#).

Далее указываем партицию и используемый сервер CallManager.

Для того, чтобы запарковать вызов, нажимаем кнопку «Park» (или «Парк») после чего звонок паркуется на первый свободный номер из заданного диапазона. Информация о номере высвечивается на дисплее телефона. После этого звонок можно подобрать с любого аппарата, входящего в указанную партицию, просто набрав парковочный номер.

Рассмотрим примеры медиа ресурсов:

Конференцмосты (Conference Bridges)

Предоставляют возможность собирать и проводить конференции. Существует два типа конференций – Ad Hoc и Meet-me. В случае Ad Hoc конференции диспетчер собирает участников, обзванивая каждого со своего аппарата. В конференции Meet-Me каждый участник набирает определённый, уникальный для конференции номер, после того, как диспетчер создал конференцию. Конференцмосты бывают программными (например сервис Software Conference Bridge, входит в состав Cisco CallManager) и аппаратными (такие как Cisco IOS Conference Bridge).

Транскодеры (Transcoders)

Устройства, осуществляющие преобразование кодеков дуплексных rtp-потоков в реальном времени. Например, из G.711 в G.729. Преобразования между двумя кодеками, осуществляющими компрессию с потерей качества (такими как G.729 и G.723) нежелательны, потому что вследствие такого преобразования качество голоса ухудшается с каждым циклом компрессии/декомпрессии.
Транскодирование потребляет DSP ресурсы, следовательно при планировании сети с транскодерами следует выделять под них обособленные, специализированные устройства, с достаточным запасом DSP ресурсов.

Точки терминации среды (Media Termination Points, MTP)

Транскодеры также могут выступать в роли точек терминации среды, которые обеспечивают дополнительные сервисы, такие как удержание и трансфер звонка для устройств, работающих на протоколе H.323, который не обеспечивает подобные услуги по умолчанию.
Сервис ТТС может быть обеспечен программно. Отличие между транскодерами и программными MTP состоит в том, что программные MTP поддерживают лишь один кодек – G.711. Соответственно, MTP могут предоставлять дополнительные услуги для H.323 устройств, но не обеспечивают преобразование кодеков.

Все голосовые шлюзы, работающие на Cisco IOS, обеспечивают т.н. «null capabilities set» для протокола H.323, соответвенно MTP обычно использются для H.323 устройств сторонних производителей.

Сервера музыки-на-удержании (Music On Hold, MOH)

Служба MOH позволяет как OnNet так и OffNet абонентам при удержании слушать музыку, предоставляемую сервером MOH.

Cisco Hardware Conference Bridge поддерживает голосовые модули Cisco Catalyst 4000 и 6000 со следующим количеством конференц-сессий:

• Cisco Catalyst 6000

В конференции с использованием кодека G.711 доступны 32 аудиопотока; до 10 конференц-сессий с тремя участниками в каждой конференции или одна конференц-сессия с 32 участниками.

• Cisco Catalyst 4000

В G.711 конференции возможен разговор между 24мя участниками, либо четыре конференции максимум, с шестью участниками в каждой.

• Cisco Software Conference Bridge; максимальное количество аудиопотоков – 128.

В програмной реализации Conference Bridge возможно участие до 128 пользователей в одной конференции, либо вплоть до 42х конференций с тремя участниками одновременно.

Замечание: если Cisco IP Voice Media Streaming Application service запущен не на одном сервере с Cisco CallManager service, то количество программных конференций (созданных при помощи Software Conference Bridge) не может превышать 128. Если же IP Voice Media Streaming Application service запущен на одном сервере с Cisco CallManager service, то количество программных конференций не должно превышать 48.

Примечание
Перевод этой статьи.

Дополнение
Количество пользователей в Ad Hoc конференциях (конференциях «по требованию», инициируемых организатором конференции) регламентируется в глобальных настройках Cisco CallManager – System/Service Parameters, Cisco CallManager Service, Maximum Ad Hoc Conference. Максимальное возможное число пользователей для этого параметра – 64; минимальное – 3; по умолчанию стоит 4. Эти данные нашел в документе, описывающем Cisco CallManager 4.0, но, подозреваю, это справедливо и для старших версий.