It seems that for some readers I was too little technical on this subject in the past, so let me address that, particularly for transparency and feature richness.
First of all, what is it exactly lack of transparency, and why is it bad? In the Internet context, transparency means the network is guaranteed not to interfere with traffic between end devices. Transparency therefore affords innovation because new features will not be impaired by unexpected network behavior. More can be found in several RFCs, namely rfc4924 and rfc2775. Similarly in the SIP context, the network represented by SIP servers, is transparent if the servers interfere only little with traffic.
Behavior of a SIP proxy server is strictly governed by RFC3261: A compliant SIP proxy server only modifies few header-fields to mark the SIP message path (Via, Record-Route, Route) and that’s it. In the field, such a hard constraint turned out to be impractical particularly due to NAT traversal. In many cases, SIP traffic from behind NATs advertises un-routable addresses (affected message parts: SDP payload, Contact header field). Then “pragmatic” proxy server implementations choose to give up on strict compliance and change the un-routable addresses to routable ones.
The key difference in a B2BUA is that rewriting SIP traffic is not an exception, it is a rule. SIP proxy servers are bound to keep messages unaltered and implementations only divert from compliance when necessary. In contrast to that, a B2BUA is not bound to keep traffic unaltered by any standard. In fact, many B2BUA implementations are built upon the concept that altering as much as possible is a feature. Some apparently suspect this is sort of academic concern — well it is definitely not. Here is a very real-world implication of B2BUA: you simply cannot troubleshoot traffic. If a request is changed, while visiting a B2BUA, it is very hard to correlate incoming traffic to outgoing. Even if — in absence of unique call id — you try to correlate by phone numbers, there are numbers to which so many calls are routed that you will get lost in tons of traffic.
Similarly the argument that B2BUA produces features is fairly broken as it in fact tends to break them. A good example is the attempt to standardize reverse verification of incoming calls as a practice. The idea has been fairly simple: when a call is coming in and before your phone begins to ring, you ask the originating end devices if the call is genuine. The argument from B2BUA vendors has been you cannot do this because B2BUA’s way of mangling traffic will remove a valid reference between the original call and the verification request.
Shortly, B2BUA does aggressive changes to SIP traffic, and these changes have negative impact both on operational life and introduction of new features.
Some argue too that B2BUA creates new features. That may sometimes be the case, even though not always, see the reverse verification example. Less vaguely this is the case when nature of a feature requires an automaton to alter existing calls. The most frequent case I am aware of is network-terminated calls either on exhaustion of prepaid calling card credit or dead end-devices.
Keeping call information does not come for free though: it increases memory consumption and effort to replicate data to offer reliability.
This may sound too uninteresting in the age of cheap gigabytes of memory, however in high-density deployments that utilize servers’ memory to full extent it means buying more equipment, and being less “green”.
What I can therefore recommend is to use “pragmatic” proxy servers for better scalability and fewer side-effects unless you need to terminate calls from inside SIP-networks. It may be accommodating to find that some vendors offer servers that offer both “passive” proxy mode and active call-state approach, which gives you the possibility to change your operational mode if your network’s requirement change.
