[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
On Thu, 5 May 2011, Simon Waters wrote:
On 05/05/11 14:49, Kevin Lucas wrote:apt-get install ekigaEkiga is already installed this end, it was the Windows/Mac client side that I was vaguer on for that sort of thing, especially the networking aspects - i.e. do ports need opening etc.
For Ekiga... You shouldn't need ports opening, but then again, sometimes you do... And here is the biggest PITA with SIP - it's NAT.
You can make a SIP device talk to another SIP device, but they both need to be able to "see" each other... So, if they both have a public IP address and you know the other-ends IP address, then you can "call" it.
If you don't have a public IP address (e.g. behind NAT), then you do need to port-forward - and it's port 5060 (UDP), and then there will be a range of ports to carry the RTP data. (5060 is the SIP command/control port, then the RTP ports carry the actual voice/video data - a bit like FTP)
Most SIP devices/applications allow you to fix the port range, so you can put it into your routers, etc.
So that's all very well for one device behind a NAT gateway, but what happens when you have more than one... Well, you can give each one it's oen port - and that will work, as long as you tell the others in your own little network what the port number and IP address is ...
But then things start to get complicated...And at that point you need some sort of external SIP registration service. A server that will let phones register to it, remember the details of that phone (IP address, port), and provide a mechanism to let a phone contact another phone. (because it's easier to dial 223 than dial 81.31.100.110:1234)
We've still got the data to wory about as some SIP registration devices just handle the SIP commands and not the data, so as long as the end-points can directly see each other, then all's well. Unfortunately this isn't always the case, and the SIP registration service has to relay the data too.
(And as I understand it, this is exactly the same issue faces by Skype, and their "supernodes" handle the relaying of the voice/video data when the end-points can't talke directly to each other)
I think Ekiga runs their own registration service, but I've no idea if they allow media relaying from endpoints behind NAT.
In general, if you're behind NAT and talking to an external registration service, then you don't need port-forwarding, but you might need to use something that lets your phone knows it's external IP address - and this is where it breaks down - again.
A SIP device doesn't rely on the IP address of each endpoint, it actually encodes it's own IP address inside the SIP command packets.
So you have a phone on 192.168.1.5 on your home ADSL, and your mate has a phone on another NATted network - your phone puts it's own IP address (ie. 192.168.1.5) inside the command packets, sends it to the other phone, the other phone extracts this IP address and tries to send data back - and fails because it's a private IP address and it can't be directly contacted.
What usually happens here is that you get one-way audio - one person can hear the other, but not the other way round - because the return packets can't be routed.
I can rant on for hours about SIP and NAT - it's one of the biggest headaches I face...
Fortunately there are well know and documented ways round NAT, but it's not always successfull - some routers think they know better and can mangle SIP packets as they go through and there are external services like STUN which help, but it's still sometimes hard when NAT is involved.
For some of my customers, I relay their VoIP data via my own network - the worst case can be 2 people on the same LAN, sitting next to each other and one calls the other - their call data goes out their ADSL line, to my servers, then back into their LAN to the other phone... (One reason to have on-site SIP registration devices - aka PBXs rather than use a hosted service)
Roll on IPv6 and no nat... Gordon -- The Mailing List for the Devon & Cornwall LUG http://mailman.dclug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/listfaq