SIP and H.323 are fine, but they are only part of the issue. Codec's are a huge problem. The free (as in no license required) codecs are bandwidth hungry.
Some of the commercial codecs are better, but Speex, GSM codecs and AMR-NB are fine for most people. Also, I suspect that most people wouldn't care even if they were using G.711 - 64Kbps in each direction is tiny compared to most things people use their internet connections for.
The real issue though, is one of configuration. Using a strict SIP or H.323 client means the user has to understand issues like addressing, ports, etc..
How so? Usually it is simply a case of entering your username, password and the address of your service provider's SIP registration server. The only thing different to Skype here is that you don't need to enter the server address for Skype (but you can't allow for multiple service providers any other way, so if you want choice of service provider, thats what you're stuck with, just like email).
NAT *usually* isn't a problem (most clients are preconfigured to use STUN so no user fiddling needed here), although it is certainly nicer to avoid it where possible.
That means having a central service that not only provides default configurations and service
Some service providers ship clients preconfigured. For example, if you create an account on SIPgate then they present you with a preconfigured copy of X-Lite to download and any hardware you buy from their shop will be preconfigured with your account details before they ship it to you, making it pretty much plug-in-and-go.
but address books, and more importantly, doesn't allow just anyone to connect and voice spam the shit out of them.
I must admit I'd like to see an XMPP-style roster in SIP. However, most SIP clients do integrate with address books. e.g. Ekiga integrates with Evolution, Telephone integrates with the OS X address book, SIPDroid integrates with the Android contacts system, etc. It would, however, but nice to see some widely implemented open standards for address books (this applies to everything that uses address books, such as email, etc too) instead of applications being tied into specific address book systems.
Open systems are prone to spam, closed systems have a lot more control over that.
I'm not convinced about that... I've heard Skype users complaining about spam (I've not used Skype myself so can't really comment) but I don't get any spam calls to my SIP accounts. This is, of course, not down to anything particularly technological, probably just that it is harder to spam a decentralised system like SIP which has no central user database, etc.
I do see quite a lot of brute-force password attempts on my SIP servers, much like you see on ssh servers, etc. but due to reasonably secure passwords they never get anywhere and I have fail2ban configured to dump clients who make too many registration attempts (note, this is specific to running a SIP server, not a client, sop wouldn't affect Skype users anyway). I also see a lot of attempts to make unauthenticated PSTN calls, presumably attackers hoping the server is misconfigured and would allow them to do so (it won't). Again, fail2ban is configured to put a stop to this.
In the end, much like other communication systems such as IM, Email and even the PSTN, all VoIP systems are going to be susceptible to spam and there is very little to be done about it. I do feel that I am in a better position to filter spam from my own servers than relying on Skype to do it for me though (subjective).
How exactly does being interconnected and generally friendly to your adjacent systems require you to be open? Skype is perfectly interconnected (it runs on everything) without being open.
Depends what you mean by "interconnected". If you mean "runs on everything".. well, it runs on a lot of stuff but there is plenty that it doesn't run on for no reason other than they haven't developed the software for those platforms (and since it is a closed system, no one else can write the software either). If you mean "can make/receive calls to/from anything" then you're quite wrong. Skype can call PSTN numbers and Skype users but can't interoperate with SIP, XMPP, etc.
What the developers have missed is that we need a single way to create a SIP ID
Well you can't really have that any more than you can have a "single way of ordering a phone line" when there are multiple service providers. I guess SIP could introduce an account registration system like XMPP has so you can register accounts directly from your client, but is it really that hard to register on the service provider's website, like you do for most other services such as email?
a single global directory
I'm not sure how that would work - you really want a list of billions of people? When you want to phone Joe Bloggs, how are you going to identify which one, out of the 10,000 "Joe Bloggs" listed is the one you want?
On the whole, it sounds like a very bad idea to me - it is the perfect place for spammers to harvest addresses and this is exactly why email servers won't let you get a user list these days (despite it being part of the SMTP protocol). For other contact details (e.g. email, phone, etc), I'm pretty happy with maintaining my own address book of the people I actually talk to, and finding out the addresses of new contacts by talking to them, looking on their website, etc. and see no reason why I'd want to do anything different for VoIP.
Worth noting that despite the fact that a telephone directory is still distributed here in the UK (and available online), the majority of land-lines are ex-directory, it doesn't include mobile numbers and I certainly haven't actually *used* a telephone directory in at least 15 years because it is practically always easier to find someone's phone number a different way.
I do, however, think that it would be nice for SIP to provide access to (or at least, supply configuration data so your client can automatically access) your personal (and corporate-wide, for companies) address books rather than each client having to be configured to access whatever address book system you use.
and a single global ID/addressing format.
Err, you know SIP has always had a single addressing format don't you? It looks like an email address - sip:localpart@example.com, where "localpart" is something to identify you on the server (often your first.lastname). In fact, my SIP address is identical to my email address, so it makes it quite easy to remember.
Until this is addressed, SIP is a dead duck.
That would be a dead duck that's used by most modern telco networks, the vast majority of corporate phone networks and a significant number of home users. Mmmm.. sounds pretty dead to me.
Can you send a message from Google's XMPP servers to Facebook's XMMP servers? Last time I looked at it, although the protocol was the same, the servers were closed boxes.
You can send messages from Google's XMPP servers to any XMPP server that supports s2s connections (i.e. practically all XMPP servers) and vice-versa. This has been true for years.
Unfortunately, Facebook's half-baked implementation doesn't support s2s, so is, indeed, a closed box. I will leave this to your imagination whether this is a strategic method of locking users in, or just that their developers did a half-arsed job (no idea why they insisted on writing their own implementation instead of using one of the readily available open ones mind you)
Moving to IPv6 isn't a solution - it's not like everyone's going to run IPv6 without a firewall.
Removing NAT from the equation (which is inherent in moving to IPv6) _does_ make everything much easier. There is no requirement to run without a firewall or even poke holes in your firewall for inbound traffic - UDP firewall traversal is completely reliable if you're not going through a NAT. The reason why things get unreliable when NATs are involved is because the software has to make educated guesses about things like what IP address and port numbers the traffic is going to appear on once it exists the NAT, remove that problem from the equation and this stuff Just Works. (To be fair, SIP through a NAT usually Just Works these days anyway, but it is even more reliable once you dispense with NAT).
So, there probably would be no way to make ftp://example.com and http://example.com/ be on different machines without people having problems accessing one of those two services (since both can be accessed by a web browser). Yep, much more usable than NAT.
Ok, fair point. But who seriously bothers running anonymous FTP servers these days rather than simply making the files available through a web server?
Also, as anyone involved in security will tell you, obscurity provides very limited security - if your security relies on obscuring your network structure then you're screwed already; and if it doesn't then there is no problem with revealing it.
Really, why should someone outside the network know that the HTTP and FTP services run on different machines?
I take the attitude that whilst there are few reasons why people outside your network need to know these specifics, there isn't really any harm in them knowing and avoiding NAT makes the network far less complex and problems easier to debug. Much the same as people blocking ICMP echo requests and traceroutes because they think it increases their security - in actual fact it does very little for the network security and makes it a hell of a lot harder (sometimes impossible) to debug networking problems; and at worst these idiots block *all* ICMP, not just echo requests, which leads to all sorts of difficult-to-debug unreliability of the network..
Most of them are probably v6-only by choice, in an attempt to persuade people to have v6 working.
That and sites aimed at the Asian markets which are already largely IPv6 enabled. But whether the site is v6-only by choice or by requirement, if it happens to be a website you are interested in you're going to need v6 to see it.
Yes, but I'll wait for my ISP to offer v6.
Given the pace of a lot of ISPs, you will probably end up getting frustrated at being unable to use some services long before the ISP has rolled out v6 support. That said, their are ISPs that do native v6, so you can just switch to one of them (I have a native v6 connection from EntaNet).
1. Is it actually supported by software that most people use be default?
Well now, that rather depends on what software you're talking about. Web browsers generally don't support it. SIP UAs almost universally do, as do XMPP UAs. MTAs tend to rely on MX records instead, but they are simply an ungenericised record along the same lines.
2. If so, we can use NAT and nonstandard ports to extend the IPv4 effective address count.
You could, but it would be an almighty pain in the arse to manage. I certainly wouldn't be interested in liasing with the company who hosts my servers each time I want to set up a new service on one of the machines as it would enevitably end up being very time consuming and unreliable..
Anyway, NAT can be used for more than just that, though I have already said that and got responses etc before. I also dislike having my network structure be visible for anyone who can see the IPs. As it is now, I use a single IP but I may have 1 or many computers arranged in one or many subnets and so on.
As a networking professional, I have enough experience to know to avoid NAT wherever possible. It *always* ends up being a complete pain in the backside to manage for any reasonably sized network, with millions of port forwards going all over the place and all sorts of kludges to get various NAT-unfriendly protocols to work.
Also, as anyone involved in security will tell you, obscurity provides very limited security - if your security relies on obscuring your network structure then you're screwed already; and if it doesn't then there is no problem with revealing it.
Speaking of subnets - IIRC something about IPv6 not supporting subnets smaller than/64 - that's really nice - if I want to actually have two subnets I would have to beg my ISP to give me another/64 instead of slipping the/64 that I have.
I suggest you actually go read up on IPv6 and the associated policies before whinging about perceived problems that actually don't exist.
1. No, IPv6 does not prevent you from using subnets smaller than/64. Its just that IPv6 stateless autoconfiguration won't work on anything smaller. If you don't want stateless autoconfig then you're free to make the subnets as small as you like. 2. ISPs are supposed to hand their clients a/56. If your ISP doesn't abide by this IETF standard then I suggest you find one that does.
For now, I can reach most websites with IPv4 and I still have my external IP and see no need to have more than one external IP.
At some point, (sooner than ISPs, IMHO), datacentres are going to run out of IPv4 addresses. At that point, people running servers are going to have little choice but run IPv6-only servers (ok, so some services might be able to be consolidated onto single IP addresses, but you can expect to see a reduction in the quality of service from doing so). At that point, you *won't* be able to access the whole internet (in fact, that point has already come - there are already v6-only sites, it just so happens that you probably don't need to use them at the moment). It would therefore seem sensible for you to get a dual stack system working *before* you find a service that isn't available on IPv4, which is sure to happen sooner or later.
And NAT is not available for IPv6 yet, so no fun tricks too - I (for example) would have to have two services running on the same machine if I wanted both of them accessible trough the same host name and want logs to show the IPs of the clients.
This is incorrect. There is no need to use NAT in order to have two different services to be available on the same host name but running on different machines. This is what SRV RRs are for.
As phone networks changed from Strowger switches to digital and then to packet switching, the end lines remained the same - I can use an old phone with the modern network.
So, do whatever you want inside the network, as long as that network delivers an IPv4 packet to the intended destination so that I can still use an old device with your new network.
When there are more devices on the internet than IPv4 addresses, how do you propose telling the network where you expect it to deliver your ipv4 packet?
The act requires ISPs to send warning letters to infringers and may be used to force ISPs to disconnect the service for repeat infringers. This is seen as placing too heavy a burdn on the ISPs and somewhat draconian against accused file sharers, especially because they may not actually be guilty of any wrongdoing.
It should be pointed out also that ISPs don't send these warning letters and disconnect people on the behest of a court decision, they are required to do these acts simply on the say-so of a copyright holder who is alleging (without proving) that a customer of the ISP is infringing their copyright. There also appears to be no process for the affected customer to appeal the decision.
I'm all for enforcing the law, but doing so without involving the courts is unacceptable - this is similar to someone being locked up without trial because I suggest that they might've stolen from me.
It seems as though you're saying SIP wasn't designed to be shoehorned onto portable Linux based mini-computers and carried around with constant connectivity everywhere, no matter what network they're currently on.
SIP is largely designed for telco networks (i.e. IMS, which is used on 3G networks uses SIP). Usually you'd have a server being the endpoint for a reasonable number of phones (accepting/making calls over the telco's IP network) and the connection between that server and the phone itself would be another protocol (such as GSM). So when you place a call using your GSM mobile phone, it would talk to the base station using the GSM protocols and the base station would then place a call over the network using SIP.
Of course, the logical conclusion (IMHO) is that in the end you do away with the extra protocols and just run a SIP UA on the handset itself. And there's nothing wrong with doing this - SIP works just fine on a sensibly configured network (that is, one where any two endpoints have globally reachable addresses without any NAT and with appropriately configured firewalls). What SIP *won't* do is pretend to be other protocols (such as HTTPS) in order to get around restrictive or misconfigured firewalls.
The separation of signalling and media has distinct advantages (e.g. they can be routed independently, putting the media over the lowest latency route, which is important for a high quality phone call and leaving the servers to just handle the signalling for call setup/teardown/etc.) But it also has distinct disadvantages (in a network without true end-to-end connectivity it is often nice to bundle the media and signalling into a single connection and let a globally reachable server forward all the traffic). I guess in hindsight, SIP should've been designed to accommodate both architectures (e.g. letting an endpoint set a flag that says "I'm behind a NAT, the media traffic must be encapsulated within this SIP session instead of delivered as a separate stream" would be nice).
The IAX2 protocol has a few features that I think would've been nice to see in SIP. Once of those features is the way it attempts to handle both types of architecture: when you set up a call, it starts off by having the server forward the traffic between the endpoints, but it also tries to negotiate a direct peer-to-peer connection at the same time. Once the endpoints have the peer-to-peer connection information, they start sending the media directly *at the same time* as sending it via the server. Once both endpoints are happy that they have a stable direct media stream they stop forwarding via the server. That is a pretty good approach to cover all bases and requires the user to do nothing because the system itself starts off with the safest approach and switches to a more appropriate method only after checking that method is working. Conversely, SIP does none of that checking - if something in the middle drops your RTP traffic then you simply get no sound (or 1-way sound).
That makes me a little sad, as I love having a "landline" everywhere I go. What would you suggest for end users?
I still think SIP is a sensible method, but you must be aware of its limitations. If you're on an un-NATted connection then you should have no problem anyway, if you're on a NATted connection then you should use STUN, but accept that wherever a NAT is involved you may not have complete reliability. Basically, NAT is a horrible kludge that causes lots of problems and needs to be removed from the internet ASAP:)
That said, I've rarely found my 3G connection reliable enough to do VoIP - it frequently drops packets.
SIP via Sipdroid & PBXes.org on the other hand seems much less processor intensive.
I also used to use Sipdroid (but connecting to my own Callweaver server) on my HTC Dream. But only over Wifi - as mentioned above, I never found 3G good enough. These days the wifi has gone foom on my phone so using it for SIP is no longer an option.
Interesting... why is it that systems like Skype always work, whereas something as fundamental as SIP is so problematic?
Because they were designed for use in different environments with different requirements.
SIP was designed to do call signalling over a well designed telco network. The actual call media (e.g. audio) is an entirely separate thing - you can use SIP as almost a direct ISUP replacement if you like (i.e. the media would be transported over switched circuits), or you can send the media over IP as well. Either way, it is designed to provide a telephony service in the most reliable and efficient way in a well designed network, and this is what makes it useful for the telcos. So, for example, if you're transporting the media over IP then it would be normal for the media to go directly between the endpoints.
Take, for example, a pair of roaming mobile phones belonging to Alice and Bob. Their home networks are both in the UK but Alice and Bob are both in Australia. Alice calls Bob. So Alice's SIP UA (in Australia) finds Bob's home network's SIP registration server (in the UK) (using DNS) and places a call to it. The registration server places a call to Bob's UA (in Australia). When Bob answers, his UA talks directly to Alice's UA. From here on in, all the signalling can be directly between the UAs and if the media is going over IP then that is directly between the 2 UAs too - i.e. very little bandwidth between Australia and the UK is needed since most of the communication is peer-to-peer.
Handling NAT, etc. is unnecessary because no one sane would put one on their network and that functionality just adds complexity. Since SIP is often used over the Internet these days, NAT traversal methods, such as STUN, are often employed. NAT traversal is, however, not reliable - there is no way to politely ask the NAT to do this for you, NAT traversal basically involves tricking the NAT into allowing your traffic, and is further complicated by the fact that NAT isn't done in a standard way so you have to cope with lots of different NAT systems in different ways.
On the other hand, Skype was designed to be used over the internet and work at all costs. The internet is generally not that well designed, especially users' home networks. There are NATs and misconfigured firewalls and all sorts. And Skype is designed to try and work through these. A lot of the time, Skype does NAT traversal and in these cases, SIP+RTP+STUN would have worked just as well. Where Skype has an advantage over SIP, is that where NAT traversal fails, it starts hijacking the connections of other Skype users (often without their knowledge) in order to proxy the traffic. There are, of course, reliability concerns with this since you don't know much about the stability of the connections you're proxying via, and the uneducated will often find their network bandwidth disappearing as they route everyone else's calls. Another trick that Skype uses is to shove calls over TCP streams, pretending to be web traffic. Anyone with a bit of knowledge of network protocols will tell you that using a protocol that employs mandatory head of line blocking (such as TCP) for realtime media (such as VoIP) is insane and liable to lead to reliability problems.
So in summary: In a situation where SIP+RTP+STUN works, Skype is probably going to work just as well although you need to be careful about accidentally letting it use your bandwidth to proxy everyone else's calls if that sort of thing bothers you, and the proprietary nature makes the security of the encryption questionable. In situations where SIP+RTP+STUN doesn't work then you may well get Skype to work, but it is going to employ methods that will reduce the reliability/quality of the call. There are 2 ways of looking at it - you may think "something is better than nothing" and decide that Skype is better, or you may think "if my network is broken, I want to know about it so I can fix it", in which case something like SIP (which simply
The reliability of SIP through a NAT is a function of exactly what sort of NATs are involved all the way along the route. The STUN RFC explicitly states that STUN cannot be reliable through all NATs. Certain combinations of NAT simply won't work, and this is going to get much worse where you have multiple NATs along the route.
push messaging/mail
What people often call "push email" in the mobile environment is only "push" in the loosest possible sense - your mobile phone opens a TCP session and keeps it open for a long time. When an email arrives then a notification is pushed along this open TCP session (e.g. long-poll HTTP). The way this differs from true push services is that your phone has to periodically wake up and shove a keep-alive message over the TCP session in order to prevent the ISP's NAT from dropping it. This, of course, costs battery and reliability. In a true "push" environment, the remote server would connect directly to your phone without requiring any existing sessions to carry the data. The only time your phone would need to contact the server when idle is to inform the server of an IP address change (which should be pretty rare).
To my knowledge, the only true "push email" system in use on mobile networks is Blackberry, and that involves servers to be installed within the MNO's network, specifically because this allows communications between the server and the phone without going through a NAT.
This also breaks VoIP, some internet video, and lots of other stuff. NAT is a terrible "solution" for users, but great for corporate profit margins.
It doesn't "break" (the concept of) VoIP, it merely makes the implementation much more of a ball-ache. So I don't think using NAT to "break" VoIP is going to help the network operators, it will simply make it harder for them to support their users who phone up asking why their favourite VoIP application isn't working.
Looking at that table, I can't help thinking that the/4 block reserved for "Future use" might come in handy about now. I know it will only last a few months, and there are probably some TCP/IP stacks around that will reject those reserved addresses, but if the future is ever going to come, it needs to come now.
Various operating systems hard code the "future use" blocks as basically being unroutable, so they aren't going to save you now. And doing this was actually quite sane - no one knew what the "future use" blocks would be used for so treating them as plain old unicast would be nuts. For example, the multicast blocks require totally different routing semantics to unicast so there would be no reason to assume that "future use" protocols would be like unicast.
Rolling out services on the "future use" blocks has similar problems to rolling out services on IPv6 - very few end users are going to be able to see those blocks. If you're going to use addresses that require people to upgrade their network infrastructure, you may as well just switch directly to IPv6 and be done with it.
A bank makes loans and does so by storing money and returning a percentage to its holders for holding that money.
I think you misunderstand how modern banks work. When you get a loan from the bank, that bank then packages the loan up, rates how much risk there is and sells it to someone. This is why the banking system basically collapsed - a load of high-risk loans were sold on under the pretence of them being low-risk and when this was discovered the whole thing went to hell. If the banks still worked the way you describe then this would never have happened as there would have been no reason for them to misrepresent the risk.
Does this mean that companies will start selling IP addresses for increasing amounts of money? should I buy a block of 100 as an investment now? A bit like buying up domain names?
No, because a block of 100 addresses (or 128, which is the closest you can get in the form of a/25) isn't routable. Subnets smaller than/22 are generally filtered out of the global BGP tables.
4. They'll double NAT home user accounts to free up IPv4, and charge extra for a real public IP.
ISPs largely have enough v4 addresses to go round at the moment anyway (I often see quotes from ISPs saying something along the lines of "we won't be implementing v6 in the near future because we have plenty of v4 addresses ourselves"). However, this largely misses the point - in about a month's time, APNIC is going to be the first RIR to essentially run out of addresses (they will hit their final/8 policies which will massively restrict new allocations). Shortly after that, you will start seeing v6-only services start to appear because the *data centres* will be running out of v4 addresses. It doesn't matter how many addresses *you* have, if the services your customers want to access are on v6 then you're going to have to roll out v6 yourself.
Anywho - with that said - which companies out there offer android/iphones, allow tethering, and don't ream their customers? I'm an ATT customer (since 2003) and pretty much ready to jump ship.
Three in the UK have no exclusions regarding tethering in their T&Cs. That said, the "mobile internet" packages are clearly not intended for use in this way because they offer "mobile broadband" packages at about twice the price for that... as far as I can tell there is no difference between them.
Amen. And in this country, when you sell someone unlimited, you better be able to provide enough to make them happy. Hows about a gool 'ol fashioned class action case against these bait and hooksters! I say, give em the Missouri boat ride!
Sadly, here in the UK the advertising standards agency ruled that it is completely acceptable for ISPs to use the word "unlimited" to describe services that were in no sense unlimited...
Slashdot Mirror
SIP and H.323 are fine, but they are only part of the issue. Codec's are a huge problem. The free (as in no license required) codecs are bandwidth hungry.
Some of the commercial codecs are better, but Speex, GSM codecs and AMR-NB are fine for most people. Also, I suspect that most people wouldn't care even if they were using G.711 - 64Kbps in each direction is tiny compared to most things people use their internet connections for.
The real issue though, is one of configuration. Using a strict SIP or H.323 client means the user has to understand issues like addressing, ports, etc..
How so? Usually it is simply a case of entering your username, password and the address of your service provider's SIP registration server. The only thing different to Skype here is that you don't need to enter the server address for Skype (but you can't allow for multiple service providers any other way, so if you want choice of service provider, thats what you're stuck with, just like email).
NAT *usually* isn't a problem (most clients are preconfigured to use STUN so no user fiddling needed here), although it is certainly nicer to avoid it where possible.
That means having a central service that not only provides default configurations and service
Some service providers ship clients preconfigured. For example, if you create an account on SIPgate then they present you with a preconfigured copy of X-Lite to download and any hardware you buy from their shop will be preconfigured with your account details before they ship it to you, making it pretty much plug-in-and-go.
but address books, and more importantly, doesn't allow just anyone to connect and voice spam the shit out of them.
I must admit I'd like to see an XMPP-style roster in SIP. However, most SIP clients do integrate with address books. e.g. Ekiga integrates with Evolution, Telephone integrates with the OS X address book, SIPDroid integrates with the Android contacts system, etc. It would, however, but nice to see some widely implemented open standards for address books (this applies to everything that uses address books, such as email, etc too) instead of applications being tied into specific address book systems.
Open systems are prone to spam, closed systems have a lot more control over that.
I'm not convinced about that... I've heard Skype users complaining about spam (I've not used Skype myself so can't really comment) but I don't get any spam calls to my SIP accounts. This is, of course, not down to anything particularly technological, probably just that it is harder to spam a decentralised system like SIP which has no central user database, etc.
I do see quite a lot of brute-force password attempts on my SIP servers, much like you see on ssh servers, etc. but due to reasonably secure passwords they never get anywhere and I have fail2ban configured to dump clients who make too many registration attempts (note, this is specific to running a SIP server, not a client, sop wouldn't affect Skype users anyway). I also see a lot of attempts to make unauthenticated PSTN calls, presumably attackers hoping the server is misconfigured and would allow them to do so (it won't). Again, fail2ban is configured to put a stop to this.
In the end, much like other communication systems such as IM, Email and even the PSTN, all VoIP systems are going to be susceptible to spam and there is very little to be done about it. I do feel that I am in a better position to filter spam from my own servers than relying on Skype to do it for me though (subjective).
How exactly does being interconnected and generally friendly to your adjacent systems require you to be open? Skype is perfectly interconnected (it runs on everything) without being open.
Depends what you mean by "interconnected". If you mean "runs on everything".. well, it runs on a lot of stuff but there is plenty that it doesn't run on for no reason other than they haven't developed the software for those platforms (and since it is a closed system, no one else can write the software either). If you mean "can make/receive calls to/from anything" then you're quite wrong. Skype can call PSTN numbers and Skype users but can't interoperate with SIP, XMPP, etc.
What the developers have missed is that we need a single way to create a SIP ID
Well you can't really have that any more than you can have a "single way of ordering a phone line" when there are multiple service providers. I guess SIP could introduce an account registration system like XMPP has so you can register accounts directly from your client, but is it really that hard to register on the service provider's website, like you do for most other services such as email?
a single global directory
I'm not sure how that would work - you really want a list of billions of people? When you want to phone Joe Bloggs, how are you going to identify which one, out of the 10,000 "Joe Bloggs" listed is the one you want?
On the whole, it sounds like a very bad idea to me - it is the perfect place for spammers to harvest addresses and this is exactly why email servers won't let you get a user list these days (despite it being part of the SMTP protocol). For other contact details (e.g. email, phone, etc), I'm pretty happy with maintaining my own address book of the people I actually talk to, and finding out the addresses of new contacts by talking to them, looking on their website, etc. and see no reason why I'd want to do anything different for VoIP.
Worth noting that despite the fact that a telephone directory is still distributed here in the UK (and available online), the majority of land-lines are ex-directory, it doesn't include mobile numbers and I certainly haven't actually *used* a telephone directory in at least 15 years because it is practically always easier to find someone's phone number a different way.
I do, however, think that it would be nice for SIP to provide access to (or at least, supply configuration data so your client can automatically access) your personal (and corporate-wide, for companies) address books rather than each client having to be configured to access whatever address book system you use.
and a single global ID/addressing format.
Err, you know SIP has always had a single addressing format don't you? It looks like an email address - sip:localpart@example.com, where "localpart" is something to identify you on the server (often your first.lastname). In fact, my SIP address is identical to my email address, so it makes it quite easy to remember.
Until this is addressed, SIP is a dead duck.
That would be a dead duck that's used by most modern telco networks, the vast majority of corporate phone networks and a significant number of home users. Mmmm.. sounds pretty dead to me.
Can you send a message from Google's XMPP servers to Facebook's XMMP servers? Last time I looked at it, although the protocol was the same, the servers were closed boxes.
You can send messages from Google's XMPP servers to any XMPP server that supports s2s connections (i.e. practically all XMPP servers) and vice-versa. This has been true for years.
Unfortunately, Facebook's half-baked implementation doesn't support s2s, so is, indeed, a closed box. I will leave this to your imagination whether this is a strategic method of locking users in, or just that their developers did a half-arsed job (no idea why they insisted on writing their own implementation instead of using one of the readily available open ones mind you)
Moving to IPv6 isn't a solution - it's not like everyone's going to run IPv6 without a firewall.
Removing NAT from the equation (which is inherent in moving to IPv6) _does_ make everything much easier. There is no requirement to run without a firewall or even poke holes in your firewall for inbound traffic - UDP firewall traversal is completely reliable if you're not going through a NAT. The reason why things get unreliable when NATs are involved is because the software has to make educated guesses about things like what IP address and port numbers the traffic is going to appear on once it exists the NAT, remove that problem from the equation and this stuff Just Works. (To be fair, SIP through a NAT usually Just Works these days anyway, but it is even more reliable once you dispense with NAT).
A nuclear power plant *may* cause a serious impact on the health of thousands (but it is unlikely). A coal fired plant *will* cause a serious impact on the health of millions (and *may* end up with a disaster of a similar scale to a nuclear accident: http://en.wikipedia.org/wiki/Kingston_Fossil_Plant_coal_fly_ash_slurry_spill http://en.wikipedia.org/wiki/Aberfan_disaster )
So, there probably would be no way to make ftp://example.com and http://example.com/ be on different machines without people having problems accessing one of those two services (since both can be accessed by a web browser).
Yep, much more usable than NAT.
Ok, fair point. But who seriously bothers running anonymous FTP servers these days rather than simply making the files available through a web server?
Also, as anyone involved in security will tell you, obscurity provides very limited security - if your security relies on obscuring your network structure then you're screwed already; and if it doesn't then there is no problem with revealing it.
Really, why should someone outside the network know that the HTTP and FTP services run on different machines?
I take the attitude that whilst there are few reasons why people outside your network need to know these specifics, there isn't really any harm in them knowing and avoiding NAT makes the network far less complex and problems easier to debug. Much the same as people blocking ICMP echo requests and traceroutes because they think it increases their security - in actual fact it does very little for the network security and makes it a hell of a lot harder (sometimes impossible) to debug networking problems; and at worst these idiots block *all* ICMP, not just echo requests, which leads to all sorts of difficult-to-debug unreliability of the network..
Most of them are probably v6-only by choice, in an attempt to persuade people to have v6 working.
That and sites aimed at the Asian markets which are already largely IPv6 enabled. But whether the site is v6-only by choice or by requirement, if it happens to be a website you are interested in you're going to need v6 to see it.
Yes, but I'll wait for my ISP to offer v6.
Given the pace of a lot of ISPs, you will probably end up getting frustrated at being unable to use some services long before the ISP has rolled out v6 support. That said, their are ISPs that do native v6, so you can just switch to one of them (I have a native v6 connection from EntaNet).
1. Is it actually supported by software that most people use be default?
Well now, that rather depends on what software you're talking about. Web browsers generally don't support it. SIP UAs almost universally do, as do XMPP UAs. MTAs tend to rely on MX records instead, but they are simply an ungenericised record along the same lines.
2. If so, we can use NAT and nonstandard ports to extend the IPv4 effective address count.
You could, but it would be an almighty pain in the arse to manage. I certainly wouldn't be interested in liasing with the company who hosts my servers each time I want to set up a new service on one of the machines as it would enevitably end up being very time consuming and unreliable..
Anyway, NAT can be used for more than just that, though I have already said that and got responses etc before. I also dislike having my network structure be visible for anyone who can see the IPs. As it is now, I use a single IP but I may have 1 or many computers arranged in one or many subnets and so on.
As a networking professional, I have enough experience to know to avoid NAT wherever possible. It *always* ends up being a complete pain in the backside to manage for any reasonably sized network, with millions of port forwards going all over the place and all sorts of kludges to get various NAT-unfriendly protocols to work.
Also, as anyone involved in security will tell you, obscurity provides very limited security - if your security relies on obscuring your network structure then you're screwed already; and if it doesn't then there is no problem with revealing it.
Speaking of subnets - IIRC something about IPv6 not supporting subnets smaller than /64 - that's really nice - if I want to actually have two subnets I would have to beg my ISP to give me another /64 instead of slipping the /64 that I have.
I suggest you actually go read up on IPv6 and the associated policies before whinging about perceived problems that actually don't exist.
1. No, IPv6 does not prevent you from using subnets smaller than /64. Its just that IPv6 stateless autoconfiguration won't work on anything smaller. If you don't want stateless autoconfig then you're free to make the subnets as small as you like. /56. If your ISP doesn't abide by this IETF standard then I suggest you find one that does.
2. ISPs are supposed to hand their clients a
For now, I can reach most websites with IPv4 and I still have my external IP and see no need to have more than one external IP.
At some point, (sooner than ISPs, IMHO), datacentres are going to run out of IPv4 addresses. At that point, people running servers are going to have little choice but run IPv6-only servers (ok, so some services might be able to be consolidated onto single IP addresses, but you can expect to see a reduction in the quality of service from doing so). At that point, you *won't* be able to access the whole internet (in fact, that point has already come - there are already v6-only sites, it just so happens that you probably don't need to use them at the moment). It would therefore seem sensible for you to get a dual stack system working *before* you find a service that isn't available on IPv4, which is sure to happen sooner or later.
And NAT is not available for IPv6 yet, so no fun tricks too - I (for example) would have to have two services running on the same machine if I wanted both of them accessible trough the same host name and want logs to show the IPs of the clients.
This is incorrect. There is no need to use NAT in order to have two different services to be available on the same host name but running on different machines. This is what SRV RRs are for.
As phone networks changed from Strowger switches to digital and then to packet switching, the end lines remained the same - I can use an old phone with the modern network.
So, do whatever you want inside the network, as long as that network delivers an IPv4 packet to the intended destination so that I can still use an old device with your new network.
When there are more devices on the internet than IPv4 addresses, how do you propose telling the network where you expect it to deliver your ipv4 packet?
The act requires ISPs to send warning letters to infringers and may be used to force ISPs to disconnect the service for repeat infringers. This is seen as placing too heavy a burdn on the ISPs and somewhat draconian against accused file sharers, especially because they may not actually be guilty of any wrongdoing.
It should be pointed out also that ISPs don't send these warning letters and disconnect people on the behest of a court decision, they are required to do these acts simply on the say-so of a copyright holder who is alleging (without proving) that a customer of the ISP is infringing their copyright. There also appears to be no process for the affected customer to appeal the decision.
I'm all for enforcing the law, but doing so without involving the courts is unacceptable - this is similar to someone being locked up without trial because I suggest that they might've stolen from me.
Still not clear on how this helps with running HTTPS sites behind a NAT...
And that helps, how exactly? (other than losing a big chunk of your customer base and causing you to go out of business, of course).
It seems as though you're saying SIP wasn't designed to be shoehorned onto portable Linux based mini-computers and carried around with constant connectivity everywhere, no matter what network they're currently on.
SIP is largely designed for telco networks (i.e. IMS, which is used on 3G networks uses SIP). Usually you'd have a server being the endpoint for a reasonable number of phones (accepting/making calls over the telco's IP network) and the connection between that server and the phone itself would be another protocol (such as GSM). So when you place a call using your GSM mobile phone, it would talk to the base station using the GSM protocols and the base station would then place a call over the network using SIP.
Of course, the logical conclusion (IMHO) is that in the end you do away with the extra protocols and just run a SIP UA on the handset itself. And there's nothing wrong with doing this - SIP works just fine on a sensibly configured network (that is, one where any two endpoints have globally reachable addresses without any NAT and with appropriately configured firewalls). What SIP *won't* do is pretend to be other protocols (such as HTTPS) in order to get around restrictive or misconfigured firewalls.
The separation of signalling and media has distinct advantages (e.g. they can be routed independently, putting the media over the lowest latency route, which is important for a high quality phone call and leaving the servers to just handle the signalling for call setup/teardown/etc.) But it also has distinct disadvantages (in a network without true end-to-end connectivity it is often nice to bundle the media and signalling into a single connection and let a globally reachable server forward all the traffic). I guess in hindsight, SIP should've been designed to accommodate both architectures (e.g. letting an endpoint set a flag that says "I'm behind a NAT, the media traffic must be encapsulated within this SIP session instead of delivered as a separate stream" would be nice).
The IAX2 protocol has a few features that I think would've been nice to see in SIP. Once of those features is the way it attempts to handle both types of architecture: when you set up a call, it starts off by having the server forward the traffic between the endpoints, but it also tries to negotiate a direct peer-to-peer connection at the same time. Once the endpoints have the peer-to-peer connection information, they start sending the media directly *at the same time* as sending it via the server. Once both endpoints are happy that they have a stable direct media stream they stop forwarding via the server. That is a pretty good approach to cover all bases and requires the user to do nothing because the system itself starts off with the safest approach and switches to a more appropriate method only after checking that method is working. Conversely, SIP does none of that checking - if something in the middle drops your RTP traffic then you simply get no sound (or 1-way sound).
That makes me a little sad, as I love having a "landline" everywhere I go. What would you suggest for end users?
I still think SIP is a sensible method, but you must be aware of its limitations. If you're on an un-NATted connection then you should have no problem anyway, if you're on a NATted connection then you should use STUN, but accept that wherever a NAT is involved you may not have complete reliability. Basically, NAT is a horrible kludge that causes lots of problems and needs to be removed from the internet ASAP :)
That said, I've rarely found my 3G connection reliable enough to do VoIP - it frequently drops packets.
SIP via Sipdroid & PBXes.org on the other hand seems much less processor intensive.
I also used to use Sipdroid (but connecting to my own Callweaver server) on my HTC Dream. But only over Wifi - as mentioned above, I never found 3G good enough. These days the wifi has gone foom on my phone so using it for SIP is no longer an option.
Interesting... why is it that systems like Skype always work, whereas something as fundamental as SIP is so problematic?
Because they were designed for use in different environments with different requirements.
SIP was designed to do call signalling over a well designed telco network. The actual call media (e.g. audio) is an entirely separate thing - you can use SIP as almost a direct ISUP replacement if you like (i.e. the media would be transported over switched circuits), or you can send the media over IP as well. Either way, it is designed to provide a telephony service in the most reliable and efficient way in a well designed network, and this is what makes it useful for the telcos. So, for example, if you're transporting the media over IP then it would be normal for the media to go directly between the endpoints.
Take, for example, a pair of roaming mobile phones belonging to Alice and Bob. Their home networks are both in the UK but Alice and Bob are both in Australia. Alice calls Bob. So Alice's SIP UA (in Australia) finds Bob's home network's SIP registration server (in the UK) (using DNS) and places a call to it. The registration server places a call to Bob's UA (in Australia). When Bob answers, his UA talks directly to Alice's UA. From here on in, all the signalling can be directly between the UAs and if the media is going over IP then that is directly between the 2 UAs too - i.e. very little bandwidth between Australia and the UK is needed since most of the communication is peer-to-peer.
Handling NAT, etc. is unnecessary because no one sane would put one on their network and that functionality just adds complexity. Since SIP is often used over the Internet these days, NAT traversal methods, such as STUN, are often employed. NAT traversal is, however, not reliable - there is no way to politely ask the NAT to do this for you, NAT traversal basically involves tricking the NAT into allowing your traffic, and is further complicated by the fact that NAT isn't done in a standard way so you have to cope with lots of different NAT systems in different ways.
On the other hand, Skype was designed to be used over the internet and work at all costs. The internet is generally not that well designed, especially users' home networks. There are NATs and misconfigured firewalls and all sorts. And Skype is designed to try and work through these. A lot of the time, Skype does NAT traversal and in these cases, SIP+RTP+STUN would have worked just as well. Where Skype has an advantage over SIP, is that where NAT traversal fails, it starts hijacking the connections of other Skype users (often without their knowledge) in order to proxy the traffic. There are, of course, reliability concerns with this since you don't know much about the stability of the connections you're proxying via, and the uneducated will often find their network bandwidth disappearing as they route everyone else's calls. Another trick that Skype uses is to shove calls over TCP streams, pretending to be web traffic. Anyone with a bit of knowledge of network protocols will tell you that using a protocol that employs mandatory head of line blocking (such as TCP) for realtime media (such as VoIP) is insane and liable to lead to reliability problems.
So in summary: In a situation where SIP+RTP+STUN works, Skype is probably going to work just as well although you need to be careful about accidentally letting it use your bandwidth to proxy everyone else's calls if that sort of thing bothers you, and the proprietary nature makes the security of the encryption questionable. In situations where SIP+RTP+STUN doesn't work then you may well get Skype to work, but it is going to employ methods that will reduce the reliability/quality of the call. There are 2 ways of looking at it - you may think "something is better than nothing" and decide that Skype is better, or you may think "if my network is broken, I want to know about it so I can fix it", in which case something like SIP (which simply
SIP
The reliability of SIP through a NAT is a function of exactly what sort of NATs are involved all the way along the route. The STUN RFC explicitly states that STUN cannot be reliable through all NATs. Certain combinations of NAT simply won't work, and this is going to get much worse where you have multiple NATs along the route.
push messaging/mail
What people often call "push email" in the mobile environment is only "push" in the loosest possible sense - your mobile phone opens a TCP session and keeps it open for a long time. When an email arrives then a notification is pushed along this open TCP session (e.g. long-poll HTTP). The way this differs from true push services is that your phone has to periodically wake up and shove a keep-alive message over the TCP session in order to prevent the ISP's NAT from dropping it. This, of course, costs battery and reliability. In a true "push" environment, the remote server would connect directly to your phone without requiring any existing sessions to carry the data. The only time your phone would need to contact the server when idle is to inform the server of an IP address change (which should be pretty rare).
To my knowledge, the only true "push email" system in use on mobile networks is Blackberry, and that involves servers to be installed within the MNO's network, specifically because this allows communications between the server and the phone without going through a NAT.
This also breaks VoIP, some internet video, and lots of other stuff. NAT is a terrible "solution" for users, but great for corporate profit margins.
It doesn't "break" (the concept of) VoIP, it merely makes the implementation much more of a ball-ache. So I don't think using NAT to "break" VoIP is going to help the network operators, it will simply make it harder for them to support their users who phone up asking why their favourite VoIP application isn't working.
NAT is the answer because that's what is being used.
Yeah, I'll just run a bunch of HTTPS servers behind a NAT... oh.. wait.
Looking at that table, I can't help thinking that the /4 block reserved for "Future use" might come in handy about now. I know it will only last a few months, and there are probably some TCP/IP stacks around that will reject those reserved addresses, but if the future is ever going to come, it needs to come now.
Various operating systems hard code the "future use" blocks as basically being unroutable, so they aren't going to save you now. And doing this was actually quite sane - no one knew what the "future use" blocks would be used for so treating them as plain old unicast would be nuts. For example, the multicast blocks require totally different routing semantics to unicast so there would be no reason to assume that "future use" protocols would be like unicast.
Rolling out services on the "future use" blocks has similar problems to rolling out services on IPv6 - very few end users are going to be able to see those blocks. If you're going to use addresses that require people to upgrade their network infrastructure, you may as well just switch directly to IPv6 and be done with it.
A bank makes loans and does so by storing money and returning a percentage to its holders for holding that money.
I think you misunderstand how modern banks work. When you get a loan from the bank, that bank then packages the loan up, rates how much risk there is and sells it to someone. This is why the banking system basically collapsed - a load of high-risk loans were sold on under the pretence of them being low-risk and when this was discovered the whole thing went to hell. If the banks still worked the way you describe then this would never have happened as there would have been no reason for them to misrepresent the risk.
Does this mean that companies will start selling IP addresses for increasing amounts of money? should I buy a block of 100 as an investment now? A bit like buying up domain names?
No, because a block of 100 addresses (or 128, which is the closest you can get in the form of a /25) isn't routable. Subnets smaller than /22 are generally filtered out of the global BGP tables.
4. They'll double NAT home user accounts to free up IPv4, and charge extra for a real public IP.
ISPs largely have enough v4 addresses to go round at the moment anyway (I often see quotes from ISPs saying something along the lines of "we won't be implementing v6 in the near future because we have plenty of v4 addresses ourselves"). However, this largely misses the point - in about a month's time, APNIC is going to be the first RIR to essentially run out of addresses (they will hit their final /8 policies which will massively restrict new allocations). Shortly after that, you will start seeing v6-only services start to appear because the *data centres* will be running out of v4 addresses. It doesn't matter how many addresses *you* have, if the services your customers want to access are on v6 then you're going to have to roll out v6 yourself.
Now all they have to do is to make sure that their desktop product does not really work well with IPv6.
MS have been reasonably pro-v6 in recent years (after a slow start), even introducing technologies like Toredo to make the transition easier.
Now MS will sell your ISP a v4 IP range for the low cost of 30 bucks an address.
Ok... how do you propose to route the traffic to those addresses?
Anywho - with that said - which companies out there offer android/iphones, allow tethering, and don't ream their customers? I'm an ATT customer (since 2003) and pretty much ready to jump ship.
Three in the UK have no exclusions regarding tethering in their T&Cs. That said, the "mobile internet" packages are clearly not intended for use in this way because they offer "mobile broadband" packages at about twice the price for that... as far as I can tell there is no difference between them.
Amen. And in this country, when you sell someone unlimited, you better be able to provide enough to make them happy. Hows about a gool 'ol fashioned class action case against these bait and hooksters! I say, give em the Missouri boat ride!
Sadly, here in the UK the advertising standards agency ruled that it is completely acceptable for ISPs to use the word "unlimited" to describe services that were in no sense unlimited...