Передача повідомлень у режимі сторінок

1. Спосіб надсилання повідомлення режиму сторінок, який відрізняється тим, що включає: надсилання такого повідомлення з використанням механізму обміну повідомленнями у режимі сеансу з індикатором, який вказує, що для повідомлень режиму сторінок використовується механізм обміну повідомленнями у режимі сеансу; і обробку прийнятого повідомлення як повідомлення режиму сторінок у випадку наявності зазначеного індикатора. 2. Спосіб за п.1, який відрізняється тим, що додатково включає започаткування сеансу зв'язку для передачі і прийому повідомлення і припинення цього сеансу зв'язку у відповідь на завершення передачі повідомлення. 3. Спосіб за п.1, який відрізняється тим, що додатково включає започаткування сеансу зв'язку для передачі і прийому повідомлення і припинення цього сеансу зв'язку у відповідь на завершення прийому повідомлення. 4. Спосіб за будь-яким з попередніх пунктів, який відрізняється тим, що додатково включає використання протоколу опису сеансу зв'язку для започаткування сеансу зв'язку у механізмі обміну повідомленнями у режимі сеансу і додавання індикатора до заголовка повідомлення про започаткування сеансу зв'язку. 2 (19) 1 3 90144 4 наявності зазначеного індикатора перевіряти розмір повідомлення і приймати рішення продовжувати або припиняти механізм режиму сеансу, базуючись на цьому розмірі. 15. Термінал за п.11, 12, 13 або 14, який відрізняється тим, що його додатково пристосовано у випадку наявності зазначеного індикатора перевіряти розмір повідомлення і вимагати від користувача подальших інструкцій стосовно продовження або припинення механізму режиму сеансу, а також показувати користувачу цей розмір. 16. Термінал за п.11, 12, 13, 14 або 15, який відрізняється тим, що його додатково пристосовано продовжувати режим сеансу переадресуванням вимоги сеансу зв'язку, що стосується зазначеного повідомлення режиму сторінок. 17. Сервер, який забезпечує обмін повідомленнями режиму сторінок і обмін повідомленнями режиму сеансу, який відрізняється тим, що його пристосовано: виявляти індикацію того, що для повідомлень режиму сторінок використовується механізм обміну повідомленнями у режимі сеансу, і приймати на себе функції кінцевого пункту механізму обміну повідомленнями режиму сеансу у випадку наявності такої індикації. 18. Сервер за п.17, який відрізняється тим, що його додатково пристосовано обробляти прийняте повідомлення як повідомлення режиму сторінок у випадку наявності зазначеного індикатора. Винахід стосується передачі повідомлень, зокрема передачі повідомлень у режимі сторінок, яку називають також одноразовою передачею повідомлень. Розвиток технологій зв'язку, зокрема, базованих на Інтернет-протоколі, кінцевих користувацьких терміналів, дозволив упровадити гнучкі системи зв'язку і різноманітні послуги. Все частіше при наданні послуг використовуються примітиви, що забезпечуються SIP (Протокол Ініціювання Сеансу зв'язку ), який не вертикально інтегрований у систему зв'язку, але є інструментом для побудови мультимедійної архітектури. Точніше, SIP є визначеним у IETF (сигнальним) протоколом контролю рівня застосування для створення, модифікування і припинення сеансів зв'язку з одним або більше учасниками. Ці сеанси зв'язку включають, наприклад, телефонні зв'язки через Інтернет, розподілення мультимедій, мультимедійніх конференцій і сеансів зв'язку РоС (Переведення у розмови через стільникову систему). Для передачі повідомлень у IETF визначено застосування SIMPLE (SIP для Негайних Повідомлень і Наявності Засобів Поширення) з використанням SIP і існуючих застосувань SIP для забезпечення послуг з негайної передачі повідомлень. ОМА (Відкрита Спілка Мобільного зв'язку) також визначає помічник IМ (Негайна Передача повідомлень), базуючись на протоколах SIP/SIMPLE. SIMPLE визначає два режими негайного обміну повідомленнями: режим сторінок і режим сеансу. У режимі сторінок використовується метод SIP MESSAGE, згідно з яким режим сторінок передбачає негайну передачу повідомлення, а на протокольному рівні всі подальші негайні повідомлення не пов'язані з попереднім: кожне негайне повідомлення, навіть відповідь не попереднє повідомлення, розглядається як незалежна транзакція. Отже, метод SIP MESSAGE нагадує звичайну e-mail або обслуговування коротких повідомлень. Режим сеансу використовує SIP для передачі сигналів і встановлення сеансу зв'язку і MSRP (Протокол передачі Повідомлення про Сеанс зв'язку) для перенесення послідовності негайних повідомлень після встановлення сеансу зв'язку. Цю комбі націю далі названо механізмом MSRP, який забезпечує повідомлення у чаті, тобто повідомлення у режимі сеансу. Проблеми виникають, коли користувач бажає надіслати велике повідомлення у режимі сторінок. Метод SIP MESSAGE передбачає використання транспорту UDP або TCP. TCP є надійним методом транспортування також і для великих повідомлень, але TCP не завжди гарантований для SIP MESSAGE. Якщо для передачі великого повідомлення використовується UDP, пакети розміром більше за максимальний розмір UDP, фрагментуються і можуть прийти до реципієнта в іншому порядку. Крім того, навіть якщо TCP гарантовано, залишається проблема, пов'язана з контролем перевантаження. Оскільки метод SIP MESSAGE є частиною сигналів контролю сеанс зв'язку SIP, передача і прийом повідомлення здійснюються з використанням тих ресурсів, які використовуються при передачі сигналів SIP. Для користувацького терміналу це означає, що реальні сигнали SIP можуть бути блоковані на час передачі або прийому великого повідомлення у користувацькому терміналі. Згаданими вище ресурсами для сигналів SIP можуть бути загальні контекстні або спеціалізовані сигнали PDP (Протокол Пакетних Даних) у випадку, наприклад, систем GERAN (GSM/Мережа Радіодоступу EDGE) і/або KTRAN (Наземна Мережа Радіодоступу). В інших системах цим ресурсом може бути, наприклад, резервована і/або спеціалізована смуга частот для передачі сигналів. Крім блокування сигналів SIP, може виникнути проблема, пов'язана з завантаженням посередників SIP. Оскільки режим сторінок звичайно використовує метод SIP MESSAGE, всі повідомлення, для яких використовується SIP MESSAGE, передаються через посередників SIP Отже, передача великих повідомлень у режимі сторінок через посередників SIP може суттєво погіршити функціонування цих посередників, наслідком чого може бути ефективне блокування всіх сигналів SIP і загальне зниження ефективності мережі SIP. Отже, у деяких 5 випадках метод SIP MESSAGE не придатний для використання з великими повідомленнями. У випадку, коли розмір повідомлення перевершує певну межу, рішенням може бути використання механізму MSRP замість SIP MESSAGE. Однак, механізм MSRP призначено для обслуговування повідомлень у режимі сеансу, а не у режимі сторінок. Крім того, прийняті повідомлення у режимі сторінок можуть бути відстрочені і зберігатись у вхідній скриньці повідомлень, звідки користувач може їх зчитати, коли це для нього зручно, а у режимі сеансу прийняті повідомлення відкриваються користувацьким терміналом і надаються користувачу для діалогу. Отже, для реципієнта режим сторінок з застосуванням механізму MSRP є неприйнятним. Задачею винаходу є створення способу усунення описаних вище проблем і пристрою для реалізації цього способу. Цю задачу вирішено застосуванням способу, користувацьких терміналів і сервера, визначених у відрізняючих частинах незалежних п.п.Формули винаходу. Бажані втілення винаходу визначено залежними п.п.Формули. Винахід базується на формулюванні і вирішення зазначеної проблеми визначенням з відповідною індикацією того, було чи ні певне повідомлення, надіслане з використанням механізму передачі повідомлень у режиму сеансу (типу чату), повідомленням режиму сторінок, і, якщо це повідомлення є повідомленням режиму сторінок, виконанням дій, які відповідали б випадку, коли при прийомі цього повідомлення був використаний механізми режиму сторінок, або дій, що відповідають спеціальним інструкціям, визначеним для такого повідомлення режиму сторінок. Режим сеансу означає застосування протоколу, наприклад, MSRP, призначеного для обміну послідовностями повідомлень. Режим сторінок означає, що кожне повідомлення є незалежною транзакцією на рівні протоколу, тобто наступне негайне повідомлення на цьому рівні протоколу не стосується попереднього повідомлення. Перевагою винаходу є те, що застосування зазначеної індикації дозволяє приймати повідомлення режиму сторінок, навіть коли вони були передані як повідомлення режиму сеансу. Іншою перевагою є можливість уникнути блокування сигналів SIP, викликаного великими повідомленнями. Далі наведено детальний опис бажаних втілень винаходу з посиланням на креслення, в яких: Фіг.1 - спрощена архітектура системи; Фіг.2 - схема операцій, що ілюструє функції користувацького терміналу згідно з винаходом у режимі передачі; Фіг.3, 4 - схеми операцій, що ілюструють функції користувацького терміналу згідно з винаходом у режимі прийому; Фіг.5А-5D - приклади повідомлень SIP INVITE згідно з втіленнями винаходу і Фіг.6, 7, 8, 9 - обмін сигналами згідно з втіленнями винаходу. Далі розглядаються типові втілення. Хоча розглядаються деякі втілення у декількох місцях це не означає, що кожне таке посилання стосується таких же втілень або їх ознаки є характерними для 90144 6 єдиного втілення. Окремі ознаки різних втілень у певних комбінаціях можуть створювати інші втілення. Винахід може знайти застосування у будь-яких користувацьких терміналах, серверах і/або у будьяких систем зв'язку або у будь-яких комбінаціях різних систем зв'язку, доступних для цих користувацьких терміналів і призначених для передачі повідомлень, тобто для передачі даних у форматі повідомлення від одного користувача до іншого у майже реальному часі або через поштову скриньку. Формат повідомлень може бути будь-яким, зокрема, типу даних або тексту. Дані можуть бути текстовими, голосовими, відеокліпами, мультимедійними даними тощо. Системи зв'язку можуть бути фіксованими системами зв'язку або безпровідними або системами зв'язку, в яких використовуються як фіксовані, так і безпровідні мережі. Протоколи і технічний рівень систем зв'язку і терміналів, особливо у безпровідному зв'язку, швидко розвиваються. Такий розвиток може потребувати додаткових модифікацій винаходу. Отже, всі терміни і побудови слід інтерпретувати у широкому сенсі, а саме, як ілюстрації, що не обмежують винаходу. У подальшому винахід розглядається як необмежуючий приклад у дуже спрощеному системному середовищі, придатному для застосування винаходу з використанням SIP і MSRP. Слід відзначити, що система зв'язку і проміжні елементи, наприклад, посередники, методи SIP і MSRP або відповідні протоколи є незалежними від винаходу у тому не розглядаються детально. Винахід здебільшого стосується передачі повідомлень на рівні застосування. Фіг.1 містить дуже спрощену архітектуру систему, де показано лише систему зв'язку 1, два користувацькі термінали КТ 2, 2' і мережу 3. Зрозуміло, що такі системи мають у складі і інші пристрої, системні елементи, наприклад, сервери негайної передачі повідомлень, функції і структури яких не розглядаються. Користувацьким терміналом 2, 2' є вузол або пристрій, який дозволяє користувачу взаємодіяти з системою зв'язку безпосередньо або через комп'ютерну систему, тобто він надає користувачу інформацію і дозволяє вводити інформацію і, отже, є кінцевим пунктом конкретного сеансу зв'язку. Інакше кажучи, користувацьким терміналом 2, 2' може бути будь-який вузол або хост, який підтримує обмін повідомленнями і може мати зв'язок з мережею системи через доступ до мереж (не показаний на Фіг.1), якщо такий доступ існує. Користувацький термінал 2, 2' може бути немобільним пристроєм, наприклад, персональним комп'ютером (ПК), приєднаним до мережі 3 безпровідним або фіксованим зв'язком. Користувацький термінал 2, 2' також може бути мобільним терміналом, здатним забезпечувати обмін повідомленнями, багатофункціональним терміналом, який слугує сервісною платформою і підтримує завантаження і виконання різних функцій обслуговування, або ноутбуком, який може бути приєднаний до мережі (через доступ до мережі), "кишеньковим" комп'ютером, що може бути приєднаний до мережі, тощо. 7 Користувацький термінал 2 має щонайменше один користувацький інтерфейс (UI) 21, через який користувач може створювати і/або зчитувати повідомлення, одну або більше служб обміну повідомленнями (АррІ) 22, пам'ять (Mem) 23 (або користувацький термінал має бути забезпечений доступом до пам'яті) для щонайменше тимчасового зберігання прийнятих повідомлень режиму сторінок, і трансівер (TRx) 24 для передачі і прийому сигналів (повідомлень). Служба 22 обміну повідомленнями 22 може бути програмним продуктом, призначеним виконувати функції згідно з винаходом. Такого виконання функцій можна досягти оновленням відповідної служби обміну повідомленнями або доданням нової служби обміну повідомленнями до терміналу. Фіг.2 містить блок-схему операцій, що реалізують функції користувацького терміналу згідно з винаходом у режимі передачі. У приклад на Фіг.2 вважається, що користувач завжди входить у режим сторінок за однією процедурою і користувацький термінал вибирає спосіб/механізм для обслуговування цих повідомлень. Початковою є операція 201, якою користувач створює режим сторінок і передає через користувацький інтерфейс інструкції для надсилання повідомлення до приймача. Інакше кажучи, користувацький термінал отримує команду "надіслати повідомлення за даною адресою". У відповідь користувацький термінал визначає (опер. 202) розмір повідомлення і перевіряє (опер. 203), чи перевищує розмір повідомлення заздалегідь визначений поріг, який може бути визначений прийнятим протоколом обслуговування, користувачем або оператором, або він може бути елементом конфігурації терміналу. Бажано, щоб цей заздалегідь визначений поріг відповідав розміру, припустимому для протоколу транспортування повідомлень. Однак, значення цього заздалегідь визначеного порогу і спосіб його встановлення не є критичними для винаходу. У деяких втіленнях винаходу навіть припустимим є використання механізму MSRP або відповідного механізму для всіх режимів сторінок незалежно від їх розмірів. Наприклад, користувацький термінал може бути заздалегідь конфігурований для постійного використання режиму сеансу, якщо оператор не дозволяє користуватись режимом сторінок. Якщо розмір повідомлення не перевищує цей поріг (опер. 203), користувацький термінал надсилає (опер. 204) контенти, використовуючи метод SIP MESSAGE; в іншому випадку (опер. 203) користувацький термінал надсилає (опер. 205) повідомлення, використовуючи механізм MSRP з індикатором режиму сторінок згідно з винаходом. Залежно від застосування користувацький термінал може додати (або не додавати до повідомлення у режимі сторінок ) інформацію про фактичний розмір повідомлення, надіслане MSRP. Процедура надсилання повідомлення ілюструється більш детально у Фіг.6, 7, 8. В одному з втілень винаходу користувач має обирати один з трьох варіантів: режим сторінок для малих повідомлень (розмір не перевищує заздалегідь визначеної межі), інший повідомлень 90144 8 режиму сторінок, сеанс зв'язку (чат) з обміном повідомленнями, і, якщо користувач вибирає інші повідомлення режиму сторінок, використовується механізм режиму сеансу з обміном повідомленнями з індикатором режиму сторінок при надсиланні повідомлення. Фіг.3 містить блок-схему операцій, що реалізують функції користувацького терміналу згідно з винаходом у режимі прийому. У прикладі на Фіг.3 вважається, що інформація про фактичний розмір повідомлення не передається, але користувацький термінал має достатньо вільної пам'яті для повідомлень і тому повідомлення може бути прийняте, причому користувацький термінал пристосовано приймати у режимі сторінок. Дії терміналу у випадку, коли розмір повідомлення перевищує вільну пам'ять, є несуттєвими для винаходу; вони залежать від типу терміналу реципієнта; термінал може відхилити вимогу сеансу зв'язку, якщо бракує вільної пам'яті, або вимога сеансу зв'язку може бути прийнята, але сеанс зв'язку буде перерваний у випадку заповнення пам'яті. У відповідь на прийом SIP INVITE (MSRP) (опер. 301) користувацький термінал перевіряє (опер. 302), чи відповідає SIP INVITE (MSRP) повідомленню режиму сторінок. Якщо так, користувацький термінал встановлює (опер. 303) сеанс зв'язку; приймає (опер. 304) повідомлення, зберігає (опер. 305) повідомлення і вивільняє (опер. 306) сеанс зв'язку. Після цього або одночасно користувацький термінал сповіщає (опер. 307) користувача, що повідомлення було прийняте. Користувач може прочитати повідомлення пізніше. Інакше кажучи, користувацький термінал взаємодіє з користувачем так, якби повідомлення було прийняте методом SIP MESSAGE. Якщо SIP INVITE (MSRP) відповідає чату (тобто режиму сеансу з обміном повідомленнями), а не для повідомлень режиму сторінок (опер. 302), користувацький термінал встановлює (опер. 308) сеанс зв'язку і показує (опер. 309) діалог до кінця сеансу зв'язку. Користувацький термінал реципієнта може бути конфігурований відхиляти всі повідомлення режиму сторінок, і тоді сеанс зв'язку не відбувається і замість опер. 303 - 307 надсилається відхилення. Користувацький термінал реципієнта може також бути конфігурований пересилати повідомлення-вимоги режиму сторінок до вхідної скриньки мережі, до іншого терміналу тощо, і у такому випадку сеанс зв'язку не відбувається і замість опер. 303-307 вимога пересилається. Приклади таких ситуацій ілюстровано Фіг.7, 8. Навіть якщо всі повідомлення режиму сторінок були переадресовані для зберігання десь в іншому місті і користувач бажає бачити їх на іншому терміналі, термінал, що здійснює переадресування, має забезпечувати режим сторінок з обміном повідомленнями. В іншому втіленні винаходу ця перевірка проводиться після того, як повідомлення прийняте (тобто опер. 302 виконується після опер. 304, і процес продовжується після перевірки в опер. 305 або в опер. 308). 9 Фіг.4 містить блок-схему операцій, які забезпечують виконання функцій користувацького терміналу згідно з іншим втіленням винаходу у режимі прийому. У цьому варіанті вважається, що наявною є інформація про фактичний розмір повідомлення, а також зроблені припущення, як для Фіг.3, тобто про достатність вільної пам'яті у користувацькому терміналі і готовність користувацького терміналу приймати повідомлення режиму сторінок. У відповідь на прийом SIP INVITE (MSRP) (опер. 401) користувацький термінал перевіряє (опер. 402), чи SIP INVITE (MSRP) призначено для повідомлень режиму сторінок. Якщо так, користувацький термінал інформує (опер. 403) користувача про розмір повідомлення. Якщо користувач приймає повідомлення (опер. 404), користувацький термінал встановлює (опер. 405) сеанс зв'язку; приймає (опер. 406),повідомлення і зберігає (опер. 407) його. Користувач може тепер прочитати повідомлення пізніше. Далі користувацький термінал вивільняє (опер. 408) сеанс зв'язку. Інакше кажучи, користувацький термінал взаємодіє з користувачем так, якби повідомлення було прийняте методом SIP MESSAGE. У цьому прикладі користувацький термінал не інформує користувача про прийом повідомлення, оскільки вважається, що прийнявши повідомлення користувач вже отримав інформацію про нього. Однак, в іншому втіленні користувацький пристрій може бути конфігурований інформувати користувача про прийом повідомлення. Якщо користувач не приймає повідомлення (опер. 404), користувацький термінал відхиляє (опер. 409) встановлення сеансу зв'язку. В іншому втіленні користувацький термінал замість відхилення може переслати встановлення сеансу зв'язку і тоді повідомлення зберігається у мережі і може бути отримане пізніше (Фіг.7, 8). Якщо SIP INVITE (MSRP) передбачено для чату (тобто для режиму сеансу з обміном повідомленнями), а не для повідомлень режиму сторінок (опер. 402), користувацький термінал встановлює (опер. 410) сеанс зв'язку і показує (опер. 411) діалог до кінця сеансу зв'язку. В іншому втіленні винаходу замість запитання, приймає користувач повідомлення чи ні (тобто замість опер. 403), користувацький термінал приймає повідомлення, які за розміром не перевищують заздалегідь визначеного порогу розмірів. Цей поріг, наприклад, може бути визначений оператором, виробником користувацького терміналу і/або користувачем. Обмін сигналами ілюструється не обмежуючими винахід прикладами з посиланнями на Фіг.5А-8, де використано SDP (Протокол Опису Сеанс зв'язку) для ініціювання сеансу зв'язку і MSRP через TCP для передачі фактичного контенту. Іншим припущенням у цих прикладах є те, що користувацький термінал реципієнта не відхиляє повідомлень. Якщо потрібно, додаткову інформацію можна знайти на сайті http://www.ietf.org/lHTepHeT-drafts/draft-ietf-simpleпoвiдoмлeн-sessions-10.txt, включеному у даний опис посиланням. Однак, для винаходу не є суттєвим, який саме протокол використовується, згадані 90144 10 вище протоколи є лише прикладами. Наприклад, замість SDP може бути використаний інший протокол механізму пропозиція-відповідь, а замість TCP - інші протоколи контролю перевантажень, наприклад, SCTP (Протокол для Сигналів Загального Транспорту). Фіг.5А - 5D ілюструють приклади індикації повідомленням режиму сеансу про те, що запрошення режиму сеансу призначено для повідомлень режиму сторінок. У втілені на Фіг.5А повідомлення режиму сторінок вказується комбінацією т-лінії, що містить новий індикатор режиму сторінок 5-1 (m= повідомлення 9 msrp режиму сторінок), і параметра 5-3 (а= max-size - максимальний розмір, що вказує фактичний розмір повідомлення 5-2 (а= max-size: фактичний розмір). У втілені на Фіг.5В повідомлення режиму сторінок вказується комбінацією т-лінії, що містить новий індикатор режиму сторінок 5-1 (m= повідомлення 9 msrp режиму сторінок), і параметра 5-3 а= max-size - максимальний розмір, що вказує фактичний розмір повідомлення 5-2 (а= max-size: фактичний розмір). У цьому втіленні, параметр а вказує максимальний розмір повідомлення. У втілені на Фіг.5С повідомлення режиму сторінок вказується параметром 5-3 а= фактичний розмір. Коли значення параметра відрізняється від 0, це неявно вказує, що це повідомлення є повідомленням режиму сторінок або навпаки. У цьому втілені інформація m-лінії вказує що має бути використане MSRP і параметр а= max-size - максимальний розмір вказує максимальний розмір повідомлення. У втілені на Фіг.5D повідомлення режиму сторінок вказується m-лініє, яка містить новий індикатор 5-1 режиму сторінок (m= повідомлення 9 msrp режиму сторінок). У цьому втілені параметр а= max-size вказує максимальний розмір повідомлення і додаткові а-параметри не потрібні. На діаграмі сигналів (Фіг.6) наведено обмін сигналами лише між кінцевими пунктами, хоча між ними можуть бути один або більше проміжних пунктів. Фіг.6 ілюструє обмін сигналами, коли повідомлення приймає приймач, точніше, клієнт при приймальному користувацькому терміналі. Процедура починається тим, що Аліса бажає надіслати повідомлення до Бобу. Алісин користувацький термінал КТ1 (точніше клієнт з КТ1) помічає (п.61), що повідомлення режиму сторінок має бути надіслане з використанням механізму режиму сеансу, (п.6-1 розглядається вище (Фіг.2)). Отже КТ1 надсилає запрошення на сеанс зв'язку повідомленням 6-2 з індикатором РМ1 режиму сторінок до користувацького терміналу КТ2 Боба. Бажано, щоб повідомлення 6-2 було одним з повідомлень, ілюстрованих Фіг.5А-5D. У відповідь на прийом повідомлення 6-2 КТ2 виявляє (п.6-3), що воно є повідомленням з запрошенням на режим сторінок, і приймає це запрошення, надсилаючи повідомлення 6-4. КТІ підтверджує це прийняття, надсилаючи повідомлення 6-5, і КТ1 потім надсилає фактичні контенти повідомлення режиму сторінок у повідомлені 6-6 режиму сеансу. Прийнявши ці контенти, КТ2 зберігає (п.6-7) їх, і тому Боб може побачити їх 11 пізніше. КТ2 може також сповістити Боба, як це описано вище (Фіг.3, 4). У відповідь на отримання контентів, КТ2 підтверджує їх прийом, надсилаючи підтвердження у режимі сеансу у повідомлені 6-8. У втілені, ілюстрованому Фіг.6 передавальний користувацький термінал КТ1 конфігуровано припиняти сеанс зв'язку у відповідь на підтвердження, надіславши повідомлення 6-9 до КТ2, який у відповідь надсилає повідомленя 6-10, підтверджучи ним кінець зв'язку. На діаграмі сигналів (Фіг.7) наведено обмін сигналами між кінцевими пунктами через сервер негайної передачі повідомлень у прийомному кінцевому пункті, хоча між ними можуть бути один або більше проміжних пунктів. Фіг.7 ілюструє обмін сигналами, коли приймач, точніше відповідний клієнт на приймальному користувацькому терміналі, не приймає повідомлення, але вимагає від мережі зберегти це повідомлення для пізнішого отримання. Спочатку Аліса бажає надіслати повідомлення до Боба. Алісин користувацький термінал КТ1 (відповідний клієнт на КТ1) помічає (п.7-1), що повідомлення режиму сторінок має бути надіслане з використанням механізму режиму сеансу (п.7-1 детально розглядається вище на Фіг.2). Отже, КТ1 надсилає повідомлення з запрошенням на сеанс зв'язку 7-2 з індикатором РМІ режиму сторінок до користувацького терміналу КТ2 Боба через сервер. Бажано, щоб повідомлення 7-2 було повідомленням, і ілюстрованим Фіг.5А-5D. Прийнявши повідомлення 7-2, КТ2 виявляє (п.7-3), що воно є повідомленням режиму сеансу з запрошенням на повідомлення режиму сторінок. З якоїсь причини КТ2 не приймає повідомлень режиму сторінок і надсилає до сервера повідомлення 7-4 про переадресування. Прикладом повідомлення про переадресування є повідомлення SIP 302 "MOVED TEMPORARILY (Тимчасова зміна)", яке може містити інформацію про те, як обробляти це повідомлення. Проте для винаходу не є суттєвим, за яким протоколом здійснюється переадресування і, якщо потрібно, при цьому надаються додаткові інструкції/інформація. Інші приклади включають використання окремих транзакцій з використанням протоколів SIP, наприклад, SIP PUBLISH, SIP OPTIONS, які називають функціями у SIP REGISTER, або ХСАР (Конфігураційний Протокол Доступу у мові з можливістю розширення). КТ2 може також сповістити Боба про повідомлення, як це було описано для Фіг.3 і 4. У цьому прикладі сервер, точніше агент користувача, що забезпечує прийом з підтвердженням, приймає пропозицію альтернативного обслуговування і бере на себе функцію кінцевого пункту сеансу зв'язку, приймаючи початкове запрошення надсиланням повідомлення 7-5. КТ1 підтверджує це, надсилаючи повідомлення 7-6 до сервер і після цього надсилає фактичні контенти повідомлення режиму сторінок у повідомленні режиму сеансу 7-7 до сервера. Прийнявши ці контенти, сервер зберігає їх (п.7-8), завдяки чому Боб може побачити їх пізніше, а також підтверджує їх прийом, надсилаючи повідомлення 7-9 режиму сеансу. У втіленні, ілюстрованому Фіг.7 передавальний користувацький термінал КТ1 має конфігурацію, 90144 12 яка у відповідь на це підтвердження забезпечує припинення сеансу зв'язку надсиланням повідомлення 7-10 до сервера, який після цього надсилає повідомлення 7-11 з підтвердженням цього припинення. Боб може проглянути контенти повідомлення пізніше, але реалізація цього не є суттєвим для винаходу і тому не розглядається. У діаграмі обміну сигналами (Фіг.8), як і на Фіг.7, показано обмін сигналами між кінцевими пунктами через сервер негайної передачі повідомлень у прийомному кінцевому пункті, хоча між ними можуть бути один або більше проміжних пунктів. Фіг.8 ілюструє обмін сигналами, коли приймач, точніше відповідний клієнт на приймальному користувацькому терміналі, не приймає повідомлення, але вимагає шлюзу GW у мережі для збереження повідомлення Процедура Фіг.8 починається, коли Аліса бажає надіслати повідомлення до Боба. Алісин користувацький термінал КТ1 (відповідний клієнт на КТ1) помічає (п.8-1), що повідомлення режиму сторінок має бути надіслане з використанням механізму режиму сеансу (п.8-1 детально розглядається вище на Фіг.2). Отже, КТ1 надсилає повідомлення з запрошенням на сеанс зв'язку 8-2 з індикатором РМІ режиму сторінок до користувацького терміналу КТ2 Боба через сервер. Бажано, щоб повідомлення 8-2 було повідомленням, ι ілюстрованим Фіг.5А-5D. Прийнявши повідомлення 8-2, КТ2 виявляє (п.8-3), що воно є повідомленням режиму сеансу з запрошенням на повідомлення режиму сторінок. З якоїсь причини КТ2 не приймає повідомлень режиму сторінок і надсилає до сервера повідомлення 7-4 про переадресування, вказуючи, що це повідомлення має бути переслане до шлюзу GW. (Переадресування повідомлень було розглянуте на Фіг.7.) КТ2 може також сповістити Боба про це повідомлення, як це описано на Фіг.3, 4. У цьому прикладі сервер, точніше агент користувача, що забезпечує прийом з підтвердженням, формує нову вимогу до URI (Уніфікований Ідентифікатор Ресурсів) у GW повідомленням 8-4 і надсилає цю вимогу у повідомлені 8-5. Бажано, щоб ця вимога була запрошенням на режим сеансу без індикації про режим сторінок. GW приймає початкове запрошення, надсилаючи повідомлення 8-6. КТ1 підтверджує це, надсилаючи повідомлення 8-7 до GW і потім надсилає фактичні контенти повідомлення режиму сторінок у повідомленні режиму сеансу 8-7 до GW. Прийнявши ці контенти, GW зберігає їх (п.7-8), завдяки чому Боб може побачити їх пізніше, а також підтверджує їх прийом, надсилаючи повідомлення 8-9 режиму сеансу. GW також підтверджує прийом, надсилаючи підтвердження режиму сеансу у повідомленні 8-10. У втіленні, ілюстрованому Фіг.7, передавальний користувацький термінал КТ1 має конфігурацію, яка у відповідь на це підтвердження забезпечує припинення сеансу зв'язку надсиланням повідомлення 8-11 до GW, який після цього надсилає повідомлення 8-12 з підтвердженням цього припинення. Боб може проглянути контенти повідомлення пізніше, але реалізація цього не є суттєвим для винаходу і тому не розглядається. 13 Фіг.9 ілюструє обмін сигналами згідно з іншим втіленням винаходу, в якому конфігурація сервера негайної передачі повідомлень дозволяє виявляти індикацію. Цей сервер може бути окремим сервером або компонентом сервера у вузлі мережі, який містить один або більше інших компонентів. У прикладі, ілюстрованому Фіг.9 припущено, що реципієнт (КТ2) є недоступним або має конфігурацію, яка забезпечує збереження повідомлень режиму сторінок у приймальній скриньці мережі реципієнта, яка у даному випадку розташована у сервері. Це може також забезпечуватись конфігурацією мережі. У діаграмі обміну сигналами (Фіг.9) показано обмін сигналами між передавальним кінцевим пунктом КТ1 і діючим сервером негайної передачі повідомлень приймального кінцевого пункту, хоча між ними можуть бути один або більше проміжних пунктів. Процедура Фіг.9 починається, коли Аліса бажає надіслати повідомлення до Боба. Алісин користувацький термінал КТ1 (відповідний клієнт на КТ1) помічає (п.9-1), що повідомлення режиму сторінок має бути надіслане з використанням механізму режиму сеансу (п.9-1 детально розглядається вище на Фіг.2). Отже, КТ1 надсилає повідомлення з запрошенням на сеанс зв'язку 9-2 з індикатором РМІ режиму сторінок до користувацького терміналу КТ2 Боба через сервер. Бажано, щоб повідомлення 9-2 було повідомленням, і ілюстрованим Фіг.5А-5D. Прийнявши повідомлення 9-2, сервер, точніше агент користувача, що забезпечує прийом з підтвердженням, виявляє, що (п.9-3) це повідомлення є запрошенням на повідомлення режиму сторінок і тому перевіряє конфігурацію КТ2 (Боб) на придатність до повідомлень режиму сторінок. Оскільки ця перевірка конфігурації показує повідомлення режиму сторінок, вони підлягають зберіганню для пізнішого отримання, і сервер приймає на себе функцію кінцевого пункту сеансу зв'язку і приймає запрошення, надсилаючи повідомлення 9-4. КТ1 підтверджує прийняття, надсилаючи повідомлення 9-5 до сервера, після чого надсилає фактичні контенти повідомлення режиму сторінок у повідомленні 9-6 режиму сеансу до сервера. Прийнявши ці контенти, сервер зберігає (п.97) їх для проглядання Бобом пізніше. У деяких інших втіленнях винаходу повідомлення може бути збережене в іншому вузлі мережі або у віддаленій базі даних, або може бути переслане до шлюзу. У відповідь на прийняті контенти сервер також підтверджує їх прийом, надсилаючи підтвердження режиму сеансу у повідомленні 9-8. У втіленні, ілюстрованому Фіг.9, передавальний користувацький термінал, КТ1, має конфігурацію, яка забезпечує припинення сеансу зв'язку ц відповідь на це підтвердження надсиланням повідомлення 9-9 до сервера, який після цього надсилає повідомлення 910, яке підтверджує припинення. Боб може проглянути контенти повідомлення пізніше, але реалізація цієї процедури не є суттєвою для винаходу і тому не розглядається. 90144 14 У ще одному втіленні винаходу сервер негайної передачі повідомлень реципієнта пристосовано вирішувати, пересилати вимогу сеансу зв'язку або приймати на себе функцію кінцевого пункту, базуючись на розмірі повідомлення, можливостях терміналу реципієнта і/або навантаженні мережі. В іншому втілені (Фіг.9) користувач може мати у розпорядженні конфігурацію, згідно з якою повідомлення режиму сторінок передані з використанням механізму режиму сеансу, зберігаються у приймальній скриньці мережі, а користувач отримує лише сповіщення, в той час, як повідомлення режиму сторінок передані з використанням механізму режиму сторінок пересилаються до користувача. Операції, пункти і обміни сигналами і повідомленнями на Фіг.2, 3, 4, 6, 7, 8, 9 показано не у хронологічному порядку і деякі з операцій/пунктів можуть бути виконані одночасно або у порядку, відмінному від наведеного. Між операціями/пунктами або у межах операцій/пунктів можуть виконуватись і інші функції. Деякі з операцій/пунктів або їх частини можуть бути видалені. Обміни сигналами і повідомленнями є лише прикладами і можуть навіть включати декілька окремих повідомлень для передачі тієї ж інформації. Крім того, повідомлення можуть містити іншу інформацію. Повідомлення і операції/пункти можуть бути вільно комбіновані або розділені н декілька частин. Назви, типи і/або контенти повідомлень, а також протоколи можуть відрізнятись від зазначених вище. Хоча у наведеному вище описі винаходу було припущено, що зв'язок тобто, передача файлів і виклики, є зв'язком від пункту до пункту, зрозуміло, що це може бути зв'язок від пункту до багатьох пунктів. Описані втілення або їх частини можуть бути комбіновані для отримання інших бажаних втілень винаходу. Користувацькі термінали, інші відповідні пристрої і/або сервери або відповідні серверу компоненти, що реалізують функції винаходу, включають не лише існуючі засоби, але також засоби передачі і/або прийому повідомлень режиму сторінок, подібні описаним вище. Вузли мережі і користувацькі термінали мають у складі процесори і пам'ять, які можуть бути використані для виконання функцій згідно з винаходом. Всі модифікації і конфігурації, необхідні для реалізації винаходу, можуть бути виконані програмно, з використанням додаткового або оновленого програмного забезпечення, або схемно з використанням прикладних інтегральних схем (ASIC) і/або програмованих схем. Зрозуміло, що з розвитком технологій концепції винаходу можуть бути застосовані різними шляхами. Винахід і його втілення не обмежуються описаними вище прикладами, і можуть бути модифіковані у межах, визначених Формулою винаходу. 15 90144 16 17 90144 18 19 90144 20 21 Комп’ютерна верстка Т. Чепелева 90144 Підписне 22 Тираж 26 прим. Міністерство освіти і науки України Державний департамент інтелектуальної власності, вул. Урицького, 45, м. Київ, МСП, 03680, Україна ДП “Український інститут промислової власності”, вул. Глазунова, 1, м. Київ – 42, 01601