Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Blocker Blocker
    • Resolution: Incomplete
    • Affects Version/s: 2.0
    • Fix Version/s: milestone 1
    • Component/s: sip_container
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      1,573
    • Tags:

      Description

      The product shall support applications that have a need to perform dns lookups
      of NAPTR records (i.e. In addition to current dns features for ENUM and SipUri
      resolving purpose).
      Comment:
      The designers of the application requesting this functionality have found out
      that almost the right method is available in the DNSResolver class and were
      considering to expand the current TelUrlResolver to expose this more general
      naptr lookup method. However they would also like the selected solution to be
      futureproof (be functional on SGCF).
      Furthermore they wish the current dns related functions and interfaces like Dns
      Alarm, refined primary/secondary retry mechanism of eas to function and
      tuneable dns cache size etc to work as in other dns functions (for example ENUM
      lookups) .
      Option1:
      Expand the current TelUrlResolver proprietary interface with a new public
      method to lookup naptr with a specified servicecode. Example
      resolveNaptrDnsRecord("SIP+D2T")
      Pro: Easy to implement in current DnsResolver code, EAS/MMAS additions will
      work out of the box
      Con: The new method does not relate to TelUrls, no support for other general
      dns record lookups that may be requested by pgm or other apps in future
      --------------------------------------
      Option2:
      Expose a brand new proprietary interface for general dns record lookups
      Pro: Avoids exposing an third party interface (e.g dnsjava), EAS/MMAS additions
      will work out of the box
      Con: It is yet another proprietary interface with purpose that can be solved by
      standard api's
      --------------------------------------
      Option3:
      Use JNDI dns resolving feature
      Pro: Avoids exposing an third party interface (e.g dnsjava).
      Con: less convenient than dnsjava: need to perform some parsing of NAPTR
      records manually, difficult to get EAS/MMS dns features working?
      --------------------------------------
      Option4:
      Let PGM application access the dnsjava api directly.
      Pro: Well spread and mature API, EAS/MMS dns features is available through
      static member initialization (setResolver())
      Con: exposes a third party interface for applications
      --------------------------------------
      We have discussed this a bit among collegues and we think that either option 3
      or 4 may the best choice.
      Option 4 seems to work with no known problem.
      With Option 3 one obstacle is is to get the EAS/MMAS dns feature additions
      working. It should be possible by plugging in the dnsjava library into the JNDI
      backend (sun.net.spi.nameservice.provider.1=dns,dnsjava see
      http://www.dnsjava.org/dnsjava-current/README). However efter some quick
      prototyping efforts this setting currently does not seem to work (dns queries
      does not seem to be actually sent via dnsjava......). I have switched on
      dnsjava verbose logging (Options.set("verbose")) and can see trace output only
      for queries via dnsjava api (not JNDI or InetAdress.getByName())

        Activity

        Hide
        eralsad added a comment -

        Changed subcomponent to SIP

        Show
        eralsad added a comment - Changed subcomponent to SIP
        Hide
        jluehe added a comment -

        ...

        Show
        jluehe added a comment - ...
        Hide
        sanandal added a comment -

        Added keyword ocean to track new RFEs

        Show
        sanandal added a comment - Added keyword ocean to track new RFEs
        Hide
        sanandal added a comment -

        Added keyword ocean to track new RFEs

        Show
        sanandal added a comment - Added keyword ocean to track new RFEs
        Hide
        sanandal added a comment -

        Added keyword ocean to track new RFEs

        Show
        sanandal added a comment - Added keyword ocean to track new RFEs
        Hide
        eralsad added a comment -

        The decision was to go for the solution which does not affect SGCS.

        Show
        eralsad added a comment - The decision was to go for the solution which does not affect SGCS.

          People

          • Assignee:
            ehsroha
            Reporter:
            eralsad
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: