По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Предыдущая статья из цикла про популярные приложения TCP/IP тут.
Установление TCP-соединения происходит до того, как любая из других функций TCP сможет начать свою работу. Установление соединения относится к процессу инициализации полей "Sequence" и "Acknowledgment" и согласования используемых номеров портов. На рисунке 5 показан пример процесса установления соединения.
Этот трехсторонний процесс установления соединения (также называемый трехсторонним рукопожатием) должен завершиться до начала передачи данных. Соединение существует между двумя сокетами, хотя в заголовке TCP нет единственного поля сокета. Из трех частей сокета подразумеваются IP-адреса на основе IP-адресов источника и назначения в IP-заголовке. TCP подразумевается, потому что используется заголовок TCP, как указано значением поля протокола в заголовке IP. Следовательно, единственные части сокета, которые необходимо закодировать в заголовке TCP, - это номера портов.
TCP сообщает об установлении соединения, используя 2 бита в полях флагов заголовка TCP. Эти биты, называемые флагами SYN и ACK, имеют особенно интересное значение. SYN означает "синхронизировать порядковые номера", что является одним из необходимых компонентов при инициализации TCP.
На рисунке 6 показано завершение TCP-соединения. Эта четырехсторонняя последовательность завершения проста и использует дополнительный флаг, называемый битом FIN. (FIN - это сокращение от "finished", как вы могли догадаться.) Одно интересное замечание: перед тем, как устройство справа отправит третий сегмент TCP в последовательности, оно уведомляет приложение о том, что соединение прерывается. Затем он ожидает подтверждения от приложения перед отправкой третьего сегмента на рисунке. На случай, если приложению потребуется некоторое время, чтобы ответить, ПК справа отправляет второй поток на рисунке, подтверждая, что другой ПК хочет разорвать соединение. В противном случае ПК слева может повторно отправить первый сегмент.
TCP устанавливает и завершает соединения между конечными точками, а UDP - нет. Многие протоколы работают в рамках одних и тех же концепций, поэтому термины "ориентированный на соединение" и "без установления соединения" используются для обозначения общей идеи каждого из них. Более формально эти термины можно определить следующим образом:
Протокол, ориентированный на соединение: протокол, который требует обмена сообщениями до начала передачи данных или который имеет требуемую предварительно установленную корреляцию между двумя конечными точками.
Протокол без установления соединения: протокол, который не требует обмена сообщениями и не требует предварительно установленной корреляции между двумя конечными точками.
Восстановление после ошибок и надежность
TCP обеспечивает надежную передачу данных, что также называется reliability or error recovery. Для обеспечения надежности TCP нумерует байты данных, используя поля "Sequence" и "Acknowledgment" в заголовке TCP. TCP обеспечивает надежность в обоих направлениях, используя поле Sequence Number одного направления в сочетании с полем Acknowledgment в противоположном направлении.
На рисунке 7 показан пример того, как поля TCP Sequence и Acknowledgment позволяют ПК отправлять 3000 байтов данных на сервер, при этом сервер подтверждает получение данных. Сегменты TCP на рисунке расположены по порядку, сверху вниз. Для простоты все сообщения содержат 1000 байтов данных в части данных сегмента TCP. Первый порядковый номер - красивое круглое число (1000), опять же для простоты. В верхней части рисунка показаны три сегмента, каждый из которых на 1000 больше предыдущего, что указывает на первый из 1000 байтов сообщения. (То есть в этом примере первый сегмент содержит байты 10001999; второй - байты 20002999, а третий - байты 30003999.)
Четвертый сегмент TCP на рисунке - единственный, который возвращается от сервера к веб-браузеру - подтверждает получение всех трех сегментов. Как? Значение подтверждения 4000 означает: "Я получил все данные с порядковыми номерами на единицу меньше 4000, поэтому я готов принять ваш байт 4000 следующим". (Обратите внимание, что это соглашение о подтверждении путем перечисления следующего ожидаемого байта, а не номера последнего полученного байта, называется прямым подтверждением.)
Однако этот пример не исправляет никаких ошибок; он просто показывает основы того, как хост-отправитель использует поле порядкового номера для идентификации данных, а хост-получатель использует прямые подтверждения для подтверждения данных. Более интересное обсуждение вращается вокруг того, как использовать эти же инструменты для восстановления ошибок. TCP использует поля "Sequence" и "Acknowledgment", чтобы принимающий хост мог заметить потерю данных, попросить отправляющий хост повторно отправить, а затем подтвердить, что повторно отправленные данные прибыли.
Существует множество вариантов того, как TCP выполняет исправление ошибок. На рисунке 8 показан только один такой пример, детализация которого аналогична предыдущему. Веб-браузер снова отправляет три сегмента TCP, снова по 1000 байт каждый, снова с легко запоминающимися порядковыми номерами. Однако в этом примере второй сегмент TCP не может пройти через сеть.
Рисунок указывает на три набора идей, лежащих в основе того, как думают два хозяина. Во-первых, справа сервер понимает, что он не получил все данные. Два полученных сегмента TCP содержат байты с номерами 10001999 и 30003999. Очевидно, сервер не получил байты, пронумерованные между ними. Затем сервер решает подтвердить все данные вплоть до потерянных, то есть отправить обратно сегмент с полем подтверждения, равным 2000.
Получение подтверждения, которое не подтверждает все данные, отправленные на данный момент, заставляет хост-отправитель повторно отправить данные. ПК слева может подождать несколько секунд, чтобы убедиться, что другие подтверждения не поступят (используя таймер, называемый таймером повторной передачи), но вскоре решит, что сервер сообщает: "Мне действительно нужно 2000 - отправьте его повторно". ПК слева делает это, как показано на пятом из шести сегментов TCP на рисунке.
Наконец, обратите внимание, что сервер может подтверждать не только повторно отправленные данные, но и любые предыдущие данные, которые были получены правильно. В этом случае сервер получил повторно отправленный второй сегмент TCP (данные с порядковыми номерами 20002999), и сервер уже получил третий сегмент TCP (данные с номерами 30003999). Следующее поле подтверждения сервера подтверждает данные в обоих этих сегментах с полем подтверждения, равным 4000.
Управление потоком с использованием окон
TCP реализует управление потоком, используя концепцию окна, которая применяется к количеству данных, которые могут быть ожидающими подтверждения в любой момент времени. Концепция окна позволяет принимающему хосту сообщать отправителю, сколько данных он может получить прямо сейчас, давая принимающему хосту способ замедлить или ускорить отправляющий хост. Получатель может перемещать размер окна вверх и вниз (это называется скользящим окном или динамическим окном), чтобы изменить объем данных, который может отправить хост-отправитель.
Механизм раздвижного окна имеет больше смысла на примере. В примере, показанном на рисунке 9, используются те же основные правила, что и в примерах на нескольких предыдущих рисунках. В этом случае ни один из сегментов TCP не содержит ошибок, и обсуждение начинается на один сегмент TCP раньше, чем на предыдущих двух рисунках.
Начнем с первого сегмента, отправленного сервером на ПК. Поле Acknowledgment должно быть вам знакомо: оно сообщает ПК, что сервер ожидает следующий сегмент с порядковым номером 1000. Новое поле, поле окна, установлено на 3000. Поскольку сегмент передается на ПК, это значение сообщает ПК, что ПК может послать не более 3000 байтов по этому соединению до получения подтверждения. Итак, как показано слева, ПК понимает, что может отправлять только 3000 байтов, и прекращает отправку, ожидая подтверждения, после отправки трех 1000-байтовых сегментов TCP.
Продолжая пример, сервер не только подтверждает получение данных (без потерь), но и решает немного увеличить размер окна. Обратите внимание, что второе сообщение, идущее справа налево на рисунке, на этот раз с окном 4000. Как только ПК получает этот сегмент TCP, ПК понимает, что он может отправить еще 4000 байтов (окно немного больше, чем предыдущее значение).
Обратите внимание, что хотя на последних нескольких рисунках показаны примеры с целью объяснения того, как работают механизмы, из этих примеров может сложиться впечатление, что TCP заставляет хосты сидеть и долго ждать подтверждения. TCP не хочет заставлять хост-отправитель ждать отправки данных. Например, если подтверждение получено до того, как окно будет исчерпано, начинается новое окно, и отправитель продолжает отправлять данные до тех пор, пока текущее окно не будет исчерпано. Часто в сети, где мало проблем, мало потерянных сегментов и небольшая перегрузка, окна TCP остаются относительно большими, а узлы редко ждут отправки.
Закрепим самое важное про TCP и UDP в следующей статье.
В процессе нашей работы, часто приходится сталкиваться с ситуациями, когда заказчик, при переходе от аналоговой телефонии (ТФОП – Телефонная Сеть Общего Пользования) к VoIP не может отказаться от имеющегося у него аналогового оборудования. Это могут быть как аналоговые телефоны, факсимильные и модемные устройства так и вся аналоговая АТС. Причины могут быть абсолютно разные, но решение всегда одно - поставить специальные шлюзы c FXS/FXO интерфейсами, с помощью которых можно "подружить" аналоговый мир и мир IP.
Как можно догадаться FXS/FXO интерфейсы (или порты) - это аналоговый мир и одно не может существовать без другого. Что же это за интерфейсы и как они работают - читайте в этой статье.
Предыстория
Традиционная аналоговая телефонная сеть – это совокупность технических сооружений и аналоговых линий связи, обеспечивающих возможность осуществления телефонных соединений по средствам аналоговых телефонных аппаратов. Подключение к телефонной сети общего пользования (POTS – Plain Old Telephone Service) - это услуга, которую предоставляет местная телефонная компания из своих центральных офисов (CO – Central Office) для домашних или офисных абонентов. Подключение осуществляется с помощью электрических проводов, состоящих из двух медных жил. Чтобы увеличить расстояние, на которое может быть передан сигнал и уменьшить электромагнитные помехи, жилы скручиваются вместе, такой метод называется «витая пара».
Интерфейс FXS
Медные провода протягиваются до помещений конечных абонентов (квартиры и жилые дома – для домашних абонентов, офисные здания и комнаты – для офисных абонентов) и заканчиваются в виде телефонной розетки в стене, как правило, с разъёмом стандарта RJ-11 (У кого то может быть ещё остались советские РТШК).
И это, дорогие друзья, и есть тот самый интерфейс или порт FXS – Foreign eXchange Subscriber / Station, по которому местная телефонная компания предоставляет сервис POTS. В данный порт должны подключаться оконечные абонентские устройства, такие как телефон, факс или модем. Буква ”S”- (Subscriber - абонент) в аббревиатуре FXS как бы подсказывает, что данный интерфейс будет ожидать подключения именно от абонентcкого устройства.
Основные функции, которые обеспечивает FXS порт это:
Зуммер - непрерывный сигнал, который Вы слышите, когда снимаете трубку, означающий, что телефонная станция готова принимать номер. В англоязычной литературе – Dial Tone;
ток заряда батареи питания линии
Напряжение линии - постоянное напряжение аналоговой телефонной линии, необходимое для осуществления звонка;
Итак, запомните – к FXS всегда подключаем абонентские оконечные устройства, это то, что мы получаем от провайдера телефонной связи.
Интерфейс FXO
Устройства FXO – Foreign eXchange Office - это устройства, которые получают сервис POTS, то есть это оконечные устройства – телефоны, факсы модемы и так далее. Эти устройства также имеют разъём стандарта RJ-11 и ожидают подключения со стороны телефонной станции (CO – Central Office), о чем свидетельствует буква «O» - Office в аббревиатуре FXO.
Данный интерфейс обеспечивает функции определения поднятия трубки (on-hook/off-hook), то есть факт замыкания цепи, которая в свою очередь вызывает отправку Dial Tone со стороны телефонной станции.
Итак, запомните – к FXO всегда подключаем линию от провайдера телефонной связи.
А теперь, закрепим усвоенное.
FXS порт – это наша домашняя (или офисная) телефонная розетка, которую нам предоставляет провайдер телефонных услуг. К ней мы подключаем абонентские аппараты (телефоны, факсы и прочие)
FXO порт – это разъем на нашем телефоне, его мы всегда подключаем к FXS, то есть к телефонной станции провайдера услуг POTS.
Кстати, важно отметить, что нельзя подключить FXO устройство к другому FXO устройству, ну и FXS к FXS. Например, если вы напрямую соедините два телефона (FXO), то вы не сможете позвонить с одного на другой.
Аналоговые УАТС и FXS/FXO
Если в офисе используется старая аналоговая учрежденческая АТС (УАТС), то это немного меняет картину. УАТС должна иметь оба типа интерфейсов, как FXS, так и FXO.
Линии от провайдера телефонных услуг (FXS), должны подключаться к FXO интерфейсам аналоговой УАТС, обеспечивая Dial Tone и напряжение линии, а сами оконечные устройства – телефонные аппараты, как устройства FXO, должны подключаться к FXS интерфейсам аналоговой УАТС и обеспечивать определения снятия трубки.
VoIP и FXS/FXO
Как я уже писал в начале статьи, для того, чтобы «подружить» аналоговый мир и мир IP, необходимо использовать VoIP шлюзы. Однако то, какой именно использовать шлюз FXO или FXS – зависит от ситуации. Как правило ситуаций всего две:
Пример №1
У нас есть медные линии от местной телефонной компании, но отказываться мы от них не хотим. Планируем поставить в качестве офисной телефонной станции IP-АТС Asterisk.
В этом случае нам нужен FXO шлюз. Медные линии от провайдера (FXS) мы подключаем в FXO порты шлюза, а к Ethernet портам шлюза подключается IP-АТС Asterisk. FXO шлюз производит преобразование аналоговых сигналов от аналоговой станции нашей местной телефонной компании в цифровые сигналы, которые понимает IP-АТС Asterisk. Схема такая:
Пример №2
У нас есть аналоговые телефоны и факс, отказываться от них мы не хотим. Однако отказались от старой аналоговой АТС и перешли на IP-АТС Asterisk
В этом случае, нам нужен FXS шлюз. Наши аналоговые телефоны – это аппараты FXO, поэтому их мы подключаем к FXS портам шлюза, а к Ethernet порту подключаем IP-АТС Asterisk. FXS шлюз осуществляет преобразование аналоговых сигналов от аналоговых телефонов в цифровые сигналы, которые понимает Asterisk. Схема примерно такая:
На этом всё, друзья. Искренне надеюсь, что данная статья поможет вам разобраться в разнице между FXS и FXO интерфейсами и пригодится в ваших проектах :)
Сегодня подробно разберёмся в том, как настроить запись телефонных разговоров, проходящих через нашу IP-АТС Asterisk, с помощью графической оболочки FreePBX 13. Данная статья будет так же полезна тем, у кого, по каким то причинам, не записываются телефонные разговоры и они хотят это исправить.
Заглянем в FreePBX
Множество модулей во FreePBX позволяют включить запись телефонных разговоров напрямую, к таким относятся Extensions, Queues, Ring Groups, Inbound Routes. То есть, например, при создании нового внутреннего номера или ринг группы мы можем определить, записывать ли разговоры проходящие через них.
Для этого, в каждом модуле, который позволяет настроить запись, есть раздел Recording Options или Call Recording, в котором доступно 5 режимов записи - Force, Yes, Don't Care, No и Never.
Данные режимы, позволяют определить, как именно будет идти запись в течение "жизни вызова" или call flow. Вы можете спросить - "Зачем в модулях предусмотрено целых 5 режимов? Почему бы просто не оставить: Yes - есть запись, No - записи нет?"
Все дело в том, что звонок может менять свое назначение, например, он может изначально поступить на телефон секретаря Extension, а потом его переведут, например, на отдел продаж Ring Group (цикл звонка и есть call flow), в одном модуле запись может быть включена, а в другом нет и вот чтобы определить, что будет записано и служат эти 5 режимов. Давайте разберёмся подробнее в их логике:
Force и Never заменяют друг друга и имеют высший приоритет чем Yes и No
Yes и No имеют одинаковый приоритет
Когда один и больше Yes или No встречается в call flow, в приоритете всегда будет первое значение.
Последующие опции Yes или No не переопределяют первую.
Force и Never будут всегда переопределять опции, которые установлены ранее.
Force и Never будут всегда заменять друг друга. Например если сначала был установлен Force, а потом встречается Never, то в приоритете будет Never
Force и Never будут всегда заменять предустановленные опции Yes и No
Yes и No никогда не заменять Force и Never
Don’t Care не будет изменять предыдущую опцию.
Чтобы было проще понять логику этих 5 режимов, каждый раз, когда встречается No представляйте себе такую фразу – «Я бы предпочел не записывать эту часть вызова, если раньше мне не говорили записать её», когда Yes, такую фразу – «Я хотел бы записать эту часть вызова, если только ранее я не был предупрежден не делать этого». Если встречаете Force, то представьте такую фразу – «Начать или продолжить запись сейчас же!», а если Never - «Закончить запись сейчас же!». И наконец, если встречаете Don’t Care - «Сейчас ничего менять не нужно»
Следует отметить, что некоторые модули, такие как Conference не имеют опций Force, Don’t Care и Never, а имеют только Yes и No, а некоторые, например, Ring Group наоборот, имеют только опции Force, Don’t Care и Never.
Ещё одной важной функцией записи телефонных разговоров, является запись по требованию - On Demand Recording. С помощью данной функции, администратор IP-АТС может настроить пользователю определенного внутреннего номера Extension, эксклюзивное право включать и выключать запись прямо во время разговора, используя программируемую кнопку на корпусе его телефона или специальный Feature Code, по умолчанию это *1. Для того, чтобы настроить данный функционал, необходимо открыть Applications → Extensions далее открыть вкладку Advanced, прокрутить меню до опции Recording Option и найти поле On Demand Recording
Как видите, On Demand Recording имеет следующие режимы:
Disable - Пользователь внутреннего номера не сможет использовать функцию записи по требованию, не зависимо от того, какой режим имеет вызов Force, Yes, Don't Care, No или Never.Если пользователь попробует ввести специальный Feature Code, то он услышит ответ “access denied” – “доступ запрещен”
Enable - Функция записи по требованию доступна пользователю, но только если звонок имеет режим Yes,No или Don’t Care. Если звонок в режиме Force, или Never, то он услышит “доступ запрещен”
Overrride - Пользователь всегда может включить или выключить запись по требованию, вне зависимости от режима Force, Yes, Don't Care, No или Never.
Теперь, чтобы основательно закрепить материал, давайте рассмотрим пример вызова и посмотрим, как будет меняться режим записи в этом call flow:
Допустим, мы имеем входящий звонок, в правилах входящего маршрута - Inbound Route которого установлен режим записи Yes. В результате генерируется файл записи и запись разговора начинается.
По правилам этого входящего маршрута, вызов переходит в очередь Queue, режим записи которой - Don’t Care - запись продолжается.
В очереди, звонок принимает оператор, в правилах внутреннего номера которого, стоит режим записи входящих звонков (Inbound External Calls) - No. Запись продолжается, потому что перед этим, в первом шаге, на входящем маршруте был установлен режим Yes и он имеет приоритет.
Оператор нажимает *1, в настройках его внутреннего номера On Demand Recording установлен режим - Enable. Запись останавливается.
Оператор переводит звонок на ринг-группу (Ring Group), режим записи которой - Force. Запись продолжается.
В ринг группе, звонок принимает менеджер, в правилах внутреннего номера которого, стоит режим записи входящих звонков (Inbound Internal Calls) - Never. Запись снова остановлена.
Менеджер хочет начать запись и нажимает *1 и слышит в трубке “доступ запрещен”, потому что функция записи по требованию заблокирована режимом Never
Таким образом, если Вы вдруг заметили, что у вас отсутствуют записи каких-либо телефонных разговоров или отдельных их частей, а вы вроде как её включали в настройках, то рекомендуем Вам проследить call flow звонка, в котором нет записи и посмотреть – какой режим включается на каждом из этапов.