3 ms·

Everything is simple if you know what you are doing. Kudos! I had my own share of adventures with SIP across NAT so I know it must have been lots of experimenta

Everything is simple if you know what you are doing. Kudos! I had my own share of adventures with SIP across NAT so I know it must have been lots of experimentation and studying to find this simple solution.

gerdesj 9y ago
It sounds like they are describing "symmetric RTP" which is still a common way to get SIP n RTP to work. Another way is to use a VPN and route the blasted things - which was/is a classic cop out with a gloss of security added in. Then you got to fix the pain of subtly incompatible IPSEC implementations instead. Strangely enough all VoIP phones with a VPN built in (that I know of) use OpenVPN and not IPSEC. OpenVPN uses a single port which may be 1194/udp or not. Another "fix" to SIP - a protocol that works just as successfully over NAT as ftp (mmm active or passive? 1:1 NAT bodge/fix? etc etc) - is to mix the control and data into one stream: eg IAX(2). IAX uses a single well known destination port (4569/udp) which is as easy to implement as DNS or NTP, which are both generally UDP but DNS can require TCP, through a NAT. IAX can make a fine Sometimes folk decide to run SIP over TCP instead of UDP and may even decide to run that inside a TCP tunnel eg OpenVPN over TCP. That's fine until you discover how TCP inside TCP can result in exponential standoffs when network conditions are sub-optimal. That can really bugger up voice traffic that really needs sub 100ms point to point latency to be acceptable. Then there is dealing with packet fragmentation if changes of media require it and of course the fact that TCP packet streams can arrive out of order and be re-assembled. That latency wont worry your web browser but it makes voice sound horrid.
- adamfisk 9y ago
  Lots of confusion on this thread. SIP never handles actual voice traffic. It is just a signaling protocol used to initiate the ICE process of actually establishing the connection, either a direct p2p connection or a relayed connection using TURN when the NATs can't be traversed. That's when traffic is typically UDP, as it's easier to traverse NATs with UDP. The transport SIP uses is largely irrelevant, although it's pretty silly for it to use anything but TCP because reliability of sending the offer and the answer is pretty important, and they can be sent in multiple packets.

gerdesj 9y ago

It sounds like they are describing "symmetric RTP" which is still a common way to get SIP n RTP to work. Another way is to use a VPN and route the blasted things - which was/is a classic cop out with a gloss of security added in. Then you got to fix the pain of subtly incompatible IPSEC implementations instead. Strangely enough all VoIP phones with a VPN built in (that I know of) use OpenVPN and not IPSEC. OpenVPN uses a single port which may be 1194/udp or not. Another "fix" to SIP - a protocol that works just as successfully over NAT as ftp (mmm active or passive? 1:1 NAT bodge/fix? etc etc) - is to mix the control and data into one stream: eg IAX(2). IAX uses a single well known destination port (4569/udp) which is as easy to implement as DNS or NTP, which are both generally UDP but DNS can require TCP, through a NAT. IAX can make a fine Sometimes folk decide to run SIP over TCP instead of UDP and may even decide to run that inside a TCP tunnel eg OpenVPN over TCP. That's fine until you discover how TCP inside TCP can result in exponential standoffs when network conditions are sub-optimal. That can really bugger up voice traffic that really needs sub 100ms point to point latency to be acceptable. Then there is dealing with packet fragmentation if changes of media require it and of course the fact that TCP packet streams can arrive out of order and be re-assembled. That latency wont worry your web browser but it makes voice sound horrid.

adamfisk 9y ago
Lots of confusion on this thread. SIP never handles actual voice traffic. It is just a signaling protocol used to initiate the ICE process of actually establishing the connection, either a direct p2p connection or a relayed connection using TURN when the NATs can't be traversed. That's when traffic is typically UDP, as it's easier to traverse NATs with UDP. The transport SIP uses is largely irrelevant, although it's pretty silly for it to use anything but TCP because reliability of sending the offer and the answer is pretty important, and they can be sent in multiple packets.