要約

  • RFC 5346は、NIDAと韓国の二つのVoIP carrierが2006年に行ったInfrastructure ENUM pre-commercial trialのInformational reportである。E.164 numberからNAPTRを得ても、URIのdomainpartをrecursive DNSまたはsoftswitch内部のfixed tableでgatewayへ結び直す必要があった。
  • Public DNSがaddressを返すことと、bilateral agreementに基づいて特定gatewayを利用できることは同じではない。Fixed tableは初期の安定性を支えたが、ENUM DNSと並ぶ第二のroute authorityを作り、欠落時にはPSTN fallbackを選んだ。
  • 完了したcallだけでは、ENUM、private table、recursive resolution、vendor-specific prefix、PSTNのどれがrouteを決めたか分からない。Query、response、NAPTR、mapping source、agreement、gateway、fallback reason、outcomeを一つのprovenance chainとして残す必要がある。

解決できることと使ってよいこと

RFC 5346のsoftswitchは、E.164 numberをENUM domainへ変換し、recursive nameserverへ問い合わせた。UsableなSIPまたはH.323 URIがあれば、NAPTRのorderとpreferenceに従って一つを選ぶ。

しかしURIは最終routeではない。Domainpartをgatewayへ変換する段階が残る。Trialには二つの方法があった。一つはrecursive resolutionとSIP location rule、もう一つはsoftswitch内のfixed routing tableである。

Fixed tableはdomain nameを特定のgateway hostnameとIP addressへ結んだ。Carrier同士はinterconnection feeを扱い、trusted carrierとのbilateral agreementでgatewayを指定することがあった。その情報は当事者だけのprivate dataになり得た。

Publicに解決できるdomainは、到達可能性の候補を示す。契約上そのgatewayへtrafficを渡してよいことまでは示さない。DNSSECを加えてresponseのauthenticityを高めても、このpermissionは自動では生まれない。

Fixed tableは契約の不完全な影だった

Table entryがあることは、operatorがdomainとgatewayの対応を承認していた証拠になる。しかしagreementそのもの、期限、料金、capacity、現在のnumber ownershipを完全には表さない。

Agreementが変わってもtableが更新されなければ、古いgatewayが選ばれる。DNSが新しいendpointを返してもtableが優先されれば、public viewと実行routeが食い違う。逆にtableを迂回してDNSだけに従えば、許可されていないinterconnectへ送る可能性がある。

したがってauditにはtable versionと更新時刻、agreement identifier、選択gateway、DNS viewを並べる必要がある。「table hit」はauthorizationの最終証明ではないが、欠落させてよい事実でもない。

二重管理は移行の価格だった

ENUM DNSとfixed tableを同時に維持するのは非効率である。Number情報とdomain routeが複数の場所に分かれ、operatorは同期を保たなければならない。

それでもtrial初期には合理性があった。ENUM dataを提供するcarrierが少なく、IP-based point of interconnectも限られていた。新しいdirectoryだけに依存すれば、多くのcallが失敗する。

Fixed tableは既存commercial serviceを保ちながらENUM processingを導入するbufferになった。Softswitchはperformanceとreliabilityへの不確実性に備え、fixed-table方式とDNS方式をすぐ切り替えられた。

RFC 5346はこの構成をtemporary expedientと呼び、長期に合理的とはしない。Temporary controlには終了条件が必要である。終了条件がなければ、二重 authorityは永久化する。

DNS response codeの意味はnumber policyが決めた

TrialではRCODE=0にusable URIがあればdomain processingへ進んだ。同じRCODE=0でもusable URIがなければ、ENUM-only numberのcallを直ちに失敗させた。

ENUM-only rangeにはPSTN point of interconnectがなかった。在用numberにはSIPまたはH.323 URIを必ず入れ、非在用numberにはdomainを残しながらusable NAPTRを置かなかった。NOERRORとzero usable answerがout-of-serviceを表した。

一方、NXDOMAIN、format error、server failure、not implemented、refused、timeoutはvendor-specific methodとPSTNへfallbackした。PSTN接続を持つ大多数のnumberは、初期段階ではENUM recordがなくてもよかったからである。

Protocol code単独ではこの差を作れない。Range class、provisioning rule、supported service、legacy interconnectの有無がresponseをactionへ変換した。

ENUM-only rangeではfallbackがloopを生み得た

ENUM-only numberのURI domainpartは、potential carrierのすべてからresolveできる必要があった。Final serverはSIP INVITEを拒否してもよいが、machine address自体は解決できなければならない。

Domainが解決できないと、softswitchはPSTNへfallbackしようとする。しかしそのnumberにはPSTN pathがない。結果はfailureまたはloopになり得る。

同じfallback ruleがtraditional numberにはresilience、ENUM-only numberには危険になる。Ruleはerror typeだけでなくnumber classを入力に持たなければならない。

Loop guardには、現在のroute regime、過去のtransition、attempt count、最終failure reasonが必要である。各attemptを独立eventとして扱えば、同じnumberが二つのsystemを往復する事実を見失う。

Timeoutはauthorityを移すclockだった

DNSからresponseがなければ、ENUM moduleは待った後にerrorとして扱った。Call setupにとってその時間は長い。最終的にPSTNで成功しても、delayは新directoryがdecisionを保持した時間である。

Trialはtimeoutを安易に短くしなかった。SoftswitchのDNS stackはENUM以外にも使われ、non-compliantな設定が他のoperationへ与える影響を調べる必要があった。

Local optimizationがshared dependencyを変える例である。Monitoringはtotal answer delayだけでなく、DNS wait、fallback decision、legacy routing、SIP responseへ分解すべきだ。

Erratum 1537はsection 4.1.1の四つの“rule 2”を“rule 3”へ直す。Erratum 1538は“non-complaint”を“non-compliant”へ直す。Runbookはoriginal textの誤番号をそのまま権威としてはならない。

平均値はroute provenanceを持たなかった

TrialはSIP INVITEから200 OKまでのaverage Answer Delayを比較した。ENUM/non-ENUMはA→Aで2.33/2.28秒、A→Bで2.23/2.25、A→other PSTNで4.11/3.79、B→Bで2.18/2.05、B→Aで2.19/2.19、B→other PSTNで3.95/3.41だった。

差はすべて一秒未満で、callerが開始品質から方式を見分けにくいという限定的観察を支える。しかしsample count、distribution、tail、failure denominator、cache state、per-call routeは示されない。

200 OKはそのSIP transactionのresponseであり、media quality、billing、conversation completion、number authorityを証明しない。Fast fallbackとpure ENUM routeは同じaverageへ入る。

誤りの発生地点と修復権限が離れた

Shared ENUM dataが誤ってprovisionされると、placing carrierのnetworkでroute errorが起きる。Number portabilityがあると、どのcarrierが現在serviceを提供し、誰へ通知すべきか分かりにくい。

Resolverは存在するrecordを正確に返し、softswitchもrule通り動作しながら、callは誤ることができる。Technical correctnessはrepair ownershipを作らない。

Incident packageにはEPP submission、Dynamic Update、record version、serving-carrier assertion、portability state、resolver view、mapping source、gateway、repair contactが必要である。

Public directoryはprivacyとresolver controlを変えた

Trialの2.8.e164.arpaはpublic Internetからアクセスできた。Carrierはtelephone number disclosureを懸念し、private accessを望んだ。

Compromised recursive resolverはcallをfailまたはdelayさせられる。RFC 5346はsoftswitchのlocal networkからのaccessを許し、outsideを制限するpolicyを求める。

Privateであることはdata correctnessではなく、publicであることはinterconnect permissionではない。Visibility、authenticity、authorization、outcomeは別のrecordである。

歴史的reportから現在を推測しない

RFC 5346はInformationalで、Internet Standardではない。2006年の二carrier trialを扱い、RFC 6116は後にRFC 3761をobsoletesした。Current deployment、vendor defect、incident、adoption rateは資料から主張できない。

再利用すべきなのはarchitectureの境界である。新directoryとlegacy routeが共存するなら、成功結果はその間のauthority transitionを消してはならない。