[Dundi] [RFC] Reliability of contact information

[Kevin P. Fleming]

(skip to the summary below, if you are in a hurry <G>)

Today we had an end-user complaint about dialing a particular number and 
getting no useful result; as it turns out, our system found a route to 
this number via DUNDi in the e164 context, and attempted to connect. 
Because of some misconfiguration (as yet unresolved) on the target 
server, the call would not complete. This is fine, we understand that 
the GPA does not require us to provide 100% service, nor is there any 
warranty for service failures.

However, I felt it would be useful to contact the provider in question, 
to inform them that their system was not properly accepting calls for 
routes they were publishing.

I then did a manual lookup for the TN in question, and obtained the EID 
of the publishing peer. A query on that EID got me their contact 
information... but it was invalid. The phone number published via DUNDi 
as their "contact number" did not reach them, it reached someone who had 
no idea who they were.

I would like to propose a small change to the DUNDi protocol and peering 
procedure: when a peer wants to join the network, they must put their 
contact information into their DUNDi server prior to requesting peerage. 
They would then issue a command to their server to compute an SHA-1 hash 
of their contact information, and provide that hash to the peer they are 
requesting peerage with. That peer would add it to the peer definition 
in their dundi.conf file (or equivalent for a non-Asterisk platform <G>).

Then, periodically, that peer's DUNDi server should request the contact 
information, recompute the hash, and compare. If the contact information 
has changed and the hash has not been updated, the peer who changed 
their information would be "cut off" from the network until the 
situation is resolved.

Finally, the dundi.conf file needs to support multiple hashes for a 
peer, so that when legitimate contact information changes are in the 
works, the peer can provide a new hash (along with the new information) 
in advance, to avoid any "magic cutover" moments.

This would allow peers who are processing peering agreements from new 
members to actually verify the contact information, and be assured that 
it will not change without notice and reasonable recourse if no notice 
is given.

-- SUMMARY--

Add a field type to a peer definition in dundi.conf: contacthash. The 
value would be an SHA-1 hash of the contact information provided by the 
peer. This field can appear multiple times in a peer definition, and if 
the peer's contact information matches _any_ provided hash, they are 
considered to be acceptable.

Periodically (possibly according to a time period set in the [globals] 
section of dundi.conf), all peer contacthash values should be verified. 
Any that do not verify would generate warnings to the Asterisk logs, and 
disable that peer's connectivity (including flushing any cached routes 
for that peer's EID).

Add a new CLI command "dundi contacthash", which computes the hash of 
this node's contact information and displays it.

Comments?