26. Получив сообщение REL, удаленный узел ISUP отвечает сообщением RLC.
27. Узел SIP посылает АСК для подтверждения приема финального ответа INVITE.
2.7.1.7. Отмена вызова на стороне SIP
28. Когда пользователь SIP инициирует сеанс связи с пользователем ТфОП, узел SIP генерирует запрос INVITE.
29. Приняв запрос INVITE, шлюз отображает его в сообщение IAM и посылает его в сеть ISUP.
30. Удаленный узел ISUP информирует, что адрес достаточен для установления соединения путем посылки сообщения АСМ.
31. Код «called party status» (статус вызываемой стороны) из сообщения АСМ отображается в промежуточный ответ SIP.
32. Для завершения вызова до ответа абонента узел SIP посылает запрос CANCEL.
33. Запрос CANCEL подтверждается ответом 200.
34. Получив запрос CANCEL, шлюз посылает ISUP сообщение REL для завершения вызова.
35. Шлюз посылает сообщение «478 Call Cancelled» (вызов отменен) на узел SIP для завершения транзакции INVITE.
36. Получив сообщение REL, удаленный узел ISUP отвечает сообщением RLC.
37. Получив сообщение 487, узел SIP подтверждает прием сообщением АСК.
2.7.2. Конечный автомат (State Machine)
Сообщение REL может быть получено в любом состоянии; для всех случаев оно обрабатывается одинаково.
2.7.2.1. Прием запроса INVITE
Приняв запрос INVITE, шлюз может послать назад в сеть SIP ответ «100 Trying», информируя, что шлюз обрабатывает вызов.
Необходимые аппаратные ресурсы для медиа-потока должны быть зарезервированы в шлюзе сразу после получения INVITE, т.к. сооб-
шение 1АМ не может быть отправлено прежде, чем ресурсы будут зарезервированы (особенно выбор ТС1С). Обычно ресурсы состоят из тайм-слота в Е1 и RTP/UDP-порта на стороне IP. Ресурсы также могут включать в себя некоторые меры по обеспечению качества обслуживания (однако в данном документе такие меры не приведены). Прежде, чем послать сообщение IAM, шлюз должен установить медиа-канал в обратном направлении (за исключением тех случаев, когда политика провайдера полагает такие действия небезопасными).
После посылки IAM запускается таймер Т7. Значение таймера Т7 по умолчанию находится в пределах от 20 до 30 секунд. Шлюз переходит в состояние Trying.
Процедуры отображенияINVITEна IAM
Этот раздел описывает отображение заголовков SIP сообщения INVITE в параметры ISUP в Начальном адресном сообщении — Initial Address Message (IAM). Шлюз ТфОП-SIP отвечает за генерацию сообщения IAM при получении INVITE.
В сообщении IAM содержится пять обязательных параметров: Номер вызываемой стороны — Called Party Number (CPN), Индикатор типа соединения — Nature of Connection Indicator (NCI), Прямые индикаторы вызова — Forward Call Indicators (FCI), Категория вызывающей стороны — Calling Partys Category (CPC), и, наконец, параметр, определяющий желательные параметры передачи вызова — в некоторых вариантах ISUP необходимы Требования к среде передачи — Transmission Medium Requirement (TMR), в других — Информация по услуге пользователя — User Service Information (USI) (или оба этих параметра). Все сообщения IAM должны содержать как минимум эти пять параметров. Таким образом, любой шлюз должен иметь значения для каждого из этих пяти параметров после получения сообщения INVITE. Многие из значений, используемых в этих параметрах (такие как NCI или USI), будут, весьма вероятно, одними и теми же для всех сообщений, генерируемых шлюзом. Другие (например, CPN) будут изменяться от вызова к вызову; для правильного заполнения этих параметров шлюз извлекает информацию из INVITE.
Существуют также довольно много опциональных параметров, которые могут содержаться в сообщении IAM; в Q.763 перечислены в общей сложности 29 опциональных параметров. Однако, не требуется транслировать каждый из этих параметров для достижения задач отображения SIP-ISUP. Как было сказано выше, трансляция позво-
ляет элементам сети SIP понимать основной контекст ТфОП для сеанса (для кого она предназначена и т.д.), если они не в состоянии декодировать инкапсулированный ISUP. Параметры, значимые только для ТфОП, передаются через сети ТфОП-81Р-ТфОП посредством инкапсуляции — трансляция для этих параметров не требуется. Из 29 вышеуказанных параметров только следующие непосредственно требуют трансляции: Номер вызывающей стороны Calling Partys Number (CIN, обычно присутствует), выбор транзитной сети Transit Network Selection (TNS), идентификационный параметр передачи — Параметр идентификации транспортной сети Carrier Identification Parameter (CIP, существует в сетях ANSI), Первоначально вызываемый номер — Original Called Number (OCN), и Generic Digits (в некоторых вариантах известен как Параметр типового адреса — Generic Address Parameter (GAP)).
Когда запрос SIP INVITE поступает на шлюз ТфОП, шлюз должен попытаться использовать инкапсулированный ISUP, если он присутствует в INVITE, для поддержки редактирования исходящей сигнализации ТфОП. Если это возможно, шлюз должен попытаться повторно использовать значения параметров ISUP инкапсулированного сообщения IAM при составлении сообщения, которое шлюз посылает через интерфейс ТфОП. В некоторых случаях, шлюз не в состоянии использовать этот ISUP, например в тех случаях, когда шлюз не понимает вариант ISUP и поэтому должен игнорировать инкапсулированное тело. Даже когда имеется понятный инкапсулированный ISUP, соответствующие значения полей заголовка SIP должны быть «перезаписаны» посредством процесса трансляции значений параметров, которые должны быть установлены на основе инкапсулированной ISUP. Другими словами, обновление критических параметров контекста сеанса, созданных в сети SIP, в «мостовых» случаях типа ISUP-SIP-ISUP, имеет преимущество перед инкапсулированной сигнализацией ISUP. Это позволяет осуществить в сетях SIP множество основных услуг, включая различные виды продвижения и перенаправления вызова.
Например, если на шлюз поступает INVITE с инкапсулированным IAM, поле CPN которого содержит телефонный номер +12025332699, но Request-URI запроса INVITE содержит tel:+15105550110, при создании IAM, которое шлюз должен послать в ТфОП, он должен отдать предпочтение телефонному номеру из Request-URI, а не инкапсулированному IAM.
Когда вызов SIP маршрутизируется к шлюзу, Request-URI весьма вероятно содержит tel URL (или SIP URI с пользовательской частью SIP URI) — шлюзы SIP-ISUP, получающие Request-URI, которые не
содержат корректных телефонных номеров, должны отвергать такие запросы с соответствующим кодом ответа. Тем не менее шлюзы должны продолжать обработку вызовов с полем From заголовка, не содержащем телефонного номера, иногда могут быть случаи, когда вызов исходит от SIP-телефона, использующего SIP URI user@host. Параметр CIN должен быть изъят из отправляемого IAM, если поле From не используется. Следует заметить, что альтернативные реализации шлюзов могут применять некоторые нестандартные пути отображения соответствующих SIP URI в телефонные номера.
Когда шлюз получает сообщение с (понятным) инкапсулированным ISUP, он должен установить значение параметра индикатора FCI сообщением для всех бит в параметре, касающемся взаимодействия в отправляемом IAM, в соответствии с инкапсулированным сообщением ISUP. Если инкапсулированный ISUP не присутствует в INVITE, полученным шлюзом, рекомендуется, чтобы шлюз устанавливал бит индикатора взаимодействия (Interworking Indicator) FCI в no interworking и ISDN User Part Indicator в ISUP used all the way; шлюз также может установить Originating Access indicator в Originating access non-ISDN.
Следует заметить, что когда interworking encountered установлен в параметре Forward Call Indicators (FCI) IAM, это показывает, что ISUP взаимодействует с сетью, которая не способна предоставить столько же услуг, сколько ISUP. Сеть ОКС №7 (ISUP) поэтому не будет использовать некоторые возможности, которые использовала бы в нормальном случае, включая потенциальное использование ISDN кодов причины в случае отказа (как противоположность посылке АСМ следом за аудиоуведомлением). Если требуется, производители шлюзов могут предоставлять конфигурируемую опцию, используемую для разграничения поставщиков услуг, которая будет сигнализировать в FCI, что взаимодействие имело место (и что ISUP не используется на всем пути), когда инкапсулированный ISUP не применяется; однако такие действия значительно ограничивают эффективность и прозрачность трансляции SIP-ISUP.
2.7.2.2. Истечение таймера ISUP T7
Т.к. от ТфОП не получено ответа, все ресурсы в MG освобождаются. Сообщение 504 Server Timeout должно быть послано в сеть SIP. В сторону ТфОП посылается сообщение REL со значением кода причины 102 (ошибка протокола, восстановление по тайм-ауту). Шлюз ожидает со стороны ТфОП ответа RLC, а со стороны сети SIP ответа АСК, подтверждающего, что действия по разъединению выполнены.
2.7.2.3. Получение CANCEL или BYE
Если запрос CANCEL или BYE получен до того, как был послан финальный ответ SIP, в сеть SIP должно быть отправлено сообщение 200 ОК для подтверждения CANCEL или BYE; также должно быть отправлено сообщение 487 для завершения транзакции INVITE. Все ресурсы освобождаются и в сеть ТфОП должно быть послано сообщение REL с указанием значения причины 16 (нормальное освобождение). Шлюз ожидает со стороны ТфОП сообщения RLC для подтверждения разъединения.
В «мостовой» ситуации использования SIP REL может быть инкапсулировано в тело запроса BYE. Несмотря на то, что BYE обычно отображается в код причины 16 (нормальное освобождение), в исключительных случаях код причины может быть другим. Поэтому параметр Cause Indicator инкапсулированного REL должен быть использован повторно в REL, отправляемом в ТфОП.
Запрос BYE или CANCEL может содержать заголовок Reason, который должен быть отображен в параметре Cause Indicator. Если BYE и заголовок Reason, и инкапсулированный ISUP, значение заголовка Reason является предпочтительным.
Все ресурсы в шлюзе должны быть освобождены, прежде чем шлюз пошлет сообщение REL.
2.7.2.4. Получение REL
Этот раздел применим, когда REL принят до отправки финального ответа SIP. Обычно такая ситуация возникает, когда вызов отклоняется со стороны ТфОП.
Все ресурсы шлюза должны быть немедленно освобождены и в сеть ISUP должно быть отправлено сообщение RLC для уведомления, что канал доступен для повторного использования.
Если INVITE, породивший эту транзакцию, содержал правильное и понятное сообщение ISUP (например, IAM поддерживаемого шлюзом варианта, предпочтительно с цифровой подписью), то инкапсулированный ISUP должен быть отправлен в ответ на INVITE когда возможно (т.к. это предполагается в случае ISUP-SIP-ISUP) — следовательно, сообщение REL, в точности как было принято, должно быть включено в тело запроса SIP. Шлюз не должен возвращать запрос с инкапсулированной ISUP, если отправитель сам не включил ISUP.
Следует заметить, что получение некоторых сообщений техобслуживания в ответ на IAM, таких как Сообщение блокировки (BLO) или Сообщение перезапуска канала (RSC), может также привести к разъединению вызова в этом состоянии.
Отображениекодовпричины (CauseCode) ISDNвкодсостояния
Применение сообщения REL в сети ОКС №7 весьма широко, в то время как SIP имеет несколько специфичных средств, играющих ту же роль, а именно — BYE, CANCEL, и различные коды status/response. Сообщение REL может быть отправлено для разъединения уже установленного вызова (BYE), для отмены посланного до него запроса на установление соединения, которое еще не завершено (CANCEL), или для отклонения принятого запроса на установление вызова (IAM) (соответствует коду статуса (status code) в SIP).
Следует заметить, что не требуется отображать некоторые коды причины ISDN в сообщения SIP, т.к. эти коды значимы только для интерфейса ISUP-шлюза. Хорошим примером для этого является код причины 44 ;Request circuit or channel not available; (Запрашиваемый тракт или канал не существует). 44 означает, что Код идентификации канала (Circuit Identification Code — CIC), для которого посылался IAM, был переведен принимающим оборудованием в состояние, не совместимое с новым вызовом — однако, подходящим поведением в этом случае будет послать IAM с другим CIC, не отменяя вызов. Проще говоря, нет кода S1P, который говорит, что должен быть выбран новый оператор — этот вопрос является внутренним по отношению к исходному шлюзу.
Следовательно, получение кода причины 44 не имеет следствием посылку какого-либо SIP status code; <этот> код причины не транслируется.
Если значение полученного кода причины другое, нежели нижеприведенные, по умолчанию должен быть использован ответ 500 Server internal error.
Наконец, в дополнение к кодам причины ISDN, параметр CAI также содержит причину location, которая дает возможность определить, какой объект в сети отвечает за завершение вызова (наиболее значительные различия существуют между пользователем и сетью). В большинстве случаев местоположение причины (cause location) не отображается в SIP status code; некоторые исключения рассмотрены ниже. В случае некоторых причин присутствует также поле диагнос-
тики (diagnostic field); это поле содержит дополнительные данные о завершении вызова.
Рекомендуются следующие значения для отображения:
Normal event
ISUP Cause value SIP response
1 unallocated number.................404 Not Found
2 no route to network................404 Not found
3 no route to destination..............404 Not found
16 normal call clearing................— ()
17 user busy.........................486 Busy here
18 no user responding.................408 Request Timeout
19 no answer from the user.............480 Temporarily unavailable
20 subscriber absent...................480 Temporarily unavailable
21 call rejected.......................403 Forbidden (+)
22 number changed (w/o diagnostic).....410 Gone
22 number changed (w/ diagnostic)......301 Moved Permanently
23 redirection to new destination........410 Gone
26 non-selected user clearing...........404 Not Found (=)
27 destination out of order.............502 Bad Gateway
28 address incomplete.................484 Address incomplete
29 facility rejected....................501 Not implemented
31 normal unspecified.................480 Temporarily unavailable
() ISDN Cause 16 обычно порождает BYE или CANCEL.
(+) Если cause location имеет значение user, то скорее код будет бхх, чем код 4хх.
(=) Процедура ANSI — в сетях ANSI, причина 26 переопределена как misrouted ported number. В других случаях причина 26 обычно не используется в процедурах ISUP.
REL с ISDN cause 22 (номер изменен) может содержать информацию о новом номере, где вызываемый пользователь может быть доступен, в поле диагностики. Если MGC способен обработать эту информацию, она должна быть добавлена в ответ SIP (301) в заголовок Contact.
Ресурснедоступен
Этот вид значения причины (cause value) означает временный отказ. Заголовок Retry-After может быть добавлен к ответу, если это целесообразно.
ISUP Cause value SIP response
34 no circuit available.................503 Service unavailable
38 network out of order................503 Service unavailable
41 temporary failure...................503 Service unavailable
42 switching equipment congestion.......503 Service unavailable