요약

  • RFC 3136은 전화망 트리거가 인터넷 사용자에게 알림을 보내고, 사용자가 선택한 통화 처리를 다시 전화 서비스 제어 쪽으로 전달하는 SPIRITS 아키텍처를 기술했다.
  • 선택 자체는 처리가 아니었다. 게이트웨이와 SPIRITS 클라이언트가 이를 전달해야 했고, 서비스 제어 기능(SCF)이 이를 동작으로 변환해야 했으며, 교환기가 통화 처리를 재개해야 발신자가 볼 수 있는 결과가 존재했다.

버튼은 두 시스템의 경계에 있었다

2001년 다이얼업 인터넷에서 한 동선은 모뎀 세션 또는 일반적인 착신 전화 중 하나를 실을 수 있었다. 회선 소유자가 웹을 읽는 동안 발신자는 전화망에서 마주하게 된다. 인터넷 착신 통화 대기(Internet Call Waiting)는 두 세계가 하나가 되었다고 속이지 않으면서 이들을 연결하겠다고 약속했다.

가입자의 컴퓨터는 발신자의 번호나 이름을 표시하고 메뉴를 제공할 수 있었다. 인터넷 세션을 끝내고 통화를 받는다. 다른 번호로 전환한다. 음성사서함으로 보낸다. 녹음된 안내 메시지를 재생한다. 거절한다. 일부 설명에서는 VoIP도 가능성으로 언급되었지만, RFC 3136은 제안된 아키텍처가 그 기능을 다루지 않는다고 명시했다.

메뉴는 그 순간을 이해할 수 있게 만들었다. 동시에 잘못된 결론을 끌어내기도 쉽게 했다. 가입자가 '전환'을 누르는 즉시 화면은 선택이 이루어졌다고 보고할 수 있었다. 그러나 그 통화가 대체 번호에 도달했는지는 보장되지 않았다. 버튼은 IP 호스트에 있었고, 보류 중인 통화는 전화 교환기에 있었다. 그 사이에는 여러 행위자, 여러 인터페이스, 그리고 지연·거절·실패의 여러 기회가 놓여 있었다.

RFC 3136의 기여는 바로 그 거리를 그려낸 것이었다. 2001년 6월 Informational RFC로 발표된The SPIRITS Architecture는 완전한 프로토콜을 명세하지 않았다. 공중 교환 전화망에서 시작되어 인터넷 상호작용이 필요한 서비스를 위해 구성 요소와 그들 사이의 논리적 경로를 명명했다. 이 문서의 소박한 지위가 중요하다. 아키텍처는 결정이 어디를 거쳐야 하는지 알려줄 수 있지만, 특정 네트워크가 그 경로를 구현했다는 증거가 되지는 못한다.

트리거는 전화망의 것이었다

첫 번째 사실은 브라우저에서 오지 않았다. 보통 전화 교환기에 위치하는 서비스 교환 기능(SSF)은 지능형 네트워크 트리거를 인식하고 서비스 제어 기능(SCF)과 상호작용했다. SCF는 서비스 로직을 실행하고 교환기에 통화 완료 방법을 지시할 수 있었다.

이것이 체인의 첫 번째 경계다. 벨이 울리는 것, 교환기가 해당 트리거를 인식하는 것, 서비스 제어가 호출되는 것은 서로 연관된 사건이지 동의어가 아니다. 트리거가 없거나 잘못 프로비저닝되었거나 SCF에 도달하지 못했다면, 인터넷 알림이 그 빠진 시작을 메울 수 없다. 트리거가 발화했다 해도 그 사실만으로 가입자에게 통보되었는지는 말해주지 않는다.

RFC 3136은 전화 제어 쪽에 SPIRITS 클라이언트를 두었다. 클라이언트는 SCF로부터 요청을 받고 응답을 돌려보냈다. 클라이언트는 SCF와 공동 배치되거나 인터페이스 D를 통해 통신할 수 있었다. 이 단서는 다이어그램을 너무 문자 그대로 읽는 것을 막는다. 논리적 역할은 책임을 기술할 뿐, 별개의 박스·벤더·관리 도메인을 증명하지 못한다.

아키텍처는 전화 측과 인터넷 측 기능 사이의 중개자로 SPIRITS 게이트웨이를 사용했다. 게이트웨이는 PINT 구성 요소와 공동 배치될 수 있었다. SPIRITS 서버는 가입자와의 상호작용—착신 알림과 선택된 처리의 중계—을 담당했다. 다시 말해 '서버', '게이트웨이', '클라이언트'는 책임의 라벨이었다. 공동 배치는 홉을 줄일 수 있어도 근거 단계를 지우지는 못했다.

다섯 인터페이스, 다섯 가지 다른 주장

RFC 3136은 인터페이스를 A부터 E까지 라벨링했다. 알파벳이 암시하는 것보다 그 차이가 더 가치가 있다.

인터페이스 A는 가입자 호스트에서 PINT 서버로 가는 PINT 요청을 실었다. SPIRITS 시나리오에서 그 주된 역할은 세션 등록이자 곧 서비스 활성화였고, 구독에도 사용될 수 있었다. 성공적인 등록은 일정 기간 동안 활성화된 관계를 성립시켰다. 그러나 그것은 이후 전화 트리거가 발생했는지, 인터넷 호스트가 여전히 도달 가능한지, 선택된 처리가 실행될지를 증명하지 못했다.

인터페이스 B는 가입자의 SPIRITS 서버와 게이트웨이 사이를 가로질렀다. 두 가지 주된 목적이 있었다: 착신 통화(가능한 경우 이름 또는 번호 포함)를 가입자에게 알리고, 가입자가 그 자리에서 선택한 처리를 게이트웨이 쪽으로 전달하는 것. 두 방향은 연결되어 있지만 대칭이 아니었다. 알림을 받았다고 응답이 돌아왔다는 증거는 아니고, 처리를 보냈다고 게이트웨이가 그것을 수락하거나 전달했다는 증거도 아니다.

인터페이스 C는 게이트웨이를 전화 측 SPIRITS 클라이언트에 연결했다. RFC 3136은 게이트웨이가 SPIRITS 서버와 통신하거나 가상 서버로 동작해 스스로 요청을 종단할 수 있도록 허용했다. 따라서 게이트웨이의 로그는 구현 방식에 따라 서로 다른 의미를 가질 수 있었다. '여기서 종단됨'은 유효한 아키텍처적 종점일 수도 있고, 메시지가 다른 프로세스로 계속 이어졌다는 증거가 아닐 수도 있다.

인터페이스 D는 SPIRITS 클라이언트와 SCF를 연결했다. 트리거 파라미터가 서비스 제어에서 클라이언트 쪽으로 이동했고, 사용자의 통화 처리가 다시 돌아왔다. RFC 3136이 결정적인 진술을 한 곳이 바로 여기다: SCF가 사용자의 처리 선택을 적절한 동작으로 '변환'하고 SSP에서 보류된 통화 처리를 재개한다는 것이었다.

인터페이스 E는 PINT 요청을 실행을 위해 SCF로 보냈다. PINT는 반대 방향—전화망에 서비스를 수행하도록 요청하는 인터넷 요청—으로 동작했지만, RFC 3136은 그 기능을 등록과 결합 아키텍처에 재사용했다. 재사용이 PINT 요청, SPIRITS 알림, 전화 동작을 하나의 기록으로 만들지는 않았다.

선택은 여전히 동작으로 번역되어야 했다

가입자가 '거절'을 선택했다고 하자. IP 호스트는 클릭을 완벽하게 기록할 수 있다. SPIRITS 서버는 그것을 직렬화할 수 있다. 게이트웨이는 수락할 수 있다. 클라이언트는 인터페이스 D를 통해 처리 선택을 전달할 수 있다. 그러나 그 어떤 기록도 아직은 발신자가 듣는 안내문도, 보류된 통화의 해제도 아니다.

SCF는 또 하나의 판단을 소유한다. 서비스 로직과 현재 통화 상태의 맥락에서 사용자가 선택한 처리를 해석한 뒤, 추상적 선택을 전화망이 이해하는 동작으로 변환해야 한다. '거절'은 안내문 재생과 단선을 필요로 할 수 있다. '전환'은 목적지, 자격 요건, 추가 통화 처리를 필요로 한다. '수락'은 회선이 음성을 실을 수 있기 전에 다이얼업 세션을 끝내야 할 수 있다. 각 단계마다 고유한 정책과 실패 지점이 있다.

그다음 교환기가 움직여야 한다. 서비스 제어가 대기하는 동안 통화는 이미 보류 상태일 수 있다. 너무 늦게 도착한 응답은 메시지로는 옳지만 처리로는 쓸모없을 수 있다. 전환 목적지가 문법상 유효해도 도달 불가능할 수 있다. 사전 녹음된 안내문은 들리지 않은 채 시작할 수 있다. 음성사서함은 사용 가능한 메시지를 남기지 않고 응답할 수 있다. 아키텍처는 모든 최종 효과를 관찰하겠다고 약속하지 않았다.

따라서 근거의 사다리는 인터페이스 다이어그램보다 길다: 등록; 트리거 인식; 알림 발신; 알림 전달 및 표시; 처리 선택; 서버/게이트웨이/클라이언트 수신; SCF 변환; 교환기 재개 및 실행; 목적지 결과; 그리고 독립적인 재확인. 한 단에서 받은 접수증이 다음 단을 조용히 증명해줄 수는 없다.

통화 기록은 여전히 관찰자의 서술이었다

RFC 3136은 실시간 선택뿐 아니라 자동 처리도 기술했다. 가입자는 기본 처리나 특정 발신 번호에 대한 규칙을 설정할 수 있었다. 시스템은 통화를 실시간으로 제시하지 않고 처리한 뒤, 가입자가 시간, 발신 번호, 발신자 이름, 처리 선택을 담은 로그를 확인하도록 할 수 있었다.

로그는 유용했다. 그러나 전지적이지는 않았다. '전환'은 선택된 정책, 서비스 제어가 발신한 명령, 또는 구현이 분류한 결과 중 무엇이든 기록했을 수 있다. 그것들은 서로 다른 사건이다. 기록이 자신의 관찰 지점과 완료 규칙을 명시하지 않는 한, 대체 회선이 울렸는지, 누군가 응답했는지, 발신자가 기대한 안내문을 들었는지, 하류 시스템이 무언가를 보관했는지를 확립할 수 없다.

이른 RFC 2995는 SPIRITS 이전의 네 가지 구현을 조사하며 이 주의가 왜 필요한지 보여주었다. 모두 인터넷 착신 통화 대기를 지원했고, 대부분 SIP를 사용했으며, 전화 측에서는 지능형 네트워크 메커니즘을 사용했다. 그러나 문서는 구현들이 모두 상호운용되지는 않았다고 명시했고, SIP 기반 구현들조차 반드시 같은 SIP 버전을 공유하지는 않았다. 'SPIRITS 서버'는 그 시스템들에서 하나의 보편적 의미를 갖지 않았다.

그 구현 코드 근거는 실재했지만 한계가 있었다. 명명된 조직들이 SPIRITS 유사 서비스를 구축하고 특정 통화 흐름을 보고했다는 것은 보여준다. 그러나 RFC 3136의 모든 구성 요소를 배포된 보편적 인터페이스로, 모든 기록된 '성공'을 독립적으로 검증된 발신자 결과로 바꾸어주지는 못했다.

알림과 제어는 같은 서비스가 아니었다

이후 RFC 3298의 프로토콜 요구사항은 이 구분을 더 날카롭게 했다. 최소 SPIRITS 프로토콜은 PINT 서비스나 전화망과의 지속적 상호작용에 의존하지 않으면서 기본 알림을 지원해야 했다. 따라서 시스템은 인터넷 호스트에 사건이 발생했다고 알리면서 그 호스트에 통화를 바꿀 권한을 주지 않을 수 있었다.

통화 처리에 대해 RFC 3298은 남은 체인을 명시적으로 그렸다: 등록, 사건 알림, 통화 처리 선택, 서비스 제어, 그리고 SSP. 알림에 대한 반응이 SPIRITS 서비스 전달에 필요한 남은 요소라고 불렀다. 처리 어휘에는 수락, 거절, 리다이렉트가 포함되었고, VoIP를 통한 수락은 워킹 그룹의 범위 밖이었다.

이것은 사용자 인터페이스 설계에 유용한 한계였다. 알림 카드는 어떤 제어도 제공하지 않으면서 '착신 통화'라고 정직하게 말할 수 있다. 제어 버튼은 실행이 보류 중인 상태에서도 '요청이 전송됨'이라고 정직하게 말할 수 있다. 둘을 하나의 초록색 체크표시로 합치면 표준화 작업이 분리해놓은 아키텍처 그 자체를 지워버린다.

2004년에 발표된 RFC 3910은 나중에 SIP SUBSCRIBE와 NOTIFY, 그리고 XML을 사용하는 SPIRITS 이벤트 패키지를 명세했다. 프로토콜 논의를 위해 혼란스러운 논리적 역할의 이름을 바꿨다: 인터넷 측 서버는 사건의 구독자였고, 전화 측 클라이언트는 통보자였다. 이름이 바뀐 이유는 어느 쪽이 옛날에 클라이언트나 서버로 불렸는가보다 누가 구독을 시작하고 누가 알림을 발신하는가가 더 중요했기 때문이다.

프로토콜은 응답을 요청하는 감지점과 단순히 알림만 하는 감지점도 구분했다. 요청 감지점은 응답이 도착할 때까지 통화 처리를 보류했다. 알림 감지점은 사건이 보고된 뒤에도 처리가 계속되도록 허용했다. 같은 사건 어휘가 두 개의 서로 다른 권한 경로 위에 놓일 수 있었던 것이다. NOTIFY를 본다고 해서 운영자가 통화가 인터넷 측 판단을 위해 일시정지했다는 것을 알 수는 없었다.

구독 수락조차 단계가 있었다. RFC 3910은202응답 뒤에 요청이 수락되어 처리 중이라고 말하는 즉시 NOTIFY가 이어지고, 감지점이 초기화된 뒤 또 하나의 NOTIFY가 오는 것을 허용했다.200경로는 '처리 중' 상태를 건너뛸 수 있지만 여전히 상태 알림이 필요했다. 수락됨, 초기화됨, 이후 발화됨은 의도적으로 분리되어 있었다.

가장 중대한 인터페이스는 로컬에 남았다

RFC 3910은 인터페이스 B와 C에 초점을 맞췄다. SCF로의 연결인 인터페이스 D는 로컬 정책의 문제이며 상세히 명세하지 않았다고 밝혔다. 그것은 빠진 각주가 아니다. 인터페이스 D는 정확히 인터넷 측 처리 선택이 전화 서비스 로직으로 바뀌는 지점에 놓여 있었다.

공통 프로토콜은 구독, 알림, 필수 XML 요소를 표준화하면서, 운영자는 자신의 서비스 제어 시스템과의 결정적인 통합을 유지했다. 한 운영자는 기능적 인터페이스를 사용하고, 다른 운영자는 메시지 패싱을 사용하고, 공동 배치가 전송 홉을 없앨 수도 있었다. 공개 명세는 보편적 실행 메커니즘을 주장하기 전에 멈췄다.

이 구분은 더 넓은 인터넷 패턴을 반영한다. 이식 가능한 메시지는 조직 경계를 넘어 제안된 동작을 실을 수 있다. 그러나 수신 시스템은 여전히 발신자가 알려진 존재인지, 요청이 인가되었는지, 상태가 현재인지, 동작이 가능한지, 그리고 그것을 로컬 기계로 어떻게 사상할지를 결정한다. 상호운용 가능한 구문은 모호성을 줄인다. 그러나 로컬 권한을 폐지하지는 못한다.

신뢰는 다이어그램이 아니라 동작을 따랐다

RFC 3136은 인터페이스 B가 일반적으로 공중 인터넷을 건너기 때문에 탈취와 서비스 거부에 특히 노출된다고 보았다. 인터페이스 C는 제공자 인트라넷을 건널 가능성이 더 높았지만, 게이트웨이의 인터넷 연결이 그 인트라넷을 외부 공격 표면과 연결했다. RFC는 방화벽만으로는 충분하지 않을 수 있다고 경고했다.

위험은 메시지를 비밀로 유지하는 데만 국한되지 않았다. 사기성 등록은 알림을 리다이렉트할 수 있었다. 변조된 처리 선택은 통화를 거절하거나, 전환하거나, 통화 정보를 유출할 수 있었다. 재전송되거나 오래된 선택은 잘못된 사건에 영향을 미칠 수 있었다. 정당한 가입자가 인증되었어도 더 이상 회선을 제어할 권한이 없을 수 있었다. 게이트웨이가 서버를 신뢰하더라도 SCF의 현재 서비스 정책이 요청된 처리를 거부할 수 있었다.

따라서 인증, 무결성, 구독 유효성, 회선 연관성, 처리 권한, 서비스 제어 정책, 교환기 실행은 각각 별도의 접수증이 필요하다. '사용자가 클릭했다'는 것은 한 인터페이스에서의 의도에 대한 진술이다. 그것은 하류의 모든 행위자에 대한 보편적 명령이 아니다.

아키텍처의 정직함이 남은 결과였다

SPIRITS는 특정 순간에 속한다: 다이얼업 인터넷 세션, 회선교환 통화, 전화 트리거를 인터넷 서비스에 제공하려는 야심찬 시도들. 인터페이스들은 지금은 역사적으로 보일 수 있다. 그러나 제어 문제는 그렇지 않다.

현대 시스템도 여전히 타인의 실행 도메인 경계에 버튼을 내세운다. 대시보드는 페일오버를 요청하고, 자격 증명을 폐기하고, 트래픽을 옮기고, 결제를 취소하고, 대화를 리다이렉트할 수 있다. 버튼은 의도를 만든다. 게이트웨이가 인증한다. 정책 엔진이 해석한다. 컨트롤러가 번역한다. 장치가 실행한다. 나중에 관찰자가 결과가 발생했는지를 판단한다.

RFC 3136은 그 계층들을 무너뜨리지 않았다. 그것들을 그려냈다. 가입자는 처리를 선택할 수 있었지만, 그 선택을 사실로 만드는 것은 여전히 네트워크의 몫이었다.