random technical thoughts from the Nominet technical team

Using hessiancpp to call Java servlets from C++

1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)
Loading ... Loading ...
Posted by Anthony on Oct 3rd, 2008

Background

Hessian is a binary web service protocol. It’s quite efficient (see Daniel Gredler’s and Miquel’s benchmarks) and it’s dynamically typed.

[proto-footnote] Dynamic typing is of course very convenient for Java-Java communication building from a single source tree. I expect it’ll be much less of a good thing if we make a habit of calling from C++ to Java via Hessian, at which point the overhead of using a different remoting mechanism which uses an IDL might be worth it, to enforce a contract between the two languages.

Hessian is written by a company called Caucho, who also make Resin, a webserver / servlet container.

Grammar

Caucho provide what they call a “Formal Definition” of the Hessian protocol; it would be more helpful if it didn’t omit several carriage returns - there’s an older version of the document which is better formatted. To be honest, I found Caucho’s documentation to be a bit of a maze of twistly little packages, all alike.

Bindings for C++

One of the reasons Nominet originally chose to use Hessian was that client bindings are available for many languages, including C++. The (only) C++ binding is hessiancpp [sourceforge]. It is released under LGPL, but isn’t being actively maintained.

Building hessiancpp

hessiancpp depends on a library called “sslpp”. A bit of searching brings up a package called SSL++; this looks promising but it’s a red herring; hessiancpp is written to use a modified version of it.
The modified version is hidden in the CVS repository for hessiancpp. It’s had a few minor changes and a GPL licence added to the original author’s copyright statement.

With a bit of fiddling to Boost include paths etc., sslpp builds fine & so does hessiancpp.

Running a basic/demo program

There are some tutorials on Caucho’s site. They use Resin, which is simple to set up. Of course if you’re already using another server (e.g. TomCat) then you can’t run both simultaneously on the same port!

  • install Resin
  • set Resin’s user/password by getting server to create a digest & pasting that into [RESIN_INSTALL_DIR]/conf/resin.conf
  • download hessian_3.1.6.jar (or whatever’s the current version)

Make a Java package (which for example I’ll call pkg_foo) with demo servlet class interface (e.g. IFoo). Write a concrete class (e.g. CFoo) which

  • imports com.caucho.hessian.server.HessianServlet;
  • extends HessianServlet
  • implements IFoo

and compile with the hessian_xxx.jar and [RESIN_INSTALL_DIR]/lib/jsdk-15.jar in the classpath.

Copy or make a link in [RESIN_INSTALL_DIR]/webapps/ROOT/WEB-INF/classes to your demo servlet package directory.

Add a file web.xml in [RESIN_INSTALL_DIR]/webapps/ROOT/WEB-INF/ containing something like:


<web-app xmlns=“http://caucho.com/ns/resin”>
  <servlet
    servlet-name=“foo”

    servlet-class
=“pkg_foo.CFoo”/>
  <servlet-mapping
    url-pattern=“/hessian/foo”
    servlet-name=“foo”/>
</web>

Make a demo client:

  • import com.caucho.hessian.client.HessianProxyFactory;
  • import your servlet interface
  • making a Hessian call like:

    HessianProxyFactory factory = HessianProxyFactory();
    String url = (“http://” + “localhost” + “:” + “8080″ + “/hessian/foo”);
    try {
        IFoo f = (IFoo) factory.create(IFoo.class, url);
        int i = f.fmethod(42);
        }
        catch (etc. …)
    {}
  • compile with hessian_xxx.jar in the classpath
  • run with hessian_xxx.jar in the classpath

Calling from C++

So far we’ve just demonstrated that you can call from Java->Java. It’s easier because both client & server can share the Java interface. Calling from C++ using hessiancpp will be more laborious, so it was worth the overhead of having made it work from Java first. We’ve verified the server set-up, and also now have a framework for prototyping the methods & their parameters, and a fallback.

There’s an example “main” in the hessiancpp distribution;

  • create a hessian_proxy instance, noting that:
    - hostspec is “host:port” (i.e. no “http://”)
    - leading slash is expected on url (e.g. “/hessian/pkg_foo”)
  • call method “call”, passing in the method name, the parameter count & the parameters

This is where you meet a hurdle: hessiancpp doesn’t include much in the way of error-handling/checking, for example

  • parameter count isn’t checked against number of parameters
  • result for the HTTP call doesn’t check the HTTP status code (e.g. 200=success, 404=page not found etc)
  • the decoding of hessian datatype “fault” makes assumptions about which fields will be populated (and their ordering) in the response, so crashes decoding some basic exceptions e.g. “wrong method name”
  • doesn’t cope with exceptions thrown in Java-land

It’s often not obvious how to construct more complicated types; what/whether to put in the “type” fields of a Hessian map representing an object, for example. However if you add code to dump the Hessian datastream input & outputs it’s straightforward to refer to the Hessian grammar & make sense of the datastream. It’s a small matter of programming to modify hessian_wrappers & hessian_input to make hessiancpp decode it correctly, and hessian_output to serialise correctly.

Download

Files as discussed above

Improvements

I’ve made some changes to hessiancpp, which I’ll document and post on this blog.

Improving copy speeds between servers

1 Star2 Stars3 Stars4 Stars5 Stars (3 votes, average: 4 out of 5)
Loading ... Loading ...
Posted by andyh on Sep 30th, 2008

As an SA I frequently have to copy large files between servers. We have a good network here at Nominet and normally files get copied relatively quickly. When I copying things to remote sites then the copy times start to increase (perfectly normal as we have less bandwidth to remote sites). This isn’t normally a problem, but has been bugging me recently. There is an answer to this - use the “-C” flag of scp to copy the file. Whilst this won’t affect copy times for highly compressed data but it will improve things for non compressed data.

Loss of .uk nameserver

1 Star2 Stars3 Stars4 Stars5 Stars (2 votes, average: 5 out of 5)
Loading ... Loading ...
Posted by ian on Sep 29th, 2008

Those who monitor the availability of .uk nameservers through RIPE NCC’s DNSMON service will have noticed that ns6.nic.uk was offline for over 24 hours last week. This is a much longer outage than I would have liked but it has highlighted some interesting issues.

We manage seven of our nameservers directly. Since a rationalisation effort in 2002 they have all been hosted in other organisation’s networks, usually IXPs or ISPs, and are subject to contracts with specific SLAs. (Prior to this .uk nameservers were hosted by volunteers on a ‘best effort’ basis.) One nameserver, ns6.nic.uk, is different. It is hosted by NikHef in Amsterdam. When we were offered the chance to have a nameserver in Amsterdam we were very keen to take it. The arrangement to host did not include an SLA and was not subject to contract. It was in effect a gentleman’s agreement. We paid a modest sum for rack space and connectivity, but we had no claim over NikHef regarding the availability of the service.

The base level of DNS traffic to the .uk nameservers is pretty low at about 15 Mb/s over all seven that we manage and monitor. However, we do see an increasing number of traffic spikes, with peaks of 400-500% of this base level. During these spikes we see a very large number of queries for non-existent MX records coming from a great number of machines. My assumption is that this is backscatter from a spam storm, with the originating IPs being part of a botnet. I have no proof of this however.

There was a major spike on Thursday 25 September with total traffic levels peaking at over 70 Mb/s. Though six of the nameservers dealt with this surge with no obvious problems, this had a large impact on ns6.nic.uk. Because NikHef is not a supplier of network services the .uk nameserver is hosted within their own network. The surge caused their gateway router to be overwhelmed and within an hour they had downed our connection. I cannot blame them for this, and I would probably sacrifice a ‘guest’ service in similar circumstances. They tried to bring it back with severe rate limiting, but it was still largely unreachable. I began to think we would have a very long outage, even that we would have to relocate the whole nameserver system.

I moaned about the situation to anyone who would listen, and it was my friend Will Hargrave who suggested I buy alternative transit from Goscomb Technologies. They are handily placed as Dan Goscomb is presently based in Amsterdam and has a router in the same datacentre. Dan was able to get ns6.nic.uk back online within 3-4 hours of me speaking to him. The biggest effort required on our side was deleting and recreating the RIPE route-object, as this involved several different maintainers working in concert.

So, we now have all our nameservers back online. The main lesson from this is that we should ensure that all services we take are properly protected by contract. This has been the way we work for many years, but we need to review the arrangements we have as this one clearly fell through the net. As it stands now we still have no contract with NikHef regarding the rack space we occupy. Arrangements like this are just not good enough for a ccTLD registry.

RFC 5105 tokens and apache xml security

1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)
Loading ... Loading ...
Posted by sion on Sep 26th, 2008

We have been using the apache xml security (java) libraries to produce RFC 5105 type signed XML tokens. There are a number of steps involved which were not obvious (to me) from the documentation or the examples; so here are some of the things that we had to do.

Firstly turn your ascii-armoured private key and certificate into DER format:

openssl x509 -in enum.crt -inform PEM -out enum-cert.der -outform DER
openssl pkcs8 -topk8 -nocrypt -in enum.key -inform PEM -out enum-key.der -outform DER

NB: in this format your private key is unencrypted, if you are more comfortable doing this on the fly then I’m sure that is possible.

In this format you can read the files into your code by doing something like:

CertificateFactory cf = CertificateFactory.getInstance("X.509");
X509Certificate cert = (X509Certificate) cf.generateCertificate(new
ByteArrayInputStream(JavaUtils.getBytesFromFile("enum-cert.der")));

and similarly with the private key:

KeyFactory keyFactory = KeyFactory.getInstance("RSA");
PKCS8EncodedKeySpec privSpec = new PKCS8EncodedKeySpec(privKeyBytes);
PrivateKey privKey = (PrivateKey) keyFactory.generatePrivate(privSpec);

where privKeyBytes is a byte array from your enum-key.der.

Now you need a String which contains your unsigned token XML, see rfc5105.

For a starting point, we used the code distributed as GenEnveloped.java in the samples directory. This has a number of issues with it; the KeyInfo is not in X.509 format and the transform lacks the InclusiveNamespaces parameter.

The first issue is dealt with by generating your KeyInfo object like this:

X509Data ki5 = kif.newX509Data(Collections.singletonList(cert));
KeyInfo ki = kif.newKeyInfo(Collections.singletonList(ki5));

Now set up your Reference object like this:

List<Transform> transformList = new ArrayList<Transform>();
transformList.add((fac.newTransform(Transform.ENVELOPED, (C14NMethodParameterSpec) null)));
transformList.add((fac.newTransform
(CanonicalizationMethod.EXCLUSIVE, new ExcC14NParameterSpec(Collections.singletonList("enum-token enum-tokendata")))));

Reference ref = fac.newReference
("#TOKEN", fac.newDigestMethod(DigestMethod.SHA1, null),
transformList, null, null);

The rest of the example code is largely unchanged. This should produce a signed token that you can imbed in other XML documents and still have it validate.

Version 1.0.0 of dnsjnio released

1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)
Loading ... Loading ...
Posted by alexd on Sep 18th, 2008

At the risk of spamming this blog with updates on dnsjnio, I’d like to announce that version 1.0.0 of dnsjnio has now been released.

The changes include :

o UDP single-port race conditions fixed.
o Single-port operation removed for UDP.
o TCP single-port and multiple-port race conditions fixed.
o Retry behaviour in ExtendedNonblockingResolver now doubles timeout for each retry.
o Port randomisation is now done by dnsjnio, rather than left to the host O/S.
o Different QID now used for each query in round-robin or timeouts.
o Timeout semantics changed slightly in SingleResolver.sendAsync().
o Redundant error message removed.
o Test code fixed.

If anyone finds any issues with this code, I’d be very keen to hear about them.

Hopefully, I’ll now be able to keep quiet about dnsjnio for a while!

DNSSEC Impact on Broadband Routers and Firewalls

1 Star2 Stars3 Stars4 Stars5 Stars (1 votes, average: 4 out of 5)
Loading ... Loading ...
Posted by ray on Sep 15th, 2008

I’ve just co-authored a report which I hope will be of interest to readers.

The report is entitled “DNSSEC Impact on Broadband Routers and Firewalls” and is available for download at:

http://download.nominet.org.uk/dnssec-cpe/DNSSEC-CPE-Report.pdf

In summary (based on 24 tested units):

… we conclude that just 6 units (25%) operate with full DNSSEC compatibility “out of the box.”  9 units (37%) can be reconfigured to bypass DNS proxy incompatibilities.  Unfortunately, the rest (38%) lack reconfigurable DHCP DNS parameters, making it harder for LAN clients to bypass their interference with DNSSEC use.

These findings, their potential impact on DNSSEC use by broadband consumers, and implications for router/firewall manufacturers, are presented and analyzed in this report.

I shall be presenting the results of our findings at the OARC Workshop in Ottawa, CA on September 24th.

Using gqlplus with Instant Client on Mac OS X

1 Star2 Stars3 Stars4 Stars5 Stars (1 votes, average: 5 out of 5)
Loading ... Loading ...
Posted by chris on Sep 15th, 2008

I need to use Oracle’s SQL*Plus quite often from my Mac but Oracle’s support for OS X is sketchy to say the least.  You can’t install the proper client on Intel machines, so you have to use the Instant Client instead.  I also want to use gqlplus, which adds things like a command history to SQL*Plus.  (You may be amused to know that SQL*Plus was once called UFI, meaning “User Friendly Interface”, not sure how it could be made less friendly really).  After a bit of trial and error, I got it working.  This is how I have it set up:

  • I installed instantclient into its own directory
  • I added this directory to PATH and to both LD_LIBRARY_PATH and DYLD_LIBRARY_PATH environment variables
  • I put tnsnames.ora and login.sql (for commands to be run at login time) in my home directory
  • I pointed the TNS_ADMIN and SQLPATH environment variables to my home directory
  • I built and installed gqlplus in /usr/local/bin

I have also set up an alias so that gqlplus runs with the -d flag.  This turns off the auto-completion which can make gqlplus slow to load.

ipv6 It Just Works :)

1 Star2 Stars3 Stars4 Stars5 Stars (1 votes, average: 5 out of 5)
Loading ... Loading ...
Posted by brettcarr on Sep 9th, 2008

With the impending exhaustion of IPV4 address space (currently predicted as 17 Oct 2011 http://www.potaroo.net/tools/ipv4/index.html ) it seems every networking event these days has coverage of ipv6, which can only be a good thing I guess. So yesterday while at uknof I discovered that google are now running an ipv6 only version of their website at ipv6.google.com which made me wonder how easy it is to get ipv6 up and running on a personal laptop/desktop.

Now I normally reserve the ‘It Just Works’ phrase for Mac OSX however today I felt the need to apply it to ipv6 or more specifically an ipv6 technology which I have only recently become aware of called Teredo. This enables you to tunnel ipv6 traffic through a NAT over ipv4. In simplistic terms it encapsulates all your ipv6 packets inside ipv4 UDP packets and sends them to a Teredo Server/Relay which then strips the ipv6 back out and forwards it to the ipv6 only internet (further technical detail available at references listed at the end of this article)

The real plus point of this approach though is how easy it is to configure on the client:

OSX- Download and install the client here: http://www.deepdarc.com/miredo-osx/
Linux- Download compile and install the client here: http://www.remlab.net/miredo/
Windows XP SP2 and above- Run two commands at a dos prompt
‘netsh interface ipv6 install’
‘netsh interface ipv6 set teredo client’

You’re done.

To check your ipv6 is working try accessing http://ipv6.google.com or do a traceroute6 (tracert6 for windows) to 2001:7fd::1 which is the ipv6 address for the K Root DNS server.

Ok so it’s not native ipv6 but it does give you some basic understanding and experience.

As I understand it the ease of use and installation under Windows is explained by the fact this was originally a Microsoft invention.

More technical details are available at the following links

http://www.microsoft.com/technet/network/ipv6/teredo.mspx
http://www.rfc-editor.org/rfc/rfc4380.txt

Additional Security note:

Potential users and in particular network security admins should be aware that running a teredo tunnel opens a publicly routed ipv6 address on the machine in question. It maybe wise to configure firewalls to block this behavior behind corporate networks.

Anoto pens, Moleskine notebooks and OSX

1 Star2 Stars3 Stars4 Stars5 Stars (2 votes, average: 5 out of 5)
Loading ... Loading ...
Posted by jay on Sep 6th, 2008

Anoto

If you’ve never heard of it before, Anoto is a company with a clever piece of technology that enables digital note taking. It starts with a special paper printed with a pattern of tiny (0.1 mm) dots on it. The pattern is based on a grid, but each dot is slightly off centre of from the grid intersections:

They then have an algorithm that can produce squares of this grid, where each square is 2×2 mm and has 36 dots on it, each with a unique pattern. The total surface area they can cover with this unique pattern is 1.8 million square miles.

Then they have a pen, which has a miniature camera built into it that takes 50 or so photographs of the nearby dots every second. From that the pen can tell exactly where you are, where your stroke was going and where it has gone, basically recording everything you write. Most importantly, if you raise the pen and then lower it to the paper, it can tell immediately where it is.

The other clever thing about this pen is the ink. The dots themselves are printed in black and are visible in the infrared (IR) portion of the spectrum, which is how the camera sees them. But in order to ensure that the ink you write does not obscure the dots they have developed IR transparent ink.

That’s the technology, which is easy enough but Anoto then complicate things drastically by their business model and appalling web site. They don’t sell anything direct but work through partners, on whom they provide precious little information. These partners then develop products and, in many cases, buy a section of the virtual Anoto paper to use for their applications.

Most of these partners have developed “business applications” such as pre-printed forms for recording medical questionnaires. All very interesting I’m sure, but no use to me and by definition a niche product.

Moleskine notebooks

This brings me onto to Moleskine notebooks. I love these. They have a way of making me feel I can create anything and anything I do write looks good.

But that’s not enough. I want a digital Moleskine, or something very similar so I get the same feeling of productivity and yet have it all digitally recorded.

OSX and sharing my data

The final thing I want is a way of getting the data off the pen onto my Mac and from there outputting it to my note taking program (SOHO Notes) or a wiki (Confluence) or even to ebook format.

The requirements

It appears that most of the Anoto partners have inherited the same “give your customer only half the information” attitude to web sites as Anoto so finding out exactly how it all fits together was painful to say the least. Even now I still don’t have some crucial answers.

Just to be clear, the three things I am after are:

  • An Anoto-enabled pen.
  • OSX software to talk to the pen above that outputs in a way I can actually use. It would be nice if it did character recognition as well but I guess that is pushing it.
  • An Anoto printed notebook that feels like a Moleskine.

I’ve found the last one quite easily, made by Livescribe. They also seem to make great pens, complete with built-in audio recording and and OLED display. Unfortunately they don’t make OSX software though they are developing some. Even with their Windows software I can’t tell what formats you can output to, they say so little about it. Sigh.

I’ve also come across two separate providers of OSX software, Pen-It and Paperium. The Paperium software claims to output in lots of ways. Both of these come with their own pens to link to their software, which gives me my first major question:

Can any Anoto-enabled pen work with any pen software or is software unique to a specific pen and vice versa?

Pen-It, who resell the Maxell pen make it clear their software only works with that pen and they don’t sell it differently. Given just how little information there is on their web site I am amazed that nugget slipped through.

If the answer is ‘no’ across the board then I’ll have to buy the Paperium pen.

The next question is:

Will any pen work any Anoto paper product?

Again, I would have hoped this answer is yes but Pen-It again say their pen doesn’t.
Until I get that one answered I won’t be able to buy anything!

The products

To save you having to search for hours like I did, here is a roughly useful set of links.

Pens:

  • Maxell DP-201. This is also branded as Pen-It (not the same as the people above). They only sell through the channel but there appear to be plenty of people who resell it.
  • Nokia SU-27W. They do sell direct and lots of others sell it. This is the latest version of the discontinued Nokia SU-1B.
  • Destiny io. This was formerly the Logitech io pen (and io2) but they sold the business. This is possibly the least informative web site I have ever come across.
  • Magicomm g303. I’m not sure this is actually an Anoto-enabled pen. They are listed as a partner by Anoto but they don’t mention anything about it.
  • Livescribe Pulse. This is easily the pen with the highest features and can also come in a 2GB variant.
  • Paperium. I’m pretty sure this pen is just another pen rebadged but I haven’t looked at the pictures closely enough to be sure.
  • Flypen”. This is a version especially for kids

Paper:

  • Oxford easy book. These notebooks appear everywhere and again are sold through resellers not direct.
  • Orignote. These are supplied by Magicomm and again I don’t know if these are Anoto-enabled or not.
  • Livescribe notebooks. These are the nice ones that look like Moleskine books.
  • Paperium notebooks. Again these are probably rebadged but I can’t tell.

And finally …

Confused? I certainly am.

Implementing ENUM in the enterprise

1 Star2 Stars3 Stars4 Stars5 Stars (4 votes, average: 4 out of 5)
Loading ... Loading ...
Posted by jay on Sep 4th, 2008

So you’ve got your VoIP servers, you understand the basics of ENUM and you will be registering your numbers, but one question remains:

How do I add support for ENUM into my enterprise VoIP system so we can start to get free calls?

well here is a guide to help understand how it all fits together

Scenario 1 - the basic setup

This is the classic enterprise VoIP deployment that you will have been sold by Cisco, Avaya or any other enterprise telephony provider:
Scenario 1
As you can see:

  • we have a clearly delineated border;
  • the VoIP server and all the internal phones sit inside the border;
  • PSTN connectivity is through a specialist border device (like a Cisco 28xx router or a Session Border Controller (SBC)), which is the single point of entry;
  • the internal phone uses SIP or possibly SCCP or another proprietary protocol internally;
  • the border device deals with signalling protocol translation and media transcoding;
  • calls in either direction use the same paths (signified by the double headed arrows).

Scenario 2 - Receiving incoming VoIP calls

Taking this one step at a time let’s just look at receiving VoIP calls. I’m going to assume your border device does that:

Scenario 2

What this diagram shows is:

  1. The external VoIP caller does an ENUM lookup to find your public SIP servers (the border device).  Strictly they might not have used ENUM for this, they might have dialled an alphanumeric SIP address or found your details some other way, but let’s assume ENUM for now.
  2. The VoIP phone uses SIP to talk to the border device.
  3. The border device proxies this SIP to the PBX.
  4. The PBX proxies the SIP to the internal phone and the connection is made.
  5. The media stream then comes from the external VoIP phone to the border device, which then
  6. terminates and reconnects the media stream to the internal phone.

At no point does the external VoIP phone see any internal infrastructure or talk to it directly.

Scenario 3 - Ideal bi-directional VoIP calls

Ideally we want outgoing calls to mirror the process for incoming calls:

Scenario 3

This preserves the single point of entry, the proxying of protocols, media transcoding and so on. Don’t forget, whilst the diagram shows SIP internally, it will might well be a different protocol entirely.

However for this to work the border device needs to be able to do an ENUM lookup and act on that.  Unfortunately this is a rarity at present, though the investment in the UK Central Numbering Database should change that.  Some attempts have been made, for example Cisco sell an add-on called CUBE  (which you need just to do the basic incoming VoIP of scenario 2) that claims to do ENUM, but it is pre-standard version and so not a lot of use.

Scenario 4 - a drop-in ENUM box for outgoing VoIP

To get around the lack of support for ENUM for making outgoing VoIP calls, we drop in an ENUM box:

Scenario 4

This shows:

  1. The internal phone talks SIP to the PBX;
  2. the PBX proxies that to the ENUM box;
  3. the ENUM box does the ENUM lookup (which might succeed, fail, or timeout);
  4. the ENUM box then tells the border device where to send the call to, either the original destination asked for by the phone (that will then use PSTN) or the new VoIP destination discovered from the ENUM lookup;
  5. the border device contacts the external VoIP phone and the connection is established (if this connection fails then it falls back to PSTN);
  6. the internal phone sends its media to the border device;
  7. which then terminates and resends the media on to the external VoIP phone.

Where the border device does not support ENUM this is easily the neatest way forward.  You have one new device that only contacts the outside world by DNS and the border device still acts as the single point of entry for signalling and media.

Scenario 5 - Border device does not do VoIP

Things could be worse though, maybe your border device does not support VoIP at all and so you need an entirely new box to do all of that:

Scenario 5

The ENUM box is more than just an ENUM box, it is also a border device in itself.  The call flow is pretty straightfoward:

  1. The internal phone contacts the PBX by SIP;
  2. the PBX proxies that SIP to the ENUM box;
  3. the ENUM box does an ENUM lookup (if it fails it passes the call back to the PSTN border device);
  4. assuming the lookup is a success the ENUM box contacts the external VoIP phone on SIP and the connection is established (if that fails then it send the call back to the PSTN border device);
  5. the internal phone sends the media to the ENUM box;
  6. which then terminates and resends the media to the external VoIP phone.

So the border is still preserved but you now have a whole new VoIP infrastructure in there.  Of course many people would then be tempted to throw out the rubbish border device that does not do VoIP and get the ENUM box to also do the PSTN connectivity.  Asterisk anyone?

Scenario 6 - all very messy

Let’s suppose your border device still doesn’t do VoIP but you don’t want or can’t have the ENUM box do all of that and want to keep it as just a lightweight SIP proxy. In that case you have no choice but to expose your internal phones:
Scenario 6
The call flow is again pretty simple but with a horrible ending:

  1. The internal phone contacts the PBX by SIP;
  2. the PBX proxies that SIP to the ENUM box;
  3. the ENUM box does an ENUM lookup (if it fails it passes the call back to the PSTN border device);
  4. assuming the lookup is a success the ENUM box contacts the external VoIP phone on SIP and the connection is established (if that fails then it send the call back to the PSTN border device);
  5. the internal phone sends the media directly to the external phone, exposing itself in the process!

And finally …

Support for ENUM amongst enterprise telephony vendors is woefully inadequate, yet history clearly shows that the Internet has left graveyards full of companies that tried to resist it. If your vendor is one of those dinosaurs then hopefully this article will help you bypass their ignorance to take control of your own telephony.

Next »

Recent Posts

Highest Rated

Categories

Archives

Meta: