[Dundi] What requirements is DUNDi addressing?

[John Todd]

A few comments on your thorough list of "problems" and "features":

1) While "cost" is not considered by many in this forum, it is of 
paramount importance in a service provider environment, which may be 
the first big traffic generators for DUNDi on a 'private' 
interconnect basis.  It is also of paramount importance in enterprise 
use.  I think that DUNDi might be well served by having some 
discussion on cost data and even payment data, even if nobody wants 
to use it today.  I think standardization of the format will 
magically create vendors who would provide services for 
inter-provider settlement.  (Note: this can be used inside a company 
just as well - imagine if I have two * boxes, one with a PRI to 
Vendor M and one with a PRI to Vendor X, and I want to have my calls 
go to the "cheapest" PRI if possible.)

Fields that need to be considered for inclusion:
  - currency
  - cost interval (30/6, 1/1, ?)
  - cost per interval (first interval, per minute)
  - cost per interval (subsequent interval, per minute)
  - price-per call (if applicable)
  - reverse charge call status
  - billing data (payment processor? OSP data? paypal account?  that 
sounds silly... but really might not be.)
  - others?


2) I'm not certain what inclusion of # of egress ports will provide, 
though I think it's at least useful to provide in the result.  Unless 
the system was "closed" (meaning each participant knew the state of 
all other participants for call status) then this number would be 
fairly useless, because it would only be on call transmission that 
available trunk status could be determined.  It perhaps could be used 
on some type of weighing mechanism for round-robin if multiple 
answers were returned, I suppose.

3) Nobody ever commented in iDUNDi, which would be using DUNDi to 
reverse-verify inbound calls to prevent SPIT, or TSPAM, or whatever 
you want to call it.  I think this (if implemented and/or useful) 
could be as much as 50% of the traffic on the e164 context of 
DUNDi-speakers in the future.  If you're working on some overall 
"problems to be solved" then perhaps this might be worth throwing 
into the list.  Again, this is not mandatory for the protocol to 
function, but might be mandatory before admission to a trust group. 
Opinions? 
http://lists.digium.com/pipermail/dundi/2004-October/000108.html

JT


At 11:47 AM -0400 on 10/30/04, Ed Guy wrote:
>All,
>
>As part of the DUNDi documentation and design effort, I'm trying to
>identify the requirements that it is trying to address.
>
>Below are my notes on the subject. (sorry, They're a little terse and rough
>in
>places - it is a work in progress.)
>
>If you have any direction, feedback or comments... fire away!
>
>
>/ed
>
>
>---+  Terminology and Definitions
>
>    * Service - The term "Service" refers to any voice-band communication
>facility, e.g., telephone, fax, modem, etc.
>
>    * Egress Gateway - The term "Egress Gateway" refers an Internet facility
>that provides a communications path to a Service or Services that may not be
>directly addressable via the Internet.
>
>    * Routes - The term "Route" refers to an Internet address, policies, and
>other characteristics associated with the Service, or the Egress Gateway
>which provides access to the specified Service.
>
>---+ Functions:
>
>    Need a trusted system to register and locate telephone services and
>Gateways
>for the purposes of immediately setting up a voice call.
>
>    * MUST provide method to Register Services and Egress gateways
>       * Identifiers SHALL BE text and numeric
>
>    * MUST provide Location service for Services and Egress Gateways in a
>timely manner
>       * TTL
>       * minimal impact on PDD
>       * Best Effort service.
>
>    * MUST Scale to:
>       * Large Enterprise
>       * Cross enterprise
>       * Not Global
>
>
>---++ Identity
>
>    * Need mechanism to represent services using phone numbers and names
>       * identified by
>          * E.164 numbers
>          * Arbitrary Strings
>          * private numbering plans
>       * No central Authority
>       * No assumed clustering of numbers
>       * No assumed interconnect of services
>       * duplicate routes may be provided -- caller to resolve.
>       * cannot assume that services are unique.  (e.g., 700 numbers)
>
>    * User Class of numbers must be represented
>       * must be able to identify number class, if available.
>          * residential
>          * business
>          * gov?
>          * non profit?
>          * Called-party pays (mobile)
>          * toll free?
>       * must be able to DND for unsolicited calls
>       * must be able to DND for unsolicited calls from businesses
>
>
>    * Must be able to represent routes to Internet-based services and Egress
>Gateways
>       * Routes in form of arbitrary URL/technology
>          * multiple technologies available at same directory.
>          * multiple routes available at same directory.
>       * Relative Quality of route must be indicated.
>       * Capacity of Egress Gateway must be indicated,
>       * Source of route must be identified.
>
>    * Need mechanism to Locate above services across a trusted collection of
>servers.
>
>    * Must be able to identify servers in network.
>
>
>---++ Roles
>
>    * Publisher
>    * Consumers
>    * Big/Small???  -- does it matter?
>
>---+ Encoding
>
>    * efficient & Compact transport
>    * easy to parse, Minimize opportunity for errors (more specific)
>
>
>---+ Transport
>
>    * minimize network traffic
>       * Avoid Querying nodes which do not have any related identities
>
>    * Resiliency -  robust under multiple failures.
>
>    * Partial Responses - need mechanism to deliver information as soon as
>available.
>        * must be able to identify complete and partial responses.
>        * must be able to identify when responses are finished.
>
>    * Network Loss/Load.
>       * automatically recover from network partitions
>       * retry with back off.
>
>---+ Security
>
>    * Limit queries/responses to a 'trust group'
>       * nodes may be members of multiple trust groups
>    * Encrypt Queries and responses
>    * Privacy - no bulk publishing
>
>---+ Caching
>
>    * responses may be cached for appropriate lifetime.
>       * TTL
>    * certain classes of responses may not be cached.
>    * mechanism to invalidate cache is recommended.
>       * topology changes can invalidate cache.
>    * SHOULD preload cache
>
>What is nature of cache activity?  how are the
>2-3 BHCAs distributed? does cache make sense?
>Seems that there is probably a correlation between
>caller/callee -- call backs are common.  may want to
>cache caller as result of query.
>
>---+ Maintenance
>
>    * ability to 'whois' a location publisher/consumer.
>    * ability to request an authoritative answer.
>    * SHOULD have ability to identity all publishers in trust group.
>
>
>---+ Out of scope ?
>    * Caller determined service location.
>       * Jurisdiction
>       * ANI
>
>
>_______________________________________________
>Dundi mailing list
>Dundi at lists.digium.com
>http://lists.digium.com/mailman/listinfo/dundi