요약

  • FCC는 잘못된 프로비저닝 기록이 적절한 Comtech IP 주소를 누락했으며, 이후 무관한 AT&T 변경이 해당 기록을 실제 세션 보더 컨트롤러 화이트리스트에 밀어 넣어 911 라우팅 정보의 회신을 중단시켰다고 결론지었습니다 [1].
  • 영향받은 연결은 고객 자산으로 분류되어 있었고, 인프라 자산으로 분류되지 않았습니다. FCC는 이 구분 덕분에 인프라 변경에 적용되는 더 엄격한 테스트와 비혼잡 시간대 통제 없이도 변경이 진행될 수 있었다고 설명했습니다 [1].
  • 오류가 일정 임계값을 넘자, 프록시 위치 라우팅 기능(PLRF)이 두 라우팅 정보 제공업체가 공유하는 링크를 리셋했습니다. 사용 불가능한 한 경로를 피하려던 대응이 결국 다른 경로마저 중단시켰습니다 [1].
  • AT&T는 5시간 동안 약 12,600명의 고유 발신자가 911에 직접 연결하지 못했다고 보고했습니다. 수동 비상 중계 센터는 전국 규모의 오버플로를 처리하도록 설계되지 않아 수신한 추가 통화 대부분을 끊었습니다 [1].
  • AT&T는 이후 FCC에 게이트웨이 링크를 재분류하고, 알림 전달을 변경하고, 두 논리 경로를 분리했으며, 수동 VoLTE-to-3G 폴백을 추가했다고 말했습니다. 이는 기록된 복구 조치이며, 그 자체로 이후 모든 운영 결과의 증명은 아닙니다 [1].

사건 경계를 정확히 유지하기

이 기사는 2017년 3월 8일 오후에 시작된 전국 규모 AT&T Mobility VoLTE 911 장애를 다룹니다. 2023년 8월 22일의 AT&T 지역 911 중단이나 2024년 2월 22일의 전국 무선 장애는 다루지 않습니다. 이후 사건들은 서로 다른 날짜, 메커니즘, 규제 기록을 갖고 있습니다.

FCC의 최종 보고서는 2017년 사건에 대한 1차 사실 기록입니다 [1]. 국(Bureau)은 기밀 장애 보고서, 공개 의견, 문서, AT&T 및 그 라우팅 하도급업체, 공공 안전 단체와의 회의를 검토했습니다. 보고서에 따르면 전국 거의 모든 AT&T Mobility VoLTE 고객이 5시간 동안 911 서비스를 잃었으며, 약 12,600명의 고유 사용자가 911에 전화를 시도했으나 기존 911 네트워크를 통해 비상 서비스에 닿지 못한 것으로 기록되어 있습니다.

이 수치는 귀속을 신중하게 해야 합니다. 이는 규제 기록에서 AT&T가 정량화한 값입니다. 신고되지 않은 시도의 수, 개별 의료 결과, 재정 손실 또는 모든 지역 서비스 상태를 확립하지는 않습니다. 보고서는 일부 통화가 레거시 네트워크를 사용하거나 백업 센터에 닿았으며 일부 지역은 영향받지 않은 것으로 보인다고도 기록했습니다. 방어 가능한 서술은 이러한 한계를 유지해야 합니다.

당시 FCC 공개 고지는 PS Docket 17-68을 개설하고 전국 규모 VoLTE 911 장애를 설명했습니다 [2]. 예비 보고서는 초기 범위와 영향 평가를 제공했습니다 [3]. NENA는 이 사건에 대한 성명을 발표했고, APCO는 동일 절차에 ex parte 기록을 제출했습니다 [4][5]. 이 공공 안전 기록은 운영 맥락을 확립하는 데 도움이 되며, 최종 FCC 보고서가 여기서 사용된 정립된 기술 재구성을 제공합니다.

라우팅 경로가 원래 작동하던 방식

FCC는 다단계 통화 경로를 설명했습니다. 고객이 VoLTE 네트워크에서 911을 누르면 근처 LTE 셀 사이트를 통해 연결되었습니다. AT&T의 비상통화 네트워크는 통화 데이터를 두 라우팅 정보 제공업체인 Comtech 또는 West 중 하나로 보냈습니다. 선택된 제공업체는 발신자의 지리 정보로부터 적절한 공공 안전 응답 지점(PSAP)을 결정하고, 라우팅 메타데이터를 추가하고, 보강된 데이터를 AT&T에 회신했습니다. AT&T는 그 통화를 해당 PSAP을 서비스하는 지역 교환 사업자를 통해 전달했습니다 [1].

이 장애에서 중요했던 두 제어 요소가 있었습니다. 프록시 위치 라우팅 기능(PLRF)은 발신자의 셀 섹터 정보에 따라 요청을 Comtech 쪽으로 보낼지 West 쪽으로 보낼지 결정했습니다. 세션 보더 컨트롤러(SBC)는 AT&T와 외부 제공업체 사이의 접근을 관제했습니다. 보강된 통화 데이터가 회신되면 SBC는 승인된 IP 주소에서 왔는지 검사했습니다.

그 승인 집합이 화이트리스트였습니다. 이는 보안 통제였습니다. 들어오는 데이터는 AT&T의 실제 911 네트워크가 신뢰할 준비가 된 주소에서만 수용되어야 했습니다. AT&T는 또한 프로비저닝 시스템에 이 주소들의 기록을 보관했습니다. 기록과 실제 화이트리스트는 서로 연관되었지만 같은 운영 상태는 아니었습니다.

이 구분이 핵심입니다. 프로비저닝 기록은 인벤토리 또는 보안 장부처럼 보일 수 있습니다. 변경이 그것을 실제 장비로 이전하기 전까지는 트래픽을 운반하지 않습니다. 따라서 정확성은 기록된 의도에서 가동 중인 구성으로의 이전을 거쳐 살아남아야 합니다. 낡거나 불완전한 기록을 둘러싼 올바른 승인 절차도 잘못된 결과를 배치할 수 있습니다.

휴면 상태의 기록 오류가 실제 라우팅 실패가 되기까지

FCC는 3월 8일 이전에 AT&T의 프로비저닝 시스템에 잘못된 화이트리스트 기록이 있었다고 판정했습니다. 여기에는 적절한 Comtech IP 주소가 포함되어 있지 않았습니다. AT&T는 프로비저닝 로그를 90일 보관했지만 잘못된 기록이 언제, 왜 삽입되었는지는 알아내지 못했습니다. 일상 인벤토리 관리는 프로비저닝 기록과 실제 화이트리스트 간의 차이를 탐지하지 못했습니다 [1].

그 시점까지 Comtech와의 통신은 작동하고 있었습니다. 잘못된 기록이 실제 네트워크를 바꾸지 않았기 때문입니다. 발화 사건은 무관한 프로젝트에서 왔습니다. AT&T는 잘못된 기록을 실제 SBC 화이트리스트로 밀어 넣는 네트워크 변경을 시작했습니다. Comtech의 실제 발신 주소가 승인 집합과 더 이상 일치하지 않자, AT&T는 회신된 라우팅 데이터를 거부했고, 적절한 PSAP 정보를 얻는 데 필요한 연결을 끊었습니다.

이 기술 연쇄는 흔히 하나로 묶이는 네 가지 통제를 분리하기 때문에 중요합니다. 첫째는 데이터 품질입니다. 기록된 주소 집합이 의도된 제공업체와 일치했는가? 둘째는 대조(reconciliation)입니다. 누군가 기록과 작동 구성을 비교했는가? 셋째는 변경 승인(admission)입니다. 제안된 델타가 올바른 검토와 테스트를 받았는가? 넷째는 변경 후 검증입니다. 실제 비상 라우팅 거래가 두 제공업체 경로를 통해 여전히 완결되는가?

제출된 구성의 해시는 배치된 바이트를 증명할 수 있습니다. 그 바이트가 필요한 모든 제공업체 주소를 포함하는지는 증명할 수 없습니다. 성공적인 장비 커밋은 변경이 수용되었음을 증명할 수 있습니다. 회신 트래픽이 실제 신뢰 검사를 통과했는지는 증명할 수 없습니다. 관련 증거는 신원, 의도 상태, 배치된 상태, 종단 간 서비스 거래를 연결해야 합니다.

자산 분류가 안전 사례를 바꿨다

FCC는 라우팅 제공업체로의 SBC 연결이 고객 자산으로 태그되어 있었다고 보고했습니다. AT&T의 인프라 자산은 더 엄격한 고장 테스트와 지정된 비혼잡 유지보수 시간대를 적용받았습니다. 이 링크들은 고객 분류를 갖고 있었기 때문에, 그 강한 통제 없이, 그리고 911 트래픽 혼잡 시간대에도 변경이 진행될 수 있었습니다 [1].

이것은 단순한 명명 오류가 아니었습니다. 분류가 통제 체계를 선택했습니다. 링크가 외부 서비스 제공업체를 향하더라도, 그 상실이 전국 규모의 비상통화 라우팅에 영향을 미치면 핵심 공유 인프라일 수 있습니다. 검토 깊이, 유지보수 시점, 동료 승인, 부정 테스트를 결정하는 라벨은 실행 가능한 정책입니다. 그 정확성은 경로 지도나 액세스 리스트와 동일한 규율을 받아야 합니다.

유용한 검사는 결과 기반입니다. 이 대상이 잘못되거나, 누락되거나, 동시에 리셋되면 신뢰할 수 있는 서비스 영향은 무엇인가? 어떤 비상 또는 공공 안전 기능이 여기에 의존하는가? 이 대상이 공유 장애 도메인에 놓여 있는가? 변경이 실제 네트워크에 닿기 전에 대표 거래를 상대로 시험될 수 있는가? 답이 광범위한 영향을 가리킨다면, 낮은 위험의 라벨이 그 증거를 무시해서는 안 됩니다.

FCC는 더 신중한 테스트라면 배치 전에 잘못된 IP 할당을 노출했을 가능성이 높았다고 말했습니다. 이는 이 사건에 대한 규제 판정이며, 특정 테스트가 언제나 기록 드리프트를 잡는다는 보장이 아닙니다. 견고한 통제 집합에는 정적 비교, 미승인 주소에 대한 부정 테스트, 승인된 각 제공업체를 통한 긍정 거래, 오류 상태에서 경로가 독립적임을 관찰하는 것이 포함되어야 합니다.

리셋 동작으로 결합된 이중화

Comtech 회신 경로의 상실은 SBC와 PLRF 사이에 오류를 만들었습니다. 그 오류가 구성된 밀도 임계값을 넘자, PLRF는 SBC로 가는 자신의 링크에 소프트 리셋을 수행했습니다. Comtech와 West 트래픽이 그 경로를 사용했으므로, 리셋 동작은 두 제공업체 모두에 대한 접근을 중단시켰습니다. West가 지원하는 통화 처리는 링크가 돌아오면 재개했으나, 해결되지 않은 화이트리스트 오류가 또 다른 메시지 물결을 만들면서 다시 중단될 수 있었습니다 [1].

이 아키텍처에는 복수의 라우팅 제공업체가 있었지만, 공유 복구 동작이 그들을 결합했습니다. 이는 '이중화가 없었다'는 말보다 더 정확한 진단입니다. Comtech와 West는 지리적으로 분산된 시설을 가진 별개 제공업체였습니다. 그러나 실제 제어 동작은 한 제공업체의 오류 상태가 다른 쪽에도 필요한 경로에 리셋을 트리거하도록 허용했습니다.

따라서 이중화는 구성 요소의 목록으로 세어지는 것이 아니라 실패 전이로서 테스트되어야 합니다. 하나의 임계값, 리셋 도메인, 구성 대상 또는 제어 노드가 둘 다 제거할 수 있다면 두 제공업체는 두 개의 사용 가능한 경로를 만들지 못합니다. 증거는 제공업체 A의 실패 후에도 제공업체 B에 도달 가능함을 보여야 하고, 알림이 건강한 경로를 억압하지 않고 영향받은 경로를 식별해야 하며, 자동 복구가 반복적으로 사건을 확대하지 않음을 보여야 합니다.

이 지점에서 토폴로지 다이어그램은 오해를 일으킬 수 있습니다. 다이어그램은 그들을 함께 다루는 제어 논리를 생략한 채 별개의 상자와 링크를 보여줄 수 있습니다. 실제 관계는 구성, 임계값, 상태 전이로 정의됩니다. 경로 다양성은 같은 부류의 고장에서 격리가 시험으로 입증될 때에만 신뢰할 수 있게 됩니다.

수동 폴백은 전국 부하를 흡수하지 못했다

AT&T가 적절한 PSAP 라우팅 정보를 얻지 못하면, 통화를 비상통화 중계 센터로 보냈습니다. 그곳의 전문 콜 테이커는 발신자에게 위치 정보를 묻고 수동으로 올바른 PSAP으로 안내할 수 있었습니다. FCC에 따르면 이 센터는 정상적으로 라우팅되지 않는 소수 통화를 위한 것이었지, 전국 장애를 위한 것이 아니었습니다. 추가 물량을 처리할 수 없었고 수신한 오버플로 통화의 압도적 다수를 끊었습니다 [1].

폴백이 연속성 통제로 인용될 때, 폴백 용량은 주 서비스 설계의 일부입니다. 질문은 백업 절차가 존재하는지가 아니라, 그 절차가 어느 실패 집합을 흡수하도록 크기가 정해졌는지, 얼마나 빨리 활성화되는지, 여전히 어떤 데이터를 수신하는지, 용량 임계값을 넘은 후 무슨 일이 일어나는지입니다.

전국 비상 서비스에서 모든 가능한 911 목적지의 수동 처리는 엄청난 인력과 조율을 요구합니다. FCC는 그 제약의 일부로 1차 PSAP의 규모를 언급했습니다. 책임성 요구는 무한한 예비 용량이 아닙니다. 폴백 경계의 명시적 선언, 측정된 과부하 동작, 지역 라우팅 실패가 즉시 전국 오버플로가 되지 않도록 방지하는 또 하나의 격리 메커니즘입니다.

공개 영향 기록이 이 경계가 왜 중요한지 보여줍니다. FCC는 발신자에게 빠른 통화 중(occupy) 신호, 반복 벨소리 또는 침묵이 나타났다고 보고했습니다. 플로리다주 오렌지 카운티의 사례를 문서화하면서도, 공개 불만이 없었다고 보고한 관할권들도 함께 기록했습니다. 이 혼합을 재난 언어로도, 안심 메시지로도 납작하게 만들어서는 안 됩니다. 이는 명확한 운영 결론을 뒷받침합니다. 수천 건의 비상 통화가 정상 경로를 통해 완결되지 않았고, 폴백은 그 범위를 커버할 용량이 없었다는 것입니다.

탐지는 빨랐지만 진단과 조율은 느렸다

FCC 타임라인은 장애 시작 몇 분 안의 핵심 알림 티켓을 기록합니다. 911 트러블슈팅 팀은 사건 시작 16분 후에 이를 확인했습니다. 이후 에스컬레이션은 911, VoLTE, 더 넓은 서비스, 백본 팀을 거쳐 직렬로 진행되었고, IP 팀은 그 뒤에야 투입되었습니다. 시작 후 거의 5시간 만에 IP 팀이 장애 시각을 네트워크 변경과 연결하고 롤백을 요청했습니다. 서비스는 3분 후 복귀했습니다 [1].

알림은 관련 가설을 시험할 수 있는 사람에게 도달할 때만 유용합니다. 직렬 에스컬레이션은 경계가 명확한 사건에서는 적절할 수 있지만, 영향받은 서비스가 여러 소유 도메인을 가로지르면 지연 메커니즘이 됩니다. 핵심 증거는 단순한 알림 생성이 아닙니다. 각 필요 팀으로의 전달, 변경 타임라인의 공유 가시성, 실제 상태를 마지막 변경과 비교할 권한, 그 변경을 빠르게 되돌릴 방법입니다.

보고서는 또한 PSAP에 대한 지연되고 불완전한 통보를 설명합니다. 일부 통보는 사건 시작 몇 시간 후에 도착했고 명확한 범위, 원인 또는 지역 세부 정보가 없었습니다. 공공 안전 기관은 소셜 미디어, 지역 언론, 대체 번호로 주민에게 닿았습니다. 따라서 이 장애 기록에는 라우팅 통제와 함께 통신 통제도 포함됩니다.

운영 통보에는 최소한 영향받은 서비스 클래스, 알려진 지역, 시작 시각, 신뢰 수준, 현재 우회 방법, 다음 업데이트 시각이 담겨야 합니다. 민감한 네트워크 세부는 보호될 수 있습니다. 레거시 통화가 여전히 작동하는지, VoLTE만 영향받는지, 어느 관할권이 대체 번호를 필요로 하는지에 대한 모호성은 PSAP의 대응 능력을 직접적으로 낮춥니다.

AT&T가 변경했다고 보고한 사항

FCC는 AT&T가 사건 이후 취했다고 말한 네 가지 주요 조치를 기록했습니다 [1]. 첫째, AT&T는 911 라우팅 제공업체로의 SBC 연결을 인프라 자산으로 재분류하여 더 엄격한 테스트 절차 하에 두었습니다. 둘째, 알림 전달을 바꾸어 911, VoLTE, IP 팀이 관련 오류를 즉시 그리고 동시에 수신하도록 했습니다.

셋째, AT&T는 SBC와 PLRF 사이의 논리 링크를 분할(이중화)했습니다. FCC는 이 분리가 3월 8일 존재했다면, Comtech 문제가 West가 지원하는 통화 처리를 중단시키지 않았을 것이라고 말했습니다. 넷째, AT&T는 VoLTE 911 장애 중 911 통화를 위해 VoLTE 서비스를 끄고 3G로 폴백하는 수동 절차를 도입했습니다.

이 복구는 관찰된 실패 연쇄와 부합합니다. 더 강한 변경 통제, 더 빠른 부서 간 진단, 더 작은 리셋 도메인, 또 하나의 서비스 경로입니다. 그러나 이들은 영구 보증이 아니라 보고된 복구 조치로 다루어져야 합니다. 지속 가능한 증명에는 구성 신원, 테스트 결과, 경로 격리 훈련, 알림 전달 기록, 폴백 활성화 증거, 이후 운영 이력이 포함되어야 합니다.

가장 강한 재발 방지 테스트는 발신자를 노출하지 않고 이 오류의 부류를 재현할 것입니다. 테스트 환경은 후보 화이트리스트에서 한 제공업체 주소를 제외하고, 그 변경이 승인에서 거부되거나 격리된 채 유지됨을 확인하고, 다른 제공업체 경로가 유지되는지 검증하고, 모든 관련 팀에 알림을 전달하고, 통제된 폴백을 수행해야 합니다. 운영 안전 훈련은 합성 거래와 엄격한 중지 조건을 사용할 수 있습니다. 결과는 테스트된 정확한 구성과 소프트웨어 버전과 함께 보관되어야 합니다.

장부는 필요하지만 네트워크가 결정한다

프로비저닝 시스템은 승인된 네트워크 인벤토리의 기록 관리자였습니다. 그 기록은 변경 자동화와 보안 정책에 필요했습니다. 이 장애는 그 역할의 한계를 보여줍니다. 기록은 승인된 시스템에 존재한다는 이유만으로 운영상의 진실이 되지 않았습니다. 실제 화이트리스트로 이전되었을 때 비로소 결과를 낳았고, 그 정확성은 작동해야 하는 제공업체 주소와 비상 거래를 기준으로만 판단될 수 있었습니다.

이것이 이 사건의 Heng.lu 층입니다. 보안 메타데이터, 네트워크 신원, 변경 이력은 연속성을 지원하는 장부입니다. 실제 네트워크의 주권적 대체물이 아닙니다. 어떤 대상의 배치 허가는 그 대상이 현실과 일치함을 확립하지 않습니다. 분류 라벨은 실패의 결과를 바꾸지 않습니다. 서류상의 두 번째 제공업체는 격리된 경로를 증명하지 않습니다.

방어 가능한 비상 라우팅 기록은 같은 변경 창에 대해 다섯 가지를 결합해야 합니다. 승인된 제공업체 신원과 주소, 프로비저닝 기록, 후보 및 배치 구성 해시, 경로별 합성 거래 결과, 알림·롤백·서비스 결과입니다. 어떤 불일치든, 공개 통화가 새 상태에 의존하기 전에 변경을 중단하거나 이름 붙은 인시던트를 만들어야 합니다.

같은 원리가 보존 기간에도 적용됩니다. AT&T는 잘못된 기록이 언제, 왜 프로비저닝 시스템에 들어왔는지 알아내지 못했습니다. 핵심 변경을 설명하는 데 필요한 증거가 불일치가 발견되기 전에 만료된다면, 운영자는 책임 공백을 닫지 않은 채 서비스를 수리할 수 있습니다. 보존 기간은 통상적인 저장 비용이 아니라 자산의 결과와 발견 창을 따라야 합니다.

실용적인 증거 패키지

변경 전에 패키지는 서비스 소유자, 영향받은 통화 경로, 제공업체 주소 집합, 자산 분류, 공유 의존성, 유지보수 창, 검토자, 예상 롤백을 식별해야 합니다. 작동 중인 실제 화이트리스트와 제안된 기록 간의 기계 비교 가능한 차이를 포함해야 합니다. 누락된 승인 주소는 경고가 아니라 차단 결과여야 합니다.

배치 전 테스트는 각 제공업체 경로를 통해 대표 합성 거래를 보내야 합니다. 회신된 라우팅 메타데이터와 통제된 PSAP 테스트 엔드포인트에 도달하는 능력을 검증해야 합니다. 고장 테스트는 한 경로를 제거하거나 거부하고, 공유 리셋 없이 다른 경로가 유지됨을 증명해야 합니다. 폴백 용량과 활성화는 합의된 실패 집합을 상대로 테스트되어야 합니다.

배치 중에 운영자는 정확한 구성 해시, 장비 확인 응답, 경로별 상태, 알림 타임스탬프, 거래 결과, 승인 및 관측 팀의 신원을 보관해야 합니다. 한 제공업체가 실패할 수 있고 다른 쪽이 유지될 수 있는 상황에서 전역 성공 상태만으로는 충분하지 않습니다.

배치 후에 패키지는 의도 상태와 가동 상태를 대조해야 합니다. 두 제공업체 경로를 확인하고, 거부 카운터를 점검하고, 종단 간 라우팅을 테스트하고, 알림 분배를 검증하고, 롤백 임계값이 넘어졌는지를 기록해야 합니다. 마감 서술은 남은 불확실성을 명시해야 하며, 부재한 증거를 확신으로 대체해서는 안 됩니다.

공개 책임성을 위해 통신사는 제공업체 IP 주소나 민감한 토폴로지를 노출할 필요가 없습니다. 영향받은 서비스 면, 지속 시간, 영향 범위, 실패 부류, 격리 경계, 폴백 성능, 지속 복구, 재발 테스트 결과를 공개할 수 있습니다. 이는 보안을 약화시키는 자료를 드러내지 않고도 통제가 바뀌었는지 보여주기에 충분합니다.

책임성의 경계

AT&T는 프로비저닝 기록, 실제 화이트리스트, 자산 분류, SBC 및 PLRF 동작, 알림 라우팅, 통신사 폴백을 통제했습니다. Comtech와 West는 라우팅 정보를 공급하고 더 넓은 비상 서비스 생태계의 일부를 운영했습니다. PSAP은 지역 공개 통보와 대체 연락 방법을 통제했습니다. FCC는 이 경계를 넘는 기록을 모았습니다.

공유 운영은 소유를 지우지 않습니다. FCC에 따르면 잘못된 화이트리스트와 공유 리셋 동작은 AT&T의 네트워크 안에 있었습니다. 라우팅 제공업체와 PSAP은 여전히 자기 역할을 수행하기 위한 시의성 있고 구체적인 정보를 필요로 했습니다. 따라서 책임성은 발화 통제와, 다른 주체들이 그 영향을 억제하는 데 필요한 인터페이스를 모두 포함합니다.

좁은 결론은 견고합니다. 핵심 네트워크 기록은 작동 구성과 성공적인 서비스 거래로 대조될 때만 신뢰할 수 있습니다. 이중화된 제공업체는 현실적인 고장에서 한 경로가 유지될 때만 독립적입니다. 폴백은 테스트된 용량 경계 안에서만 보호적입니다. 빠른 롤백은 올바른 증거를 가진 팀이 책임 변경을 제때 식별할 수 있을 때만 유용합니다.

출처

  1. https://docs.fcc.gov/public/attachments/DOC-351492A1.pdf
  2. https://docs.fcc.gov/public/attachments/DA-17-277A1_Rcd.pdf
  3. https://docs.fcc.gov/public/attachments/DOC-344049A1.pdf
  4. https://www.nena.org/news/334578/NENA-Statement-on-March-8-9-1-1-Outage.htm
  5. https://ecfsapi.fcc.gov/file/10410294707272/APCO%20Apr2017%20ex%20parte%20-%20ATT%20Mobility%20Outages%20v2.pdf
  6. https://about.att.com/content/dam/snrdocs/Tips%20for%20Customers%20for%20911.pdf