Процесс инициализации Cisco IP Phone: часть 4

Поиск и устранение неисправностей при межкластерном вызове между Cisco IP Phone

В этом разделе рассматривается пример, когда Cisco IP Phone совершает вызов на другой Cisco IP Phone, расположенный в другом кластере (межкластерный вызов).
Для примера возьмем следующую топологию:два кластера, каждый имеет два CUCM, а также Cisco IOS Gateways и Cisco IOS Gatekeeper.

Intercluster H.323 Communication

Cisco IP Phone в Cluster 1 звонит на Cisco IP Phone in Cluster 2. Межкластерное соединения CUCM происходит с использование протокола H.332 версии 2. Cisco IOS Gatekeeper служит для контроля доступа.

Cisco IP Phone может соединятся с CUCM используя Skinny Station протокол (SCCP), а CUCM может соединятся с Cisco IOS Gatekeeper, используя H.323 RAS протокол. Admission request message (ARQ)[2] посылается к Cisco IOS Gatekeeper, который посылает Admission confirmed message (ACF)[3], убедившись, что межкластерный вызов будит совершаться с использованием протокола H.323 версии 2. После этого происходит установление звукового тракта между Cisco IP Phones в разных кластерах, с использованием RTP протокола.

Trace потока вызова

В этом разделе рассматривается поток вызова, на примере использования SDI trace, записанного в файле CCM000000000. Traces, рассматриваемый в этом примере, содержит информацию только этого конкретного вызова (рассматриваемого в примере).

В данном случае, Cisco IP Phone (2002), расположенный в Cluster 2, звонит на Cisco IP Phone (1001), расположенный в Cluster 1. Помните, что вы можете следить за устройством с использованием trace, просматривая значения TCP handle, time stamp или имени устройства. Значение TCP handle для устройства не изменяется, пока оно не будет перезагружено или не будит выведено из сети.

В следующем trace показано: Cisco IP Phone (2002) снимает трубку, TCP handle и номер вызывающего абонента. Так же показан номер вызываемого абонента (набранный номер) (1001), H.225 запрос на соединение и H.245 подтверждающие сообщения. Тип кодеков - выбран G.711 mu-law.

16:06:13.921 CCM|StationInit - InboundStim - OffHookMessageID tcpHandle=0x1c64310
16:06:13.953 CCM|Out Message -- H225ConnectMsg -- Protocol= H225Protocol
16:06:13.953 CCM|Ie - H225UserUserIe IEData= 7E 00 37 05 02 C0 06 
16:06:13.953 CCM|StationD - stationOutputCallInfo CallingPartyName=, CallingParty=2002, 
CalledPartyName=1001, CalledParty=1001, tcpHandle=0x1c64310
16:06:14.015 CCM|H245Interface(2) OLC indication chan number = 2
16:06:14.015 CCM|StationD - stationOutputOpenReceiveChannel tcpHandle=0x1c64310 myIP: 
e74610ac (172.16.70.231)
16:06:14.015 CCM|StationD - ConferenceID: 0 msecPacketSize: 20 
compressionType:(4)Media_Payload_G711Ulaw64k
16:06:14.062 CCM|StationInit - InboundStim - StationOpenReceiveChannelAckID 
tcpHandle=0x1c64310, Status=0, IpAddr=0xe74610ac, Port=20444, PartyID=2
16:06:14.062 CCM|H245Interface(2) paths established ip = e74610ac, port = 20444
16:06:14.187 CCM|H245Interface(2) OLC outgoing confirm ip = fc4610ac, port = 29626

Представлены номера вызывающего и вызываемого абонентов, которые связаны с IP адресами и шестнадцатеричными значениями.

16:06:14.187 CCM|StationD - stationOutputStartMediaTransmission tcpHandle=0x1c64310 myIP: e74610ac (172.16.70.231)
16:06:14.187 CCM|StationD - RemoteIpAddr: fc4610ac (172.16.70.252)

Далее представлен trace, показывающий размер пакетов и MAC адрес Cisco IP Phone (2002), затем идет разъединение, сообщение о том, что трубку положили.

RemoteRtpPortNumber: 29626 msecPacketSize: 20 compressionType:(4)Media_Payload_G711Ulaw64k
16:06:16.515 CCM| Device SEP003094C26105 , UnRegisters with SDL Link to monitor NodeID= 1
16:06:16.515 CCM|StationD - stationOutputCloseReceiveChannel tcpHandle=0x1c64310 myIP: 
e74610ac (172.16.70.231)
16:06:16.515 CCM|StationD - stationOutputStopMediaTransmission tcpHandle=0x1c64310 myIP: 
e74610ac (172.16.70.231)
16:06:16.531 CCM|In Message -- H225ReleaseCompleteMsg -- Protocol= H225Protocol
16:06:16.531 CCM|Ie - Q931CauseIe -- IEData= 08 02 80 90 
16:06:16.531 CCM|Ie - H225UserUserIe -- IEData= 7E 00 1D 05 05 80 06 
16:06:16.531 CCM|Locations:Orig=1 BW=64Dest=0 BW=-1 (-1 implies infinite bw available)
16:06:16.531 CCM|MediaManager - wait_AuDisconnectRequest - StopSession sending disconnect 
to (64,2) and remove connection from list
16:06:16.531 CCM|MediaManager - wait_AuDisconnectReply - received all disconnect replies, 
forwarding a reply for party1(16777219) and party2(16777220)
16:06:16.531 CCM|MediaCoordinator - wait_AuDisconnectReply - removing MediaManager(2) from 
connection list
16:06:16.734 CCM|StationInit - InboundStim - OnHookMessageID tcpHandle=0x1c64310

Поток вызова с ошибкой

В следующем разделе рассматривается межкластерный поток вызова с ошибкой. Cisco IP Phone (1001) снимает трубку. TCP handle присваивается Cisco IP Phone.

16:05:33.468 CCM|StationInit - InboundStim - OffHookMessageID tcpHandle=0x4fbbc30
16:05:33.468 CCM|StationD - stationOutputDisplayText tcpHandle=0x4fbbc30, Display= 1001 
16:05:33.484 CCM|StationD - stationOutputSetLamp stim: 9=Line instance=1 lampMode=LampOn 
tcpHandle=0x4fbbc30

Пользователь набирает номер вызываемого абонента (2000), и процесс анализа цифр пытается сопоставить номер (с шаблоном).

16:05:33.484 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="")
16:05:33.484 CCM|Digit analysis: potentialMatches=PotentialMatchesExist
16:05:35.921 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="2")
16:05:35.921 CCM|Digit analysis:potentialMatches=ExclusivelyOffnetPotentialMatchesExist
16:05:36.437 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="20")
16:05:36.437 CCM|Digit analysis:potentialMatches=ExclusivelyOffnetPotentialMatchesExist
16:05:36.656 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="200")
16:05:36.656 CCM|Digit analysis:potentialMatches=ExclusivelyOffnetPotentialMatchesExist
16:05:36.812 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="2000")

Trace, представленный ниже, результат завершившегося процесса анализа цифр. Обратите внимание, что PotentialMatches=NoPotentialMatchesExist сообщает, что CUCM не может найти соответствие этому абонентскому номеру. В завершении, посылается сигнал занятости линии вызывающему абоненту (1001), за которым следует сообщение «трубка повешена».

16:05:36.812 CCM|Digit analysis: analysis results
16:05:36.812 CCM||PretransformCallingPartyNumber=1001
|CallingPartyNumber=1001
|DialingPattern=2XXX
|DialingRoutePatternRegularExpression=(2XXX)
|PotentialMatches=NoPotentialMatchesExist
|CollectedDigits=2000
16:05:36.828 CCM|StationD - stationOutputCallInfo CallingPartyName=1001, 
CallingParty=1001, CalledPartyName=, CalledParty=2000, tcpHandle=0x4fbbc30
16:05:36.828 CCM|StationD - stationOutputStartTone: 37=ReorderTone tcpHandle=0x4fbbc30
16:05:37.953 CCM|StationInit - InboundStim - OnHookMessageID tcpHandle=0x4fbbc30

Скорее всего имеется ввиду, что для набранного номера имеется несколько перекрывающихся шаблонов (например, 2ХХХ и 20ХХ). Номер будит выбран по условиям Closest Match Routing. После соединения с абонентом, выбранным по условиям Closest Match Routing, вызывающий слышит сигнал о занятости линии потому, что вызываемый абонент разговаривает (всего лишь предположение).

[2]Запрос на разрешение об участии в разговоре от конечной точки к gatekeeper. [3]Положительный ответ от gatekeeper, разрешающей конечной точке принимать участие в разговоре.

Ссылка на первую часть и на вторую, на третью

P.S. Это перевод части официальной документации,если кто будит пользоваться обратите внимание, что точность и правильность перевода не гарантируется. В тексте могут присутствовать орфографические, пунктуационные и другие ошибки. За более полной информацией необходимо обратится к официальной документации.

Процесс инициализации Cisco IP Phone: часть 3

Call Flow Traces при внутрикластерном вызове

В следующий SDI trace детально рассматривается внутрикластерный поток звонков. Определить Cisco IP Phones в потоке звонков можно по DN, tcpHandle и IP address. Cisco IP Phone (dn: 1001, tcpHandle: 0x4fbbc30, IP address: 172.16.70.231), который расположен в Cluster 2, звонит на другой Cisco IP Phone в том же кластере (dn=1000, tcpHandle= 0x4fbb150, IP address=172.16.70.230). Помните, что вы можете следить за устройством с помощью trace, обращая внимание на значения TCP handle, time stamp или именем устройства. Значение TCP handle для устройства остается тем же, пока устройство не перезагрузится или не или не будит отключено от сети.

На телефоне Cisco IP Phone (1001) поднята трубка. Trace показывает TCP handle и номер вызывающего[1] абонента, который отображается на Cisco IP Phone (в правом верхнем углу). Номер вызываемого абонента, в данном случае, не показывается, потому что пользователь не пытался набирать никакие цифры. Информация отображается в форме Skinny Station сообщений (имеется ввиду протокол SCCP) между Cisco Unified IP Phones и Cisco Unified Communications Manager.

16:05:41.625 CCM|StationInit - InboundStim - OffHookMessageID tcpHandle=0x4fbbc30
16:05:41.625 CCM|StationD - stationOutputDisplayText tcpHandle=0x4fbbc30, Display= 1001

Следующий trace показывает сообщение Skinny Station, которое передано от CUCM к Cisco IP Phone. Это сообщение включает световой индикатор на телефонной трубке (если использовать для примера модель телефона Cisco IP Phone 7911) на вызывающем телефоне.

16:05:41.625 CCM|StationD - stationOutputSetLamp stim: 9=Line instance=1 lampMode=LampOn tcpHandle=0x4fbbc30

Используя сообщение stationOutputCallState CUCM, уведомляет определенную станцию о информации относящейся к вызову.

16:05:41.625 CCM|StationD - stationOutputCallState tcpHandle=0x4fbbc30

Сообщение stationOutputDisplayPromptStatus используется для отображения «подсказки» на дисплее телефона.

16:05:41.625 CCM|StationD - stationOutputDisplayPromptStatus tcpHandle=0x4fbbc30

CUCM использует stationOutputSelectSoftKey сообщение, для уведомления Skinny Station (телефона) о выборе конкретного набора программных клавиш.

16:05:41.625 CCM|StationD - stationOutputSelectSoftKeys tcpHandle=0x4fbbc30

Информирует Skinny Station о корректном отображении линии.

16:05:41.625 CCM|StationD - stationOutputActivateCallPlane tcpHandle=0x4fbbc30

Процесс анализа цифр готов, для определения входящих цифр и проверки их на возможность маршрутизации в соответствии с базой данных. Запись cn=1001, представляет собой номер вызывающего абонента, где dd="" представляет собой набранные цифры, которые будут соответствовать номеру вызываемого абонента (набранный номер). Телефон посылает сообщение StationInit, CUCM посылает сообщение StationD и CUCM выполняет анализ цифр.

16:05:41.625 CCM|Digit analysis:match(fqcn="", cn="1001", pss="", dd="")
16:05:41.625 CCM|Digit analysis: potentialMatches=PotentialMatchesExist

CUCM предоставляет dial tone для вызывающего телефона (посылает сигнал готовности принять номер).

16:05:41.625 CCM|StationD - stationOutputStartTone: 33=InsideDialTone tcpHandle=0x4fbbc30

После CUCM определяет входящее сообщение и распознает, что на клавиатуре телефона нажата кнопка 1 и немедленно останавливает звуковой сигнал.

16:05:42.890 CCM|StationInit - InboundStim - KeypadButtonMessageID kpButton: 1 
tcpHandle=0x4fbbc30
16:05:42.890 CCM|StationD - stationOutputStopTone tcpHandle=0x4fbbc30
16:05:42.890 CCM|StationD - stationOutputSelectSoftKeys tcpHandle=0x4fbbc30
16:05:42.890 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="1")
16:05:42.890 CCM|Digit analysis: potentialMatches=PotentialMatchesExist
16:05:43.203 CCM|StationInit - InboundStim - KeypadButtonMessageID kpButton: 0 
tcpHandle=0x4fbbc30
16:05:43.203 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="10")
16:05:43.203 CCM|Digit analysis: potentialMatches=PotentialMatchesExist
16:05:43.406 CCM|StationInit - InboundStim - KeypadButtonMessageID kpButton: 0 
tcpHandle=0x4fbbc30
16:05:43.406 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="100")
16:05:43.406 CCM|Digit analysis: potentialMatches=PotentialMatchesExist
16:05:43.562 CCM|StationInit - InboundStim - KeypadButtonMessageID kpButton: 0 
tcpHandle=0x4fbbc30
16:05:43.562 CCM|Digit analysis: match(fqcn="", cn="1001", pss="", dd="1000")

После того, как CUCM принимает достаточное количество цифр для выполнения соответствия (соответствует шаблону, только при методе набора digit-by-digit), он предоставляет результат анализа цифр в табличном формате. CUCM игнорирует любые дополнительные цифры, которые набираются на телефоне, с этого момента, т.к. соответствие уже найдено.

16:05:43.562 CCM|Digit analysis: analysis results
16:05:43.562 CCM||PretransformCallingPartyNumber=1001
|CallingPartyNumber=1001
|DialingPattern=1000
|DialingRoutePatternRegularExpression=(1000)
|PotentialMatches=PotentialMatchesExist
|DialingSdlProcessId=(1,38,2)
|PretransformDigitString=1000
|PretransformPositionalMatchList=1000
|CollectedDigits=1000
|PositionalMatchList=1000
|RouteBlockFlag=RouteThisPattern

CUCM посылает эту информацию вызываемой стороне (tcpHandle указывает на телефон).

16:05:43.578 CCM|StationD - stationOutputCallInfo CallingPartyName=1001, 
CallingParty=1001, CalledPartyName=1000, CalledParty=1000, tcpHandle=0x4fbb150

CUCM заставляет лампочку моргать (не знаю как более красиво сказать), для индикации входящего вызова, на вызываемом телефоне.

16:05:43.578 CCM|StationD - stationOutputSetLamp stim: 9=Line instance=1 lampMode=LampBlink tcpHandle=0x4fbb150

CUCM предоставляет для Cisco IP Phone, на вызываемой стороне, звонок, уведомление на дисплее и другую связанную с вызовом информацию. Опять же, в этом можно убедится, что все сообщения направляются тому же телефону. Параметр tcpHandle имеет тоже значение во всех traces.

16:05:43.578 CCM|StationD - stationOutputSetRinger: 2=InsideRing tcpHandle=0x4fbb150
16:05:43.578 CCM|StationD - stationOutputDisplayNotify tcpHandle=0x4fbb150
16:05:43.578 CCM|StationD - stationOutputDisplayPromptStatus tcpHandle=0x4fbb150
16:05:43.578 CCM|StationD - stationOutputSelectSoftKeys tcpHandle=0x4fbb150

Обратите внимание, что CUCM так же предоставляет аналогичную информацию телефону на вызывающей стороне. Опять же, tcpHandle у этих Cisco IP Phones – различен.

16:05:43.578 CCM|StationD - stationOutputCallInfo CallingPartyName=1001, 
CallingParty=1001, CalledPartyName=, CalledParty=1000, tcpHandle=0x4fbbc30
16:05:43.578 CCM|StationD - stationOutputCallInfo CallingPartyName=1001, 
CallingParty=1001, CalledPartyName=1000, CalledParty=1000, tcpHandle=0x4fbbc30

CUCM отправляет уведомление или звуковой сигнал о том, что соединение было установлено, на телефон вызывающей стороны.

16:05:43.578 CCM|StationD - stationOutputStartTone: 36=AlertingTone tcpHandle=0x4fbbc30
16:05:43.578 CCM|StationD - stationOutputCallState tcpHandle=0x4fbbc30
16:05:43.578 CCM|StationD - stationOutputSelectSoftKeys tcpHandle=0x4fbbc30
16:05:43.578 CCM|StationD - stationOutputDisplayPromptStatus tcpHandle=0x4fbbc30

В этот момент, поднимается трубка на вызываемом телефоне, поэтому CUCM прекращает подачу звукового сигнала для вызывающего телефона.

16:05:45.140 CCM|StationD - stationOutputStopTone tcpHandle=0x4fbbc30

CUCM сообщает Skinny Station (в данном случае телефону) о начале приема Unicast RTP потока. Для этого CUCM предоставляет информацию об IP адрес вызываемого абонента, а так же информацию о кодеках и размер пакета в милисекундах. PacketSize обозначает целое число, которое содержит выборки, в миллисекундах, использующиеся для создания RTP пакетов (нормальное значение 30мс, в данном случае 20мс).

16:05:45.140 CCM|StationD - stationOutputOpenReceiveChannel tcpHandle=0x4fbbc30 myIP: e74610ac (172.16.70.231)
16:05:45.140 CCM|StationD - ConferenceID: 0 msecPacketSize: 20 compressionType:(4)Media_Payload_G711Ulaw64k

Аналогичную информацию CUCM отправляет вызываемому телефону (1000).

16:05:45.140 CCM|StationD - stationOutputOpenReceiveChannel tcpHandle=0x4fbb150 myIP: e64610ac (172.16.70.230)
16:05:45.140 CCM|StationD - ConferenceID: 0 msecPacketSize: 20 compressionType:(4)Media_Payload_G711Ulaw64k

CUCM принимает подтверждающее сообщение от вызываемой стороны об установлении открытого канала для RTP потока, а так же IP адрес вызываемой стороны. Оно сообщает CUCM о двух фрагментах информации, относящихся к Skinny Station. Первое содержит статус об открытии. Второе содержит полученный адрес порта для передачи к удаленной стороне. IP адрес передатчика (вызывающей стороны) в RTP потоке указывается ipAddr, а PortNumber на номер порта.

16:05:45.265 CCM|StationInit - InboundStim - StationOpenReceiveChannelAckID 
tcpHandle=0x4fbb150, Status=0, IpAddr=0xe64610ac, Port=17054, PartyID=2

Следующие сообщения, говорит станции (телефону) о начале передачи аудио и видео потока на указанный IP адрес и номер порта Cisco IP Phone на удаленной стороне.

16:05:45.265 CCM|StationD - stationOutputStartMediaTransmission tcpHandle=0x4fbbc30 myIP:e74610ac (172.16.70.231)
16:05:45.265 CCM|StationD - RemoteIpAddr: e64610ac (172.16.70.230) RemoteRtpPortNumber: 
17054 msecPacketSize: 20 compressionType:(4)Media_Payload_G711Ulaw64k
16:03:25.328 CCM|StationD(1): TCPPid=[1.100.117.1] OpenMultiReceiveChannel 
conferenceID=16777217 passThruPartyID=1000011 compressionType=101(Media_Payload_H263) 
qualifierIn=?. myIP: e98e6b80 (128.107.142.233)|
16:03:25.375 CCM|StationInit: TCPPid=[1.100.117.1] StationOpenMultiMediaReceiveChannelAck 
Status=0, IpAddr=0xe98e6b80, Port=65346, 
PartyID=16777233|
16:03:25.375 CCM|StationD(2): TCPPid = [1.100.117.2] 
star_StationOutputStartMultiMediaTransmission conferenceID=16777218 
passThruPartyID=16777250 remoteIpAddress=e98e6b80(66.255.0.0) remotePortNumber=65346 
compressType=101(Media_Payload_H263) qualifierOut=?. myIP: e98e6b80 
(128.107.142.233)|

Сообщение информирует о том, что стартовал RTP медиа поток между вызываемой и вызывающей стороной.

16:05:45.312 CCM|StationD - stationOutputStartMediaTransmission tcpHandle=0x4fbb150 myIP: 
e64610ac (172.16.70.230)
16:05:45.328 CCM|StationD - RemoteIpAddr: e74610ac (172.16.70.231) RemoteRtpPortNumber: 
18448 msecPacketSize: 20 compressionType:(4)Media_Payload_G711Ulaw64k
16:05:46.203 CCM|StationInit - InboundStim - OnHookMessageID tcpHandle=0x4fbbc30

Вызывающий абонент наконец кладет трубку, что служит сигналом о завершении всех управляющих сообщений между Skinny Station (телефонами) и CUCM, а так же завершает RTP поток между телефонами.

16:05:46.203 CCM|StationInit - InboundStim - OnHookMessageID tcpHandle=0x4fbbc30

Ссылка на первую часть и на вторую

P.S. Это перевод части официальной документации,если кто будит пользоваться обратите внимание, что точность и правильность перевода не гарантируется. В тексте могут присутствовать орфографические, пунктуационные и другие ошибки. За более полной информацией необходимо обратится к официальной документации.

Процесс инициализации Cisco IP Phone: часть 2

Процесс регистрации на Cisco Unified Communications Manager

Другая важная часть SDI trace включает в себя процесс регистрации. Когда устройство подключают к сети оно используя информацию, полученную по DHCP (IP адрес, адрес TFTP сервера), соединяется с TFTP сервером для получения .cnf файла, и после этого соединяется с CUCM, который указан в этом .cnf файле. Устройством может быть MGCP gateway, Skinny gateway, или Cisco Unified IP Phone. Поэтому необходимо иметь возможность выяснить, зарегистрировалось ли устройство.

CUCM принял новые запрос на регистрацию. Регистрирующиеся устройства включают в себя MTP_nsa-cm1 (MTP services on Unified CM1) and CFB_nsa-cm1 (Conference Bridge service on Unified CM1). Хотя это программные функции, работающая на CUCM, внутри (в пределах CUCM) они рассматриваются как отдельные внешние функции, и поэтому им назначается TCPHandle, socket number, port number, а так же имя устройства.

16:02:52.750 CCM|StationInit - New connection accepted. DeviceName=, TCPHandle=0x4fbaa00, Socket=0x594, IPAddr=172.16.70.228, Port=3279, StationD=[0,0,0]
16:02:52.750 CCM|StationInit - New connection accepted. DeviceName=, TCPHandle=0x4fe05e8, Socket=0x59c, IPAddr=172.16.70.228, Port=3280, StationD=[0,0,0]
16:02:52.781 CCM|StationInit - Processing StationReg. regCount: 1 DeviceName=MTP_nsa-cm1, TCPHandle=0x4fbaa00, Socket=0x594, IPAddr=172.16.70.228, Port=3279, StationD=[1,45,2]
16:02:52.781 CCM|StationInit - Processing StationReg. regCount: 1 DeviceName=CFB_nsa-cm1, TCPHandle=0x4fe05e8, Socket=0x59c, IPAddr=172.16.70.228, Port=3280, StationD=[1,96,2]

Cisco Unified Communications Manager KeepAlive Process

Станция, устройство или сервис и CUCM используют следующие сообщения, подтверждающие, что они знанают о каналах связи между ними. Начало сообщений keepalive последовательности, подтверждает, что линия связи между CUCM и станцией остается активной. Остальные сообщения могут прийти от любых CUCM или станции.

16:03:02.328 CCM|StationInit - InboundStim - KeepAliveMessage - Forward KeepAlive to StationD. DeviceName=MTP_nsa-cm2, TCPHandle=0x4fa7dc0, Socket=0x568, IPAddr=172.16.70.229,Port=1556, StationD=[1,45,1]
16:03:02.328 CCM|StationInit - InboundStim - KeepAliveMessage - Forward KeepAlive to StationD. DeviceName=CFB_nsa-cm2, TCPHandle=0x4bf8a70, Socket=0x57c, IPAddr=172.16.70.229, Port=1557, StationD=[1,96,1]
16:03:06.640 CCM|StationInit - InboundStim - KeepAliveMessage - Forward KeepAlive to StationD. DeviceName=SEP0010EB001720, TCPHandle=0x4fbb150, Socket=0x600, IPAddr=172.16.70.230, Port=49211, StationD=[1,85,2]
16:03:06.703 CCM|StationInit - InboundStim - KeepAliveMessage - Forward KeepAlive to StationD. DeviceName=SEP003094C26105, TCPHandle=0x4fbbc30, Socket=0x5a4, IPAddr=172.16.70.231, Port=52095, StationD=[1,85,1]

Сообщения в следующем trace описывают keepalive последовательность, которая показывает, что линия связи между CUCM и станцией – активна. Опять же, сообщения могут исходить или от CUCM или от станции.

16:03:02.328 CCM|MediaTerminationPointControl - stationOutputKeepAliveAck tcpHandle=4fa7dc0
16:03:02.328 CCM|UnicastBridgeControl - stationOutputKeepAliveAck tcpHandle=4bf8a70
16:03:06.703 CCM|StationInit - InboundStim - IpPortMessageID: 32715(0x7fcb) tcpHandle=0x4fbbc30
16:03:06.703 CCM|StationD - stationOutputKeepAliveAck tcpHandle=0x4fbbc30

Ссылка на первую часть

P.S. Это перевод части официальной документации,если кто будит пользоваться обратите внимание, что точность и правильность перевода не гарантируется. В тексте могут присутствовать орфографические, пунктуационные и другие ошибки. За более полной информацией необходимо обратится к официальной документации.

Основные термины CUCM

Представлены основные определения терминов, которые применяются в Cisco CallManager.

Directory Number (DN) - это номер телефона конечного устройства. Это может быть IP phone, Cisco IP SoftPhone, факс или аналоговый телефон, работающий через голосовой шлюз. Количество цифр в номере зависит от диал плана: 100, 2003, 32475 и т.д.

Route Pattern – В VoIP route patterns можно сравнить со статической маршрутизацией. Разница лишь в том, что route patterns указывает на номера стандарта E.164 вместо IP адреса. Route Pattern является конкретным номером или, чаще всего, диапазоном номеров, которые используются для направления вызовом напрямую к устройствам, таким как DT-24+ или к маршрутизаторам с поддержкой «голоса», или косвенно через Route List. Например, шаблон 1XXX указывает на диапазон 1000-1999. Где X в 1XXX означает единичную цифру, заполнитель или спец. символ. !). A Route Pattern does not have to be unique within a Partition, as long as the Route Filter is different. Route Pattern, в общем, соответствует набираемому номеру при внешних вызовах, выполняет манипуляцию с цифрами (если необходимо) и указывает на Route List для маршрутизации.

Route List – Ранее назывался Route Point. Route List позволяет Cisco CallManager работать с Route Groups (представленных в Route List) в конкретном порядке. Route Lists расширяет понятие Route Groups и позволяет выбрать и назначить приоритет для группы маршрутов. Несколько Route Lists могут указывать на одну и ту же Route Groups. Route List выбирает направление для маршрутизации вызова и указать на предпочитаемую Route Groups.

Route Group - Route Groups and Route Lists работают вместе над контролем и улучшением маршрутизации внешних звонков. Route Group состоит из одного или нескольких шлюзов или портов шлюза. For instance, one can have two Primary Rate Interface (PRI) circuits to the same carrier that can be used arbitrarily. Шлюз или определенный порт на шлюзе, могут быть добавлены только в одну Route Group.

Device – устройством, в этом смысле, является шлюз, такой как Skinny-based (DT-24+, AS/AT или Catalyst 6000), MGCP-based (VG200) или H.323-based (все Cisco IOS® шлюзы и другие Cisco CallManagers). Эти все устройства могут быть указаны в Route Group. Сюда не входят Skinny или H.323 конечные точки, такие как IP телефоны или клиенты для сетевых конференций.

Translation Pattern – используется для того, что бы преобразовать вызываемый (Dialed Number Identification Service [DNIS]) и вызывающий (automatic number identification [ANI]) номер до маршрутизации вызова. Например, вы можете получать звонки из диапазона номеров 919 392-3XXX, которые должны преобразованы для IP телефонов, с внутренними номерами в диапазоне 2XXX. В Cisco CallManager вы установили Translation Pattern, для данного диапазона номеров 919 392-3XXX, который изменяет первый цифры номера 919 392-3 просто на 2, в то время как остальные цифры остаются нетронутыми. Затем звонок направляется к соответствующему телефону. Translation Patterns должен использоваться для истинного преобразования (как написано у Cisco «true translations») и не должен использоваться как простой способ удалить prefix digits.

От себя: у нас Translation Pattern используется для соответствия городского номера внутреннему, т.е номеру 123456 соответствует внутренний номер 0798. Просто чтобы не использовать line group, hunt list и hunt pilot.

Route Filter – может быть использован не только для ограничения набора, но также и для указания набора шаблонов с заполнителем, когда заполнитель @ используется в NANP. Cisco CallManager определяет тэги в каждом номере: международный номер, код города, номер офиса. Например, вы можете использовать его для блокировки кода города 900. Он может быть также использован совместно с Partitions и CSS, для настройки комплексных (более сложных правил).

Например, можно установить Route Filters, который позволяет пользователям группы «администратор» набирать любые номера, в том числе и международные, но ограничить пользователей группы «персонал» городскими (у Cisco они называются local numbers) и междугородними звонками, и разрешить пользователям группы «гость» звонки только на городские номера, и номера 911 и 800.

Partition – это логические группы DN и Route Patterns с аналогичными характеристиками достижимости. Для простоты восприятия их обычно называют, по их выполняемым свойствам, например, "NYLongDistance" и "NY911." Когда DN или Route Pattern помещены в определенную Partition, «создается» правило, определяющее кто может звонить на устройство или Route List.

Calling Search Space – группа партиций для поиска, определяющая на какие номера можно звонить. Например, номер телефона, который включен в CSS «Executive» может звонить на международные, междугородние, городские номера и 911, т.е. CSS «Executive» содержит список партиций "NYInternationalCall," "NYLongDistance," "NYLocalCall," и "NY911". Номер телефона, включенный в CSS «Guest» может звонить только на городские номера и 911, т.е. CSS «Guest» содержит список партиций "NYLocalCall" и "NY911". Попытка позвонить с этого номера (CSS «Guest») на международные номера потерпит неудачу, т.к. совпадение не найдено. Таким образом CSS определяет какие DN и Route Patterns могут быть вызваны.

Примечание: С точки зрения маршрутизации вызовов основное отличие между Cisco CallManager 2.x и Cisco CallManager 3.x или 4.x в понятии Partitions и Calling Search Spaces и замена термина "Route Point" на "Route List".

Hunting - позволяет направлять вызовы на список line groups, где каждая группа может независимо использовать один из трех алгоритмов, известные как broadcast, top down, или circular.

• Hunting начинается, когда номер hunt pilot связан с hunt list, определяющего номер вызываемого абонента.
• Hunt pilot может быть вызван непосредственно или назначен в качестве номера для переадресации.
• Определения получателя входящего вызова (hunting), поля переадресации, участников hunting, игнорируются. Какой телефон должен зазвонить следующим определяется line groups в соответствующем hunt list.

Примечание: В Cisco CallManager Release 4.0 hunting останавливается, когда одна из сторон ответит на звонок или, когда hunt list будит исчерпан.

Call Forwarding – позволяет пользователям указать каким образом вызовы к их номерам, если пользователю не удалось ответить в указанный интервал времени, поле Call Forward No Answer, или если пользователь занят, поле Call Forward Busy.

P.S. Это перевод части официальной документации,если кто будит пользоваться обратите внимание, что точность и правильность перевода не гарантируется. В тексте могут присутствовать орфографические, пунктуационные и другие ошибки. За более полной информацией необходимо обратится к официальной документации.

Типы Call Information Records

В этой главе описывается два типа call information records, генерируемые CUCM

CUCM генерирует два раздельных типа call information records: Call Detail Records (CDR) и Call Management Records (CMR), их также называют диагностические записи вызова. CDRs предоставляет информацию о конечных точках вызова и других аспектах вызова контроль/маршрутизация. CMRs содержит диагностическую информацию о качестве аудио потока вызова. CDR запись может содержать более одного CMR.

CMRs поддерживаются Cisco IP Phones, телефонами серии Cisco 7960 и шлюзами MGCP. Если одна из этих конечных точек принимает участие в вызове, будут сгенерированы CMR записи после завершения вызова.  Каждая конечная точка в вызове создает отдельную CMR запись. Если в вызове участвуют конечные точки, которые не поддерживают диагностику вызова, записи не будут генерироваться для этих конечных точек. Вызов от Cisco 7960 phone к H.323 шлюзу будит генерировать одну CMR запись (от Cisco 7960 phone.)

CDRs с CMRs имеет две общие колонки globalCallID: globalCallID_callManagerId и globalCallId_callId.

Когда параметр Call Diagnostics установлен в True, система генерирует до двух CMRs для каждого вызова. Каждый тип вызова, такой как конференцсвязь, переадресация вызова, переадресованный вызов и вызов, с использованием шлюза, производят множество записей в тестовый (ASCII) файл в конце вызова. CUCM не выполняет никакую постобработку CDR или CMR.

Global Call Identifier (Глобальный идентификатор вызова)

CUCM назначает глобальный идентификатор вызова (GlobalCallID_callId) каждый раз, когда на Cisco IP Phone поднимается трубка или вызов принимается со стороны шлюза. GlobalCallID_callId  назначается последовательно на сервере CUCM, независимо от вызовов работающих (происходящих) на других серверах кластера.  Для каждой тысячи вызовов CUCM фиксирует значение GlobalCallID_callId в файл, который хранится на диске. При любом перезапуске CUCM производится сопоставление тысячного вызова со следующим GlobalCallID_callId.

Например, когда вызов завершен успешно, значение GlobalCallID_callId в CDR устанавливается 1001. При следующем вызове, GlobalCallID_callId значение устанавливается 1002 и т.д. Когда CUCM перезагружается, значения для следующих вызовов в CDR начинается с 2001.  Последовательность продолжается пока CUCM неперезагрузится снова.  При следюющей перезагрузки значение GlobalCallID_callId будит равно 3001.

Максимальное значение, которое будит присвоено GlobalCallID_callId ограничено 24 бит. Когда этот предел достигнут, значение GlobalCallID_callId сбрасывается до 1.

GlobalCallID_callIds в CDR файле может идти не по порядку в текстовом CDR файле. Если вызов с  GlobalCallID_callId = 1 длится долше, чем вызов с GlobalCallID_callId = 2, в CDR файл идентификатор GlobalCallId_callId = 2  запишется раньше GlobalCallId_callId = 1. GlobalCallID_callIds может  полностью отсутствовать в  CDR файле. Если первая CDR запись имеет GlobalCallID_callId = 1, а вторая  GlobalCallID_callId = 3, это не означает, что GlobalCallID_callId = 2 потеряна. GlobalCallID_callId = 2 не соответствует критериям для создания CDR. CDR может отсутсвовать, потому что пока первый и третий вызов были успешно завершены, второй вызов не был завершен, или, GlobalCallID_callId = 2 может быть частью конференции. Каждой участнику конференции (call leg) присваивается свой GlobalCallID_callId, который переписывается в GlobalCallID_callId конференции. Исходный GlobalCallID_callId может не появится в CDR файле.

Если поле GlobalCallID_callId отсутствует в CDR записи, CAR сообщает об ошибке для этой конкретной записи. Дополнительная информация о ошибках CDR доступна в главе "Configuring CDR Error Reports" руководства  the CDR Analysis and Reporting Administration Guide.

Преобразование номера

CUCM может выполнять преобразование цифр, которые набрал пользователь. В CDR появляется номер после преобразования (translated number), а не фактически набранные цифры.

Например, некоторые компании преобразуют вызов «911» в «9-911», таким образом вызывающему не нужно набирать выход на внешнюю линию (в данном примере 9) в экстренных ситуациях. В данном случае CDR содержит «9911» даже если пользователь набрал «911».

Примечание

Шлюзы могут выполнять дальнейшие модификации номера, до актуальных состояния необходимого для передачи их через шлюз. CDR не отображает эти модификации.

Партиции и Номера

В пределах CDR, сочетание extension number (номера) и партиций определяет каждый телефон, на который ссылается, если партиции определены.  Когда партиции определены, для полного распознавания телефона требуются оба значения потому, что extension number (номер) может быть не уникальным.

Поле Partition остается пустым, при входящем вызове (call ingresses) со стороны шлюза. При исходящем вызове (call egresses) для шлюза, поле Partition показывает партицию, которой принадлежит шлюз.

Если dial plan позволяет абоненту использовать # для быстрого набора, то # записывается в базу данных при ее использовании. Например, поле Called Party Number может содержать значение, такое как  "902087569174#".

Поле Party Number может содержать SIP URIs вместо обычных номеров вызывающего/вызываемого абонента.

CDRs используется Partition/Extension Numbers, которые представлены в таблице 1.

Таблица 1

Phone Number	Description
callingPartyNumber	Это сторона совершающая вызов. При переадресации вызовов она становится передающей стороной.
originalCalledPartyNumber	Указывает на  первоначально набранный номер, после того как произошло любое преобразование номера.
finalCalledPartyNumber	Для переадресованных вызовов, этот указывается последняя сторона (абонент), которая приняла вызов. Для нереадресованных вызовов – это  поле показывает первоначальный номер абонента.
lastRedirectDn	Для переадресованных вызовов, это поле обозначает последнюю сторону (абонент), перенаправившую вызов. Для не переадресованных вызовов, это поле показывает последнюю сторону перенаправившую вызов.
originalCalledPartyNumberPartition	Это поле связывает имя партиции с номером телефона. Оно однозначно определяет этот номер потому, что CUCM поддерживает много Cisco Unified IP Phones, имеющие такой же номер, но в других партициях. При исходящих вызовах (проходящих через шлюз) – это поле указывает на имя партиции, которое связано с route pattern, который связан со шлюзом.
finalCalledPartyNumberPartition	Это поле связывает имя партиции с номером телефона. Оно однозначно определяет этот номер потому, что CUCM поддерживает много Cisco Unified IP Phones, имеющие такой же номер, но в других партициях. При исходящих вызовах (проходящих через шлюз) – это поле указывает на имя партиции, которое связано с route pattern, который связан со шлюзом.
lastRedirectDnPartition	Это поле связывает имя партиции с номером телефона. Оно однозначно определяет этот номер потому, что CUCM поддерживает много Cisco Unified IP Phones, имеющие такой же номер, но в других партициях. При исходящих вызовах (проходящих через шлюз) – это поле указывает на имя партиции, которое связано с route pattern, который связан со шлюзом.
outpulsedCallingPartyNumber	The calling party number outpulsed from the device.
outpulsedCalledPartyNumber	The called party number outpulsed from the device.

Временные отметки
Временные метки в CDR показываются в формате UTC. Это значение остается постоянным при переходе на летнее время.

Беззнаковое 32-разрядное целое число представляет все значения времени. Это значение отображается в базе как одно целое.  Это поле показывает значение time_t, которое было получено от операционной системы.

CDR включает в себя временные метки, которые показаны в таблице 2
Таблица 2

Field	Description
dateTimeOriginatio	Для исходящих вызовов – это поле указывает время, когда на телефоне подняли трубку. Для входящих вызовов – это поле указывает время, когда было принято сообщение SETUP.
dateTimeConnect	Это поле показывает время, когда соединение установлено и начался разговор. Это поле показывает ноль, если звонок «не прошел».
dateTimeDisconnect	Это поле показывает время, когда соединение было разорвано. Это поле показывает ноль, если звонок «не прошел».

Причины разрыва соединения
CDR включает в себя два кода причины разрыва соединения: OrigCause и DestCause. Когда инициатор вызова завершает вызов – заполняется OrigCause. Когда вызываемая сторона завершает вызов или вызов сброшен – заполняется DestCause.  Когда поля не заполнены, оторбражается ноль.

Для внутренних звонков (On Net call legs) CUCM определяет значение кода причины. Для внешней части соединения (Off Net call legs), значение кода определяется на дальнем конце.
Список кодов завершения вызова согласно спецификации ITU Q.850 представлены в таблице, на странице оф. документации.


P.S. Это перевод части официальной документации,если кто будит пользоваться обратите внимание, что точность и правильность перевода не гарантируется. В тексте могут присутствовать орфографические, пунктуационные и другие ошибки. За более полной информацией необходимо обратится к официальной документации.

Процесс инициализации Cisco IP Phone: часть 1

При рассмотрении процесса инициализации будит использоваться топология:

топологии при внутрикластерном вызове

Далее следует процедура, объясняющая в деталях процесс инициализации (загрузки) Cisco IP Phone:

Шаг 1

Если вы включили соответствующие опции на DHCP сервере (такие как опции 066 (имя TFTP сервера) или 150 (IP-адрес TFTP-сервера)), Cisco IP Phone отправляет запрос на инициализацию к DHCP серверу, для получения IP адрес, адрес DNS сервера и имя или адрес TFTP сервера. Он также получает адрес шлюза по умолчания, если вы включили эту опцию на DHCP сервере (опция 003).

Шаг 2

Если DHCP передает DNS имя TFTP сервера, вам понадобится IP адрес DNS сервера, для перевода имени в IP адрес. Этот шаг можно пропустить, если DHCP сервер передает IP адрес TFTP сервера. В данном примере DHCP сервер передает IP адрес TFTP потому, что DNS не настроен.

Шаг 3

Если ответ DHCP не включает в себя имя TFTP сервер, Cisco IP Phone использует имя сервера по умолчанию.

Шаг 4

Конфигурационные файлы (.cnf) находятся на TFTP сервере. Все .cnf файлы имеют имя формата SEP.cnf. Если телефон первый раз регистрируется на CUCM, по умолчания загружается файл SEPdefault.cnf. В этом примере, первый телефон Cisco IP Phone использует IP адрес 172.16.70.230 (его MAC address - SEP0010EB001720), а второй Cisco IP Phone использует IP адрес 172.16.70.231 (его MAC address - SEP003094C26105).

Шаг 5

Все .cnf файлы содержат IP адрес главного и вторичного CUCM. Cisco IP Phone использует этот IP адрес для соединения с главным CUCM и регистрации.

Шаг 6

После подключения телефона и его регистрации на CUCM, CUCM сообщает телефону о том, какую версию исполняемого файла нужно использовать. Если указанная версия не соответствует версии исполняемого файла на телефоне, телефон отправит новый запрос к TFTP серверу и автоматически перезагрузится.

CUCM процесс инициализации

В этом разделе объясняется процесс инициализации CUCM, с перехваченного traces от Unified CM1 (определяется по IP адресу 172.16.70.228). SDI traces представляет собой очень эффективный инструмент по поиску и устранению неисправностей потому, что он представляет детальную информацию по каждому пакету, пересылаемому между конечными точками.

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

Следующие сообщения, полученные утилитой SDI trace от CUCM показывает процесс инициализации на CUCM в данном случае, Unified CM1.

• Первое сообщение указывает, что CUCM начал процесс инициализации
• Второе сообщение показывает, что CUCM читает значения базы данных по умолчанию (в этом случае он является основной базой данных)
• Третье сообщение показывает, что CUCM принимает различные сообщения по TCP порту 8002
• Четвертое сообщение показывает, что после получение этого сообщения первичный (главный) CUCM добавляет вторичный CUCM в этот список (Unified CM2 172.16.70.229)
• Пятое сообщение указывает, что CUCM стартовал (это актуально начиная с версии Cisco Unified Communications Manager 3.1(1))

16:02:47.765 CCM|CMProcMon - Communications ManagerState Changed - Initialization Started.
16:02:47.796 CCM|NodeId: 0, EventId: 107 EventClass: 3 EventInfo: Cisco CCMDatabase Defaults Read
16:02:49.937 CCM| SDL Info - NodeId: [1], Listen IP/Hostname: [172.16.70.228], Listen Port: [8002]
16:02:49.984 CCM|dBProcs - Adding SdlLink to NodeId: [2], IP/Hostname: [172.16.70.229]
16:02:51.031 CCM|NodeId: 1, EventId: 1 EventClass: 3 EventInfo: Cisco CallManager Version=<3 .1=""> started

Self-Starting Processes

После того, как CUCM загрузился и работает,он стартует несколько других своих процессов. Некоторые из этих процессов выполняют в том числе MulticastPoint Manager, UnicastBridge Manager, digit analysis, and route list. Вы увидите, что сообщения, которые получены в ходе этих процессов очень полезны при устранении проблем, которые относятся к функциям CUCM. Например,предположим, что route list не работает и настроен не правильно. Для решения этой проблемы, вы можете просмотреть traces, чтобы определить запустил ли CUCM RoutePlanManage и пытается ли он загрузить RouteLists. Следующий простой пример показывает, что RouteListName=''ipwan'' and RouteGroupName=''ipwan'' загружены и запущены.

16:02:51.031 CCM|MulicastPointManager - Started
16:02:51.031 CCM|UnicastBridgeManager - Started
16:02:51.031 CCM|MediaTerminationPointManager - Started
16:02:51.125 CCM|MediaCoordinator(1) - started
16:02:51.125 CCM|NodeId: 1, EventId: 1543 EventClass: 2 EventInfo: Database manager started
16:02:51.234 CCM|NodeId: 1, EventId: 1542 EventClass: 2 EventInfo: Link manager started
16:02:51.390 CCM|NodeId: 1, EventId: 1541 EventClass: 2 EventInfo: Digit analysis started
16:02:51.406 CCM|RoutePlanManager - Started, loading RouteLists
16:02:51.562 CCM|RoutePlanManager - finished loading RouteLists
16:02:51.671 CCM|RoutePlanManager - finished loading RouteGroups
16:02:51.671 CCM|RoutePlanManager - Displaying Resulting RoutePlan
16:02:51.671 CCM|RoutePlanServer - RouteList Info, by RouteList and RouteGroup Selection Order
16:02:51.671 CCM|RouteList - RouteListName=''ipwan''
16:02:51.671 CCM|RouteList - RouteGroupName=''ipwan''
16:02:51.671 CCM|RoutePlanServer - RouteGroup Info, by RouteGroup and Device Selection Order
16:02:51.671 CCM|RouteGroup - RouteGroupName=''ipwan''

Следующий trace показывает RouteGroup, к которому добавляется устройство Unified CM3 с адресом 172.16.70.245, который расположен в  Cluster 1 и считается H.323 устройством. В этом случае RouteGroup производит маршрутизацию вызовов к Unified CM3 в кластер1 с разрешения Cisco IOS Gatekeeper. Если проблемы возникают, когда вызов передается к Cisco IP Phone, который расположен в Cluster 1, следующие сообщения помогут вам найти причину проблемы.

16:02:51.671 CCM|RouteGroup - DeviceName=''172.16.70.245''
16:02:51.671 CCM|RouteGroup –AllPorts

Часть процесса инициализации показывает, что CUCM добавляет DNs (абонентские номера). Просмотрев это сообщение, вы можете определить, прочитал ли CUCM абонентский номер из базы.

16:02:51.671 CCM|NodeId: 1, EventId: 1540 EventClass: 2 EventInfo: Call control started
16:02:51.843 CCM|ProcessDb - Dn = 2XXX, Line = 0, Display = ,RouteThisPattern, NetworkLocation = OffNet, DigitDiscardingInstruction = 1, WhereClause = 
16:02:51.859 CCM|Digit analysis: Add local pattern 2XXX , PID: 1,80,1
16:02:51.859 CCM|ForwardManager - Started
16:02:51.984 CCM|CallParkManager - Started
16:02:52.046 CCM|ConferenceManager - Started

Следующий traces показывает, что Device Manager в CUCM производит статическую инициализацию двух устройств. Устройство с IP адресом 172.17.70.226 является gatekeeper, и устройство с адресом 172.17.70.245 получает другой CUCM в другом кластере.

16:02:52.250 CCM|DeviceManager: Statically Initializing Device;
DeviceName=172.16.70.226
16:02:52.250 CCM|DeviceManager: Statically Initializing Device; 
DeviceName=172.16.70.245

P.S. Это перевод части официальной документации,если кто будит пользоваться обратите внимание, что точность и правильность перевода не гарантируется. В тексте могут присутствовать орфографические, пунктуационные и другие ошибки. За более полной информацией необходимо обратится к официальной документации.

Вот такие вот зарплаты в Дом.ru

Пришла очередная рассылка с hh, теперь Дом.ru решил не отставать от Ростелекома. Они сообща решили довести зарплаты своих сотрудником до уровня Газпрома.

Сообщество плоской земли

В настоящее время, если кому-нибудь сказать, что Земля плоская, он как минимум улыбнется, приняв это за шутку, а в худшем случае подумает, что вы в не своем уме. Но и в наше время есть люди, которые пытаются доказать, что Земля плоская.

Flat Earth Society (сообщество плоской земли), также известная как Международное сообщество плоской земли или Международное сообщество исследователей плоской земли, эта организация развивает идею, что земля плоская, а не сплюснутый сфероид. Современная организация основана англичанином Самюэль Шентон в 1956 г. и позднее возглавлена Чарльз К. Джонсон, который основал ее в своем доме в Lancaster, California. Формально сообщество не активно после смерти Чарльз К. Джонсон в 2001 г., но возобновила свою деятельность в 2004 г. с новым председателем Даниэлем Шентоном.

Символ Сообщества 

Идея, что земля плоская, типична для европейской космологии приблизительно до 4 века до нашей эры, когда древние греки рассуждали, что земля сфера или по крайней мере округлой формы. Аристотель первый из европейских мыслителей указал на то, что Земля является сферой в 330 г. до нашей эры. К началу средневековья, широко распространилось мнение по всей Европе, что Земля сфера.

Первым, из современником, кто предложил гипотезу, что Земля плоская, был английский изобретатель Самюэль Роуботам (1816–1884). Основываясь на своем не верном толковании experiments on the Bedford Level, Роуботам опубликовал 16-страничную брошюру, назвав ее "Zetetic Astronomy", которая после была расширена до 430-страничной книги Earth Not a Globe, в которой он изложил свои взгляды. Согласно его взглядам, Земля плоский диск с центром на северном полюсе и ограничена вдоль южной окраины Антарктидой, солнцем и луной 3000 миль (4800 км) и "Космос" 3100 миль (5000 км) над Землей. Он так же выпустил маленькую брошюру озаглавленную "The inconsistency of Modern Astronomy and its Opposition to the Scriptures!!", в которой убеждает, что «Библия, как и наши ощущения, поддерживают идею, что Земля плоская и не подвижная, и эта истина не должна оставаться в стороне, основываясь только на человеческих предположениях».

Роуботам и его последователи, такие как Вильям Карпентер, продолжили его работу, привлекли внимание участием в публичных дебатах с ведущими учеными того времени. Роуботам создал Zetetic Society (Сообщество скептиков) в Англии и Нью-Йорке, в него входили посол США в Китае и глава общественных школ Балтимора.

После смерти Роуботама, Элизабет Блаунт создала Universal Zetetic Society, целью которого было «пропаганда знаний, основанных на естественной космологии, подтверждающей Священное Писание, на основе практических научных исследований». Создала журнал «The Earth Not a Globe Review» просуществовавший до начала 20 века. После первой мировой войны движение стало уменьшаться.

Современное воплощение оно получило в 1956 г. благодаря Самюэлю Шентону, создавшему International Flat Earth Society, как приемника Universal Zetetic Society в своем доме в Dover. Так как Шентон интересовался альтернативными науками и технологиями, акценты на религии, чем в предшествовавшем сообществе.

Это было перед запуском первого искусственного спутника земли. После того как были переданы первые изображения Земли как сферы, сообщество осталось непоколебимо в своих убеждениях. Шентон отметил: «Легко можно заметить как фотография может обмануть неопытный взгляд».

 В 1971 г. Шентон умер и Чарльз К. Джонсон унаследовал часть библиотеки Шентона от его жены. Под его руководством, за последующие три десятилетия, Flat Earth Society увеличилась в размерах от нескольких членов, до 3000. Джонсон распространял листовки, флаеры, карты, и другие рекламные материалы каждому, кто его об этом спрашивал. Джонсон оплачивал эти публикации через ежегодные сборы с членов сообщества, от 6 до 10 $US.

Сертификат члена сообщества 

Большая часть литературы общества была основана на толкования Библии, утверждавшей, что Земля плоская, хотя они действительно пытались предложить научные объяснения и доказательства.

Некоторые заголовки, напечатанные Flat Earth Society в газетах:

Whole World Deceived... Except the Very Elect" (Dec. 1977) (Весь мир обманут…Кроме самых избранных)

"Australia Not Down Under" (May 1978) (Австралия не внизу)

"Sun Is a Light 32 Miles Across" (Dec. 1978) (Солнце – это свет 32 мили в ширину)

"The Earth Has No Motion" (Jun. 1979) (Земля не движется)

"Nikita Krushchev Father of NASA" (Mar. 1980) (Никита Хрущев отец NASA)

"Galileo Was a Liar" (Dec. 1980) (Галилео был лжецом)

"Science Insults Your Intelligence" (Sep. 1980) (Наука оскорбляет вам интелект)

"World IS Flat, and That's That" (Sep. 1980) (Мир плоский и точка)

"The Earth Is Not a Ball; Gravity Does Not Exist" (Mar. 1981) (Земля не шар; гравитации не существует)

В 1980 г. в сообществе осталось примерно 200 членов. Они до сих пор верят, что Земля плоская. Юджен Скотт говорит, что сообщество служит примером «Крайнее буквальное толкование Библии: Земля плоская, потому, что Библия сказала – плоская, несмотря на, что наука нам говорит».

Чарльз К. Джонсон умер 19 марта 2001г.

В 2004г. Даниэль Шентон (не связанный с Самюэлем) заново организовал Flat Earth Society, основываясь вокруг дискуссии на веб форуме. В итоге это привело к возобновлению деятельности сообщества в октябре 2009г. и созданию нового сайта, располагающим крупнейшим собрангием литературы Flat Earth в мире и отредактированной пользователями энциклопедией. Более того, сообщество начало принимать новых членов в первые с 2001г, им стал музыкант Томас Долби, в марте 2012г. их уже было около 420. Даниэль Шентон, после возобновления деятельности сообщества, также дал несколько интервью, в том числе газете The Guardian.

Связанный с Flat Earth Society форум на данный момент не активен. Flat Earth Society представлена в Twitter и Facebook.

В данный момент у сторонников этого сообщества нету центральной теории. Некоторые участники предлагают уникальные идеи о том как устроена Земля. Некоторое утверждают, что это конечная плоскость неизвестной величины с ускорением свободного падения, направленного вверх, 9.8 м/с2, другие утверждают, что это бесконечная плоскость.

Модель конечной плоской земли 

В поп-культуре так же встречается упоминания об этом:

Английский музыкант Томас Долби выпустил альбом под названием «The Flat Earth», связанную с мифом о плоской Земле.

В 1980г. Уолли Джордж часто высмеивал членов сообщества в своем ток-шоу Hot Seat.

В 1990г. основанная в Калифорнии панк-рок группа Bad Religion, включила песню "Flat Earth Society в свой альбом Against the Grain.

Ричард А. Лапофф в романе Circumpolar! описал плоскую планету, похожую на Землю, как ее описывает Flat Earth Society, за исключением того, что она имеет отверстие по центру, а не Северный полюс, и другая сторона содержит вымышленные страны такие, как Атлантида и Лемурия.

P.S.За более подробной информацией обращайтесь к гуг или википедию (лучше английскую).