77225

Разработка SIP телефонии для операционной системы Google Android

Курсовая

Информатика, кибернетика и программирование

Целью курсовой работы является создание SIP клиента для мобильной операционной системы Android. С клиента необходимо иметь возможность совершать звонки по протоколу SIP, а также обычные GSM звонки.

Русский

2015-02-02

511.42 KB

14 чел.

САНКТ-ПЕТЕРБУРГСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ

МАТЕМАТИКО-МЕХАНИЧЕСКИЙ ФАКУЛЬТЕТ

КАФЕДРА СИСТЕМНОГО ПРОГРАММИРОВАНИЯ

Разработка SIP телефонии для операционной системы Google Android

Курсовая работа студента 444 группы

Малышева В.В.

Научный руководитель:      Сафонов В. О.

профессор каф. информатики

Санкт-Петербург

2009

  

Постановка задачи

     Целью курсовой работы является создание SIP клиента для мобильной операционной системы Android. С клиента необходимо иметь возможность совершать звонки по протоколу SIP, а также обычные GSM звонки. В приложении также должна быть гибкая система настроек, чтобы пользователь мог подобрать для себя оптимальный режим работы клиента. Приложение должно использовать для звонка входящее в состав Android приложение Dialer, позволяющее осуществлять GSM звонки. Также необходимо сделать приложение расширяемым, чтобы в дальнейшем можно было легко внедрять новый функционал взаимодействия с сервером. На рынке приложений для мобильной операционной системы Android SIP клиентов пока не существует, поэтому задача создания SIP телефонии является актуальной.

   Все поставленные задачи были успешно решены.

   

Описание приложения

   Приложение, далее именуемое “MC Client”, является приложением, позволяющим осуществлять телефонные звонки с использованием протокола SIP для Open Source операционной системы Google Android. С помощью данного приложения можно бесплатно общаться по протоколу SIP(описание протокола следует далее). MC Client ориентирован на использование точек доступа Wi-Fi. Когда пользователь заходит в приложение впервые, он вводит свои данные для SIP регистрации (такие, как адрес сервера, порт, имя пользователя и прочие регистрационные данные).

      Главное окно приложения                     Настройки(Settings)

                                 

Настройки соединения с сервером(SIP Settings)

                                                                                                                                                            

Далее, когда пользователь находится вблизи точки доступа Wi-Fi, идет автоматическая попытка соединения через найденную точку доступа. В случае успеха, пользователь регистрируется на сервере, который он указал в настройках.

Нотификация об успешной регистрации

Обмен сообщениями между клиентом и сервером происходит по протоколу SIP, в дальнейшем планируется применить TLS для шифрования трафика.  Медиапоток передается по протоколу RTP, в дальнейшем планируется шифровать этот поток, передавая его по протоколу SRTP(Secured RTP).

   MC Client очень тесно интегрируется со стандартным dialer (приложение для GSM звонков), находящемся в операционной системе Android. Происходит это следующим образом:

  1.  Пользователь запускает наше приложение и идет успешная регистрация на сервере
  2.  Пользователь запускает стандартный dialer системы и набирает некий номер

  1.  Он нажимает кнопку звонить
  2.  Это событие перехватывается и предлагается пользователю выбор

  1.  Позвонить по GSM(GSM call)

В этом случае идет стандартный звонок через Dialer по GSM, средствами           операционной системы Android. Т.е. все происходит так, как если бы наше      приложение ни на что не влияло

  1.  Позвонить по SIP(Enterprise Call)

 В этом случае, звонок, инициируемый dialer, - обрывается. Берется номер, набранный пользователем, и считается, что он набирал SIP адрес.

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

  1.  Визуально звонок выглядит одинаково для звонков GSM и SIP

     Дозвон до абонента                 Разговор с абонентом

                                       

   Результаты SIP звонков отображаются в логе dialer, как если бы пользователь говорил по GSM(кто звонил, сколько времени поговорил и прочая информация о разговоре)

   Возможно, на сервере будет некая база соответствия телефонных номеров и SIP номеров. Т.е. пользователь набирает GSM номер, посылает его по SIP, сервер берет этот GSM номер, превращает его в SIP номер с помощью своей базы и звонит по этому SIP номеру. А возможно этой базы и не будет, и пользователь сам должен знать и GSM номер и SIP номер человека, которому он хочет позвонить. И должен будет сам думать перед звонком, по какому типу связи он хочет звонить, GSM или SIP и вводить соответствующий номер.

Архитектура приложения MC Client

   Activity – это визуальный пользовательский интерфейс. Например, это список элементов меню, которые пользователь может выбирать. Всегда есть activity переднего плана и activities заднего плана. Когда создается новая activity, она выходит на передний план, смещая на задний план ту, которая раньше была передним планом. При уничтожении activity переднего плана, на передний план выходит первая в очереди заднего плана. Если системе будет не хватать ресурсов, то самые ненужные из activity заднего плана (система сама устанавливает критерии ненужности) будут уничтожены.  Каждая activity живет в собственном процессе.

   Service – не имеет визуального пользовательского интерфейса и работает в заднем плане в течение неопределенного времени. Например, сервис может играть музыку, в то время как пользователь может использовать браузер.  Пользователь не видит списка песен и состояния проигрывания, однако музыку он слышит. Каждый сервис живет в собственном процессе.

   Так как activity и сервис живут в разных процессах, то нельзя напрямую обращаться к сервису из activity (иначе activity будет ждать окончания действий сервиса и не будет реагировать на действия пользователя). Для разрешения этой ситуации существует специальное понятие ServiceWrapper. Он является посредником между сервисом и activity и связывает их. Происходит это следующим образом: при создании activity нужно создать в ней ServiceWrapper и установить связывание между ServiceWrapper и сервисом (которое является системным, т.е. система берет на себя такое связывание). Потом, все обращения к сервису идут через ServiceWrapper, вызывая его методы.  

   Сервис может вызвать создание новой Activity путем посыла соответствующего Intent сообщения,  которое ловится системой. Сам по себе Intent – это объект, который содержит в себе описание абстрактных операций, которые необходимо выполнить. Таким образом, мы можем посылать сообщения, которые потом ловятся системой Android, Android смотрит в манифест – файл (в котором описаны настройки приложения), если находит соответствие между activity и intent, то создает этот activity.

   SIPEngine – это классы, ответственные за передачу звука по протоколу SIP. (они уже существуют, поэтому разрабатывать их заново не надо, нужно было лишь адаптировать их под приложение). Там есть методы, позволяющие совершать звонки, а также реагировать на сообщения от сервера (такие как, успешный звонок, отвергнутый звонок, таймаут по времени соединения с сервером и т.д.).

   Сервис взаимодействует с SIPEngine тем, что вызывает его методы, связанные со звонком по SIP. Т.е. пользователь нажал кнопку позвонить, это событие было поймано в Activity, Activity передает через ServiceWrapper команду к сервису позвонить, а сервис обращается к SIPEngine с просьбой выполнить звонок.

Далее будут рассмотрены основные классы этих сущностей.

Activity

  Рассмотрим класс Sipdroid – главное окно(Activity) нашего приложения.

 getInstance()  – статический метод, который позволяет получить экземпляр класса    

              

onCreate(Bundle savedInstanceState) – самый первый метод, который вызывается при создании сущности

onDestroy() – последний метод, который вызывается при разрушении сущности

onCreateOptionsMenu(Menu menu) – метод, инициализирующий меню, появляющегося на нажатии на кнопку “Menu

onOptionsItemSelected(MenuItem item) – метод, который вызывается при нажатия на какую-то кнопку меню, созданную в onCreateOptionsMenu(Menu menu)

onSettingsMenuItemSelected()метод, используемый в onOptionsItemSelected(MenuItem item), обрабатывает нажатие на кнопку “Settings”

onHideMenuItemSelected() - метод, используемый в onOptionsItemSelected(MenuItem item), обрабатывает нажатие на кнопку “Hide”

onExitMenuItemSelected() - метод, используемый в onOptionsItemSelected(MenuItem item), обрабатывает нажатие на кнопку “Exit”

closeFromSipServiceListener()метод, который отсоединяет activity от сервиса

getConfig() – метод, который возвращает текущий конфиг – файл(в котором храняться все настройки пользователя)

reinitializeService() – перезапускает сервис.(убивает и создает заново)

isRegistered() – позволяет узнать, зарегистрированы ли мы сейчас или нет.

SipServiceWrapper

Есть два конструктора, в которых происходит связывание activity с сервисом на основе контекста activity.

unbind() – отсоединяет сервис от activity

start() – запускает сервис

stop() – останавливает сервис

getService() – получает получить экземпляр сервиса

getCallBeginTime() – вспомогательный метод, позволяет получить время начала разговора из сервиса

getCallElapsedTime() - вспомогательный метод, позволяет получить время разговора из сервиса

answerCall() - вспомогательный метод, позволяет у сервиса вызвать метод поднятия звонка

hangupCall() - вспомогательный метод, позволяет у сервиса вызвать метод сброса звонка

Service

getContext() – позволяет получить контекст сервиса

getInstance() – статический метод, позволяет получить экземпляр сервиса

loadConfig() – вызывается для инициализации конфига сервиса(берется из файла и засовывается в структуру UAConifig – класс, представляющий конфиг

onBind() – вызывается при связывании SipServiceWrapper

onStart(Intent intent, int startId) – вызывается при запуске сервиса

onCreate() - вызывается при создании экземпляра сервиса

onDestroy() - вызывается при убивании экземпляра сервиса

httpsRequestDone(int result) – связано с функцией CallBack. Смысл в следующем – формируется специальный https запрос, который содержит в себе имя пользователя, зашифрованный пароль, имя адресата, и этот запрос посылается на сервер. Сервер перезванивает адресату, который автоматически берет трубку, и соединяет с пользователем по GSM связи.

outgoingCallCaught(final String phone) – инициализация дозвона по телефону через SIP

answerIncomingCall() – ответ на входящий SIP вызов

hangUpCall() – повесить трубку текущего SIP звонка

fireStateChanged(final int state, final String result)оповещает всех о текущем состоянии звонка

Далее следует методы, которые выглядят как onUa*, - это callback методы из SipdroidEngine(смотреть их описание там), здесь идет только вызов метода fireStateChanged

showCallTypeSelector(String phone)показать диалог выбора(Enterprise Call, GSM Call)

wifiStateChanged(boolean on)оповещение об отключении Wi-fi

canRegister() – проверка на то, можем ли мы достучаться до сервера

SIPEngine

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

GetState() – получить текущее состояние разговора

StartEngine(UAConfig config) – запустить движок(прочитать конфиг из файла и прочее, связанное с посылкой SIP сообщений)

init() – вспомогательный метод, используется в StartEngine, инициализирует поля

reloadConfig(UAConfig config) – перезагрузить конфиг данным и выполнить init()

isServiceSteelRunning() – можем ли мы посылать сообщения серверу

getMyNumber() – получить номер клиента, под которым он зарегистрировался

getRealm() – получить адрес сервера, на котором произошла регистрация

register(int expire_time) – отослать запрос на сервер о регистрации.

loopRegister(int expire_time, int renew_time, long keepalive_time)посылать периодические сообщения о регистрации

unregister() – отсоединиться от сервера

isRegistered() – зарегистрированы ли мы в данный момент

isUnRegistered() – незарегистрированы ли мы в данный момент

onUaRegistrationSuccess(RegisterAgent ra, NameAddress target, NameAddress contact, String result)вызывается после подтверждения о регистрации от сервера

onUaRegistrationFailure(RegisterAgent ra, NameAddress target, NameAddress contact, String result) - вызывается после отказа о регистрации от сервера

listen() – перейти в режим прослушивания входящих звонков

isInCall() – находимся ли мы в звонке

call(String target_url) – совершить SIP звонок на номер

answercall() – ответить на входящий звонок

rejectcall() – отклонить входящий звонок

onUaCallIncoming(UserAgent ua, NameAddress callee, NameAddress caller, String contactUrl) – получено сообщение о входящем звонке

onUaCallRinging(UserAgent ua) – идет дозвон до абонента

onUaCallCancelled(UserAgent ua)вызов отклонен

onUaCallAccepted(UserAgent ua)вызов принят

onUaCallTrasferred(UserAgent ua) – звонок был передан по сети

onUaCallFailed(UserAgent ua) – в звонке было отказано или вышло время ожидания абонента

onUaCallClosed(UserAgent ua) – звонок был или локально или удаленно закрыт

StopEngine() – остановить движок. Очистить все ненужные объекты

getTransportString(short transport) – получить текстовое представление транспортного протокола, который используется

Протокол SIP

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

В модели взаимодействия открытых систем SIP является сетевым протоколом прикладного уровня.

Протокол описывает, каким образом клиентское приложение (например, MC Client) может запросить начала соединения у другого, возможно, физически удалённого клиента, находящегося в той же сети, используя его уникальное имя. Протокол определяет способ согласования между клиентами об открытии каналов обмена на основе других протоколов, которые могут использоваться для непосредственной передачи информации (например, RTP). Допускается добавление или удаление таких каналов в течение установленного сеанса, а также подключение и отключение дополнительных клиентов (то есть допускается участие в обмене более двух сторон — конференц-связь). Протокол также определяет порядок завершения сеанса.

Пример сети на базе протокола SIP.

Наряду с довольно сильно в настоящее время устаревшим H.323, SIP — один из протоколов, лежащих в основе Voice over IP(VoIP).

Принципы

В основе протокола лежат следующие принципы:

  1.  Простота: включает в себя только шесть методов (функций)
  2.  Независимость от транспортного уровня, может использовать UDP, TCP, ATM и т. д.
  3.  Персональная мобильность пользователей. Пользователи могут перемещаться в пределах сети без ограничений. Это достигается путем присвоения пользователю уникального идентификатора. При этом набор предоставляемых услуг остается неизменным. О своих перемещениях пользователь сообщает с помощью сообщения REGISTER.
  4.  Масштабируемость сети. Структура сети на базе протокола SIP позволяет легко ее расширять и увеличивать число элементов.
  5.  Расширяемость протокола. Протокол характеризуется возможностью дополнять его новыми функциями при появлении новых услуг.
  6.  Интеграция в стек существующих протоколов Интернет. Протокол SIP является частью глобальной архитектуры мультимедиа, разработанной комитетом IETF. Кроме SIP, эта архитектура включает в себя протоколы RSVP, RTP, RTSP,SDP.
  7.  Взаимодействие с другими протоколами сигнализации. Протокол SIP может быть использован совместно с другими протоколами IP-телефонии, протоколами ТфОП, и для связи с интеллектуальными сетями.

Дизайн протокола

Главной задачей разработки SIP было создание сигнального протокола и протокола установления соединений для IP коммуникаций, который может поддерживать расширенный набор функций обработки вызова и услуг, представленных в существующей ТфОП. Сам протокол SIP не определяет этих функций, а сосредоточен только на процедурах установления звонка и сигнализации. При этом он был спроектирован обеспечивать создание таких функций элементов сети, как Прокси-сервер (Proxy Servers) и Пользовательские Агенты (User Agents). При помощи этих элементов можно поддерживать базовые телефонные операции: набор номера, звонок телефонного аппарата, возможность после набора услышать длинные или короткие гудки.

SIP используется вместе с несколькими другими протоколами и участвует только в сигнальной части сессии связи. SIP исполняет роль носителя для SDP, который описывает параметры media-данных в рамках сессии, например используемые порты IP и кодеки. В типичном применении сессии SIP — это просто потоки пакетов RTP. RTP является непосредственным носителем голосовых и видеоданных.

Первая предложенная версия стандарта (SIP 2.0) была определена в RFC 2543. Протокол был дополнительно уточнён в RFC 3261, хотя многие реализации по-прежнему основаны на промежуточных версиях стандарта. Номер версии остался 2.0.

Адресация

Для организации взаимодействия с существующими приложениями IP-сетей и для обеспечения мобильности пользователей, SIP использует адрес, подобный адресу электронной почты. В качестве адресов рабочих станций используются универсальные указатели ресурсов URL, так называемые SIP URL:

  1.  имя@домен
  2.  имя@хост
  3.  имя@IP-адрес

Адрес состоит из двух частей. Первая часть — имя пользователя (может указываться в виде телефонного номера), зарегистрированного в домене или на рабочей станции. Вторая часть идентифицирует какой-либо шлюз по его доменному имени или IP-адресу.

В начале SIP-адреса ставится слово «sip:», указывающее, что это именно SIP-адрес, так как бывают и другие (например, «mailto:»).

Архитектура сети

Протокол SIP имеет клиент-серверную архитектуру.

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

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

Терминал

Когда клиент и сервер реализованы в оконечном оборудовании и взаимодействуют непосредственно с пользователем, они называются клиентом агента пользователя — User Agent Client (UAC) — и сервером агента пользователя — User Agent Server (UAS). Если в устройстве присутствуют и UAC, и UAS, то оно называется агентом пользователя — User Agent (UA), а по своей сути представляет собой терминальное оборудование SIP.

Сервер UAS и клиент UAC имеют возможность непосредственно взаимодействовать с пользователем. Другие клиенты и серверы SIP этого делать не могут.

Прокси-сервер

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

Предусмотрено два типа прокси-серверов

  1.  с сохранением состояний (stateful). Такой сервер хранит в своей памяти все полученные запросы и связанные с ним новые сформированные запросы до окончания транзакции.
  2.  без сохранения состояний(stateless). Такой сервер просто обрабатывает получаемые запросы. Но на его базе нельзя реализовать сложные, интеллектуальные услуги.

Сервер переадресации

Сервер переадресации используется для определения текущего местоположения пользователя. Сервер переадресации не терминирует вызовы и не инициирует собственные запросы, а только сообщает адрес необходимого терминала или прокси-сервера. Для этих целей он взаимодействует с сервером определения местоположения.

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

Сервер определения местоположения пользователей

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

Пользователь, которому нужна адресная информация не связывается с сервером определения местоположения напрямую. Эту функцию выполняют другие SIP-серверы при помощи протоколов LDAP, RWHOIS, или других протоколов.

Сообщения протокола SIP

Сообщения протокола SIP (запросы и ответы), представляют собой последовательности текстовых строк, закодированных в соответствии с документом RFC 2279. Структура и синтаксис сообщений SIP идентичны используемым в протоколе HTTP. Структура сообщений протокола SIP:

Стартовая строка

Заголовки

Пустая строка

Тело сообщения

  1.  Стартовая строка — начальная строка любого SIP-сообщения. Если сообщение является запросом, в ней указывается тип запроса, адресат и номер версии протокола. Если сообщение является ответом на запрос, в ней указывается номер версии протокола, тип ответа и его короткая расшифровка.
  2.  Заголовки сообщений содержат информацию, необходимую для обработки сообщения (информация об отправителе, адресате, пути следования и пр.)
  3.  Тело сообщения содержит описание сеансов связи. Не все запросы содержат тело сообщения (например запрос BYE). Все ответы могут содержать тело сообщения, но содержимое тела в них бывает разным.

Пример запроса INVITE:

INVITE sip:nikolia@zenit.chempion.spb.ru SIP/2.0

Record-Route: <sip:nikolia@10.0.0.10;lr>

Via: SIP/2.0/UDP 10.0.0.10;branch=z9hG4bK3af7.0a6e92f4.0

Via: SIP/2.0/UDP 192.168.0.2:5060;branch=z9hG4bK12ee92cb;rport=5060

From: "78128210000" <sip:78128210000@vladimir.spb.ru>;tag=as149b2d97

To: <sip:nikolia@zenit.chempion.spb.ru>

Contact: <sip:78128210000@vladimir.spb.ru>

Call-ID: 3cbf958e6f43d91905c3fa964a373dcb_zenit.chempion.spb.ru

CSeq: 103 INVITE

Max-Forwards: 16

Date: Wed, 10 Jan 2001 13:16:23 GMT

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY

Supported: replaces

Content-Type: application/sdp

Content-Length: 394

v=0

o=root 3303 3304 IN IP4 10.0.0.10

s=session

c=IN IP4 10.0.0.10

t=0 0

m=audio 40358 RTP/AVP 0 8 101

a=rtpmap:0 PCMU/8000

a=rtpmap:8 PCMA/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-16

a=silenceSupp:off - - - -

a=sendrecv

Запросы

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

  1.  INVITE — Приглашает пользователя к сеансу связи. Обычно содержит SDP-описание сеанса.
  2.  АСК — Подтверждает прием ответа на запрос INVITE.
  3.  BYE — Завершает сеанс связи. Может быть передан любой из сторон, участвующих в сеансе.
  4.  CANCEL — Отменяет обработку ранее переданных запросов, но не влияет на запросы, которые уже закончили обрабатываться.
  5.  REGISTER — Переносит адресную информацию для регистрации пользователя на сервере определения местоположения.
  6.  OPTION — Запрашивает информацию о функциональных возможностях терминала.

    Но в процессе развития, в протокол было добавлено еще несколько типов запросов, которые дополнили его функциональность:
  7.  PRACK - временное подтверждение (RFC 3262)
  8.  SUBSCRIBE - подписка на получение уведомлений о событии (RFC 3265)
  9.  NOTIFY - уведомление подписчика о событии (RFC 3265)
  10.  PUBLISH - публикация события на сервере (RFC 3903)
  11.  INFO - передача информации, которая не изменяет состояние сессии (RFC 2976)
  12.  REFER - запрос получателя о передаче запроса SIP (RFC 3515)
  13.  MESSAGE - передача мгновенных сообщений средствами SIP (RFC 3428)
  14.  UPDATE - модификация состояния сессии без изменения состояния диалога (RFC 3311)

Ответы на запросы

Ответы на запросы сообщают о результате обработки запроса, либо передают запрошенную информацию. Структуру ответов и их виды протокол SIP унаследовал от протокола HTTP. Определено шесть типов ответов, несущих разную функциональную нагрузку. Тип ответа кодируется трехзначным числом, самой важной является первая цифра, которая определяет класс ответа:

  1.  1ХХ — Информативные ответы показывают, что запрос находится в стадии обработки. Наиболее распространенные ответы данного типа 100 Trying180 Ringing183 Session Progress.
  2.  2ХХ — Финальные ответы означающие, что запрос был успешно обработан. В настоящее время в данном типе определён только один ответ — 200 OK.
  3.  3ХХ — Финальные ответы информирующие оборудование вызывающего пользователя о новом местоположении вызываемого пользователя, например ответ 302 Moved Temporary.
  4.  4ХХ — Финальные ответы информирующие об ошибке при обработке или выполнении запроса, например 403 Forbidden или классический для протокола HTTP, ответ 404 Not Found.
  5.  5ХХ — Финальные ответы информирующие о том, что запрос не может быть обработан из-за отказа сервера, 500 Server Internal Error.
  6.  6ХХ — Финальные ответы информирующие о том, что соединение с вызываемым пользователем установить невозможно, например ответ 603 Decline означает, что вызываемый пользователь отклонил входящий вызов.

Алгоритмы установления соединения

Протокол SIP определяет 3 основных сценария установления соединения: с участием прокси-сервера, с участием сервера переадресации и непосредственно между пользователями. Сценарии отличаются по тому, как осуществляется поиск и приглашение вызываемого пользователя. Основные алгоритмы установления соединения описаны в RFC 3665.

Сравнение с H.323

SIP пригоден для чтения человеком и структурирован в отношении запросов и откликов. Сторонники SIP также заявляют о нём как о более простом, по сравнению с H.323. Однако некоторые склонны считать, что, в то время как первоначально целью SIP была простота, в своём сегодняшнем виде он стал так же сложен, как и H.323. Другие считают, что SIP — протокол без состояний, который тем самым даёт легко реализовать восстановление при отказе и другие возможности, которые затруднены в протоколах с состояниями, таких как H.323. Этот аргумент приобрёл религиозный характер, но, судя по всему, SIP выиграл сражение, если не войну протоколов. SIP и H.323 не ограничены голосовой связью, они могут обслуживать любой сеанс связи, от голосового до видеосеанса или приложений будущего.

Параметр сравнения

SIP

H.323

Дополнительные услуги

Набор услуг, поддерживаемых обоими протоколами примерно одинаков

Персональная мобильность пользователей

Имеется хороший набор средств поддержки мобильности

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

Расширяемость протокола

Удобная расширяемость, простая совместимость с предыдущими версиями

Расширяемость поддерживается, но существует ряд сложностей

Масштабируемость сети

Оба протокола обеспечивают хорошую масштабируемость сети

Время установления соединения

Достаточно одной транзакции

Требуется несколько транзакций.

Сложность протокола

Простой, мало запросов, текстовый формат сообщений

Сложный, много запросов и протоколов, двоичное представление сообщений

Средства, используемые для реализации приложения

   Для реализации приложения используется Android SDK версии 1.1, предлагаемый компанией Google. Разработка ведется в среде Eclipse со специальным плагином для разработки приложений под операционную систему Android. В качестве языка программирования используется Java.

 


 

А также другие работы, которые могут Вас заинтересовать

50792. Повторение операторов цикла 31 KB
  Цель: Проверить уровень знаний по теме операторы цикла. 1. Напечатать столбиком: а) все целые числа от 20 до 35...
50793. Циклы с условием 32.5 KB
  Дано целое число N 0. Найти наименьшее целое положительное 2 число K квадрат которого превосходит N: K N. Дано целое число N 0. Найти наибольшее целое число K квадрат 2 которого не превосходит N: K N.