"However, it does NOT solve the NAT problem. There still needs to be an intermediate system in the middle if both ends are behind a NAT."
Sure, but the intermediary doesn't need to relay the RTP packets. Once both ends know each others public IP and port, they both send UDP packets to each other, and both NAT firewalls open up the (single) UDP port. Some SIP clients are clever enough to do this for each RTP channel (using the same port for both incoming and outgoing multimedia data). But keeping everything in one UDP port makes things much simpler.
It doesn't really matter whether your softphone is open source or proprietary - that is a personal choice. There are many fine commercial SIP softphones, as well as open source ones. And it matters even less when buying a piece of hardware - a SIP phone or personal PBX. It *does* matter when the protocol is secret and proprietary. This is the problem with Skype. Choosing the Skype service locks you into using their client (and vice versa).
Authored Comments
"However, it does NOT solve the NAT problem. There still needs to be an intermediate system in the middle if both ends are behind a NAT."
Sure, but the intermediary doesn't need to relay the RTP packets. Once both ends know each others public IP and port, they both send UDP packets to each other, and both NAT firewalls open up the (single) UDP port. Some SIP clients are clever enough to do this for each RTP channel (using the same port for both incoming and outgoing multimedia data). But keeping everything in one UDP port makes things much simpler.
It doesn't really matter whether your softphone is open source or proprietary - that is a personal choice. There are many fine commercial SIP softphones, as well as open source ones. And it matters even less when buying a piece of hardware - a SIP phone or personal PBX. It *does* matter when the protocol is secret and proprietary. This is the problem with Skype. Choosing the Skype service locks you into using their client (and vice versa).