Кратко

  • RFC 3057 отделил физическое завершение D-канала ISDN от места обработки вызовов Q.931: шлюз сигнализации завершал Q.921, а IUA передавал границу пользователя Q.921 через SCTP к серверу приложений.
  • Переключение ASP могло направить сигнализацию другому процессу, но восстановление транспорта не восстанавливало состояние вызова. В RFC 4233, который позднее заменил RFC 3057, прямо сказано: вызовы в переходной фазе могут завершиться неудачей, если процессы не разделяют состояние способом, лежащим вне IUA.

Перенос верхнего уровня, а не линии

В традиционной сети ISDN D-канал несёт сигнализацию, с помощью которой оконечное оборудование устанавливает и обслуживает вызовы с коммутацией каналов. На нижнем уровне Q.921 предоставляет службу канального звена. Q.931 и QSIG используют её как пользователи Q.921. RFC 3057 разделил функции именно на этой границе протокола.

Шлюз сигнализации (SG) принимал сообщения со стандартного интерфейса ISDN и завершал Q.921. На стороне IP контроллер медиашлюза (MGC) размещал одноранговый уровень Q.931 и логику управления вызовами. Между ними уровень адаптации пользователей ISDN Q.921 — IUA — переносил примитивы интерфейса по SCTP. Это не означало, что абонентская линия, D-канал или каждый телефонный канал стали объектами IP. IUA давал возможность передавать вышележащую функцию сигнализации, сохраняя старый интерфейс на SG.

Для эксплуатации это различие принципиально. Примитив Q.921 DL-DATA может доставить сообщение Q.931; примитивы установления, освобождения и передачи данных без установления соединения сообщают о разных состояниях линии. Поэтому IUA должен был сохранять и идентичность интерфейса, и семантику границы. За физический канал сигнализации и локальное поведение Q.921 продолжал отвечать шлюз. Удалённый контроллер обрабатывал сообщения управления вызовами, не выдавая это за владение самим D-каналом.

Один идентификатор интерфейса — одна локальная привязка

Interface Identifier в IUA связывал сообщение с физическим интерфейсом на SG. В зависимости от реализации он мог быть числом или текстовой меткой, однако смысл оставался локальным: значение согласовывали SG и сервер приложений. RFC прямо не делал этот идентификатор общим для разных шлюзов. Похожая на глобальное имя метка в действительности служила локальным ключом сопоставления контекстов сигнализации.

На этой привязке держалась передача сигнализации. SG связывал идентификатор интерфейса с сервером приложений и активным процессом сервера приложений (ASP). Сервер приложений необязательно был одной машиной: это могла быть логическая служба с упорядоченным набором процессов ASP — например, основного и резервного контроллеров. Для каждого интерфейса сигнализации шлюзу требовалось знать, какой процесс активен; при переключении эта привязка могла измениться.

RFC 3057 рекомендовал SCTP и отдельный поток SCTP для каждого D-канала, чтобы уменьшить буферизацию и задержки между независимыми каналами. Поток был механизмом транспорта; Interface Identifier по-прежнему сообщал узлу-партнёру, о каком физическом интерфейсе идёт речь. Состояния ассоциации и потоков, локальная карта интерфейсов и активность ASP были связаны, но не подменяли друг друга.

Переключение не означает общую память о вызовах

Модель резервирования выбирал оператор. В варианте 1+0 резервирования ASP не было. В схеме 1+1 один процесс обслуживал трафик, другой мог принять его на себя. Более общая модель n+k предполагала n процессов, необходимых для нагрузки, и k резервных процессов на замену недоступным. Сообщения IUA позволяли SG и ASP обмениваться сведениями о состоянии процессов и определять, куда направлять новую сигнализацию.

Но работающая ассоциация с резервным процессом не говорит, что тот знает состояние вызова, который ещё устанавливается. RFC 4233, опубликованный в 2006 году и заменивший RFC 3057, сформулировал это явно. В сетях операторского класса стабильные вызовы SHOULD NOT прерываться при отказе одного ASP; для этого ASP может потребоваться совместно поддерживать состояние вызовов. Во время переключения вызовы, находящиеся в переходной фазе, MAY завершиться неудачей. Общая память или протокол между ASP способны снизить риск, но такой протокол выходит за рамки IUA.

Это не скрытый недостаток SCTP. SCTP сообщает состояние ассоциации, упорядочивает пользовательские сообщения внутри потоков и поддерживает многосетевую доступность. Это свойства транспорта. Они не сообщают, какие решения по вызову уже принял отказавший контроллер, дошло ли сообщение до другой стороны и был ли вызов уже установлен или ещё менял состояние. IUA мог изменить путь сигнализации; непрерывность работы приложения оставалась отдельной задачей.

Что изменил стандарт — и чего он не доказал

Опубликованный в феврале 2001 года RFC 3057 добавил к архитектуре SIGTRAN адаптацию для пользователей ISDN Q.921. Он позволил распределить обработку вызовов и передавать сигнализацию по IP, сохранив стандартизованную границу с сетью коммутации каналов. В 2006 году RFC 4233 заменил документ и уточнил ту же адаптацию. Эта история фиксирует развитие протокола, но сама по себе не доказывает, какие операторы внедрили его, какое оборудование закупили или сколько вызовов удалось сохранить при реальном отказе.

Долговременный инженерный вывод уже, чем формула «телефония перешла на IP». Граница службы может переместиться, пока физический интерфейс остаётся в другом месте. Для шлюза, завершающего линию, адаптации пользовательских примитивов, транспортной ассоциации, принимающего процесса и состояния приложения, объединяющего последовательность сообщений в один вызов, нужны отдельные свидетельства. Зелёный индикатор SCTP или активный ASP — ещё не подтверждение успешно завершённого вызова.

Источники