4 ms·
The solution was very simple. It came down to this. - SIP end points register every so often. Each registration had a TTL. We set the TTL to 20 seconds. T
by jmartrican 9y ago
The solution was very simple. It came down to this.
- SIP end points register every so often. Each registration had a TTL. We set the TTL to 20 seconds. This actually leads to a registration every 16 seconds, since SIP end points register at 80% into their TTL.
- When a SIP end point reigsters, do not register the end point at the IP:port that it is advertising int he SIP Registration message. Instead use the source IP and port of the IP/UDP packet/datagram.
- Inbound calls to that SIP end point must go through the server that the SIP end point registered with and it must use the destination port (10,000) as the source port. We need to match the NAT entry in the router.
- When a phone call comes in for that end point, send the SIP Invite message to source IP:port of the SIP end point. Since the device is registering every 16 sec, there is sure to be a NAT entry in the router to allow our packets into the network and routed to the SIP end point. It is vital that we use the same server that the SIP end point registered with.
- Drdrdrq 9y agoEverything 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 agoIt 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 agoLots 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.
- adamfisk 9y agoSIP is just the signaling protocol. The actual NAT traversal really takes place in ICE, which uses STUN. ICE does the heavy lifting though.