sip uac что это

Андрей Погребенник

Всё, что вы хотели знать о протоколе SIP

Что общего у Microsoft Exchange 2007, Asterisk и Google Talk? А общим здесь является использование протокола SIP, который обещает единое решение задач как реализации мультимедийных функций в веб-приложениях, так и переноса сигнального трафика в сетях операторов связи.

В одном из писем своим компаньонам Александер Грэм Белл впервые в истории и при этом весьма подробно изложил план создания в большом городе телефонной сети, базирующейся на центральном коммутаторе. В письме он настаивал на том, что в целях рекламы было бы желательно бесплатно установить телефонные аппараты в центральных магазинах города. Это письмо стало первоисточником привычной телефонной лексики, в том числе фразы «алло, центральная», которая умерла лишь при появлении автоматических телефонных станций. В течение более чем 100 лет все значимые изменения, происходившие с телефонной станцией, касались именно телефонной станции. И лишь в эпоху Интернета стало возможным говорить о действительно новом направлении коммуникаций.

Путь будущего развития коммуникаций лежит через разделение логики работы сетей и предоставления услуг. Новые услуги будут предоставляться опорной сетью, т.е. независимо от сети доступа. Таким образом, в любом месте, при использовании любого метода доступа к сети и с любого оконечного устройства пользователь может обращаться к одним и тем же услугам. В опорных сетях уже сейчас происходит переход от сетей с коммутацией каналов и мультиплексированием с разделением по времени (Time-division Multiplexing, TDM), на которых реализована вся традиционная телефония, к пакетным сетям. Дополняет картину Fixed Mobile Convergence – идея интеграции функционала мобильных и фиксированных сетей.

Операторы готовят инфраструктуру к предоставлению услуг следующего поколения путем применения программных коммутаторов, отличающихся большой гибкостью. Программные коммутаторы реализуют функции сопряжения с телефонной сетью общего пользования (ТфОП), обеспечивают централизованный биллинг, управление и интеллектуальную динамическую маршрутизацию звонков. Их применение означает для операторов фиксированной и мобильной связи возможность предоставления услуг транзита голосового трафика через опорную сеть IP/MPLS (Internet Protocol/Multiprotocol Label Switching), подключения корпоративных клиентов, управления вызовами и обслуживания клиентских устройств – и всё это, как правило, с меньшими затратами в сравнении с сетями TDM.

Происходящие в последние годы изменения на мировом рынке услуг телефонной связи сравнимы по своей значимости с переходом телефонии на автоматическую коммутацию. Эти изменения не в последнюю очередь связаны с появлением так называемых услуг SIP-телефонии, активно обсуждаемых в телекоммуникационном сообществе. Протокол SIP был стандартизирован в апреле 1999 года, а актуальная спецификация (версия 2.0 протокола SIP) датирована 2002 годом.

Session Initiation Protocol (SIP) – это клиент-серверный протокол прикладного уровня, предназначенный для установления, изменения и окончания сеансов связи с одним или несколькими участниками для обмена интерактивным трафиком: голосом, видео, мгновенными сообщениями. SIP относится к классу протоколов сигнализации; его задачи аналогичны тем, которые выполняет протокол общеканальной сигнализации №7 (ОКС7 или SS7) в обычной телефонии, а протоколы H.323 и MGCP (Media Gateway Control Protocol) – в IP-телефонии. Основными функциями SIP являются:

Непосредственным носителем голосовых или видеоданных является протокол RTP (Real-time Transport Protocol), SIP-сообщение же выполняет роль контейнера для сообщений протокола описания сеансов связи SDP (Session Description Protocol). Сообщение SDP описывает медиаданные в рамках сессии: тип медиаданных, транспортный протокол, формат данных и пр. RTP и SDP будут рассмотрены в следующей статье цикла, сейчас же сделаем акцент на том, что SIP был расширен для поддержки функций обмена мгновенными сообщениями и информацией о присутствии и статусе абонента. Последнее позволяет выполнять более совершенное управление голосовыми вывозами с переадресациями и продвинутой маршрутизацией. SIP поддерживает также приглашение участников к текущим сеансам наподобие многоточечных конференций, добавление к текущему сеансу или удаление из него мультимедийных данных, прозрачное распределение имён и перенаправление услуг, включая персональную мобильность пользователя.

Так что, хотя о протоколе SIP чаще всего говорят в контексте IP-телефонии, на самом деле он может применяться для установки поверх IP самых разнообразных сеансов связи, порой не имеющих ничего общего с телефонным звонком (что неудивительно для протокола, разработанного IETF, а не телекоммуникационной индустрией, как H.323). Впрочем, H.323 сегодня также не ограничен голосовой связью и может обслуживать любой сеанс связи.

Традиционно H.323 называли более зрелым протоколом, а SIP – более динамичным, расширяемым, масштабируемым и, главное, простым в сравнении с H.323. Впрочем, эти границы постепенно размываются: в своём сегодняшнем виде SIP так же сложен, как и H.323.

Так или иначе, кажется, что отрасль уже сделала свой выбор в пользу SIP (хотя позиции H.323 в операторской среде по-прежнему прочны). Выбор SIP консорциумом 3GPP (3G Partnership Project) в качестве фундамента для строительства сетей мобильной связи следующего поколения в ноябре 2000 года способствовал появлению сервисной архитектуры подсистемы IP-мультимедиа (IP Multimedia Subsystem, IMS). Протоколу SIP, который уже сегодня получил распространение в корпоративных и операторских сетях, уготовано центральное место в унифицированной модульной архитектуре сетей нового поколения (Next Generation Networks, NGN) – фактически то место, которое cистема сигнализации SS7 сегодня занимает в сетях TDM.

SIP предполагает простую (и, следовательно, хорошо масштабируемую) сеть с интеллектом, встроенным в конечные элементы (пользовательские агенты). Другими словами, функции SIP реализованы в конечных устройствах, в отличие от традиционных возможностей SS7, которые поддерживаются самой сетью. Протокол SIP по структуре напоминает протоколы HTTP и SMTP. Из HTTP он взял клиент-серверную архитектуру и использование URL и URI, а из SMTP – способ кодировки текста и стиль заголовков.

SIP ориентирован в первую очередь на взаимосвязи точка-точка, но поддерживает и режим многоадресной рассылки (multicast). Последний может использоваться для организации конференций, когда информация передается на один multicast-адрес, а затем доставляется сетью конечным адресатам. Другие два варианта организации конференций – соединение каждого пользователя с каждым в режиме точка-точка и соединение каждого пользователя с устройством управления конференцией.

Впрочем, «точка-точка» – это слегка идеализированный сценарий, возможный лишь в рамках одного домена. Типичная сеть SIP содержит и другие элементы: сервер регистрации, прокси-серверы, а иногда и сервер переадресации. SIP работает в среде IPv4 и IPv6 с использованием транспорта протоколов UDP, TCP, TLS или SCTP. Таблицы 1, 2 помогут читателю оценить различия архитектур SIP, H.323 и MGCP.

Таблица 1. Компоненты и сервисы протоколов сигнализации

Источник

Знакомимся с Session Initiation Protocol

Протокол SIP как основа функционирования нового сервера Microsoft RTC Server.

Чтобы получить представление о работе RTC Server и подобных ему продуктов, необходимо знать протокол, обеспечивающий функциональность сервера. Далее я представлю основные концепции работы и состав SIP.

Основы SIP

SIP — это сквозной (end-to-end) клиент-серверный протокол, который обеспечивает создание, изменение и завершение коммуникационных сессий с участием одного или большего числа пользователей. Коммуникационные сессии могут включать самые разные формы взаимодействия — в основном это точка-точка или групповая передача, — в том числе мультимедийные видеоконференции и телефонные разговоры. Участниками коммуникационных сессий могут быть люди (которые пользуются SIP-телефонами, а также клиенты видеоконференций) или автоматические компоненты (сервер-автоответчик, сервер ведения медиа-архивов).

Хотя телефонная индустрия дала толчок развитию SIP, протокол разрабатывался с целью совершенствования Internet-коммуникаций. Дополнительная информация о развитии протокола SIP приведена на врезке «Краткая история SIP».

Любая коммуникационная сессия, основанная на использовании SIP, подразумевает как минимум три действия и работу трех протоколов.

SIP описывается в IETF Request for Comments (RFC) 2543, который можно получить из хранилища IETF (http://www.ietf.org/rfc.html). До марта 1999 г. RFC 2543 не публиковался, поэтому рабочие группы IETF имели возможность применить концепции иных архитектур Internet-протоколов, которые были известны и уже хорошо себя зарекомендовали. В архитектуре SIP многие идеи позаимствованы из SMTP. Например, в SIP пользователи получают SIP-адреса (т. е. SIP URL), которые напоминают адреса SMTP (т. е. Mailto URL). В протоколе SIP заимствована также концепция HTTP. Информация о коммуникационной сессии, которая управляется SIP, напоминает то, что обычно представлено в HTTP. Например, SIP-пакет может выглядеть так, как показано на Экране 1. Из содержимого пакета видно, что пользователь George на компьютере gpc.yankees.com приглашает пользователя Jerry открыть сессию.

Экран 1. Пример запроса INVITE.

SIP предоставляет четыре ключевые функции. Две из них — Name Mapping And Redirection и Capabilities Negotiation — используются во время процедуры установления сессии.

Две другие функции — Participant Management и Capabilities Management — во время работы.

Name mapping and redirection. SIP транслирует информацию об описательных именах участников сессии (descriptive naming information) в информацию о размещении (location information) в соответствии со службами каталога и иными службами. SIP облегчает персональную мобильность участников, поэтому пользователи могут установить SIP-сессию, перемещаясь, например, со своего рабочего места с подключенным настольным компьютером в автомобиль, и объявляя, таким образом, мобильный телефон или PDA предпочтительным средством связи.

Capabilities negotiation. SIP определяет различные характеристики медиаданных всех участников сессии и оговаривает возможности медиасреды, которые будут использоваться во время сеанса связи. Например, если у двух участников сессии имеются видеовозможности, а третий располагает только аудиоаппаратурой, SIP устанавливает, что видеоданные могут использоваться в сессии, но для третьего участника будут передаваться только аудиоданные.

Participant management. Во время сеанса связи SIP позволяет участникам конференции приглашать новых участников, отключать или приостанавливать их работу.

Capabilities management. Во время сеанса связи SIP осуществляет мониторинг характеристик медиасреды и в случае необходимости выполняет корректировку настроек. Рассмотрим, например, сеанс связи с двумя участниками. У обоих имеются только аудиоустройства. Если новый участник подключается к конференции и у него имеется видеоаппаратура, SIP добавляет передачу видеоданных для нового участника конференции.

Компоненты SIP

SIP состоит из пяти компонентов: User Agent Client (UAC), User Agent Server (UAS), Proxy Server, Redirect Server и Registrar Server. UAC и UAS — компоненты, устанавливаемые на стороне клиента, тогда как службы proxy, редиректора и регистратора запускаются на сервере.

UAC представляет собой приложение, которое инициирует SIP-запрос для UAS. Сообщение SIP — это или запрос от UAC к UAS, или ответ UAS компоненту UAC. В оригинальной спецификации SIP описано шесть возможных типов запросов (или методов), которые может выдать UAC: INVITE, ACK, OPTIONS, BYE, CANCEL и REGISTER. Расширения SIP, описанные в RFC, определяют дополнительные методы — такие, как MESSAGE, INFO и NOTIFY. Например, метод SIP, показанный на Экране 1, демонстрирует использование метода INVITE и универсальный идентификатор ресурса — Request Uniform Resource Identifier (URI) sip:jerry@acme.com. Метод заканчивается указанием номера версии SIP.

Когда UAC инициирует SIP-сессию, он определяет протокол, порт и IP-адрес UAS, которому посылается запрос. При отсутствии любой информации о локально настроенном proxy-сервере (об этом подробнее чуть позже), UAC использует данные в URI запроса для определения маршрута SIP-запроса. Данный URI запроса всегда определяет хост, но не всегда — порт и протокол. Если хост через адрес IP указан явным образом, UAC пытается связаться с UAS по этому адресу. Если URI запроса специфицирует полностью определенное доменное имя Fully Qualified Domain Name (FQDN), UAC опрашивает службы DNS для разрешения имен, используя для этого ADDRESS, CNAME или другие данные в ресурсной записи. Реализация операционной системы, в которой размещен UAC, может поддерживать альтернативный механизм для определения имени хоста, например через локальные HOSTS-файлы, WINS, широковещательные пакеты; однако в RFC 2543 об их применении не упоминается. Так или иначе, если локальная операционная система определяет и возвращает имя хоста, UAC в дальнейшем использует это имя в сеансе SIP.

Если URI запроса указывает порт, UAC пытается установить соединение с UAS по этому порту. Если URI запроса не указывает порт, UAC соединяется с UDP-портом 5060 по умолчанию. Если URI запроса указывает транспортный протокол (TCP или UDP), UAC использует его. Если URI запроса не указывает транспортный протокол, UAC пытается применить UDP; в случае ошибки UAC пытается задействовать TCP.

Если в запросе INVITE указан порт и протокол, то запрос может выглядеть следующим образом:

Однако чаще всего приложения используют укороченный формат (указывается только имя хоста), пример приведен на Рисунке 1.

UAS представляет собой приложение, которое получает SIP-запросы от UAC и отвечает на эти запросы. UAS может взаимодействовать с пользователем, поэтому вместе с запросом SIP пользователь иногда в той или иной форме получает уведомление от UAS.

Так же, как и статус-код HTTP, ответ SIP состоит из трехзначного целого кода возврата и текста. Результирующие SIP-коды распадаются на шесть категорий: 1xx (информационное сообщение), 2xx (успех), 3xx (перенаправление), 4xx (ошибка клиента), 5xx (ошибка сервера) и 6xx (глобальный сбой). В Section 7 в RFC 2543 результирующие коды расписаны полностью.

Какова бы ни была природа запроса UAC и итоговое действие UAS, последний посылает UAC ответ. UAS выдает более одного ответа на запрос. Например, когда UAC выдает запрос INVITE участникам конференции, UAS в ответ может послать UAC-инициатору запроса три ответа. Транзакция SIP считается полностью завершенной только тогда, когда UAS исчерпывающе ответил на инициирующий запрос. UAC выдает финальный запрос, в котором используется метод ACK, для получения подтверждения, что на запрос INVITE был дан финальный ответ. Запрос ACK UAC использует только в связке с запросом INVITE — это единственный случай применения ACK.

Поскольку SIP — это одновременно и протокол точка-точка, и клиент-серверный протокол, оконечная точка SIP должна быть способна отвечать на запросы сессии SIP и инициировать их. Следовательно, оконечная точка должна обладать функциональностью и UAS, и UAC. Пользовательский агент UA именно таков — в нем присутствует функциональность UAC и UAS. Для UA существует также другое название — SIP-клиент.

Proxy-сервер

До сих пор мы рассматривали ситуацию, когда соединение UAC и UAS устанавливалось как точка-точка, хотя, строго говоря, данный механизм — клиент-серверный. Однако наличие proxy-серверов в SIP-реализациях — общее правило. Proxy-сервер действует как посредник, который обслуживает запросы и пересылает их дальше — к другим UAC или UAS. По такой методике пользовательский UA маршрутизирует все свои SIP-транзакции через явным образом указанный proxy-сервер. На Экране 2 показан типичный пример внутриорганизационной конфигурации, когда пользователь, инициируя SIP-сессию с другим пользователем внутри той же организации, посылает сообщения по определенному маршруту через proxy-сервер до того, как эти сообщения достигнут целевого SIP-клиента.

Экран 2. Типичная внутриорганизационная конфигурация proxy-сервера.

Такая внутриорганизационная архитектура может быть расширена до межорганизационной. На Экране 3 показана межорганизационная, или федеративная, архитектура. Пользователи в каждой организации имеют собственные UA, настроенные на соответствующий proxy-сервер, а proxy в свою очередь взаимодействуют друг с другом для рассылки сообщений.

Еще один аргумент в пользу применения proxy — это преобразование имен. В случае использования почтовых служб пользователи нередко имеют адрес, который известен внешним клиентам, и внутренний адрес — для корпоративной переписки. Похожая концепция имеет место и для SIP. Proxy-сервер посылает запрос на локализацию службы, скажем Lightweight Directory Access Protocol (LDAP) Directory Service, и преобразует внешний SIP-адрес во внутренний.

В дополнение к показанной федеративной архитектуре, на Экране 3 изображено взаимодействие между компонентами SIP, когда задействованы службы преобразования имен. Когда proxy-сервер Acme получает запрос INVITE, сервер «консультируется» с соответствующей службой для выполнения в случае необходимости преобразования имени. В приведенном примере Proxy Acme предлагает адрес jerry@acme.com, а служба размещения (location service) возвращает внутренний SIP-адрес в виде js@nyc.acme.com.

Реализация службы размещения никоим образом не завязана на спецификацию SIP. Аналогично и SIP не диктует правила взаимодействия между proxy-сервером и службой размещения. Можно использовать службу размещения, а можно и не использовать. Если решено это делать, то предстоит выбрать тип службы. RTC Server задействует собственную службу размещения (не Active Directory).

В случае необходимости служба размещения может использовать множество SIP-адресов пользователей. Например, несколько SIP-адресов может понадобиться в том случае, когда получатель регистрируется в нескольких местах (с разных телефонов и компьютерных терминалов). Когда служба размещения возвращает несколько SIP-адресов, proxy предоставляет запрос INVITE каждому идентифицированному UAS. Серверы proxy пытаются опросить SIP-адрес в последовательном или параллельном режиме до тех пор, пока соединение не будет установлено, отклонено или пользователь не окажется вне зоны обслуживания.

Когда proxy-сервер пересылает SIP-запрос, он добавляет свое имя (имя сервера) в начало списка Forwarders в поле Via в заголовке SIP-сообщения. Это поле позволяет возвращать ответы по тому же маршруту, по которому проходил запрос. На «обратном» пути каждый proxy-сервер удаляет свое имя из поля Via после обработки SIP-ответа.

Redirect Server

Одна из основных задач SIP — перенаправление запросов. Перенаправление дает пользователям возможность перемещаться, но по-прежнему быть на связи, имея тот же самый SIP-идентификатор. Например, если пользователь jerry@acme.com покинул офис и зарегистрировался с данным SIP-идентификатором в отеле, в котором остановился, SIP-сообщения, пришедшие на адрес jerry@acme.com, будут, в конце концов, маршрутизированы на адрес: room1206@la.hyatt.com.

В подобных ситуациях, учитывая тот факт, что на proxy-сервере имеется «привязка» оригинального сообщения SIP к новому адресу SIP, имеет место не совсем оптимальное отслеживание сетевого маршрута. Вместо этого, хорошо было бы иметь сервер-редиректор Acme, который сообщит вызывающей программе, что для установления контакта с получателем нужно использовать другой SIP-адрес. В этом случае серверу-редиректору необходимо предоставить доступ к службе размещения для пользователей Acme, как показано на Экране 4.

После того как proxy-сервер получает инициирующий запрос INVITE, сервер посылает запрос серверу-редиректору. Сервер-редиректор взаимодействует со службой размещения, получает новые данные о временных адресах и возвращает ответ SIP/2.0 300 Moved Temporarily. Поле Contact содержит временный адрес. Оригинальная вызывающая программа повторно выдает INVITE, но на этот раз с указанием временного адреса. Чтобы транзакция была выполнена полностью, вызывающая программа выдает запрос ACK серверу-редиректору. (На Экране 4 этот последний шаг не показан.)

Хотя proxy и редиректор — это разные компоненты, RTC Server реализует их в составе единого сервера. Сервер, который сочетает в себе функции того и другого, носит название SIP-сервер. Настройки SIP-сервера устанавливают, как будут обрабатываться сообщения SIP для различных получателей (т. е. определяют, будет сообщение направлено proxy-серверу или серверу-редиректору).

Registrar Server

Пользователи могут информировать proxy-сервер или сервер-редиректор, по какому адресу следует обращаться для установления сеанса связи. Когда пользователю понадобится изменить адрес, SIP-клиент выдает запрос REGISTER. Сервер-распорядитель (Registrar Server) принимает REGISTER и записывает содержащуюся в запросе обновленную информацию. Обычно SIP-сервер использует эти данные для передачи службе локализации, которая направляет запрос на правильный адрес.

Клиенты SIP могут контактировать с Registrar Server двумя способами. Они могут напрямую обращаться к серверу, используя данные об адресах в настройках клиента. Или обращение может быть опосредованным — с помощью широковещательного адреса sip.mcast.net (224.0.1.75). При этом запрос регистрации направляется на группу All SIP Servers. SIP-серверы «слушают» обращения по указанному адресу и соответствующим образом обрабатывают поступившие запросы SIP REGISTER.

Экран 5. Пример запроса REGISTER.

На Экране 5 показан пример запроса REGISTER. URI запроса специфицирует назначение запроса REGISTER (читайте — Registrar Server) и должен включать только данные об имени хоста и домена — в нем не может содержаться имя пользователя. Поле To идентифицирует адрес SIP пользователя, который будет регистрироваться. Когда пользователь выполняет собственно регистрацию, данные об адресах в поле To и From обычно соответствуют друг другу. Если имеет место регистрация у независимого разработчика (а в этом случае процедура может выполняться с учетом каких-либо иных характеристик пользователя), поле From содержит SIP-адрес данного разработчика.

Хотя это и не всегда требуется, запрос REGISTER может включать поле Contact. На примере Экрана 5 видно, что адрес в поле Contact отличается от адреса в поле To. Тогда proxy-сервер или редиректор в дальнейшем станут направлять запросы пользователя, указанного в поле To, по адресу, заданному в поле Contact.

Поле Expires указывает время жизни запроса регистрации в секундах.

В приведенном примере запрос REGISTER перестает быть актуальным через 12 ч. Однако если клиент не указал значение этого параметра, серверы SIP, как правило, регистрируют пользователя на 1 ч. Пользователь имеет право отменить регистрацию, повторно выдав запрос REGISTER с указанием времени жизни 0 с.

Точно так же, как на одном SIP-сервере можно объединить функции proxy-сервера и редиректора, можно добавить на тот же самый сервер функцию регистратора. Сервер RTC воплощает функции proxy, редиректора и регистратора на одном сервере SIP.

Итак, я изложил концепцию SIP, как она представлена в RFC 2543. Перед тем как рассматривать конкретные способы реализации SIP, необходимо ясно себе представлять принципы работы SIP. В одной из следующих статей будет рассказано о том, как работают и взаимодействуют продукты SIP Client (Windows Messenger) и SIP Server (RTC Server) производства компании Microsoft.

Компоновка сервера RTC

Однако разработчики Microsoft пересмотрели свои планы относительно распространения RTC Server и решили компоновать его независимо. На мой взгляд, такое изменение планов не связано со стремлением увеличить доходы корпорации. Ко времени написания статьи лицензионная политика еще не была установлена. Очевидно, однако, что теперь нет никакой возможности воспользоваться лицензией Client Access License (CAL) в качестве платы за доступ к RTC Server. Изменение компоновки теоретически означает большую гибкость при формировании RTC-среды.

Краткая история SIP

Session Initiation Protocol (SIP) не без оснований следует отнести скорее к телефонной индустрии, нежели к компьютерной. Телефонная индустрия дала начало SIP с целью улучшить обслуживание абонентов, но очень быстро специалисты-компьютерщики адаптировали SIP в качестве протокола, с помощью которого можно было упростить все виды связи в масштабе реального времени. То, что раньше было в сфере влияния обычной телефонии, с появлением Internet-коммуникаций перестало быть таковым.

Проект, который со временем стал стандартом SIP, был начат в феврале 1996 г. Самый первый проект IETF, озаглавленный Draft-Ietf-Mmusic-Sip-00, состоял только из одного типа запросов — запроса на установление соединения, Call Setup Request. Между прочим, mmusic — это не название новой поп-группы, это акроним Multiparty Multimedia Session Control. Исправления оригинального проекта привели к опубликованию в декабре 1996 г. Draft-Ietf-Mmusic-Sip-01. По-прежнему для большинства пользователей эта версия проекта оставалась неизвестной, как и ее предшественница. Спустя восемь исправлений и три года работы проект был оформлен как протокол SIP, и теперь пользователи с ним хорошо знакомы. IETF опубликовал проект под названием Draft-Ietf-Mmusic-Sip-12 в январе 1999 г.

На этот раз он содержал уже шесть типов запросов, число которых не изменилось и по сей день. С момента публикации Draft-Ietf-Mmusic-Sip-12 до RFC 2543, посвященного SIP и появившегося в марте 1999 г., произошло очень немного изменений.

На протяжении последних лет SIP продолжал изменяться. Еще важнее то обстоятельство, что появились новые рабочие группы, которые надеются получить от использования SIP определенные преимущества. Наиболее известная группа — SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE) Working Group. Эта группа расширила оригинальную спецификацию SIP, и теперь в проект введено описание доставки данных Instant Messaging (IM) через запрос MESSAGE Request. Первоначально этот запрос представлял собой механизм, с помощью которого в сервере Microsoft Real Time Communications (RTC) были реализованы функции IM.

Поделитесь материалом с коллегами и друзьями

Источник

• ← Фикус бенджамина желтеют и опадают листья что делать летом
• Фелодип для чего назначают →