Calling SIP URI

I now have a SIP URI on my business card - it is actually shorter than my phone number by quite a bit :-) I am showing the phone number as well.

It is a bit of an experiment to see if people ever use it, and obviously is a bit geeky.

But it does strike me as progress - it is a way of calling me that does not involve a telco or OFCOM.

That means no Data Retention Directive records for the call at all.

I think we may want to do a wiki page on how to set up your domain and FireBrick to accept SIP URI based calls directly.

At the moment it is a tad messy - a real SIP phone tends to want to call numbers, and via a proxy, so I can get calls but can't yet call people back. I suspect we'll refine this a bit over time to make direct SIP URIs easier to manage.

All good fun.


  1. On the Gradwell service I can set SRV records for my domain to be handled by their VoIP servers, which is a nice idea in principle but of course no one has ever used it. The main problem seems to be clients not allowing URI dialing and other providers not allowing incoming calls other than via PSTN. Can we construct URIs to access our AA VoIP numbers?

    1. An am thinking of supporting that, yes, but when we have moved over to new call server fully.

  2. I've had a SIP URI on my email signature for years - no one (legitimate) has ever called it. When we install VoIP systems for customers we block calls that don't come from a known extension or trunk because there's a surprising amount of SIP spam (just plug a SIP phone directly into the internet with no firewall and you'll get frequent calls from the spammers... although they never seem to actually offer an RTP stream so you just get silence when you pick up).

    1. Interesting. Indeed, we have set up FireBricks to be very cautious even responding to SIP messages with a challenge or an error without identifying the source sensibly from the config. The caller would have to match my SIP URI not just the host part. Will be interesting to see if I get duff calls.

    2. Typically we seem to see 3 types of attack:
      1. Repeated registration attempts using common usernames (usually numeric) - presumably they are trying a dictionary attack on the passwords.
      2. Repeated attempts to place unauthenticated calls to numeric extension numbers (e.g. "200", etc.) These haven't caused any problems for us because they never seem to hit the range of numbers we use for our extension numbers.
      3. Repeated attempts to place unauthenticated calls to real phone numbers using various formats. For example, someone has been trying to call 000972598679402, 900972598679402 and 00972598679402 through one of my Asterisk servers all this afternoon - presumably the attacker is hoping for a misconfigured server that gateways to the PSTN for unauthenticated clients. A quick google says this is a mobile number in Israel; although I've previously seen attempts to dial out to published callcentre numbers for various businesses, which I assume is an attempt to DOS the callcentre.

      Since these attacks pretty much all seem to target SIP addresses with a numeric user-part, I guess you might be reasonably safe if you only expose a non-numeric address to the outside world - I currently expose both sip:steve@example.com and sip:20@example.com (my internal extension number) to anonymous callers, which is probably a mistake. I've not been brave enough to set up any customer systems to accept anonymous calls yet though. :)

      We also employ fail2ban to automatically drop traffic from obvious attackers on all the servers we deploy.

      Another thing to potentially watch out for is making it obvious to the callee when a caller id is being provided by an anonymous SIP caller rather than from the PSTN. Although CLID isn't trustworthy on the PSTN either, its probably a whole lot more likely to be accurate than that provided by an unauthenticated SIP caller.

      Secondly, a lot of SIP phones get quite confused by SIP addresses with non-numeric user-parts, and often don't expose the domain name to the user at all (so a call from 4412345678@your-sip-proxy.com and a call from 4412345678@some-random-domain.com will both often be shown by the phone as simply being a call from 4412345678).

  3. Trying again since Google decided to eat my last post...

    It would be nice if the smaller telcos could all get together, divvy out some phone numbers (the 06 range looks free to me!), say "b@lls to you, Ofcom" and set up our own numbering scheme, all properly done with ENUM. Inter-telco (i.e. calls to 06 numbers) calls would be free and would surely be a reasonable selling point. Get the big telcos to buy into it and gateway those calls at their own interconnects and we're on the way to giving Ofcom a kick in the nether regions and doing a proper job properly.

    Ah, all wishful thinking...

    1. Funny you should say that - we were thinking of officially asking OFCOM for a block like 04 or 06 as a registry for settlement free SIP interconnect using DNS/ENUM but allowing call charge at retail to match 01/02/03 and standard interconnect charges on SS7 if BT wanted to route calls to SIP for old fashioned telcos, etc. If OFCOM don't play we just "take" a block and use it ourselves and get ITSPs to use it.

    2. I'd love that idea - or if it required reciprocal termination charges, so a mobile net charging 2p/min to terminate inbound calls would have to pay 2p/min to call 04 numbers, while VoIP operators could be settlement-free and landline telcos could either join that or would be the same fraction of a penny they charge.

      I have long wanted telco interconnect to move to a settlement-free setup for a while now, with originating and terminating operators each paying for the capacity they have at the tandems or NGS equivalents, rather than by traffic volume and direction.


Comments are moderated purely to filter out obvious spam, but it means they may not show immediately.

NOTSCO (Not TOTSCO) One Touch Switching test platform (now launched)

I posted about how inept TOTSCO seem to be, and the call today with them was no improvement. It seems they have test stages... A "simul...