Реферат: Санкт петербургский государственный университет
САНКТ - ПЕТЕРБУРГСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ
Математико-механический факультет
Кафедра информатики
Разработка модели шлюза IP-телефонии для отображения
сигнализаций SIP-ISUP
Дипломная работа студентки 541 группы
Данг Тхи Хьеу
Научная руководительница,
Канд. технических наук ..........С.Л.Алексеева
/подпись/
Рецензент,
Проф., докт. физ.-мат. наук ........... А.Н.Терехов
/подпись/
"Допустить к защите" Заведующий кафедрой,
Проф., докт. физ.-мат. наук ........... Н.К.Косовский
/подпись/
Санкт-Петербург
2007г.
Оглавление
Введение
1. Описание реализации
1.1 Описание по MSC для шлюза
1.1.1 Потоки вызовов от SIP к ISUP
1.1.1.1 Установление вызова с блочной сигнализацией(без автоответа)
1.1.1.2 Установление вызова с автоответом
1.1.1.3 Истечение таймера T7 в ISUP
1.1.1.4 Истечение таймера SIP
1.1.1.5 Невозможность установления соединения в ISUP
1.1.1.6 Сообщение АСМ с указанием причины
1.1.1.7 Отмена вызова на стороне SIP
1.1.2 Переходы вызовов с ISUP на SIР
1.1.2.1 Установл. вызова-сигнализация блоком (ответ неавтоматический)
1.1.2.2 Установление вызова с автоматическим ответом
1.1.2.3 Истечение времени ответа SIP
1.1.2.4 Истечение времени T9 для ISUP
1.1.2.5 Ответ SIP с индикацией ошибки
1.1.2.6 Перенаправление в SIP
1.1.2.7 Отмена вызова со строны ISUP
1.2 Описание по FSM для шлюза(Finish State Machine)
2. SDL-Диаграммы
2.1 Состояние Idle и Wait ANM
2.2Состояние Wait ACK
2.3Состояние Wait ACM
2.4 Состояние Wait active ACK
2.5 Состояние Active
2.6 Состояние Wait RLC
2.7 Состояние Wait Clear
2.8 Состояние Wait Clear1
2.9 Состояние Wait SIP Response
2.10 Состояние Wait SIP Release
3. Реализация C#
3.1 Цель программа
3.2 Алгоритм
3.3 Программа
4. Результаты
5. Вывод
6. Литературы
Введение
IP-телефония-(Voice-over-IP) — Технология, при которой аналоговый звуковой сигнал от одного абонента дискретизируется (кодируется) в цифровой вид, компрессируется и пересылается через сеть с пакетной коммутацией до второго абонента, где производится обратная операция — декомпрессия, декодирование и воспроизведение аналогового сигнала.Возможность передачи голосовых сообщений через сеть с пакетной коммутацией впервые была реализована в 1993 году. Данная технология получила название VoIP (Voice over IP). Одним из частных приложений данной технологии является IP-телефония — услуга по передаче телефонных разговоров абонентов по протоколу IP.
IP-телефонии - значительная экономия средств при ведении междугородных или международных переговоров. Эта экономия достигается благодаря тому, что большую часть расстояния между абонентами голосовой сигнал проходит не по телефонной сети, а по сети Интернет. Но недостатком IP-телефона является более низкое чем в ТФОП, кочество связи
Рис. 1 Сравнение технологий пакетной передачи речи: a)VoATM,в)VoIP
В настоящее время для установления вызовов через сети IP создано несколько протоколов,например SIP(Session Initiation Protocol). Появление данных стандартов открывает широкие возможности децентрализации обеспечения услуг телефонии,так что теперь услуги могут управляться со стороны пользователя.Протокол инициирования сеансов(SIP)-предзначен для органзации,модификации и завершения мультимедийных сеансов или вызовов.SIP является одним из ключевых протоколов,используемых для реализации передачи речи по сетям IP(Voice over IP-VOIP).SIP-Это протокол сигнализации,имеющий широкое применение в Интернет-телефонии.
При стыке с ТфОП по сигнализации ОКС7 важно обеспечить прозрачность работы протокола ISUP для вызовов ТфОП — VoIP — ТфОП (все ISUP-параметры должны изменяться только согласно логике обработки вызовов и не должны теряться). Это означает, что для сигнализации между программными коммутаторами необходимо применять специальные протоколы, например SIP-T или BICC. Предназначенные для решения одних и тех же задач, эти два протокола имеют различную “идеологию”. Протокол SIP-T, исторически вышедший из Интернет-сообщества (IETF), — это обычный SIP, в сообщения которого инкапсулируются сигнальные единицы ISUP со всеми специфическими параметрами. Протокол BICC, детище традиционных связистов (МСЭ-Т), наоборот, является расширенным протоколом ISUP, к которому может прикрепляться SDP-заголовок, описывающий параметры, необходимые для успешной передачи упакованного в пакеты голоса между двумя оконечными точками. Протокол BICC — более сложный и, несмотря на формальное равноправие с SIP-T, явно проигрывает последнему в популярности.
^ 1.Описание реализации
SIP является протоколом прикладного уровня для установления, завершения и изменения мультимедийных сеансов.Обычно он передается средствами IP.Телефонные вызовы считаются разновидностью мультимедийных сеансов, где передается только звук
ISUP, как правило, передается средствами подсистемы MTP (Message Transport Part),хотя он также может передаваться средствами IP.ISUP используется для управления телефонными вызовами и обслуживания сети(блокировки каналов,переустановления каналов,и т.д)
MGC -это модуль, выполняющий отображение между этими двумя протоколами, называется контроллером транспортного (медиа) шлюза (Media Gateway Controller)
Этот раздел описывает логику и процедуры,которые может использовать MGC для осуществления отображения между SIP и ISUP,путем иллюстрции соответствий между протоколами на уровне сообщений и уровне параметров
Основное внимание уделено трансляции сообщений ISUP в сообщения SIP ,отображению параметров ISUP в заголовках SIP.Для вызовов ISUP,которые проходят через сеть SIP,целью трансляции является разрешить элементам SIP,таким как прокси-сервера(которые обычно не понимают ISUP)принимать решения по маршрутизации на основе такого критерия ISUP,как номер вызываемой стороны.
1.1 Описание по MSC для шлюза
^ 1.1.1 Потоки вызовов от SIP к ISUP
Приведенные потоки вызовов иллюстрируют порядок сообщений в типичном случае и в слчаях ошибок при установлении соединения,инициированного сетью SIP.Подтверждения ”100 Truing” на запросы Invite не показаны,хотя они требуются во многих архитектурах
На этих диаграммах представлена вся сигнализация (SIР, ISUР) к и от МGС; управление медиа-информацией (проключение аудиоканала, освобождение канала) выполняется МG под управлением МGС, Для упрощения они показаны одним узлом, обозначенным как «МGС/МG».
1.1.1.1 Установление вызова с блочной сигнализацией(без автоответа)
^ SIP MGC/MG PSTN
1|---------INVITE---------->| |
|<----------100------------| |
| |------------IAM---------->|2
| |<=========Audio===========|
| |<-----------ACM-----------|3
4|<----------18x------------| |
|<=========Audio===========| |
| |<-----------CPG-----------|5
6|<----------18x------------| |
| |<-----------ANM-----------|7
| |<=========Audio==========>|
8|<----------200------------| |
|<=========Audio==========>| |
9|-----------ACK----------->| |
1.Когда пользователь SIР желает инициировать сеанс связи с пользователем ТфОП, узел SIР выдает запрос INVITE
2.При приеме запроса INVITE, шлюз отображает его в сообщение IAM и посылает его в сеть ISUP
3.Удаленный узел PSTN информирует, что адрес достаточен для установления соединения путем посылки сообщения адрес полный (АСМ).
4.Код «статус вызываемой стороны (called party status)»из сообщения АСМ отображается в промежуточный ответ SIР и возвращается узлу SIР. Этот ответ может содержать SDР для раннего установления медиа-потока (как показано на диаграмме). Если SDР отсутствует, аудиоканал в обоих направлениях будет установлен после шага 8.
5.Если вариант ISUР позволяет, удаленный узел ISUР может выдавать ряд сообщений СРG, например, для индикации того, что соединение устанавливается.
6.Получив сообщение СРG, шлюз отображает код события (event code) в промежуточный ответ SIР и посылает его на узел SIР.
7.Когда пользователь ТфОП ответит, шлюзу посылается сообщение ответа (АNМ).
8.Приняв сообщение АNМ, шлюз посылает сообщение 200 к узлу SIР.
9.Узел SIР, получив финальный ответ INVITE (200), посылает сообщение АСК для подтверждения.
1.1.1.2 Установление вызова с автоответом
^ SIP MGC/MG PSTN
1|---------INVITE---------->| |
|<----------100------------| |
| |------------IAM---------->|2
| |<=========Audio===========|
| |<-----------CON-----------|3
| |<=========Audio==========>|
4|<----------200------------| |
|<=========Audio==========>| |
5|-----------ACK----------->| |
1.Когда пользователь SIР инициирует сеанс связи с пользователем ТфОП, узел SIР генерирует запрос INVITE.
2.Приняв запрос INVITЕ, шлюз отображает его в сообщение IАМ и посылает его в сеть ISUР.
З.Так как удаленный узел сконфигурирован на автоматический ответ, после приема IАМ он посылает сообщение СОN после принятия IАМ (для ANSI этим сообщением будет АNМ).
4.Приняв сообщение СОN, шлюз посылает сообщение 200 в направлении узла SIР.
5.Узел SIР, приняв финальный, ответ INVITE (200), посылает АСК
1.1.1.3 Истечение таймера T7 в ISUP
^ SIP MGC/MG PSTN
1|---------INVITE---------->| |
|<----------100------------| |
| |------------IAM---------->|2
| |<=========Audio===========|
| | *** T7 Expires *** |
| ** MG Releases PSTN Trunk ** |
4|<----------504------------|------------REL---------->|3
5|-----------ACK----------->| |
1.Когда пользователь SIР инициирует сеанс связи с пользователем ТфОП, узел SIР генерирует запрос INVITЕ.
2.Приняв запрос INVIТЕ, шлюз отображает его в сообщение IАМ и посылает его в сеть ISUP.В зто время запускается таймер T7 ISUP
З.Таймер Т7 ISUР срабатывает до прихода сообщения АСМ или СОN, поэтому посылается сообщение REL для отмены вызова.
4.Сообщение шлюза об истечении таймера посылается узлу SIР.
5.Узел SIР, приняв финальный ответ INVIТЕ (504), посылает АСК для подтверждения.
1.1.1.4 Истечение таймера SIP
^ SIP MGC/MG PSTN
1|---------INVITE---------->| |
|<----------100------------| |
| |------------IAM---------->|2
| |<=========Audio===========|
| |<-----------CON-----------|3
| |<=========Audio==========>|
4|<----------200------------| |
| *** T1 Expires *** | |
|<----------200------------| |
| *** T1 Expires *** | |
|<----------200------------| |
| *** T1 Expires *** | |
|<----------200------------| |
| *** T1 Expires *** | |
|<----------200------------| |
| *** T1 Expires *** | |
|<----------200------------| |
| *** T1 Expires *** | |
5|<----------200------------| |
| *** T1 Expires *** | |
| ** MG Releases PSTN Trunk ** |
7|<----------BYE------------|------------REL---------->|6
| |<-----------RLC-----------|8
1.Когда пользователь SIP инициирует сеанс связи с пользователем ТФОП,узел SIP генерирует запрос INVITE
2.Приняв запрос INVITE,шлюз отображает его в сообщение IAM и посылает его в сеть ISUP
3.Так как удаленный узел сконфигурован на автоматический ответ,он посылает сообщение CON после принятия IAM.Для потоков ANSI будет послано сообщение ANM(без ACM)
4.Приняв CON,шлюз посылает сообщение 200 узлу SIP и запускает таймер T1
5.Запрос посылается заново каждый раз при истечении таймера T1.
6.После семи повторных передач вызов прерывается посылкой на узел ISUP сообщения REL с кодом 102( recover on timer expiry- возврат из-за срабатывания таймера).
7.Сообщение BYE передается узлу SIP c целью попытаться завершить вызов.Последующие действия для завершения вызова не предусмотрены,т.к точное состояние узла SIP в этом сценарии не известно
8.Получив сообщение REL,удаленный узел ISUP отвечает сообщением RLC
1.1.1.5 Невозможность установления соединения в ISUP
^ SIP MGC/MG PSTN
1|---------INVITE---------->| |
|<----------100------------| |
| |------------IAM---------->|2
| |<-----------REL-----------|3
| |------------RLC---------->|4
5|<----------4xx+-----------| |
6|-----------ACK----------->| |
1.Когда пользователь SIP инициирует сеанс связи с пользователем ТФОП,узел SIP генерирует запрос INVITE
2.Приняв запрос INVITE,шлюз отображает его в сообщение IAM и посылает его в сеть ISUP
3.Т.к удаленный узел ISUP не может установить соединение,он посылает сообщение REL
4.Шлюз освобождает канал и подтверждает,что он свободен для дальнейщего использования посылкой сообщения RLC
5. Шлюз транслирует код причины из сообщения REL в ответ SIP об ошибке и передает его на узел SIP
6. Узел SIP посылает ACK для подтверждения приема финального ответа INVITE
1.1.1.6 Сообщение АСМ с указанием причины
^ SIP MGC/MG PSTN
1|---------INVITE---------->| |
|<----------100------------| |
| |------------IAM---------->|2
| |<=========Audio===========|
| |<---ACM with cause code---|3
4|<------183 with SDP-------| |
|<=========Audio===========| |
** Interwork timer expires **
5|<----------4xx+-----------| |
| |------------REL---------->|6
| |<-----------RLC-----------|7
8|-----------ACK----------->| |
1. Когда пользователь SIР инициирует сеанс связи с пользователем ТфОП, узел SIР генерирует запрос INVITE
2.Приняв запрос INVITЕ, шлюз отображает его в сообщение IАМ и посылает его в сеть ISUP.
3.Т.к. узел ISUP не в состоянии завершить вызов и сам хочет генерировать сигнал/аудио сообщение об ошибке, он посылает АСМ с кодом причины. Шлюз запускает таймер взаимодействия (interwork timer)
4.Приняв АСМ с причиной (присутствует параметр Индикатор причины (САI)), шлюз генерирует сообщение 183 в направлении узла SIР; оно содержит SDР для проключения медиа-канала.
5. Генерируется финальный ответ INVITE, базирующийся на коде причины, переданном в предыдущем сообщении АСМ, и посылается на узел SIР для завершения вызова.
6. По истечении таймера взаимодействия в направлении узла ТфОП посылается сообщение REL- для завершения вызова. Следует заметить, что узел SIР также может прервать вызов путем посылки сообщения CANCEL до истечения таймера взаимодействия.
7.Получив сообщение REL, удаленный узел ISUР отвечает сообщением RLC.
8.Узел SIР посылает АСК для подтверждения приема финального ответа INVITE
1.1.1.7 Отмена вызова на стороне SIP
^ SIP MGC/MG PSTN
1|---------INVITE---------->| |
|<----------100------------| |
| |------------IAM---------->|2
| |<=========Audio===========|
| |<-----------ACM-----------|3
4|<----------18x------------| |
|<=========Audio===========| |
| ** MG Releases IP Resources ** |
5|----------CANCEL--------->| |
6|<----------200------------| |
| ** MG Releases PSTN Trunk ** |
| |------------REL---------->|7
8|<----------487------------| |
| |<-----------RLC-----------|9
10|-----------ACK----------->| |
1.Когда пользователь SIР инициирует сеанс связи с пользователем ТфОП, узел SIР генерирует запрос INVITЕ.
2. Приняв запрос INVIT'Е, шлюз отображает его в сообщение IАМ и посылает его в сеть ISUР.
3.Удаленный узел ISUР информирует, что адрес достаточен для установления соединения путем посылки сообщения АСМ.
4. Код «called party status» (статус вызываемой стороны) из сообщения АСМ отображается в промежуточный ответ SIР.
5 .Для завершения вызова до ответа абонента узел SIР посылает запрос САNCEL.
6.Запрос САNCEL подтверждается ответом 200.
7.Получив запрос САNCEL, шлюз посылает ISUР сообщение REL для завершения вызова.
8. Шлюз посылает сообщение «487 Call Cancelled» (вызов отменен) на узел SIР для завершения транзакции INVITЕ.
9. Получив сообщение REL, удаленный узел ISUР отвечает сообщением RLС.
10. Получив сообщение 487, узел SIР подтверждает прием сообщением АСК.
^ 1.1.2 Переходы вызовов с ISUP на SIР
На этих схемах все сигналы вызова (SIР, ISUР) проходят через МGС, а обработку медиа-информации (например, аудиовставки, освобождение media-канала) осуществляет МG под управлением МGС. Для простоты они показаны в виде единого устройства, обозначенного-как "МGС/МG".
1.1.2.1 Установление вызова-сигнализация блоком (ответ неавтоматический)
^ SIP MGC/MG PSTN
| |<-----------IAM-----------|1
| |==========Audio==========>|
2|<--------INVITE-----------| |
|-----------100----------->| |
3|-----------18x----------->| |
|==========Audio==========>| |
| |=========================>|
| |------------ACM---------->|4
5|-----------18x----------->| |
| |------------CPG---------->|6
7|-----------200-(I)------->| |
|<=========Audio==========>| |
| |------------ANM---------->|8
| |<=========Audio==========>|
9|<----------ACK------------| |
1. Когда абоненту ТфОП требуется начать установку сеанса к абоненту SIР, ТфОП генерирует сообщение IАМ в направлении шлюза.
2.При приеме сообщения IАМ шлюз генерирует сообщение INVITЕ и посылает его соответствующему узлу SIР.
З.Если происходит событие, обозначающее, что адресная информация вызова является достаточной, то узел SIР генерирует предварительный ответ 180 или больший.
4.При приеме предварительного ответа 180 или большего шлюз генерирует сообщение АСМ. Если ответ был не 180, то в сообщении АСМ значение "Called party status" («статус вызываемой стороны») будет "no indication" («не указано»).
5.Узел SIР может и далее использовать предварительные сообщения для индикации хода сеанса.
6.После того, как сообщение АСМ послано, все предварительные ответы транслируются в сообщения ISUР СРG.
7.Когда узел SIР ответит на вызов, он посылает сообщение 200 ОК.
8.При приеме сообщения 200 ОК шлюз посылает сообщ. АNМ в направлении узла ISUP
9.Для подтверждения приема окончательного ответа на INVITЕ шлюз посылает сообщение АСК узлу SIР.
1.1.2.2 Установление вызова с автоматическим ответом
^ SIP MGC/MG PSTN
| |<-----------IAM-----------|1
| |==========Audio==========>|
2|<--------INVITE-----------| |
3|-----------200----------->| |
|<=========Audio==========>| |
| |------------CON---------->|4
| |<=========Audio==========>|
5|<----------ACK------------| |
1.Когда абоненту ТфОП требуется начать установку сеанса к абоненту SIР, ТфОП генерирует сообщение IАМ в направлении шлюза.
2.При приеме сообшения IАМ шлюз генерирует сообщение INVITЕ и посылает его соответствующему узлу SIР на основе анализа номера вызываемого абонента.
З.Так как узел SIР установлен в режим автоматического ответа на вызов, то он посылает сообщение 200 ОК.
4.При приеме сообщения 200 ОК шлюз посылает сообщение СОN в направлении узла ISUР.
5.Для подтверждения приема окончательного ответа на INVIТЕ шлюз посылает сообщение АСК узлу SIР
1.1.2.3 Истечение времени ответа SIP
^ SIP MGC/MG PSTN
| |<-----------IAM-----------|1
| |==========Audio==========>|
2|<--------INVITE-----------| |
| *** T1 Expires *** | |
3|<--------INVITE-----------| |
| *** T1 Expires *** | |
|<--------INVITE-----------| |
| | *** T11 Expires *** |
| |------------ACM---------->|4
| *** T1 Expires *** | |
|<--------INVITE-----------| |
| *** T1 Expires *** | |
|<--------INVITE-----------| |
| *** T1 Expires *** | |
|<--------INVITE-----------| |
| *** T1 Expires *** | |
|<--------INVITE-----------| |
| *** T1 Expires *** | |
| ** MG Releases PSTN Trunk ** |
| |------------REL---------->|5
6|<--------CANCEL-----------| |
| |<-----------RLC-----------|7
1.Когда абоненту ТфОП требуется начать установку сеанса к абоненту SIР, ТфОП генерирует сообщение IАМ в направлении шлюза.
2.При приеме сообщения IАМ шлюз генерирует сообщение INVITЕ и посылает его соответствующему узлу SIР на основе анализа номера вызываемого абонента. В это время производится установка таймера Т11 для ISUР и таймера Т1 для SIР.
3.Каждый раз по истечении времени таймера Т1 узлу SIР посылается сообщение INVITE. По стандарту SIР предусматривается производить передачу сообщения INVITЕ 7 раз, если нет приема ответа.
4.По истечении времени таймера Т11 узлу ISUР будет послано сообщение АСМ для предотвращения сброса вызова таймером Т7 ISUР удаленного узла. В этом сообщении АСМ значение "саlled party status" («статус вызываемой стороны») будет "no indication" («не указано»).
5.После того, как максимальное число запросов INVITЕ будет передано, шлюз пошлет REL (код причины 18) узлу ISUР для завершения вызова.
6.Кроме того, шлюз передает сообщение САNCEL узлу SIР для завершения любых попыток инициации.
7.При приеме REL удаленный узел ISUР в качестве подтверждения передает RLC.
1.1.2.4 Истечение времени T9 для ISUP
^ SIP MGC/MG PSTN
| |<-----------IAM-----------|1
| |==========Audio==========>|
2|<--------INVITE-----------| |
| *** T1 Expires *** | |
3|<--------INVITE-----------| |
| *** T1 Expires *** | |
|<--------INVITE-----------| |
| | *** T11 Expires *** |
| |------------ACM---------->|4
| *** T1 Expires *** | |
|<--------INVITE-----------| |
| *** T1 Expires *** | |
|<--------INVITE-----------| |
| *** T1 Expires *** | |
|<--------INVITE-----------| |
| | *** T9 Expires *** |
| ** MG Releases PSTN Trunk ** |
| |<-----------REL-----------|5
| |------------RLC---------->|6
7|<--------CANCEL-----------| |
1. Когда абоненту ТфОП требуется начать установку сеанса к абоненту SIР, ТфОП генерирует сообщение IАМ и направлении шлюза.
2.При приеме сообщения IАМ шлюз генерирует сообщение INVIТЕ и посылает его соответствующему узлу SIР на основе анализа номера вызываемого абонента. В это время производится установка таймера Т11 для ISUР и таймера Т1 для SIР.
3.Каждый раз по истечении времени таймера Т1 узлу SIР посылается сообщение INVITЕ. По стандарту SIР предусматривается производить передачу сообщения INVITЕ 7 раз, если нет приема ответа. Так как таймер Т1 начинает первоначальный отсчет для SIР со значения 0,5 с или большего и удваивает его при каждом повторении передачи, то пройдет не меньше минуты, пока истечет время по запросу INVIТЕ; а так как начальное значение Т1 для SIР разрешается устанавливать больше, чем 500 мс, то возможен вариант, когда 7-кратное повторение Т1 для SIР превысит сумму Т11+Т9 для ISUР.
4.По истечении времени таймера Т11 узлу ISUР будет послано сообщение АСМ для предотвращения сброса вызова таймером Т7 ISUР удаленного узла. В этом сообщении АСМ значение "called party status" («статус вызываемой стороны») будет "no indication" («не указано»),
5.По истечении времени таймера Т9 для ISUP удаленного узла ТфОП, он передает REL.
6. При приеме REL шлюз для подтверждения передает RLC.
7.REL запускает запрос САNCEL, посылаемый узлу SIР.
1.1.2.5 Ответ SIP с индикацией ошибки
^ SIP MGC/MG PSTN
| |<-----------IAM-----------|1
| |==========Audio==========>|
2|<--------INVITE-----------| |
3|-----------4xx+---------->| |
4|<----------ACK------------| |
| ** MG Releases PSTN Trunk ** |
| |------------REL---------->|5
| |<-----------RLC-----------|6
1.Когда абоненту ТфОП требуется начать установку сеанса к абоненту SIР, ТфОП генерирует сообщение IАМ в направлении шлюза.
2.При приеме сообщения IАМ шлюз генерирует сообщение INVIТЕ и посылает его соответствующему узлу SIР на основе анализа номера вызываемого абонента.
З.Узел SIР указывает на состояние ошибки ответным сообщением с кодом 400 или большим.
4.Для подтверждения приема окончательного ответа на INVITE шлюз посылает сообщение АСК узлу SIР.
5.Сообщение REL ISUР генерируется из шлюза.
6.Удаленный узел ISUР подтверждает прием сообщения REL сообщением RLC.
1.1.2.6 Перенаправление в SIP
^ SIP MGC/MG PSTN
| |<-----------IAM-----------|1
| |==========Audio==========>|
2|<--------INVITE-----------| |
3|-----------3xx+---------->| |
| |------------CPG---------->|4
5|<----------ACK------------| |
| |
| |
SIP удел 2 | |
6|<--------INVITE-----------| |
7|-----------18x----------->| |
|<=========Audio===========| |
| |------------ACM---------->|8
9|-----------200-(I)------->| |
|<=========Audio==========>| |
| |------------ANM---------->|10
| |<=========Audio==========>|
11|<----------ACK------------| |
1.Когда абоненту ТфОП требуется начать установку сеанса к абоненту SIР, ТфОП генерирует сообщение IАМ в направлении шлюза.
2.При приеме сообщения IАМ шлюз генерирует сообщение INVIТЕ и посылает его соответствующему узлу SIР на основе анализа номера вызываемого абонента.
З.Узел SIР посылкой сообщения Зхх указывает, что ресурс, к которому пользователь пытается установить контакт, расположен в другом месте. В таких случаях мы предполагаем, что контактный URL указывает действительный URL, который доступен VOIP SIР вызову.
4.Шлюз передает СРG с индикацией события перенаправления вызова при приеме сообщения Зхх. Заметим, что должна быть возможность отмены такой трансляции из-за конфигурации, так как некоторые узлы ISUР не поддерживают прием сообщений СРG до сообщений АСМ.
5.Шлюз подтверждает прием окончательного ответа на INVITЕ, передавая сообщение АСК узлу SIР.
6.Шлюз посылает принятое сообщение INVITЕ по адресу, указанному в поле контакт сообщения Зхх.
7.Когда происходит событие, говорящее о том, что вызов имеет достаточную адресную информацию, узел SIР генерирует предварительный ответ 180 или больший.
8.При приеме предварительного ответа 180 или большего шлюз генерирует сообщение АСМ с кодом события.
9.Когда узел SIР отвечает на вызов, он посылает сообщение 200 ОК.
10.При приеме сообщения 200 ОК шлюз посылает сообщение АNМ в направлении узла ISUР.
11.Для подтверждения приема окончательного ответа на INVIТЕ шлюз посылает сообщение АСК узлу SIР
1.1.2.7 Отмена вызова со строны ISUP
^ SIP MGC/MG PSTN
| |<-----------IAM-----------|1
| |==========Audio==========>|
2|<--------INVITE-----------| |
3|-----------18x----------->| |
|==========Audio==========>| |
| |------------ACM---------->|4
| ** MG Releases PSTN Trunk ** |
| |<-----------REL-----------|5
| |------------RLC---------->|6
7|<---------CANCEL----------| |
| ** MG Releases IP Resources ** |
8|-----------200----------->| |
9|-----------487----------->| |
10|<----------ACK------------| |
1.Когда абоненту ТфОП требуется начать установку сеанса к абоненту SIР, ТфОП генерирует сообщение IАМ в направлении шлюза.
2.При приеме сообщения IАМ шлюз генерирует сообщение INVITЕ и посылает его соответствующему узлу SIР на основе анализа номера вызываемого абонента.
3.Когда происходит событие, говорящее о том, что вызов имеет достаточную адресную информацию, узел SIР генерирует предварительный ответ 180 или больший.
4.При приеме предварительного ответа 180 или большего шлюз генерирует сообщение АСМ с кодом события.
5.Если вызывающий абонент положит трубку раньше, чем поступит ответ на вызов от узла SIР, то будет генерироваться сообщение REL.
6.Шлюз освобождает линию ТфОП и посылкой RLC показывает, что она доступна лля нового использования.
7.При приеме сообщения REL до заключительного ответа на INVIТЕ шлюз посылает САNСЕL в направлении узла SIР.
8.При приеме САNСЕL узел SIР посылает ответ 200.
9.Удаленный узел SIР посылает "487 Call Cancelled!" для завершения транзакции INVIТЕ.
10. Для подтверждения приема окончательного ответа на INVIТЕ шлюз посылает сообщение АСК узлу SIР.
1.2 Описание по FSM для шлюза(Finish State Machine)
2. SDL-Диаграммы
2.1 Состояние Idle и Wait ANM
2.2Состояние Wait ACK
2.3Состояние Wait ACM
2.4 Состояние Wait active ACK
2.5 Состояние Active
2.6 Состояние Wait RLC
2.7 Состояние Wait Clear
2.8 Состояние Wait Clear1
2.9 Состояние Wait SIP Response
2.10 Состояние Wait SIP Release
SIP Message Types
SIP спецификация (RFC 3261) определяет шесть SIP методов, каждый из которых имеет различое назначение:
• INVITE – инициирует сессию, приглашая пользователя на участие в ней;
• ACK (Acknowledgement)– подтверждает, что клиент принял окончательный ответ на INVITE запрос;
• BYE – инициирует прерывание сессии;
• CANCEL - отменяет SIP запрос, на который еще не получен окончательный ответ;
• REGISTER – регистрирует местоположение пользователя в сервере регистрации;
• OPTIONS – вопрос о возможностях сервера(поддерживаемые методы, расширения SIP, кодеки, и т.д.).
Кроме ещё расширения SIP определяют новые методы:
• INFO – позволяет передачу информации в течение сессии (mid-session), при чем состояние сессии не меняется. SIP для телефонии (SIP-T) использует INFO метод для передачи инкапсулированной ISUP информации;
• PRACK – подтверждает принятие сообщения временного (provisional) SIP ответа, когда требуется надежность его передачи;
• UPDATE – обеспечивает изменение параметров сессии (например, SDP), при чем состояние сессии не меняется;
• SUBSCRIBE – требует передачу сообщения отекущем состоянии или об изменении состояния вызова для различных ресурсов или вызовов в сети;
• NOTIFY – информирует об изменениях состояния ресурсов, т.е. произошло событие, для которого было потребовано подтверждение;
Из которых в рамках дипломной работы используются 4 :INVITE,ACK,BYE,CANCEL
^ Коды отклика SIP
• 1xx, Provisional – значит, что сообщение запроса принято, и что оно обрабатывается;
• 2xx, Success – запрос успешно принят и обработан;
• 3xx, Redirection – означает, что запрос должен быть перенаправлен;
• 4xx, ^ Client Error – означает, что запрос не может быть усвоен из-за ошибки клиента;
• 5xx, Server Error – означает, что запрос не может быть усвоен из-за ошибки сервера;
• 6xx, ^ Global Failure – означает, что ни один из серверов не может выполнить запрос.
Ответы со статусными кодами 100 – 199 информационные (provisional) и не прерывают SIP транзакцию,в отличие от ответов со статусными кодами 200– 699, которые являются окончательными (final) и завершают SIP транзакцию.
^ ISUP Message Types
IAM – Начальное адресное сообщение передается в “прямом” направлении для каждого вызова между вызывающим абонентом и вызываемым.В IAM содержится номер вызываемой стороны в обязательной части переменной длины и может содержаться имя и номер вызывающей стороны в необязательной части .
ACM – “Адрес полный” передается в “обратном” направлении для индикации удалееой стороны о том, что канал зарезервирован.Инициатор вызова, получив сообщение ACM проключает в голосовой канал вызывающей стороны вызываемую сторону.Вызывающему абоненту выдается сигнал посылки вызова.
REL – Передается в любом направлении как индикация того, что канал должен быть освобожден.Содержит индикатор причины освобождения: Например, 16-нармальное завершение вызова после разговора, 17-вызываемый абонент занят.
RLC- Передается в направлении, обратном к направлению REL как подтверждение освобождения канала на удаленной стороне и окончания тарификации
CPG – Передается в любом направлении во время установления соединения или на фазе разговора для индикации о соответствующем событии вызывающий или вызываемой стороны
RSC – Сообщение “сброс канала” передается в любом направлении как требование на завершение вызова и освобождение канала
^ 3.Реализация C#
При создании приложения для платформы .NET наиболле целесообразным является использование C#. Конечно, можно использовать и Си++, и Visual Basic или любой язык программирования, тем более что независимыми разработчиками создаются трансляторы с APL, Кобола, Eiffel, Haskell, Оберона, Smalltalk, Perl, Python, Паскаля и др. Однако для компилятора, способного генерировать приложения среды .NET CLR (Common Language Runtime), только C# является «родным» языком. Он полностью соответствует идеологии .NET и позволяет наиболее продуктивно работать в среде CLR. В свое время для использования виртуальной машины Java было создано множество так называемых «переходников» (bridges) c различных языков программирования, в частности PERCobol, JPython, Eiffel-to-JavaVM System, Tcl/Java и т.д
C# является языком объектно-ориентированного программирования, поэтому классы играют в нем основополагающую роль. Более того, все типы данных C#, как встроенные, так и определенные пользователем, порождены от базового класса object. Иными словами, в отличие от Java, где примитивные типы данных отделены от объектных типов, все типы данных в C# являются классами и могут быть разделены на две группы:
ссылочные (reference types);
обычные (value types).
Внешне ссылочные и обычные типы очень похожи, так как аналогично Cи++ в них можно объявлять конструкторы, поля, методы, операторы и т.д. Однако, в отличие от Cи++, обычные типы в C# не позволяют определять классы и не поддерживают наследования. Они описываются с помощью ключевого слова struct и в основном используются для создания небольших объектов. Ссылочные же типы описываются с помощью ключевого слова class и являются указателями, а экземпляры таких типов ссылаются на объект, находящийся в “ heap”
Интерфейсом в C# является тип ссылок, содержащий только абстрактные элементы, не имеющие реализации. Непосредственно реализация этих элементов должна содержаться в классе, производном от данного интерфейса (нельзя напрямую создавать экземпляры интерфейсов). Интерфейсы C# могут содержать методы, свойства и индексаторы, но в отличие, например, от Java, они не могут содержать константных значений
Язык программирования C# хотя и допускает, но все же не поощряет использование указателей. В некоторых ситуациях бывает особенно трудно обойтись без указателей на функции. Для этих целей в C# реализованы так называемые делегаты (delegates), которые иногда еще называют безопасными аналогами указателей на функцию
Анализируя особенности реализации классов языка C#, хотелось бы уделить внимание и способам передачи параметров метода по ссылке. Иногда возникает потребность в том, чтобы функция возвращала сразу несколько значений
Язык программирования C#, как и платформа .NET, находится в развитии. В частности, в ближайшее время можно ожидать появления обобщенных шаблонов, которые подобно шаблонам языка Cи++ ,позволят создавать сильно типизированные классы-коллекции.
^ 3.1 Цель программа
Обрабатывает сигналы между IP-сетю и PSTN(Телефонная сеть общего пользования).
Здесь Отображение ISUP в SIP (ISUP to SIPMapping). Определяет перевод ISUP сообщения в SIP сообщение и отображение ISUP параметров в заголовки SIP, базируется на ISUP ITU-T и на некоторых дополнениях, применимых для других вариантов ISUP
3.2 Алгоритм
Обрабатывает записи из Buffer_in(запись включает 3 параметра : Address,Code,Type)
Address – Это адрес сообщения которое принято
Code – Код сообщения теминологии SIP и ISUP
Type – Тип сообщения SIP,ISUP или OS(истечение тайм-аутов)
У нас есть 2 Buffer: Buffer_in и Buffer_out
Buffer_in содержит сообщения,которые шлюз может получить из IP-сети(Invite,Cancel,BYE, ACK,200OK,100Trying,18x,4xx,5xx,6xx), и из PSTN(IAM,ACM,CON,CPG ,ANM,RLC) и от OS (T1expires ,T1.1expires ,T5expires ,T7expires,T9expires , T11expires)
Buffer_out содержит сообщения,которые шлюз посылает к IP-сети (100,18x,invite, 200ok,504 (server timeout), 487, 4xx, 480(temporarily unavailble), BYE,ACK,Cancel), к PSTN (IAM,REL,RLC,RSC,CPG,CON,ANM), к OS(Start T1,Start T5,Start T7,Start T9,Start T1.1,Start T11,Stop T1,StopT1.1,Stop T5,Stop T7,Stop T9,Stop T11)
Программа читает последовательно сообщения из Buffer_in(После чтения и обработии сообщение из Buffer_in удаляется)
В состоянии Idle(Свободно):
Если Code Invite,мы посылаем сообщение 100,IAM,StartT7 в Buffer_out и переходим в состояние Wait_ACM.
Если Code IAM,мы посылаем сообщение Invite,Start T1,Start T11 в Buffer_out и переходим в состояние Wait_SIP Response
В состоянии Wait_ACM
Если Code ACM, мы посылаем сообщение StopT7,18x,Start T9 в Buffer_out и переходим в состояние Wait_ANM
Если Code CON, мы посылаем сообщение Stop T7,200OK,Start T1 в Buffer_out и переходим в состояние Wait_active_ACK
Если Code T7expires, мы посылаем сообщение 504(Server Timeout), REL(cause=102),StartT1,StartT5,StartT1.1 в Buffer_out и переходим в состояние Wait_clear
Если Code Cancel, мы посылаем сообщение Stop T7,200OK ,487, REL (cause=31),StartT1.1,Start T5,StartT1 в Buffer_out и переходим в состояние Wait_clear
Если Code BYE, мы посылаем сообщение Stop T7,200OK ,487, REL (cause=31),StartT1.1,Start T5,StartT1 в Buffer_out и переходим в состояние Wait_clear
Если Code REL, мы посылаем сообщение Stop T7,RLC,4xx,StartT1 в Buffer_out и переходим в состояние Wait_ACK
В состоянии Wait_ANM
Если Code CPG, мы посылаем сообщение 18x в Buffer_out и переходим в состояние Wait_ANM
Если Сode ANM, мы посылаем сообщение StopT9,200OK,StartT1 в Buffer_out и переходим в состояние Wait_Active_ACK
Если Code T9expires, мы посылаем сообщение 480(temporarily unavailble) ,REL(cause=19),StartT1.1,StartT5,StartT1 в Buffer_out и переходим в состояние Wait_clear
Если Code Cancel, мы посылаем сообщение Stop T9,200OK ,487, REL (cause=31),StartT1.1,Start T5,StartT1 в Buffer_out и переходим в состояние Wait_clear
Если с Code BYE, мы посылаем сообщениие Stop T9,200OK ,487, REL (cause=31),StartT1.1,Start T5,StartT1 в Buffer_out и переходит в состояние Wait_clear
Если Code REL, мы посылаем сообщение Stop T9, RLC,4xx,StartT1 в Buffer_out и переходим в состояние Wait_ACK
В состоянии Wait_Active_ACK
Если Code ACK, мы посылаем сообщение StopT1 в Buffer_out и переходим в состояние Active
Если Code Cancel, мы посылаем сообщение StopT1,200OK ,487, REL (cause=31),StartT1.1,Start T5,StartT1 в Buffer_out и переходим в состояние Wait_clear
Если Code BYE, мы посылаем сообщение StopT1,200OK ,487, REL (cause=31),StartT1.1,Start T5,StartT1 в Buffer_out и переходим состояние Wait_clear
Если Code REL, мы посылаем сообщение StopT1, RLC,4xx,StartT1 в Buffer_out и переходим в состояние Wait_ACK
Если Code T1expires,Counter:=Counter+1,if Counter < 7 then мы посылаем сообщение 200OK,StartT1 StartT1 в Buffer_out и переходим в состояние Wait_Active_ACK else посылаем сообщение BYE,REL(cause =102),StartT1.1,StartT5 в Buffer_out и переходим в состояние Wait_RLC
В состоянии Wait_ACK
Если Code T1expires, мы посылаем сообщение BYE в Buffer_out и переходим в состояние Idle
Если Code 200OK, мы посылаем сообщение StopT1 в Buffer_out и переходим в состояние Idle
Если Code ACK ,мы посылаем сообщение StopT1 в Buffer_out и переходим в состояние Idle
В состоянии Active
Если Code BYE, мы посылаем сообщение 200OK,REl(cause=16),StartT1.1 ,StartT5 в Buffer_out и переходим в состояние Wait_RLC
Если Code REL, мы посылаем сообщение RLC,BYE,StartT1 в Buffer_out и переходим в состояние Wait_ACK
Если Code 200OK, мы посылаем сообщение ACK в Buffer_out и переходим в состояние Active
Если Code 4xx, мы посылаем сообщение ACK,StopT1,StopT11,StopT9, REL(cause=31),StartT1.1,StartT5 в Buffer_out и переходим в состояние Wait_RLC
Если Code 5xx, мы посылаем сообщение ACK,StopT1,StopT11,StopT9, REL(cause=31),StartT
еще рефераты
Еще работы по разное
Реферат по разное
Учебном процессе программного обеспечения для решения экстремальных задач
17 Сентября 2013
Реферат по разное
| наименование |един|кол-во| цена | цена | | |изм
17 Сентября 2013
Реферат по разное
Опис кредитного модуля (дисципліни)
17 Сентября 2013
Реферат по разное
Агрегирование (aggregation) соединение отдельных единиц или данных в единый показатель
17 Сентября 2013