New feature request: Use own domain name

Hi,

It looks like I may have missed out on the "What do you want to see from VoIP User?" thread, so I thought I'd raise a feature I'd love to see which wasn't covered there.

I'd like to be able to change my VoIP User URI from a SIP URI of the form:

sip:<VoIPUserID>@voipuser.org

into one with my own domain name (e.g. example.com):

sip:<VoIPUserID>@example.com

It would be easy for me to enter DNS SRV records for SIP for my domain name to point to sip.voipuser.org.

All that needs to happen is for VoIPUser's SIP server to allow incoming INVITES from any domain and to redirect them based on the username. This could be a blanket "allow all" policy or, with more work, you could set the system up so that you have to register for this service in the manner of Google Apps For Your Domain or Microsoft's Office Live services.

Ideally, the user would also be able to register with the VoIPUSer sip registrar with their own domain name as well, so that the return address for outgoing calls returns correctly.

These types of personalised domain services work for Google and Microsoft, they could work for VoIP User too! Many business users don't care much about the phone numbers they publish, but they usually do when it comes to publishing things like email addresses and SIP URIs - e.g. not many professional businesses use hotmail.com ... if you gave them the option to use their own domain name, you may find business users (who are responsible for large volumes of calls) are more interested in trialling the service.

Sam.

Take a look at this, it seems to offer what you are looking for and the basic package is free ...

http://www.dyndns.com/

We still need to do some work server-side here though John.

Funnily enough I talked to TJ about doing this a year or so ago, and again a couple of weeks ago with x-console at VoN in Berlin.

It's not possible with SRV simply because SRV has not yet matured and few SIP user-agents can make use of it, so the majority of calls would fail.

But what we could do, and what we discussed doing, is using SIP as a sub-domain so you could have, for example:-

sam @sip.samsdomain.com

.... as your SIP URI (assuming you have full control of your domain and could setup DNS records for sub-domains).

That's the best that's doable with current technology and the current state of SRV.

Quote:

you may find business users (who are responsible for large volumes of calls) are more interested in trialling the service.

We do not support that beyond network testing and experimentation. Business users need a business grade ISP and support structure which we can't offer. VoIP User is for non-commercial use.

I agree with you that the main VoISP suppliers should be supporting use of own domains in some capacity though. SRV just has some way to go yet.

It's definitely something we'll be experimenting with.

Dean

I already have the capability to create SRV records (pretty much have full control over the domain aspects) ... but I don't think pointing them to sip.voipuser.org is enough. The server has to route the call and, I suspect, it will throw away anything that isn't *@voipuser.org ... tho, I'm sure you guys know better than me how it's currently configured.

The other "thing" is that to allow the name to show in outgoing calls, I assume I'd need to login as me @mydomain.com rather than me @voipuser.org.

I'm surprised to hear that SRV isn't mature enough yet, tho. The SIP User Agents I use certainly support it ... and isn't Jabber/XMPP also built on SRV?

Sam.

P.S. I only mentioned business customers in a vain attempt to increase interest in the feature.

P.P.S. As a home user, I'd be happy to trial any experiments in this area. I'd much prefer to be able to refer people to my own domain name SIP address and I can't think of a way to do that short of buying my own server. I run a small one from my home LAN, but buying a SIP-aware router to do the NATing would probably cost a small fortune.

In fact,

just for the record - I did try pointing my SRV records at sip.voipuser.org and it failed as expected.

Response from the server included below, with my details suitably changed ...

example.com - my domain name
example.net - SIP provider I'm calling from

Sam.

22:39:52.2
SENDING TO: 216.127.66.119:5060
INVITE sip:samwise@example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.1:5063;branch=z9hG4bK-d87543-b7041c1df7421e49-1--d87543-;rport
Max-Forwards: 70
Contact: <sip:samwise2@192.0.2.1:5063>
To: <sip:samwise@example.com>
From: "A.N.other SIP provider example.net"<sip:samwise2@example.net>;tag=66719c48
Call-ID: 6a3d690f7026bd67@U0FNUw..
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
Content-Type: application/sdp
Supported: eventlist
User-Agent: eyeBeam 1.1
Content-Length: 346

v=0
o=- 40167528 40167767 IN IP4 192.0.2.1
s=eyeBeam
c=IN IP4 192.0.2.1
t=0 0
m=audio 9206 RTP/AVP 100 6 0 8 3 18 97 5 101
a=alt:1 1 : 931FDC8B 00000012 192.0.2.1 9206
a=alt:2 3 : DF7A32CA 000000E9 192.168.2.2 9206
a=fmtp:101 0-15
a=rtpmap:100 speex/16000
a=rtpmap:97 speex/8000
a=rtpmap:101 telephone-event/8000
a=sendrecv

22:39:52.4
RECEIVING FROM: 216.127.66.119:5060
SIP/2.0 403 No relaying
Via: SIP/2.0/UDP 192.0.2.1:5063;branch=z9hG4bK-d87543-b7041c1df7421e49-1--d87543-;rport=5063
To: <sip:samwise@example.com>;tag=48ce9d90351f9cce9563eb189acc14a7.76b8
From: "A.N.other SIP provider example.net"<sip:samwise2@example.net>;tag=66719c48
Call-ID: 6a3d690f7026bd67@U0FNUw..
CSeq: 1 INVITE
Server: OpenSer (1.0.0 (i386/linux))
Content-Length: 0

As I mentioned above, we would need to do some things server-side first. What you're trying won't work.

Quote:

The SIP User Agents I use certainly support it

Which ones? Would be useful to compile a list.

dean :

As I mentioned above, we would need to do some things server-side first. What you're trying won't work.

Yep, that's what I said too ... I did it for the doubters amongst us.

dean :

Which ones? Would be useful to compile a list.

OK, well, this is off the top of my head ...

* Counterpath's eyeBeam 1.1 for Windows which definitely does. I'm fairly certain the new eyeBeam 1.5 does as well (but they removed the diagnostic log feature so I refuse to upgrade!).

* Counterpath's X-Lite 2 & 3 for Windows (the latter is built on the eyeBeam 1.5 codebase so, whilst I haven't actually checked it, I'm confident it does).

* Counterpath's X-Lite 2 for Linux

* Xten's X-PRO for Windows

* Xten's X-PRO for Pocket PC

* Cisco 7960

* Grandstream GXP-2000

* Hitachi WirelessIP5000E-A (and fairly certain it's predecessor, the WirelessIP5000E did as well)

* According to this doc, SJphone does as of 1.60

* and therefore SJphone for Pocket PC ...

* KPhone, as of 1.0.2 (now up to v4.2 +)

* Twinkle for Linux

* Microsoft Windows Messenger 5.1

* Grandstream BudgeTone 102 (according to this voip-info page)

* ProVu Snom 200

* Linksys SPA-1001

... and I haven't really played with many others. Maybe someone else can add more.

Which UAs don't support it? Are you sure that list won't be shorter?

This is the first I've heard that RFC 2782 SRV records aren't the current, standard way to call between providers. Is the only problem you see with SRV the client support (which I think could be disputed ) or do you think there is something more fundamentally wrong? Would appreciate your thoughts or a link to further reading, if there are other issues with it.

Sam.

Thanks Sam - that's a really useful list. I'll see if we can get some others added to it and might split that into a new thread.

I'm happy to revisit the idea of SRV if the majority of SIP UA devices support it properly.

Dean

dean :

Thanks Sam - that's a really useful list. I'll see if we can get some others added to it and might split that into a new thread.

Yeah. I know that some of them may not have implemented it exactly to the letter (e.g. CounterPath have been accused of ignoring the priorities in the SRV records and just using them in the order returned by the DNS server) but I believe all the above user agents would "work" when making a call. I've used the Windows, Linux and Pocket PC platforms as well as many hardware (wired and wireless) devices and I've never had an issue with SRV in the last three years or longer.

dean :

I'm happy to revisit the idea of SRV if the majority of SIP UA devices support it properly. Dean

Well, the only platform I can't speak authoratively on is Mac OS, but I'm sure the majority of clients there will support it as well (e.g. CounterPath produce X-Lite for the Mac).

Basically, I have no objections to the idea of implementing a workaround which might be helpful for those users who don't have enough control over their DNS to add SRV records.

However, the official "standard" route for this interoperability is SRV, so I think this should come first.

The long-term view for the new wave of protocols like SIP, XMPP etc., AIUI, is that users should be able to use one address for email, jabber, SIP etc. It's fairly routine for jabber servers to interoperate in this way.

I want to be able to start using samwise @example.com as my SIP address, samwise @sip.example.com is closer than samwise @voipuser.org but not what I think should be aimed for. I'd run my own domain but NATing the SIP to a server behind a home router is a bit of a painful exercise on a low budget.

I'm happy to put my domain and the myriad clients I have installed here at your service, if you get a chance to look into this ...

samwise :

I'd run my own domain but NATing the SIP to a server behind a home router is a bit of a painful exercise on a low budget.

Unless I have mistaken what you have said above, I don't see how this can be a painful exercise. As far as SIP concerns, the FQDN is transparent behind a NAT/Firewall router so long as you have properly configured your VoIP devices and/or servers connected behind the NAT/Firewall router.

Quote:

However, the official "standard" route for this interoperability is SRV, so I think this should come first.

I agree - there's no question that SRV is the future. It'll be interesting to perhaps run a trial and see how many SIP UA's are not SRV compliant.

Dean

mazilo :

samwise : I'd run my own domain but NATing the SIP to a server behind a home router is a bit of a painful exercise on a low budget. Unless I have mistaken what you have said above, I don't see how this can be a painful exercise. As far as SIP concerns, the FQDN is transparent behind a NAT/Firewall router so long as you have properly configured your VoIP devices and/or servers connected behind the NAT/Firewall router.

mazilo,

My home network, like the majority of broadband connections here in the UK, is behind a typical home router which provides firewall and NATing capabilities. It's possible to use SIP UAs through this NAT using features like STUN or SIPatH (or whatever it's now called). However, to run a SIP server behind this type of NAT router, I think, will be troublesome because the router is not SIP-aware. The SIP messages that flow through the router will contain, embedded in the body, the IP address of the SIP server on my local network. This would need translating to my internet-facing IP on the way outbound, and back to the local IP for incoming traffic.

Such functionality is available in higher-priced commercial routers, such as those from Cisco, but not, AFAIK, in the cheaper all-in-one routers aimed at the typical residential market.

There may be other ways round this but, I suspect, nothing simple that I could recommend to non-technical users (I have less geeky friends who sometimes attempt to duplicate my setup). I'll probably do some further investigation into this in the future (unless voipuser trials this feature) so if you have any suggestions, I'd be happy to hear them.

dean :

I agree - there's no question that SRV is the future. It'll be interesting to perhaps run a trial and see how many SIP UA's are not SRV compliant. Dean

Dean,

If you want to work on this, the offer's there. I'll be more than happy to assist as I can.

Sam.

dean :

It'll be interesting to perhaps run a trial and see how many SIP UA's are not SRV compliant.

I believe most Linksys ATA devices are SRV compliant.