요약

  • RFC 3372는 PSTN–IP 경계에서 두 가지 역할을 분리했다. ISUP 캡슐화는 기능을 처리할 수 있는 엔드포인트를 위해 레거시 시그널링을 보존했고, 선별된 사실을 SIP 헤더로 번역하는 작업은 SIP 중개자가 요청을 라우팅할 수 있게 만들었다.
  • 어느 쪽 경로도 다른 쪽의 영수증이 아니었다. 보존된 바이트가 올바른 라우팅이나 기능 전달을 증명하지 못했고, SIP 요청이 성공적으로 라우팅되었다고 해서 ISUP의 충실한 재구성, 미디어 설정 또는 사용자 경험이 증명되지 않았다.

한 통화가 전화망을 떠나 IP 네트워크를 건너 다른 지점에서 다시 전화망으로 들어가는 상상을 해 보자. 발신 게이트웨이는 전화망의 풍부한 의미를 담은 ISUP 메시지를 받는다. 중간에 있는 SIP 프록시는 목적지를 선택하기에 충분한 가시 정보를 필요로 한다. 종착 게이트웨이는 SIP 자체가 표현하지 못하는 기능을 재현하기 위해 원본 ISUP 세부 정보가 필요할 수 있다.

2002년 9월 BCP 63으로 공표된 RFC 3372는 이 프레임워크에 SIP-T라는 이름을 붙였다. 저자들은 신중했다. SIP-T는 새 프로토콜이 아니었다. 전통적인 전화 시그널링과 SIP가 공존하게 만드는 관행의 모음이었다. 그 소박한 설명 뒤에는 심오한 회계 문제가 숨어 있었다. 하나의 통화가 서로 연관된 두 개의 기록으로 이동해야 했다.

첫 번째 기록은 캡슐화된 ISUP 메시지였다. 게이트웨이는 RFC 3204에서 규정한 MIME 유형을 사용해 레거시 시그널링 객체를 SIP 메시지 본문 안에 넣었다. 이 채널은 이후 PSTN 게이트웨이가 필요로 할 수 있는 정보, 즉 SIP에 깔끔한 대응물이 없는 파라미터까지 보존했다. PSTN에서 PSTN으로 가는 트랜짓 사례에서는 상대 게이트웨이가 본문을 복원해 템플릿으로 사용할 수 있었다.

두 번째 기록은 SIP 요청 자체였다. 프록시는 Request-URI와 헤더 같은 SIP 가시 요소를 기준으로 라우팅한다. 모든 ISUP 변형을 해석하라고 기대할 수는 없다. 그래서 발신 게이트웨이는 선별된 ISUP 사실—가장 대표적으로 착신 번호—을 중개자가 이해하고 행동할 수 있는 SIP 필드로 번역했다.

RFC 3372는 이 두 가지 목표를 기능 투명성(feature transparency)과 라우팅 가능성(routability)이라 불렀다. 캡슐화가 첫째를, 번역이 둘째를 담당했다. 이 둘을 동의어로 다루었다면 서로 다른 두 가지 장애 양상이 가려졌을 것이다. 손상되지 않은 본문이 네트워크를 건너는 동안 잘못 번역된 헤더가 요청을 엉뚱한 게이트웨이로 보낼 수 있었다. 올바른 경로가 본문이 없거나, 훼손되었거나, 지원되지 않거나, 호환되지 않는 ISUP 변형에 기반한 요청을 전달할 수도 있었다.

종착 게이트웨이는 봉인된 메시지를 단순 재생하지 않았다. 프레임워크는 캡슐화된 ISUP을 템플릿으로 사용하고, SIP 헤더에서 유래한 값을 덮어쓰며, 로컬 정책을 적용할 수 있다고 규정했다. ISUP 본문이 없으면 로컬에 구성된 표준 템플릿에서 시작할 수 있었다. 따라서 재구성은 책임 있는 행위였으며, 원본 통화 상태가 손대지 않고 살아남았다는 증명이 아니었다.

요청이 시작될 때 엔드포인트 유형은 종종 알 수 없었다. PSTN 발신 통화는 다른 게이트웨이에서 끝나거나 순수 SIP 전화기에서 끝날 수 있었다. SIP 전화기가 언젠가 PSTN에 도달할 수 있었지만, 모든 전화기에 ISUP 생성을 요구하는 것은 터무니없었다. 발신 측은 미리 고정된 흐름을 선택할 수 없었다. 아는 것을 공급했고, 최종 종착자는 적용되는 부분을 해석했다.

순수 SIP 엔드포인트는 일반적으로 캡슐화된 ISUP을 무시했다. 그래도 멀티파트 MIME과 알 수 없는 콘텐츠를 우아하게 견뎌야 했다. 이것은 과소평가된 상호운용성 규칙이다. 첨부된 레거시 기록을 이해하지 못하는 것과 요청 전체를 거부하는 것은 다른 문제였다. RFC 2046이 멀티파트의 기반을 제공했고, RFC 3261이 SIP의 세션 프레임워크를 제공했다.

통화 중 시그널링은 또 다른 이음매를 드러냈다. 일부 ISUP 정보는 SIP 세션 상태를 바꾸지 않으면서 통화 도중에 도착할 수 있었다. RFC 3372는 RFC 2976의 SIP INFO 메서드를 운반체로 지목했다. 다시 말하지만, 메시지의 전송이 엔드포인트가 그 의미를 이해했거나 사용자에게 보이는 기능이 발생했다는 뜻은 아니었다.

라우팅 및 번호 작업은 인근에 자리했다. RFC 3219는 전화 라우팅 정보 교환을 위한 TRIP을 기술했고, RFC 2916의 ENUM 작업은 전화번호를 DNS 기반 서비스 정보로 사상했다. 이 메커니즘들은 SIP 요청이 어디로 가야 하는지 판단하는 데 도움을 줄 수 있었다. 그러나 레거시 기능 맥락에 필요한 ISUP 기록을 대체하지는 못했다.

보안도 두 기록을 하나로 합치지 않았다. RFC 3372는 SIP-T 엔드포인트에 S/MIME 서명 지원을 요구하고 암호화를 권고했으며, 이는 RFC 2633에 기반했다. 서명은 운반되는 콘텐츠를 보호할 수 있었다. 그러나 게이트웨이가 올바른 필드를 번역했는지, 올바른 출구를 선택했는지, 정당한 로컬 정책을 적용했는지, 베어러 경로를 완성했는지는 증명하지 못했다.

이후 문서들은 인접한 풍경의 부분들을 정교하게 다듬었다. RFC 3398은 상세한 SIP–ISUP 상호접속을 규정했다. RFC 3326은 SIP 메시지가 프로토콜 한정 이유를 실을 수 있게 했지만, 이유는 맥락을 설명할 뿐 프로토콜 동작을 수행하지 않았다. RFC 3331과 RFC 3332는 SS7 적응 기능을 SCTP 위에 놓았다. 이들은 링크 또는 MTP 사용자 상태가 어디에 사는지 답하며, 하나의 통화가 불투명한 레거시 의미와 가시적인 IP 라우팅 데이터로서 동시에 살아남는 방법이라는 SIP-T의 질문에는 답하지 않는다.

공식 기록은 도입 현황 조사나 승리적 대체 서사를 뒷받침하지 않는다. 그러나 정밀한 역사적 교훈은 뒷받침한다. 상호접속은 하나의 진실을 다른 진실로 바꾸고 원본을 버리는 변환기가 아니었다. 그것은 각기 다른 행위자에게 유용한 표현들의 통제된 공존이었다.

Lu Heng의 “최소 초기 명세(Minimum Initial Specification)” 관점은 이 절제를 설명해 준다. 가장 작은 공통 기계를 표준화하고, 지역화된 결정은 가시적으로 남겨 두라는 것이다. “현실의 층위들에 대하여(On Reality Layers)”는 근거 규율을 더한다. 수신된 SS7, 캡슐화된 본문, 번역된 헤더, 프록시 경로, 재구성된 출구 메시지, 베어러 경로, 인간의 경험은 연관되어 있지만 서로 구별되는 현실의 층위들이다.

인터넷은 그 층위들을 동일하게 만들어 전화망을 흡수하지 않았다. RFC 3372는 게이트웨이가 옛 시스템이 말한 것을 보존하면서, 동시에 새 시스템이 라우팅할 수 있는 것을 별도로 노출해야 한다는 점을 인정함으로써 경계를 작동 가능하게 만들었다. 이중 기록은 중복이 아니었다. 운반과 의미가 같은 증명이라고 가장하지 않고 아키텍처를 건너기 위한 대가였다.

출처