[reSIProcate] enum support in resip

[Klaus Darilion]

Hi Jason!

Recently there was an ENUM plugtest at ETSI. The results are available at:
http://www.etsi.org/plugtests/History/DOC/2005_Enum_Final_Report.pdf

I think it might be worth reading it. It shows several aspects of ENUM 
clients behaviour.

regards
klaus

Jason Fischl wrote:
> I am in the process of adding support for enum into resiprocate.
> Here's the approach I'm planning on taking. I hope to have something
> in place for basic testing by the end of the week.
> 
> Reference rfcs: 
> http://www.faqs.org/rfcs/rfc2915.html   NAPTR
> http://www.faqs.org/rfcs/rfc3761.html   enum
> http://www.faqs.org/rfcs/rfc2916.html   enum (obsoleted by 3761)
> http://www.ietf.org/rfc/rfc3824.txt         enum with sip
> 
> Assumptions: 
> - only pick one sip uri for a given input phone number
> - only support E2U+sip service or sip+E2U (for backward compatibility
> with 3761). records using other services will be ignored.
> - delimiter is not required to be '!'
> - antecedent of regexp does not need to be greedy (e.g. ^.*)
> - NAPTR records for ENUM must not use the replacement field (only the
> regexp field). records using the replacement field will be ignored.
> - URIs will only be sip or sips. records using other schemes will be ignored
> - order values are assumed to be the same
> - preference value will be used to discriminate multiple records. If
> there are multiple records at the same preference they will chosen
> arbitrarily
> - only one ENUM NAPTR record will be selected
> - no recursive ENUM lookups allowed
> - if the subsequent NAPTR lookup on the domain in the URI fails, no
> additional ENUM records will be considered.
> 
> Interface: 
> 
> /** 
> Define the default enum suffix to use for this stack instance. If no
> suffix is provided, enum lookups will not be performed (unless
> specified on the request uri)
> */
> SipStack::setEnumSuffix(const Data& suffix="e164.org")
> 
> New resip specific parameters: 
> - These parameters are intended to be used on the request uri of a
> SipMessage coming from the TU. The DnsResult will look at the Uri
> being resolved. If it contains p_enumSuffix, then DnsResult will
> perform an enum query using the specified suffix. Otherwise, the usual
> NAPTR / SRV processing will take place. These new parameters are for
> internal use only and will not be sent over the wire.
> - if there SipStack::setEnumSuffix was called by the application and a
> request is passed from the TU to the stack with no p_enumSuffix
> parameter on the Request URI, the stack will add a p_enumSuffix
> parameter to the Request URI with the value provided in
> SipStack::setEnumSuffix
> 
> p_enumSuffix 
> - used to specify an override for the enum suffix to use on this lookup. 
> - will be removed from the request uri before the request is sent over the wire
> 
> p_telDomain
> - if no enum record is found (or no enum lookup is requested) and a
> tel URL is passed to the stack, p_telDomain can be provided in the
> Request URI as policy for converting a tel URL to a sip URL.
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at list.sipfoundry.org
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
> 
>