요약

  • RFC 3064는 일부 반응이 수십 밀리초 안에 일어나야 했기 때문에 저수준 채널 연관 신호(CAS)의 상태와 타이밍을 미디어 게이트웨이에 두었다. 호 처리 에이전트(Call Agent)는 자릿수 분석과 더 높은 수준의 호 판단을 계속 담당했다.
  • 가장 깔끔한 경계는 해제 시 나타났다.rel과rlc는 전화 구간을 해제하고 트렁크를 재사용 가능하게 만들었지만, 패킷 네트워크 연결까지 삭제하지는 않았다. 그것에는 별도의DLCX동작과 별도의 근거가 필요했다.

제어기는 그렇게 빠르게 왕복할 수 없었다

구식 전화 회로는 원격 소프트웨어 제어기를 예의 바르게 기다려 주지 않았다. 채널 연관 신호(CAS, Channel Associated Signaling)는 접속, 응답, 해제 등 감시 상태를 수십 밀리초 단위로 타이밍이 중요한 상태에 부호화했다. 모든 전이를 멀리 있는 호 처리 에이전트에 두면 네트워크 지연이 신호 기계의 일부가 되어 버린다.

2001년 2월에 발표된 RFC 3064는 의도적인 분할을 선택했다. 미디어 게이트웨이는 가능한 한 저수준 CAS 프로토콜, 타이머, 타임아웃을 처리한다. 호 처리 에이전트는 더 높은 수준의 처리가 필요할 때 개입한다. 어떤 자릿수가 무슨 뜻인지 판단하고, 상대 엔드포인트를 선택하고, 패킷 연결을 준비하는 일은 윙크(wink)나 오프훅 전이 하나하나를 세세히 제어하지 않고도 할 수 있었다.

이 문서는 여섯 개의 MGCP 패키지를 기술했다. 기본 MF CAS용MS, DTMF 및 다이얼 펄스 트렁크용DT, 기본 PBX 또는 FXS 인터페이스용BL, FXO용DO, Feature Group D EANA 및 EAIN용MD, 교환원 서비스 신호용MO가 그것이다. IANA는 지금도 그 여섯 개의 버전 0 이름을 기록하고 있다. 이 레지스트리는 이름이 할당되었다는 사실만 알려 줄 뿐, 어느 게이트웨이가 이를 구현했는지 또는 오늘날 어느 회선이 살아 있는지는 말해 주지 않는다.

추상화는 물리적 차이를 그대로 남겨 두었다

단순한 착신 자릿수 문자열의 경우, 한 트렁크가 윙크 스타트이고 다른 트렁크가 즉시 스타트라는 이유만으로 호 처리 에이전트가 다른 호 흐름을 사용해야 할 필요는 없어야 했다. 게이트웨이가 그 지역적 차이를 흡수하고 공통의 호 설정 이벤트를 보고할 수 있었다.

그러나 추상화는 소거가 아니었다. 구체적인 트렁크 유형은 MGCP 바깥에서 게이트웨이에 프로비저닝된 채로 남아 있었다. 제어기는 여전히 어느 패키지를 사용 중인지, 트렁크가 착신 방향인지 발신 방향인지 양방향인지 알아야 했다. 공통 이벤트 이름은 서로 다른 기계 위의 인터페이스였지, 그 기계가 동일해졌다는 증거가 아니었다.

이것은 국소적 권한의 실용적인 형태였다. 타이밍 제약에 가장 가까운 장치가 되돌릴 수 있는 빠른 전이를 제어했다. 제어기는 엔드포인트와 네트워크를 넘는 범위의 판단을 계속 보유했다. 어느 쪽 계층도 상대를 완전히 대체하지 않았다.

신호는 내려가고, 이벤트는 되돌아왔다

RFC 3064는 방향성을 어휘에 드러냈다. 신호(signal)는 호 처리 에이전트가 미디어 게이트웨이에 내리는 명령이었다. 이벤트(event)는 게이트웨이가 감지해 호 처리 에이전트에 통보하는 것을 가리켰다. 명령 응답은 게이트웨이가 프로토콜 단계 하나를 수용했음을 보여 줄 수 있고, 이후의 동작 완료 이벤트는 국소 신호 작업이 끝났음을 보여 줄 수 있다. 응답 감시(answer supervision)는 또 다른 상태였다.

예시 흐름들은 이러한 접수증들을 압축하는 것을 거부한다. 설정 요청은200 OK를 받고, 자릿수 출력의 완료는 그 자체의 통보를 낳으며, 응답은 나중에 연결과 회선 상태를 바꾼다. 따라서 성공적인 응답 확인은 자릿수 출력이 끝났거나, 상대가 응답했거나, 유용한 미디어가 흘렀거나, 사람 간 대화가 일어났다는 근거가 아니었다.

일부 이벤트는 감사 가능한 상태를 표시하는S를 실었다. 감사의 범위는 의도적으로 좁았다. 어느 한 상태군은 회선이나 트렁크에서 호 설정이 시작되었는지에 답했다.rlc상태는 전화 구간이 유휴이고 다른 호에 사용 가능한지에 답했다. 감사는 불확실한 상황에서 제어기의 현재 시각을 복구할 수 있었지만, 그 지점까지 이르게 된 모든 원인을 재구성하지는 않았다.

해제에는 서로 다른 두 대상이 있었다

RFC 3064에서 가장 가치 있는 문장은 해제 로직에 나온다.rel신호 또는 이벤트는 단순한 오프훅 이상을 의미했다. 즉 전화 구간의 자원 해제를 요청하거나 보고하는 것이었다. 그 뒤의rlc(release complete)는 트렁크 자원이 완전히 해제되어 다른 호에 사용 가능함을 나타냈다.

그러나rel이 게이트웨이의 네트워크 연결 삭제를 의미하지는 않았다. 그 연결들을 포함한 호 전체를 해제하려면, 호 처리 에이전트는rel과 함께 또는 그 외에 별도로DLCX를 발행해야 했다.

이것은 중복되는 정리 작업이 아니었다. 두 동작은 서로 다른 대상을 다루었다. 패킷 연결이 존재하는 동안 회선 감시가 끝날 수 있고, 상대 회선의 해제가 완료되지 않은 상태에서 패킷 연결이 삭제될 수도 있었다. 따라서 재사용 가능한 트렁크 접수증과 삭제된 연결 접수증은 서로를 대신할 수 없었다.

이 구분은 장애 상황에서 더 선명해진다.rel은 정상적인 상대측 오프훅에서 올 수도 있고, 글레어(glare)를 포함한 비정상적인 게이트웨이 상태에서 올 수도 있었다. 그러한 경로에서는 실제 관측된 오프훅과 문자 그대로 일치하지 않더라도 해제를 완료하기 위해rlc가 보내질 수 있었다. 이 이벤트는 프로토콜의 자원 상태를 보고할 뿐, 사람이 호를 끝낸 이유에 대한 보편적인 이야기를 전달하지 않았다.

글레어는 국소적 판단을 드러냈다

양방향 트렁크는 양쪽 끝에서 동시에 접속될 수 있었다. RFC 3064는 DS0 단위의 글레어 선택을 포함해 구성 가능한 게이트웨이 동작을 논의했다. 그 판단은 충돌이 국소적이고 시간에 민감했기 때문에 물리 인터페이스 가까이에 놓였다. 호 처리 에이전트는 여전히 그 결과 이벤트와 원인을 받아 다음 단계를 결정해야 했다.

이 설계는 하나의 보편적인 글레어 정책을 약속하지 않았다. 프로비저닝된 국소 선택을 둘러싸고 상호운용 가능한 제어를 위한 어휘를 제공했을 뿐이다. 따라서 운영자는 구성된 규칙, 관측된 훅 상태, 원인 코드, 그 후의 해제 접수증을 보존해야 했다. 최종 유휴 상태만으로는 어느 쪽 접속이 이겼는지, 네트워크 연결이 회수되었는지 알 수 없었다.

전환기가 이미 보이는 Informational 문서

RFC 3064는 인터넷 표준이 아니라 Informational 문서였다. IESG 노트는 이 프로토콜이 당시 여러 제품에 배포 중이라고 밝히면서, IETF Megaco 그룹과 ITU-T SG16에서 진행되는 후속 작업에 대해 구현자에게 경고했다. 이후의 RFC들은 MGCP 기본 프로토콜을 개정하고 패키지 등록 절차를 다루었으며 Megaco/H.248을 기술했다. 이들은 수명 주기적 맥락을 제공할 뿐, 여섯 개의 CAS 패키지를 소급적으로 다시 정의하거나 현재 배포를 증명하지는 않는다.

오래 남을 공학적 교훈은 더 작고 더 강하다. 마감 시간을 맞출 수 있는 곳에 반응을 두라. 더 넓은 거래를 볼 수 있는 행위자에게 상위 판단을 남겨 두라. 그리고 모든 경계의 통과에 이름을 붙여, 하나의 국소적 성공이 전체 결과인 것처럼 보이지 않게 하라. RFC 3064에서 밀리초의 소유자는 게이트웨이였다. 호의 소유자는 여전히 호 처리 에이전트였다. 그리고rlc도DLCX도 양쪽을 대신하여 말할 수 없었다.

출처