По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Одним из важных компонентов установления соединения по протоколу SIP является протокол Session Description Protocol, или сокращенно SDP.
О протоколе SDP впервые заговорили в 1998 году в рамках опубликованного RFC2327. Спустя 8 лет, в 2006 году протокол претерпел некоторые изменения, которые были отображены в RFC4566.
Протокол SDP используется для установления соединения и согласования параметров передачи и приема аудио или видео потоков между оконечными устройствами. Наиболее важными параметрами обмена являются IP – адреса, номера портов и кодеки. Давайте разбираться?
Пример SDP
При установлении сессии SDP параметры передаются в рамках SIP – запросов. Давайте взглянем на один из таких запросов. В данном случае распарсим SIP INVITE, который прилетело на нашу IP – АТС Asterisk с помощью утилиты sngrep:
INVITE sip:74996491913@192.168.x.xxx:5061;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 80.xx.yy.zz:5060;branch=z9hG4bK-524287-1-MThkZjMzNzMyXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX;rport
Via: SIP/2.0/UDP 80.xx.yy.zz:5077;branch=z9hG4bK-XXXXXXXXXXXXXXXX;rport=5077
Max-Forwards: 69
Record-Route: <sip:80.xx.yy.zz:5060;lr;transport=UDP>
Contact: <sip:80.xx.yy.zz:5077>
To: <sip:74996491913@80.xx.yy.zz>
From: <sip:7925XXXXXXX@80.xx.yy.zz>;tag=qdpxhe2avyyjcqfn.o
Call-ID: fb9909e8fYYYYYYYYYYYYYYYYYYYYYY
CSeq: 479 INVITE
Expires: 300
Allow: INVITE, ACK, BYE, CANCEL, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS, UPDATE
Content-Disposition: session
Content-Type: application/sdp
User-Agent: Sippy
P-Asserted-Identity: <sip:7925XXXXXXX@80.xx.yy.zz>
Remote-Party-ID: <sip:7925XXXXXXX@80.xx.yy.zz>;party=calling
h323-conf-id: 4133864240-4217115111-2706418710-XXXXXXXXX
Portasip-3264-action: offer 1
cisco-GUID: 4133864240-4217115111-2706418710-XXXXXXXXX
Content-Length: 278
v=0
o=Sippy 1011212504475793896 1 IN IP4 80.xx.yy.zz
s=-
c=IN IP4 80.xx.yy.zz
t=0 0
m=audio 57028 RTP/AVP 0 8 18 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
В приведенном примере можно увидеть, что основная часть SIP – сообщения отделена от SDP сегмента пустой строкой. Помимо прочего, поле Content-Type, что сообщение сопоставимо с SDP параметрами.
Про SDP поля
Каждый из параметров SDP сообщения можно отнести к одной из следующих категорий:
Имя сессии;
Время, в течении которого сессия активна;
Параметры медиа;
Информация о пропускной способности;
Контактная информация;
Поговорим об основных параметрах. Они всегда имеют следующее обозначение: <поле> = <значение>. Поле всегда обозначается 1 буквой.
Поле
Значение
Формат
v=
версия протокола
v=0
o=
инициатор сессии и соответствующие идентификаторы
o=<имя_пользователя> <идентификатор_сессии> <версия> <тип_сети> <тип_адреса> <адрес>. В нашем примере поле o=Sippy 1011212504475793896 1 IN IP4 80.xx.yy.zz (IN - тип сети, интернет, IP4 - тип адреса, IPv4;
s=
имя сессии
в нашем примере прочерк ("-"), имя сессии не указано;
c=
информация о подключении;
Синтаксис таков: c=<тип_сети> <тип_адреса> <адрес>. В нашем примере IN IP4 80.xx.yy.zz. Параметры IN/IP4 объяснены выше.
t=
время активности сессии
Синтаксис поля таков: t=<начальное_время> <конечное_время>. Это обязательное поле, но важно отметить, что оно весьма субъективно, так как невозможно предсказать точное время начала и окончания. В нашем примере t=0 0
m=
тип передачи медиа данных, формат и адресация
m=<тип_медиа> <порт> <транспорт> <формат_передачи>. Давайте разберемся - у нас m=audio 57028 RTP/AVP 0 8 18 101, это означает передачу аудио (может быть значение video, или передача обоих типов), порт передачи обозначен как 57028, транспорт, указанный как RTP/AVP, означает передачу по протоколу RTP в рамках стандарта Audio and Video Conferences with Minimal Control, который описан в RFC3551. После, первый 0 означает протокол G.711 uLaw, 8 означает G.711 ALaw, 18 означает G.729. То есть условно говоря, нам предложено предпочтение кодеков сначала G.711 uLaw, затем G.711 ALaw, и третьим приоритетом G.729. 101 означает поддержку динамического типа данных, например DTMF.
a=
параметры сессии
a=<параметр> или a=<параметр><значение>. SDP сессия может содержать несколько дополнительных атрибутов передачи. Более подробно мы рассмотрим далее.
Помимо указанных параметров, зачастую встречаются такие как k=, в рамках которого описывается метод шифрования, или i=, содержащий дополнительную информацию о сессии. Поговорим про параметры поля a=:
Параметр
Синтаксис и описание
rtpmap
a=rtpmap:<тип> <название_кодировки>/<частота_дискретизации> [/<параметры_кодирования>].
Данный параметр подсказывает имена кодеков, частоту и прочие параметры кодирования для данных, обозначенных в параметре m=. Например, у нас a=rtpmap:0 PCMU/8000, означает использование G.711 с импульсно - кодовой модуляцией по U - закону с частотой дискретизации 8000 Гц.
sendrecv
a=sendrecv
Данный параметр указывает на то, что мы собираемся отправлять и получать медиа - данные. Например, возможно опция отправки (sendonly), только получение (recvonly) и отключения медиа (inactive);
ptime
a=ptime:<длительность_пакета>
Продолжительность RTP - пакет (в миллисекундах). Условно говоря, какой длительности фрагмент голоса переносит один RTP - пакет;
fmtp
a=fmtp:<формат> <специальные_параметры>
Параметр описывает дополнительные параметры сессии, например, такие как режим подавления тишины (VAD) и прочие;
Привет друг! В нашей прошлой статье, мы назвали 10 причин , почему IP-телефония и технология VoIP в целом – это круто. А сейчас, предлагаем тебе взглянуть на обратную сторону медали. У каждой технологии есть свои недостатки, уязвимости и ограничения и VoIP – не исключение. Итак, мы нашли для тебя целых 9 причин, почему VoIP – это отстой. Поехали!
!
Проблемы с NAT
Сигнальные протоколы SIP и H.323 работают, обмениваясь сообщениями с сервером IP-телефонии. Пользователь, который совершает звонок и пользователь, который принимает его, могут находиться в разных сетях за NATирующими устройствами. Несмотря на это, VoIP трафик может дойти до сервера, и пользователи услышат звонок, после того как параметры вызова будут полностью согласованы. Как только пользователь, принимающий звонок, поднимет трубку в дело вступает медиа протокол - RTP, который будет отправлять пакеты на внутренний адрес удалённого телефона (так как именно внутренний адрес будет указан в предшествующих SIP/H.323 заголовках), вместо того, чтобы отправлять их на правильный NATируемый адрес. Но даже если RTP пакеты будут отправляться на правильный NATируемый IP-адрес, большинство межсетевых экранов, особенно без соответствующей настройки, будут выкидывать такие пакеты. Так что, если решили внедрять IP-телефонию и у Вас есть удалённые сотрудники или филиалы, будьте готовы разбираться в теории NAT и правильно настраивать Firewall.
Проблемы с качеством связи
Сети с коммутацией каналов (ТФоП) гарантируют отличное качество передаваемой аудио-информации, поскольку не делят среду передачи с другими сервисами. IP-телефония, как правило пересекается с другим пользовательским трафиком, таким как почта и интернет. Поэтому, чтобы достичь такого же хорошего качества голоса при использовании IP-телефонии, зачастую приходится правильно настраивать приоритизацию трафика или даже обновлять имеющуюся инфраструктуру.
Определение местоположения звонящего
В случае с сетями с коммутацией каналов, информация о местоположении абонента записывается всего раз при непосредственном предоставлении абоненту сервиса и изменяется только в том случае, если он перемещается, при этом номер за ним сохраняется. В случае с сетями подвижной сотовой связи, информация о местоположении абонента может быть определена при помощи метода триангуляции по имеющимся координатам базовых станций (мобильных вышек) или при помощи GPS координат, которые сообщает мобильный телефон абонента. В сетях VoIP нет простого способа определения местоположения звонящего, чем очень часто пользуются всякие мошенники, вымогатели, тролли и другие сомнительные личности. Кто-то может подумать, что это и хорошо – зачем кому-то давать возможность узнать Ваше местоположение? Но подумайте о безопасности своей и своих сотрудников. В случае звонка на номер экстренных служб в чрезвычайной ситуации, они также не смогут определить где находится звонящий, а это может стоить кому-то жизни.
Подмена CallerID и доступ к приватным данным
CallerID (CID) – это информация о номере звонящего абонента. Многие организации используют эту информацию, чтобы определить стоит ли принимать звонок с того или иного номера или же нет. В случае с телефонной сетью общего пользования, данную информацию сообщает домашняя сеть абонента. В VoIP сетях – CID настраивается администратором VoIP-сервера. Администратором может быть, как честный провайдер VoIP телефонии, так и злоумышленник, желающий выдать себя за кого-либо другого, подменив свой номер (CID).
Кроме того, поскольку информация о номере (CID) передаётся в процессе согласования параметров будущего SIP или H.323 соединения, её можно перехватить, используя специальные программы, такие как Ethereal, tcpdump и Wireshark. Поэтому даже если Ваш провайдер скрывает ваш CID, его всё равно можно узнать, проанализировав перехваченный трафик соединения.
Интерфейс телефонов
IP-телефоны, зачастую, имеют очень скудный интерфейс, который лимитирует возможность задания пароля только циферными значениями, вместо надежного пароля на основе всего набора символов ASCII. Кроме того, многие организации пренебрегают безопасностью и делают пароль, совпадающий с внутренним номером сотрудника. (ext: 3054, secret: 3054). Не трудно догадаться, что злоумышленник, получивший доступ к телефону, в первую очередь попробует угадать пароль и введёт в качестве него внутренний номер, соответствующего телефона.
Атака при SIP аутентификации
В процессе аутентификации по протоколу SIP, пароли передаются не в виде открытого текста, а в виде хэш-сумм этих паролей, посчитанных по алгоритму MD5. Злоумышленник может перехватить трафик и в оффлайн режиме воспользоваться словарями для расшифровки хэшей, для получения пароля. Опять же, если вы используете слабые пароли, такие как цифры внутреннего номера сотрудника, то на расшифровку подобных хэшей уйдут миллисекунды.
Перехват переговоров
Кстати, перехватить RTP трафик тоже несложно, а именно в RTP пакетах содержится голосовая информация, то есть то, что Вы говорите. Захватив достаточно RTP трафика, можно декодировать его и послушать о чём же был разговор.
DoS атака (отказ обслуживания) по протоколу SIP
Из-за того, что протокол SIP использует в качестве транспортного протокол UDP, который не устанавливает предварительных сессий, злоумышленник может “скрафтить” SIP пакеты и забросать ими сервер IP-телефонии. Например, он может закидать сервер пакетами типа SIP CANCEL, что заставит его прервать все текущие звонки.
Уязвимости ПО
VoIP сервера, телефоны, шлюзы и софтфоны – это решения, которые содержат то или иное программное обеспечение. Всевозможные CУБД, языки программирования, программные коннекторы, интерпретаторы, модули, операционные системы – во всём этом постоянно находят критичные уязвимости, а информация об этих уязвимостях публикуется в открытых источниках Если Вы используете старое программное обеспечение, не следите и регулярно не обновляете его, то рискуете стать жертвой злоумышленников, которые знают об этих уязвимостях и умеют их использовать.
Давайте для начала разберемся, что же такое контроль версий? Системой контроля версий является программный продукт, который запоминает все ваши модификации данных и, при необходимости, позволяет выполнить откат. А также дополнительной функцией является возможность определить, кто внес различные изменения в документ.
Конечно, все знакомы с этой проблемой при работе с проектом, когда возникает возможность добавить изменения, но для этого необходимо создать огромное количество папок с разными метками. Через некоторое время количество папок становится большим, особенно плохо следить за документами, если над ними трудится целая команда.
Для того, чтобы устранить таковые трудности, большинство программистов стали использовать систему контроля версий, с помощью нее удобно следить за проектом как командно, так и индивидуально. С представленной системой программист способен отслеживать различные модификации документов, добавлять и объединять ветви проектов, а также выполнять сброс документа до определенных моментов. Репозиторий считается главным определением VCS - это специальное выделенное хранилище, на котором хранится информация о файлах, также с помощью хранилища возможно наблюдать за модификацией данных.
Основные группы
На сегодняшний день существует две группы VCS: распределенные и централизованные. Давайте перейдем к более подробному описанию каждой группы ниже.
Централизованные
Представленные системы являются клиент-серверным программным обеспечением, что означает, что данные проекта находятся в единственном образце на сервере. Пользователи имеют доступ к файлам через специальный программный продукт, например, вы можете выбрать CVS, Subversion.
CVS (система одновременных версий) - одна из первых систем, которая приобрела большую популярность среди многих разработчиков. Сегодня представленный программный продукт более не развивается, поскольку имеет несколько важных недостатков: невозможно изменить имя файла, плохое хранение данных, отсутствует контроль целостности.
Subversion (SVN) - эта система контроля версий заменила описанный выше CVS в 2004 году и по сегодняшний день активно используется разработчиками. Несмотря на большое количество преимуществ CVS, у SVN есть некоторые недостатки: невозможно удалить данные из репозитория, проблемы с изменением имени, трудности в слиянии ветвей.
Распределенные системы контроля версий
С помощью этих систем контроля версий каждый разработчик может сохранить копию проекта. У них также есть общее центральное хранилище, которое уже содержит изменения, отправленные из сохраненных копий разработчиков, и они уже синхронизируется. Когда пользователи работают с распределенными системами контроля версий, они обычно синхронизируют свою копию с центральным репозиторием и вносят любые изменения в свой локальный репозиторий.
Есть несколько преимуществ таких систем:
Автономность программиста при работе над проектами.
Повышенная надежность.
Гибкость всей системы.
Все эти преимущества получены благодаря локальной копии центрального хранилища. Мы можем выделить наиболее известные DVCS - это Git и Mercurial.
Mercurial >представляет собой свободную систему, в которой не существует центральное хранилище. Ради комфортного использованию существует специальное консольное программное обеспечение под названием Hg. Представленные VCS обладает всеми основными функциями: объединение, ветвление, синхронизация. Данная система выполнена на языке программирования питон, за счет чего имеет возможность использоваться на всех современных ОС.
Git - представляет собой распределенную систему контроля версий, предназначенная для использования на ОС Linux. Мы также можем выделить несколько популярных компаний, которые используют VCS Git - Qt, Линукс, Андроид. VCS по своему стандартному функционалу довольно похож на Mercurial, который описанный выше, но имеет ряд преимуществ (производительность) и довольно популярен среди разработчиков. Git является лидером системы контроля версий.