< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

Re: [reSIProcate] enum support in resip


Hi Jason,

this really sounds great to me. Just two short comments from my own 
experience:
- I would consider support for multiple enum suffix domains. Several private 
ENUM branches showed up, and no matter if you like this or not, it should be 
possible to query more then one branch before giving up.
- maybe requiring a specific URI parameter for doing ENUM lookups would be an 
alternative to comparing the domain suffix. Although I'm currently not quite 
sure what is the better/cleaner solution.

  Nils

On Wednesday 31 August 2005 23:47, 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@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel