Sip айті бубон
Тим, хто збереться робити власну реалізацію протоколу SIP, стане в нагоді список RFC. описують протокол і його доповнення:
2543. Первісне опис SIP / 2.0
RFC 2976: передача інформації, що не змінює стан сесії (метод INFO)
RFC 2279: Повідомлення протоколу SIP (запити і відповіді)
RFC 3262: Розширення протоколу SIP: метод Provisional Response ACKnowledgement (PRACK) і тег 100rel
RFC 3263: пошук SIP серверів за допомогою DNS (записи SRV)
RFC 3311: Оновлення сесії без зміни діалогу (метод UPDATE)
RFC 3372: модифікація SIP-T (інтерконект ISUP - SIP)
RFC 3398: зіставлення параметрів ISUP і SIP (Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping)
RFC 3428: Розширення SIP для передачі миттєвих повідомлень (Instant Messaging) і метод MESSAGE
RFC 3515: метод REFER
RFC 3903: публікація події на сервері (метод PUBLISH)
RFC 4235: Пакет подій, ініційованих за INVITE (An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP))
RFC 4262: SIP Event Lists (SUBSCRIBE, NOTIFY, Presence)
RFC 5806: Diversion Indication in SIP
SIP- запити
Запити. У початковій версії протоколу SIP (RFC 3261) було визначено шість типів запитів. За допомогою запитів клієнт повідомляє про поточне місцезнаходження, запрошує користувачів взяти участь в сеансах зв'язку, модифікує вже встановлені сеанси, завершує їх і т. Д. Тип запиту вказується в стартовій рядку.
АСК - Підтверджує прийом відповіді на запит INVITE.
BYE - Завершує сеанс зв'язку. Може бути переданий будь-який зі сторін, що беруть участь в сеансі.
CANCEL - Скасовує обробку раніше переданих запитів, але не впливає на запити, які вже закінчили оброблятися.
Але в процесі розвитку, в протокол було додано ще кілька типів запитів, які доповнили його функціональність:
PRACK - тимчасове підтвердження (RFC 3262)
NOTIFY - повідомлення передплатника про подію (RFC 3265)
PUBLISH - публікація події на сервері (RFC 3903)
INFO - передача інформації, яка не змінює стан сесії (RFC 2976)
REFER - запит одержувача про передачу запиту SIP (RFC 3515)
MESSAGE - передача миттєвих повідомлень засобами SIP (RFC 3428)
UPDATE - модифікація стану сесії без зміни стану діалогу (RFC 3311)
У SIP підтримує функції messaging і presence. Перша забезпечує обмін в реальному часі короткими повідомленнями (як ICQ на ПК або SMS в мережах GSM), друга дозволяє визначати стан абонента, т. Е. На місці він, чи не зайнятий і т. Д. (В ICQ теж є така можливість ). Завдяки цим двом функціям SIP дозволяє реагувати на події, а також розсилати повідомлення "за подією".
між користувачами
в мережі підприємства
Гольдштейн Б.С. Зарубін А.А. Саморізів В.В. Протокол SIP. Глава 2.6. Процедури функціонування HTTP аутентифікації
md5 алгоритм на вході приймає будь-яку довжину символів і на виході видати 128-бітний відбиток (finger-print) або профіль повідомлення (message digest), яке було подано на вхід алгоритму. Гіпотетично вважається, що два повідомлення, які мають один і той же профіль повідомлення або вироблені будь-яким повідомленням, мають певний профіль повідомлення.
Message digest - коротка цифрова рядок фіксованої довжини, формується з довшого сполучення з використанням спеціального алгоритму. Алгоритм md5 призначений для цифрового підпису (digital signature) додатків, де великі файли повинні бути «стиснуті» в безпечний спосіб, до того як вони будуть закріптовани за допомогою публічного або прихованого ключа за допомогою криптосистеми з відкритим ключем, наприклад RSA. Digital signature - цифровий підпис, який є унікальним електронним ідентифікатором, що забезпечує перевірку повідомлення з встановленням автентичності відправника та гарантії те, що документ не був змінений з моменту підписання.
Варіант №1. Абонент: висилає сервера повідомлення із заголовком REGISTER. Якщо в налаштуваннях абонента не вказано secret, то цього достатньо, сервер надсилає відповідь SIP / 2.0 200 OK і процес реєстрації закінчується.
На третьому етапі абонент висилає сервера рядок в повідомленні REGISTER
Де параметр response - рядок, що складається з 32 шістнадцяткових розрядів і засвідчує, що користувачеві відомий пароль. Формується за допомогою застосування функції хешування до значень nonce, nc, cnonce, qop, uri, username, realm, типу запиту і паролю password. За замовчуванням хешування проводиться за алгоритмом MD5.
Варіант №3. Якщо використовується зовнішній сервер для аутентифікації (процедура перевірки справжності) по протоколу RADIUS. Сервер на запит REGISTER надсилає відповідь SIP / 2.0 407 Proxy Authentication Required - необхідна аутентифікація на проксі-сервері).