SIP Witch media proxy for NAT transversal

SIP Witch does not operate as a B2BUA. This means that SIP Witch passes the SDP of each endpoint of the incoming invite to the remote destination, and the incoming caller must be able to directly establish a RTP media connection with the remote destination. When one destination is behind a NAT and the other is not, or if one destination is on a different subnet, this may not be possible. If there is a STUN server available, it may be possible for remote user agents to use STUN, but when a local user agent uses STUN, we sometimes get strange effects since the SIP server is on the local network with the user agent and not at a remote public internet destination. Even worse, many routers (such as the popular cisco linksys) are SIP aware and will suppress ack packets making it impossible to confirm and complete SIP call setup in such an arrangement.

One solution is RTP media proxy. Since RTP media proxy only reflects (routes) packets unmodified, it can be safely used with peer-to-peer secure connections. For NAT transversal, one would only need to port forward a block of RTP ports to the media proxy.

SIP Witch offers potential to support an integrated RTP media proxy supported through the core library and a plugin. This plugin and feature is not yet complete, however. What is complete is the ability to "classify" calls based on how the source and destinations appear, that is whether they are on the same subnet, different subnets, or remote and local. The RTP media engine is built into libsipwitch itself, and is intended to be programmed for different packet forward scenarios as needed, as well as to allocate and release RTP proxy ports based on demand. It does not yet however support the rewriting of SDP, and SDP rerwrite code has to be integrated into call state code and passed through a plugin. This means there is still some complicated work remaining to make RTP media proxying work as intended and this blueprint simply qualifies an outline of the problem. The reason for the use of an additional plugin was to allow different scenarios, such as media proxying for a service provider vs that of peer endpoints, which may involve other requirements since most providers do not for example support re-invites.